Skip to main content

Visit Mozilla.org

ARIA: Accessible Rich Internet Applications/Relationship to HTML FAQ

From MDC

Contents

[edit] FAQ: ARIA in HTML

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

[edit] What is the legacy of HTML 4 that developers seek to advance beyond?

HTML 4 provided us with a fairly stable set of form controls and widgets. However, the basic set of widgets have been around for a while, and one could argue they've become passe. Both users and authors are attracted to technology that is new, exciting and different. One can even add excitement to a page just by adding well-known widgets from the desktop world, such as menus, spreadsheets, sliders, progress meters, tab panels and tree views. These widgets have inexplicably been left out of HTML 4, and web authors not only want to use them in their web applications, they also want to innovate beyond them.

[edit] What are JavaScript widgets?

JavaScript widgets are developed by listening to mouse movements and clicks, and calling script methods that change the appearance and content of HTML elements on a web page. The author uses either plain HTML elements, such as div, span and img, which do not have a rich meaning of their own, or reuses an element (such as <input type="image">) for a different meaning. A sighted user understands the author's intended meaning from its appearance, and from changes to the appearance that occur during interactions. For example, a background color change when a mouse is over the element often indicates that an action will be performed when the mouse button is pressed. Perhaps the mouse click will make another HTML element display that has the appearance of a menu. Such techniques can be combined to simulate the look and feel of desktop widgets and applications.

[edit] Why are Javascript widgets a problem?

Unfortunately two major issues typically make both of JavaScript widgets inaccessible to users with disabilities:

  1. Keyboard navigation is usually left out, and
  2. Assistive technologies don't have enough information to map the widgets to a text interface (such as Braille or speech output).

[edit] Can HTML 5 provide an accessible alternative?

The HTML 5 standardization effort at W3C seeks to add new features -- additional elements, attributes, interfaces, etc. that provide authors with a more complete set of widgets and the ability to better describe web page structures such as sections. Eventually, once HTML 5 is available on most browsers, authors will be able to use many new widget elements and descriptive structures that will provide new functionality for mouse and keyboard users, as well as accessibility for users of assistive technologies such as screen readers, screen magnifiers, voice input software and on-screen keyboards. Because authors will have a larger set of ready-to-use widgets, there will be less need for authors to develop their own.

However, HTML 5 is not available yet, although some new elements from it are being implemented in browsers now. There is no clear date when it will be usable for authors.

The accessibility issue cannot wait for HTML 5 to be finalized, let alone widely deployed, as the entire industry is jumping on the "Web 2.0" bandwagon today, using inaccessible JavaScript widgets.

[edit] How long before HTML 5 is ready?

No one knows, but if the web's migration to CSS 2 is used as an predictor, it could be 5-9 years before HTML 5 is ubiquitous, and there is unfortunately not even a guarantee that it ever will be.

[edit] What is ARIA and how does it enable accessible JavaScript widgets today?

ARIA enables accessibility in JavaScript widgets.

ARIA provides authors with the following:

  • roles which describe what type of widget an element is portraying, such as "menu", "treeitem", "sliders" or "progressmeter" -- elements which do not exist in HTML 4.01 but which authors really need for web applications.
  • roles that can describe the structure of a web page
  • properties which describe the state widgets are in, such as valuenow="50%", required="true", expanded="true" etc.
  • properties which define live regions of a page that are likely to get updates (such as stock quotes), as well as an interruption policy for those updates
  • properties describing drag sources and drop targets
  • a way to provide keyboard navigation for JavaScript widgets in HTML -- this is basically the same as IE's extensions to tabindex which have been around since IE 5, which means the technique works to make key navigable widgets in IE. In addition, these tabindex changes have been part of the HTML 5 specification for quite a while. Setting tabindex="0" allows something like a div-based slider to be added to the tab order, while tabindex="-1" allows something to be focusable by click or script even though it's not in the tab order (such as tree items or spreadsheet cells). Using this combination of tabindex values allows for the development of complex container widgets with single or multi directional navigation within the descendants. In addition, an alternative method exists for developing container keyboard navigation patterns: the activedescendant=[id] property allows a focused container to specify which descendant currently has focus. This makes fully accessible keyboard navigation easier to implement, especially for widgets that have already been designed to simulate focus with CSS (such as the Gmail email header list).

