ARIA roles and states and MSAA events exposed via MSAA by browsers on Windows - IE 8, Firefox 3, Opera 10, Chrome 5, and Safari 5

Author: Phil Richards
Contact: phrichards@gmail.com

Roles & Inspect 32

These tests are updates of those performed by Steve Faulkner, detailed at The Paciello Group Blog. As all five of the browsers tested by Steve have been updated since those tests were performed, these tests were conducted with the latest version of each browser, specifically:

• Internet Explorer 8.0.6
• Firefox 3.6.3
• Opera 10.53
• Chrome 5.0.375.55
• Safari 5.0

Test methodology for ARIA roles exposed by MSAA was identical to the methodology used in Steve's tests, and the expected MSAA roles presented here are taken from Steve's tests. The Inspect 32 software used to conduct these tests is available here.

The updated summary is as follows:

WAI-ARIA has 59 possible role values (excluding abstract roles):

• IE 8.0.6 exposes 40 role values via MSAA
• Firefox 3.6.3 exposes 45 role values via MSAA
• Opera 10.53 exposes 22 role values via MSAA
• Chrome exposes 4 role values via MSAA
• Safari 5.0 exposes 4 role values via MSAA

The current versions of IE, Firefox, and Safari perform slightly poorer than the versions used in Steve's tests, while Opera and Chrome perform slightly better. There are no dramatic changes in performance for any browser.

Roles & Accessibility Probe

These tests are identical to those performed with Inspect 32, but here Accessibility Probe is used to confirm the results displayed by Inspect 32. Accessibility Probe is available here. According to Accessibility Probe:

• IE 8.0.6 exposes 40 role values via MSAA
• Firefox 3.6.3 exposes 45 role values via MSAA
• Opera 10.53 exposes 22 role values via MSAA
• Chrome exposes 0 role values via MSAA
• Safari 5.0 exposes 4 role values via MSAA

The only difference here is Chrome, but as the reported role for every case in Chrome is "grouping", this is likely due to an incompatibility of the Chrome browser with Accessibility Probe. Otherwise, the reported roles in Accessibility Probe confirm those displayed by Inspect 32.

States & Inspect 32

I was unable to find published tests of the reported ARIA states for specific broswers or a list of expected states. For these tests, I considered a reported state to be correct if the name of the state was displayed by Inspect 32 in at least one of the test item's possible states. For example, the "aria-checked" state test item could be either checked or unchecked; while checked, Inspect 32 reports the state as "checked, marqueed, focusable" so the reported state is considered correct even though the unchecked item does not specifically report that it is not checked. This decision was made because no browser reported both positive and negative states of a particular test item, with the exception of the expanded/collapsed state. In all other cases, only the positive (checked, pressed, selected) state was reported as such.

Test examples were taken from the Illinois Center for Information Technology and Web Accessibility and the Codetalks wiki.

Methodology:

• Test examples for "aria-checked", "aria-expanded", "aria-pressed", and "aria-selected" are listed at the above links.
• Each example provides keyboard shortcuts to navigate the page. With Inspect 32 running, use the keyboard to navigate through the example. Inspect 32 will display the state of the test item, though after changing a test item (checking or unchecking a box, for example), focused must be moved to a different test item and then moved back to the original item, generally by using tab/shift-tab or the arrow keys, for Inspect 32 to display the new state.
• Keyboard shortcuts work for all browsers except Internet Explorer. The mouse can be used in IE to select test items, and Inspect 32 will display the current state of those items, but IE will not allow the state to be changed with the mouse. A checked box cannot be unchecked, for example.
• Firefox and IE will display the state of a button or checkbox if the cursor is hovered over the item, but the other browsers will not.

Note:

• No test example is provided for "aria-busy". Examples are given for "aria-disabled", "aria-hidden", and "aria-invalid", but I was unable to determine how these examples were to be used to test these states. Inspect 32 does not display any of these states for the given examples. As well, Internet Explorer does not render the "aria-selected" example correctly, so this state could not be tested in IE.

Of the five states that were tested ("aria-checked", "aria-expanded", "aria-grabbed", "aria-pressed", and "aria-selected"), the summary is as follows:

• IE 8.0.6 exposes 3 state values via MSAA
• Firefox 3.6.3 exposes 4 state values via MSAA
• Opera 10.53 exposes 0 state values via MSAA
• Chrome exposes 2 state values via MSAA
• Safari 5.0 exposes 3 state values via MSAA

Events & AccEvent

Similarly to states, I was unable to find published tests of the reported MSAA events fired for ARIA states. For these tests, I matched ARIA states with MSAA events as presented in the W3C's WAI-ARIA User Agent Implementation Guide, and used the ARIA state examples from the Illinois Center for Information Technology and Web Accessibility and the Codetalks wiki along with AccEvent software to monitor the events fired for each change of ARIA state. The AccEvent software used to conduct these tests available here.

Methodology:

• By default AccEvent lists far more events than those that are being tested here; to limit the displayed events only to those associated with the ARIA states being tested, go to AccEvent's Options>Settings menu and choose only OBJ_HIDE, OBJ_SHOW, OBJ_SELECTION, and OBJ_STATECHANGE from the Events menu.
• Examples for all states except "aria-hidden" are taken from the Illinois Center for Information Technology and Web Accessibility. The keyboard or mouse can be used for these examples.
• The test example for "aria-hidden" is taken from the Codetalks wiki. In this case, the mouse must be used to hover over the link provided in the example.
• When the state of a test item is changed, AccEvent will display the event that is fired when that state change occurs.

Note:

• None of the test examples work correctly on Internet Explorer, so these events could not be tested in IE. IE differs from Opera, Chrome, and Safari, for which I've listed no reported events, in that the latter three browsers will allow the states of the test items to be changed but will not display any associated events in AccEvent, while IE will not allow the states of the test items to be changed at all.
• I was unable to find test examples for "aria-disabled" and "aria-readonly", so these states were not tested.
• These tests are only for MSAA events. IAccessible 2 and UIA events were not tested.
• The W3C lists other events, including MSAA, IA2, and UIA, that are associated with document and node visibility changes, selection, and menus, but these events were not tested. Only events that are matched with ARIA states or properties are included in this document.

Of the four state-event pairs that were tested ("aria-checked", "aria-expanded", "aria-grabbed", and "aria-hidden"), the summary is as follows:

• IE 8.0.6 exposes 0 event values via MSAA
• Firefox 3.6.3 exposes 2 event values via MSAA
• Opera 10.53 exposes 0 event values via MSAA
• Chrome exposes 0 event values via MSAA
• Safari 5.0 exposes 0 event values via MSAA