WAI-ARIA role support – How the browsers stack up
For the roles defined in WAI-ARIA it is expected that browsers expose the role values via an accessibility API, on the Windows platform the information is usually exposed using the Microsoft Active Accessibility (MSAA) Application Programming Interface (API). Use of an Accessibility API such as MSAA means that Assistive Technology can access the role information ARIA provides employing the same methods they use to access role information of native HTML and desktop controls.
Therefore an important piece of the ARIA support puzzle is the support browsers have for exposing ARIA roles using the MSAA API.
The study ARIA roles exposed via MSAA by browsers on Windows provides test of the major browsers available for windows.
WAI-ARIA has 59 possible role values (excluding abstract roles):
- IE 8RC1 exposes 42 role values via MSAA
- Firefox (Minefield) 3.2a1pre exposes 49 role values via MSAA
- Opera 10 Alpha exposes 21 role values via MSAA
- Safari 4 Beta exposes 8 role values via MSAA
- Chrome exposes 0 role values via MSAA
For roles with an “Expected MSAA Role” value of “none” an incorrect or no role does not necessarily indicate that the ARIA role information is not available to Assistive Technology.
- These ARIA roles do not have direct mapping with MSAA roles, but may be made available to assistive technology via the UIAutomation (UIA) API or the IAccessible2 (IA2). From preliminary testing using UISpy for UIA and Accprobe for IA2, it was found that none of the ARIA roles without a corresponding MSAA role were exposed via either UIAutomation or IAccessible2.
- In the case of the ARIA Landmark roles for example, the JAWS screen reader supports them, although they are not exposed using an accessibility API. It is surmised that JAWS picks them up from the browsers HTML DOM.