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.
ARIA roles exposed via MSAA by browsers on Windows – Summary
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
Notes:
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.
Comments
Interesting post, and that’s a useful table you have in the linked study. I feel that is an important note at the bottom or this blog. Platform API now has to catch up a bit, but at least IA2 (and of course ATK on Linux) has a catch all way to expose semantics via object attributes.
This is an interesting baseline. I think UIA on IE and IA2 on FF will be the best comparison for those browsers. I know for UIA some control types elimnated the need for additional roles from MSAA
Hi David
>I feel that is an important note at the bottom or this blog
Yes, I am unsure what is the expected method to expose some roles, though it appears that Firefox(for example) exposes some roles using MSAA that are not documented in MSAA (that I could find).
Hi Thomas, I used MSAA as a baseline for IE as the test cases provided by microsoft used it. Will look into UIA and IA2 further, thanks for the advice.
Thanks Steve, the comparision table is really interesting. ARIA support is greater than I was expecting – gives me reason to feel optimistic. The table reports slider is not exposed by Opera and yet I find I can use the sample slider you prepared sometime back successfully with Opera.
anyway when I look at the accessibility of safari itself ARIA is far to be the more important things they need to focus on (same for opera). For UIA you can test with UISpy https://msdn.microsoft.com/en-us/library/ms727247.aspx
Hi roger, I tested Hans’ slider example with inspect32, the slider role is not exposed in Opera 10 alpha. What version of Opera do you have installed?
here you can find the link to download the documentation about aria support in the MSAA and UIA framework (name of the property and so on) https://www.microsoft.com/downloads/details.aspx?familyid=A1FE1066-BF4F-44FC-834B-676B311E83A2&displaylang=en&tm as you can see in the document some ARIA property are expected to work only with the UIA framework
Hi Aurelien, thanks for the pointer to the UIautomation/ARIA mapping doc, it’s a valuable reource! I will update the IE related results to reflect the mappings.
Hi Thomas, Aurelien, I had added some notes in regards to IA2 and UIA to both the post and the testing docs.
Thanks Steve, these posts on WAI-ARIA role support are really helpful. Can’t wait till I can get this stuff to validate.
Steve, today your blog article is one year old! Is there any update on WAI-ARIA support?
The project I’m working on is related to UI automation, so I’m really not interested in exposing every tiny little element of HTML within a web document. All I need to know is, where are the input fields, which input field corresponds to which function, where are the submit buttons, and can I see the URL so I know I’m not automating the wrong webpage. Regardless of the browser, if that page loads, I need to be able to automate it.
Even with such a basic requirement as this, I’m still having to tweak the algorithm to account for the eccentricities of different browsers. For example:
Safari consistently reports editable fields as static text, even when they are clearly editable. Other browsers don’t.
Google Chrome doesn’t expose accLocation for anything and seems unable to tell you where a hyperlink is going to send you, but as long as you remember to use the command line switch –enable-renderer-accessibility to enable AT support you can see some elements.
Opera seems pretty good, but the web page content gets buried in between elements of its own UI if you tree-walk your way through the accessible objects. No other browser is doing this.
Firefox obstinately returns every single DIV element from a web page seperately, and creates a new element every time a word in the static text is formatted differently to the word before. TMI is not a problem except on older machines, where it really hits the performance of the automation tool.
Cheers