With ARIA, accessibility need not lag behind the innovations of Javascript. It was never really true that JavaScript is bad for accessibility, as some have claimed. Previously there was simply no mechanism to describe what the Javascript code is visually portraying to users.

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.

[edit] 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.

[edit] 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, WebKit, 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.

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.

[edit] What is the relationship between HTML 5 and ARIA?

Simply put: they both enable new features for web authors -- in an accessible way.

HTML 5 will be a great solution when it's available across the board. However, HTML 5 will not be completely available for common usage for many years.

ARIA enhances the use of JavaScript, which is already available. New, interesting widgets can be developed today using HTML 4.01 and JavaScript -- and ARIA can already be used to describe accessibility for those widgets.

Eventually HTML 5 will build in many of the most common use cases for ARIA -- such as progress meters, directly into easy-to-use elements. HTML 5 will ultimately make common things much easier to do. However, the need for ARIA goes beyond the time that HTML 5 becomes a reality for authors. ARIA will be necessary for at least as long as authors want to develop their own widgets, until there is a ubiquitous cross-browser way to develop widgets (such as XBL).

[edit] 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.

[edit] Does ARIA require the use of namespaces, which are not available in text/html?

No. Starting in Firefox 3, namespaces are in fact no longer used for ARIA markup, which is a fortunate because namespaces are not allowed in text/html. It is recommended that all developers using ARIA target Firefox 3.

It now no longer matters whether you use HTML, XHTML, SVG or XUL. Firefox will process the new non-namespaced markup the same way on anything it renders. You can use ARIA markup declaratively and set it dynamically the same way, regardless of the content type. For those who dealt with ARIA in the beginning, this is a drastic improvement.

You can now do things like: <span role="checkbox" aria-checked="true">My checkbox</span>

[edit] 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.

[edit] Will ARIA be mostly underused or misused because it is a complex accessibility-only solution?

Problem: Accessibility-only solutions are often not used correctly, and authors often ignore the solutions if they do not provide a mainstream benefit. For example, longdesc is often not used and authors are not always clear what to use it for. However, the label attribute provides both an accessibility benefit of associating a readable name with a control, as well as a mainstream benefit by enabling a control to be accessed when the label is clicked. Because of this, label is more likely to be used and used correctly.

Under utilization of ARIA is being addressed by the developers of ARIA, who are working directly with open source JavaScript toolkits projects such as Dojo. It often makes sense for the authors of these toolkits, which provide solutions to a number of problems, such as security and cross-browser scripting. Because of this, entire companies and industries are moving forward with applications that use toolkits like Dojo. Authors that utilize toolkits like Dojo with ARIA support can thus get accessibility for free.

Misuse is even less of a problem. Yes, some authors will want to use ARIA directly in their own homegrown widgets. However, web pages that use JavaScript are already so broken for accessibility that ARIA cannot really make them less accessible. And, ARIA won't affect their pages at all in legacy browsers nor for mainstream users in browsers that support ARIA. So web pages are not worse off with ARIA support, even when implemented incorrectly.

[edit] 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.

[edit] 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.

[edit] If HTML 5 is a cleaner solution for advanced widgets, why have ARIA at all?

ARIA is implemented now and ready to be used. ARIA doesn't require the cooperation of the entire industry. Because some free browsers support it, users with disabilities can already have access to the ARIA-enabled widgets and web applications. HTML 5 is not far enough along -- only tiny pieces are currently implemented and there is a huge working group going through the issues. It's likely going to be many years before HTML 5 is ready to take over the job of making accessible web applications.

And again, the reality about developers is that they like to invent their own widgets. So, even with HTML 5, there is a need for ARIA for the enablement of basic custom widgets.

