WAI-ARIA role support – How the browsers stack up

Posted on Monday, 16 March 2009 by Steve Faulkner

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.

About Steve Faulkner

Steve is the Senior Web Accessibility Consultant and Technical Director, TPG Europe. He joined The Paciello Group in 2006 and was previously a Senior Web Accessibility Consultant at Vision Australia. He is the creator and lead developer of the Web Accessibility Toolbar accessibility testing tool. Steve is a member of several groups, including the W3C HTML Working Group and the W3C Protocols and Formats Working Group. He is an editor of several specifications at the W3C including HTML 5.1, Using WAI-ARIA in HTML and HTML5: Techniques for providing useful text alternatives. He also develops and maintains HTML5accessibility

Comments

  1. 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.

  2. 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

  3. 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).

  4. 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.

  5. 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.

  6. 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.

  7. 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

Comments for this post are closed.

Recent Posts

See all posts in the blog archive

Any time I have a question about Web accessibility, TPG’s Steve Faulkner is the first person I ask. And he’s almost always the only person I need to ask—because I hardly ever come up with a question about Web accessibility that he can’t answer.

Mike[tm]Smith, HTML Activity Lead - W3C (World Wide Web Consortium).