W3C logoWeb Accessibility Initiative (WAI) logo

WAI: Strategies, guidelines, resources to make the Web accessible to people with disabilities

[EARLY ROUGH DRAFT] WAI-ARIA FAQ's

Page Contents

This page was adapted from content originally presented on the ARIA pages of the Mozilla Foundation

Note: This document is a draft and should not be referenced or quoted under any circumstances.

1. FAQ: ARIA in HTML

This document should help HTML developers understand ARIA, its purpose, and how it relates to HTML and HTML development.

Back to Top

2. What is ARIA and how does it allow for accessible JavaScript widgets?

Accessibility should not hold web authors back from innovating. Several basic Javascript widgets are well-known and commonly used and yet conspicuously missing from HTML 4 today. Accessibility need not lag behind such innovations. The problem is not that JavaScript is bad for accessibility, as some have claimed, but that there is no mechanism to describe what the script is visually portraying to a user. ARIA seeks to make accessibility possible for such JavaScript widgets.

ARIA provides authors with the following:

Using ARIA to develop accessible widgets can be complex. However, supporting ARIA is no harder than developing cross-browser widgets with JavaScript in the first place.

Back to Top

3. What is the use case for ARIA?

  1. A web developer or team has developed one or more JavaScript widgets, and needs to make the widget accessible because accessibility is part of a project's requirements, which uses those widgets. The author must use the ARIA properties to provide the basic type, state and changes of their JavaScript widgets to screen readers and other assistive technologies. The author utilizes the available documentation and examples on the web, and tests the results with free assistive technologies or test tools. When the author needs help they sign up for the wai-xtech mailing list and ask there.
  2. A web developer is using widgets from a JavaScript toolkit, and needs their web application to be accessible. The toolkit already has ARIA support built in. The author can just use the accessible JavaScript toolkit without understanding ARIA.

JavaScript is how industry is developing compelling Web 2.0 applications today, and these applications need to be made accessible today. ARIA provides a mechanism for describing the JavaScript widgets.

Back to Top

4. Is ARIA available now?

Yes, ARIA is available in Firefox 1.5 and above, and Opera has begun to add support to the Opera browser (9.5 and above). Microsoft has joined the standardization team, but no announcements have been made in terms of support.

IE, Opera and Firefox all support the expanded tabindex feature, so whether you use that or you use activedescendant and style the focus yourself, the widgets will be keyboard accessible in every major browser except Safari. Feel free to help Apple fix Safari's tabindex for accessible web apps bug -- they need it for HTML 5 support as well.

In any case, users have access to at least one free web browser on multiple platforms which make widgetized and dynamically updated web pages accessible. Therefore, ARIA can be used to make accessible web applications today.

Back to Top

5. What is the relationship between ARIA and Desktop Accessibility APIs?

Desktop accessibility APIs were invented because developers just won't stop developing their own widgets, often even when perfectly good versions of those widgets exist. An accessibility API allows communication with assistive technologies about what meaning is behind the widgets' visual presentation and visual changes.

It is standard for environments to provide an accessibility API, which allows developers to enable full accessibility even when authors don't use the pre-canned widgets. The reality is that developers often don't want to use pre-canned widgets. For whatever reason, they design their own. The web is no different.

The first desktop accessibility API was Microsoft Active Accessibility (MSAA), which was provided for Windows developers. This was followed by Java Accessibility, Gnome's ATK/AT-SPI, Apple's Universal Access, Microsoft's UI Automation and the Linux Foundation's IAccessible2. These APIs fill an important niche for the accessibility of any environment.

ARIA is designed to map to all of these. All the information a developer codes in ARIA is mapped by Firefox through an accessibility API that is understood by an assistive technology. In fact although ARIA is markup-based it can really be considered an Accessibility API in its own right. It is a mechanism for communicating the basic type, properties and changes of author-built widgets to assistive technologies.

Back to Top