[edit] Who supports ARIA?

This much is public information:

  • W3C PF: standardization effort: Roadmap, Roles and States
  • IBM -- Firefox implementation, Dojo toolkit support, testing tools, supporting standardization effort, test cases and docs. Testing tools being developed and contributed to the Eclipse Foundation. Dojo is being incorporated in numerous IBM products including many under the WebSphere brand.
  • Dojo Foundation in conjunction with the University of Toronto -- the Dojo 1.0 toolkit now has full ARIA support for the core Dojox widget set
  • JQuery Community -- work has begun. Communication happens on the jQuery-a11y google group created by the jQuery leads.
  • The University of Toronto -- they have received a grant which includes supporting ARIA developers in both browsers and toolkits such as JQuery
  • University of Illinois -- test cases, Firefox accessibility extension testing tool, developer training, supporting standardization effort
  • Mozilla Foundation -- grants to developers for ARIA work
  • NV Access -- have a grant to polish Mozilla support in the NVDA screen reader. This will include support for ARIA.
  • Opera -- beginning support in Kestrel (Opera 9.5), supporting standardization effort
  • Sun Microsystems -- Orca screen reader support, contributor to style guide group
  • Freedom Scientific -- JAWS screen reader support
  • GW Micro -- Window-Eyes screen reader support
  • AI Squared -- ZoomText screen magnifier support
  • CLC World -- Fire Vox screen reader extension implementation of ARIA widgets and live regions, live region test cases, live region report and recommendations
  • Google -- ARIA support in Google Reader and experimental support in Google Notebook. Developing the AxsJAX framework which can "inject accessibility enhancements into existing Web 2.0 applications using any of several standard Web techniques.". Google Web Toolkit (GWT) has ARIA support -- at this time it is unknown how solid the support is.
  • Paciello Group -- developing support in some pages, assisting with Best Practices document, articles, such as WAI-ARIA in HTML and WAI-ARIA live regions
  • Yahoo! -- presentations to accessibility community, working on ARIA examples
  • Adobe -- Adobe is working to add WAI-ARIA support to the Spry Framework for Ajax which will add support for Dreamweaver in the future.
  • AOL -- work on style guide and best practices
  • SAP -- developing support in SAP applications, supporting standardization effort
  • Microsoft -- supporting standardization effort, IE 5+ supports ARIA keyboard navigation (via the same tabindex extensions contained in HTML 5). IE 8 (starting with beta 1) will include ARIA support.
  • IWA -- International Webmaster Association, endorses ARIA and will promote it in education and outreach activities
  • The Web Compliance Center of the Fraunhofer Institute for Applied Information Technology FIT -- WebCC supports ARIA by participating in its development within W3C and introducing its requirements in our sets of imergo® Web Compliance tools.
  • Apple -- ARIA implementation for Safari/WebKit has begun. Tabindex work completed.

[edit] 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.

[edit] Will all this effort take away from the needed effort to make HTML 5 accessible?

No, accessibility for HTML 5 will obviously be a top priority for any browsers that wish to have an accessible product. In fact, because ARIA support has pushed forward AT usage of accessibility APIs like IAccessible2 and AT-SPI, it will be easier to make the advanced widgets of HTML 5 accessible. The browsers can simply use the same roles, states and events to get the same support.

[edit] 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.

[edit] How is ARIA practical for authors? Why not wait for HTML 5?

It's unfortunate that so much work rests on the part of JavaScript authors to develop widgets, and that HTML 5 is not yet an option, but that's the reality. It's not clear when HTML 5 will be ubiquitous enough to rely on. There is still much work to be done on the specification itself. How long might HTML 5 take before content developers can fully adopt it? For a historical example, we can look at CSS 2, which took 7 years to become ubiquitous enough for developers to rely on.

However, because JavaScript is already available, developers are using it to develop advanced functionality right now. For authors needing to develop their own advanced widgets now, ARIA is currently the only way to make those accessible. Is it easy? Not necessarily, but there are examples to go from, and work continues on documentation to assist authors.

