Web 2.0 Accessibility with WAI-ARIA FAQ

From CodeTalks

This document should answer common questions around Web 2.0 accessibility. The primary focus is assisting HTML developers in understanding ARIA, its purpose, and how it relates to HTML and HTML development.

What is the legacy of Web 1.0 and 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.

Web 1.0 was about static content requested page by page. Original web accessibility guidelines were written to support this model. Web 2.0 involves building much more complicated user interfaces that load information dynamically from disparate information sources. A new accessibility framework is necessary to provide access to the rich set of information being exposed in Web 2.0.

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.

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

Can HTML 5 provide an accessible alternative?

Eventually, once HTML 5 is available on most browsers, authors will be able to use many new widget types and semantic structures that will provide new functionality for everyone. 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 will not be widely supported in browsers for many years.

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.

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.

Is ARIA available now?

Yes, almost full ARIA support is available in Firefox 3. IE, Opera, and WebKit are all adding support to upcoming releases.

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.

What is the relationship between ARIA and Desktop Accessibility APIs?

Desktop accessibility APIs were invented to allow developers to provide accessibility support when developing custom widgets. 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 AX APIs, 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 the browser 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.

What does ARIA markup look like?

ARIA markup is basically the same no matter what kind of content you use it with. It does not matter whether you use HTML, XHTML, SVG or XUL.

Here's a quick sample:

<span tabindex="0" role="checkbox"
      aria-checked="true"
      onkeydown="return checkBoxEvent(event);"
      onclick="return checkBoxEvent(event);">
  Any checkbox label
</span>

The above checkbox is custom built, but acts just like a normal checkbox as far as assistive technologies and the user are concerned. It can have any visual appearance the author wishes to code via CSS. Here is a breakdown of the attributes:

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.

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.

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.

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.

What about validation?

A lot of people feel that validation is required, especially for accessibility.

Here is a useful answer from Henri Sivonen (including a link to the Validator.nu prototype with WAI-ARIA support):

First, getting new features is much more important than validating against a legacy validation target. ARIA adds markup, so ARIA can’t validate against a legacy validation target such as XHTML 1.0 (without retroactively changing what XHTML 1.0 is).

One could define a new validation target like “XHTML 1.0 plus ARIA” or “HTML 4.01 plus ARIA”. However, XHTML 1.0 and HTML 4.01 themselves are being replaced by HTML 5 and the expectation is that ARIA will be included in HTML5 as ARIA matures, so I’ve opted to prototype an “HTML 5 plus ARIA” validation target instead in Validator.nu. (Please note that the prototype is based on an older draft of ARIA and takes some liberties with it. The liberties taken or the way HTML 5 and ARIA are integrated in the prototype aren’t endorsed by any spec at this time.) [ Note: this is true as of September 12, 2008, please check latest release notes ].

Also, the normative validation formalism for XHTML 1.0 is DTDs. DTDs are woefully inadequate to capture the kind of interdependencies ARIA places on attributes. While it would be feasible to punch holes in a DTD to let ARIA through, DTDs don’t work for detailed ARIA validation. HTML 5 validation requires more advanced technology than DTDs to begin with, which also makes it more natural to prototype ARIA validation in the context of an HTML 5 validation.

But wait, you say, WCAG 1.0 has a priority two checkpoint which says: “3.2 Create documents that validate to published formal grammars.” Right? Well, accessibility is really more important than validation, and for this reason WCAG 2.0 has left this requirement out.

In other words, the accessibility of the web needs to move forward, validation or not. In addition, current validation tools such as DTDs can't handle the complexity of WAI-ARIA with HTML. If you are interested in validating WAI-ARIA, please try Validator.nu and provide feedback.

Who is involved with WAI-ARIA?

An updated list is maintained in the Who_Supports_WAI-ARIA document.

How is ARIA implemented in a browser?

ARIA lines up nicely with how accessibility APIs work. It's mostly a matter of adding a table of role and properties to API support. Unlike natural widgets, ARIA 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. Browser vendors are collaborating on the specific details of how ARIA is mapped to accessibility APIs.

What JavaScript toolkits provide ARIA support for free?

Authors want both cross-browser compatibility and accessibility for free -- via easy-to-use, pre-built widgets.

A number of JavaScript toolkits are quickly evolving powerful sets of widgets:

• Dojo: ARIA support is mature
• YUI: ARIA support growing rapidly
• GWT: ARIA support growing rapidly
• Jquery: ARIA support in beginning stages

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.

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.

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

The current plan is for ARIA to enable custom widgets. However, this is slated for a future version of ARIA. If you're interested in helping to shape the development of this part of the ARIA standard, please take a look at the JSON ARIA proposal.

Alternatively, if XBL becomes ubiquitous on the web, it would clearly be the natural approach. However, it is unlikely that XBL will be adopted by all browsers in any reasonable time frame.

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 newer technologies. However, it is likely that ARIA support will be necessary for some time. Even as newer versions of HTML provide new capabilities, ARIA will still be necessary for sustom widgets.

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.

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

Yes, the PFWG is 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).

Please use the wai-xtech mailing list (described below) to provide feedback.

Where do ARIA discussions happen?

• Wai-xtech mailing list -- holds discussions on ARIA specs. This is an official W3C mailing list. People who want to join should email the PFWG Chair and request subscription. Some people have had trouble signing up. If you have problems , try the truly open Free-ARIA list.
• Free-ARIA mailing list -- for developers and users of free tools and resources (such as this website) occurs on the Free ARIA mailing list.
• WAI-ARIA channel on IRC -- for anyone who wants to chat about WAI-ARIA. Point your IRC client to irc.w3.org:6665 with the channel #wai-aria.