6. Is ARIA too complex for web authors to get right?

ARIA is not any more complex than developing cross-browser, custom JavaScript widgets. That is not a small undertaking, and not a task for the average web developer. Yes, ARIA support adds another layer of complexity. However, even without ARIA many authors will be running JavaScript toolkits with powerful pre-built widgets. ARIA support should be, and is being added to these toolkits, which authors can then reuse.

While it is not extremely likely for an individual author to use ARIA directly, it is reasonable to expect that an array of organizations will need to make their web applications accessible. Individual web authors can benefit from ARIA integration in any open source JavaScript toolkits that these organizations build, just as they already benefit from the debugged cross-browser support in these toolkits.

In addition, testing tools are being developed as are examples and "best practices" documents, to guide web authors that wish to use ARIA.

Back to Top

7. Does ARIA break web pages on current browsers?

No, ARIA role and property information only affects how the page interacts with assistive technologies -- it does not affect how mainstream users interact with the page. It also does not affect how the page works on legacy browsers at all. It only changes accessibility for inaccessible widgets and web pages.

Back to Top

8. Does ARIA need implementation in all popular browsers?

No, because the ARIA enabled widgets simply will work as they currently do in those browsers. The ARIA enabled widgets will work for sighted mouse users, etc., but won't be accessible on those browsers. That's not really a loss, since they already aren't accessible there. So there is basically no effect except the positive one for users with disabilities using modern software.

This is very key because ARIA can be used now. There is no guarantee that any well-meaning new web technologies will be implemented by all browser manufacturers. This is what has stopped the web from moving forward in the past. There is no such issue with ARIA.

Back to Top

9. Who supports ARIA?

This much is public information:

Back to Top

10. Why are so many organizations prioritizing ARIA?

Vendors are prioritizing ARIA, largely in response to major content developers wanting to use it to improve accessibility now, because they cannot wait for HTML 5 to be ubiquitous. Yes, it will be good for accessibility if HTML 5 eventually is in fact ubiquitous, but it's not yet clear when that will happen.

Back to Top

11. Isn't ARIA expensive to implement in browsers? Does it double the amount of widget code?

No, ARIA is not expensive to implement. In fact it is significantly easier to implement in a browser than implementing HTML 5 widgets.

First, it lines up nicely with how accessibility APIs work. It's mostly a matter of adding a table of role and properties to API support. Second, unlike natural widgets, it does not require code to be added to the core browser -- only to the module that implements accessibility proxy objects. The accessibility module simply passes the roles, states and state changes on through the APIs they already support, and this can be done on the base accessibility object class. The entire Firefox implementation of ARIA was essentially coded by one person, in addition to much other accessibility work. Documentation on mapping ARIA to desktop accessibility APIs has provided to assist other developers of other browsers.

Most of the code for the Firefox ARIA implementation is as follows:

  1. A table mapping ARIA roles and states to API roles and states
  2. A set of IAccessible2/AT-SPI object properties that exactly match ARIA attributes, (where there was no other way to expose that in the accessibility APIs)
  3. Code to support ARIA accessible relations, which is already needed for things like <label for>
  4. Code to handle attribute changes and map them to state changes
  5. Code to fire special MSAA menu events based on menus becoming visible or menu items becoming active
  6. A few additional special case rules here and there

ARIA is very simple to implement, because the real implementation work is done by JavaScript author to develop these widgets.

Back to Top

12. Is there a JavaScript toolkit which provides ARIA support for free?

Authors want both cross-browser compatibility and accessibility for free -- via easy-to-use, pre-built widgets. They may not care whether the underlying technology is HTML 5 or via JavaScript. Authors do care that it's fast and is compatible with the majority of web browsers in use at that moment.

A number of JavaScript toolkits, such as Dojo, GWT, YUI and Scriptaculous, are quickly evolving powerful sets of widgets. Most of the leaders seem to be both free (cost) as well as free (source code license).

