WAI-ARIA role support – How the MAC 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 Apple OS X platform the information is exposed using the Mac OS X Accessibility Protocol. Use of an Accessibility API 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 on a MAC OS is the support browsers have for exposing ARIA roles using the The Mac OS X Accessibility Protocol.

The study ARIA role tests on MAC provides tests of the major browsers available for MAC OS X.

ARIA role tests on MAC – Safari 4 beta Firefox 3 (minefield) & Opera 10 Alpha – Summary

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

  • Firefox (Minefield) 3.2a1pre exposes 0 role values correctly via the MAC accessibility API
  • Opera 10 Alpha exposes 14 role values correctly via the MAC accessibility API
  • Safari 4 Beta exposes 15 role values correctly via The MAC accessibility API


The inital motivation for collecting this data was a post by Roger Johansson – Safari 4 public beta with WAI-ARIA support. Or not?, which prompted me to start looking more at how ARIA is supported by Safari on MAC. (thanks Roger!) I was also mindful of the use of such information in general terms for helping to work out which bit of the implementation is broken; Is it my code or the browser or the assistive tech that is not working as it should? Furthermore as part of my work for the W3C Protocols and Formats Working Group, who are responsible for the WAI ARIA specification, I thought this information would be a useful resource.

Yesterday’s post WAI-ARIA role support – How the browsers stack up lead to some unfortunate statements being made about the relative priorities of browser vendors when it comes to accessibility. While I do think when it comes to accessibility and support for WAI ARIA in particular, Mozilla leads the pack and Microsoft is doing good work (some may think suprisingly), all browser vendors are making an effort to support WAI ARIA and in the process improving the general accessibility of their browsers and web content to Assistive Technology.

In regards to Google chrome: I wrote about the Accessibility of Google Chrome when it was first released, which I think was and still is underwhelming, but Jonas Klink from Google has been doing some great work , details of which can be found in the Chrome Accessibility Design and Implementation Roadmap. It would be nice though, to see Google put more resources into Chrome accessibility…

So all in all we are moving in the right direction, while some are moving slower than others, they are still moving.

Categories: Development
Tags: , , ,

About Steve Faulkner

Steve is the Chief Accessibility Officer at TPGi. He joined TPGi in 2006 and was previously a Senior Web Accessibility Consultant at vision australia. Steve is a member of several groups, including the W3C Web Platforms Working Group and the W3C ARIA Working Group. He is an editor of several specifications at the W3C including ARIA in HTML and HTML Accessibility API Mappings 1.0. He also develops and maintains HTML5accessibility and the JAWS bug tracker/standards support.