In the very long term, for most common widgets, natural HTML elements may be easier to use. However, it is likely to take a long time for HTML to catch up with the capabilities of widget toolkits, especially because they are both evolving in parallel. In addition, continued use of JavaScript toolkits remains likely, even many years from now after HTML 5 (or 6!) becomes available. Not merely because of habit, but because web authors love to innovate and experiment -- they want the flexibility of going beyond what is built in. This is the reality of developers -- they don't want to be restricted to pre-canned widgets. This is the same reason Microsoft developed the original Active Accessibility API.

[edit] 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.

[edit] 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.

[edit] 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.

[edit] What is the plan for defining accessibility on advanced custom widgets?

The current plan is for ARIA to enable custom widgets. Currently there are three possibilities for defining widgets on the table:

  1. RDF
  2. XBL
  3. JSON

[edit] RDF Pros

  • Does not require all browser vendors to participate -- only those browsers that wish to support accessibility of truly new author-defined widgets

[edit] RDF Cons

  • Not well-implemented in browsers and admittedly unpopular
  • Does not help the author encapsulate all of their widgets' JavaScript logic in one place
  • Not good at defining new event types or managed properties (properties which require code to be calculated instead of just being declared by the author).

[edit] XBL Pros

  • Allows the definition of an inheritance chain, sub-content, custom properties, localizations for those properties, and custom events
  • Allows encapsulation of widget code, including accessibility information, in one place, essentially developing new HTML elements for that page. The HTML page can simply use the widget like any other HTML tag, e.g. <mychart type="pie">some-data</mychart> This is the ultimate in clean code and reusability.
  • Allows new widgets to inherit behavior from previous widgets
  • Most likely, many more pros can be listed -- XBL is very cool and is where future-facing standards developers are concentrating their efforts

[edit] XBL Cons

  • Requires that all browser developers produce implementations (which need to be mostly compatible). Not all browser vendors have committed to it.
  • Requires that those new browser versions become ubiquitous. Any pages that use XBL will be broken in non-XBL browsers.

[edit] JSON Pros

  • All modern browsers can read JSON
  • AJAX developers are familiar with JSON
  • Easy-to-learn syntax
  • Fast to parse

RDF may stick around for the W3C standards developers to define widgets. However, it does not appear likely to be used within the browser for mapping widgets to accessibility APIs.

XBL is a great long term approach for accessible custom widgets, but it is not a reality yet, and in fact is very far away.

JSON seems to be a great possibility which could be implemented now. Here is a JSON mockup of an ARIA custom widget.

[edit] 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.

[edit] 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.

[edit] 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.

[edit] The 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).

[edit] Where can I learn more about ARIA?

Here are some useful links:

  1. Notes and examples for web authors (from the Firefox accessibility team). Please send feedback to the Mozilla accessibility community.
  2. ARIA Style Guide. A fairly short cheat sheet for web authors. It does not discuss ARIA specifically but makes recommendations for keyboard navigation in JavaScript widgets. Please send feedback to wai-xtech.
  3. ARIA Best Practices for authors. This document is a bit longer, and is also an official W3C document. It discusses how authors should use ARIA. Please send questions and feedback to public-pfwg-comments@w3.org.
  4. ARIA implementors guide. This document is for user agent developers who need to map ARIA from the DOM through an accessibility API or directly to alternative output such as text to speech. Feedback is welcome through the associated wiki talk page.

[edit] Where can I ask questions about ARIA?

Please join us on the #wai-aria channel (irc.w3.org:6665) for public discussions about WAI-ARIA, Members should keep discussion of internal drafts on #pf.

The mailing list for public dicussions is wai-xtech. People who want to participate in wai-xtech should email the PFWG Chair (wai-pf-call@w3.org) to request a subscription.

Retrieved from "http://developer.mozilla.org/en/docs/ARIA:_Accessible_Rich_Internet_Applications/Relationship_to_HTML_FAQ"