JavaScript toolkits integrating ARIA will make the technology practical for individual authors. By using popular toolkits, developers will be able to get any keyboard and assistive technology support already built-in. This is already happening: for example, the Dojo toolkit already has significant amounts of ARIA support.

Dojo 1.0 is slated to ship in the 4th quarter of 2007 and have accessibility built into the core widget set.

Back to Top

13. What are basic custom widgets and how are they supported by ARIA?

Basic custom widgets are variations on a standard widget -- something close enough to a familiar widget so that it is possible to just reuse the roles and properties we already have. This actually is the most common case, because most widgets basically come down to allowing input of a basic simple data type. Most widgets allow the user to toggle or cycle through a set of choices, choose from a list of choices, enter a free-form value, traverse a grid, or perform one of the basic functions provided by the ARIA 1.0 roles and properties.

These widgets can be made accessible with ARIA 1.0. If an author wants circular menus, and can only do that today with JavaScript -- then no problem, they can develop a circular menu library complete with ARIA support, and it can be accessible. The author should use the same keyboard user interface that a normal menu has -- allow the user to arrow through and activate a menu item with Enter. Another example would be an interactive month-view in a calendar, which could just use the ARIA role of grid.

Back to Top

14. What are advanced custom widgets?

Truly new widgets can usually be said to extend some previous type of widget. It's fairly rare that a new widget has developed a completely new concept. However, sometimes there may be a type of widget that is just not yet addressed in ARIA 1.0 at all, such as interactive diagrams (this is slated to be dealt with in ARIA 2.0).

Making radically new widgets accessible is not yet addressed by ARIA 1.0.

Back to Top

15. Will ARIA be necessary in the long term? Or can it be deprecated eventually?

It would be great if ARIA could eventually be supplanted by a clean solution utilizing HTML 5 and other relevant specs such as XBL. However, it is likely that ARIA support will be necessary for some time. If and when HTML 5+ and XBL are ubiquitous and JavaScript websites and toolkits move to that, then eventually ARIA can be deprecated. It could be a very long wait, but it's possible. After all, there are HTML elements such as <isindex> which are truly going away.

If XBL does not become ubiquitous, then we will continue to need ARIA, because JavaScript widget development will never be completely supplanted by built-in widgets. No toolkit is ever complete enough for innovative developers. There will always be a need to surpass the current state-of-the art by developing new widgets, thus there will always be a need to be able to express accessibility for those innovations. In fact there will continue to be a mutually beneficial coevolution between JavaScript usage and new HTML elements that provide those capabilities in ready-to-eat form.

Back to Top

16. Can ARIA be used with other kinds of markup?

Yes, ARIA can be used with SVG or XUL, for example. It could even be used to enable accessible interaction with "special knowledge domain" markup languages, such as CellML, a markup language designed to express cellular structures.

Back to Top

17. What's the state of ARIA standardization?

Inside the W3C's Web Accessibility Initiative is the Protocols and Formats Working Group (PFWG). This group has largely been focusing on what they call the Dynamic Web Content Accessibility Work roadmap, which is both an effort to define the basic roles and properties needed for ARIA.

The PF aims to have finalized working drafts by mid-October, in time for the next W3C plenary.

Back to Top

18. The checkboxtristate or fill-in-the-blank feature of ARIA stinks! Can it be changed?

Yes, we're open to suggestions and can make changes, but please make those suggestions soon. We already have implementations out there which use ARIA. But by all means, if something is awful there's a good chance we can change it (or already have in an unreleased working draft).

Back to Top

19. Where can I learn more about ARIA?

Here are some useful links:

Back to Top

20. Where can I ask questions about ARIA?

The WAI-XTech list is where anyone interested in ARIA may discuss technical issues.

To subscribe to the WAI-XTech list, please follow the instructions in Participation in the Protocols and Formats Working Group.

Back to Top