Web 2.0 applications often have accessibility and usability problems because of the limitations of (X)HTML. The W3C’s standards draft for Accessible Rich Internet Applications (ARIA) addresses those limitations. It provides new ways of communicating meaning, importance, and relationships, and it fills gaps in the (X)HTML specifications and increases usability for all users by enabling navigation models familiar from desktop applications. Best of all, you can start using ARIA right away to enhance the accessibility of your websites.
The extension was first proposed by Richard Schwerdtfeger from IBM, member of the WAI Protocols and Formats Working Group and the HTML Working Group, and Becky Gibson of the WAI WCAG Working Group. Together with Aaron Leventhal they implemented these and other accessibility features in Firefox 1.5-3.0 and various assistive technologies.
All this, of course, is illegal,
said Joe Clark about the proposed extension, and while I totally agree that standards should not be broken and that there are more pressing issues to be resolved, the solution was both pragmatic and timely. In August 2005 IBM contributed a vast amount of code to the Mozilla project to enhance accessibility, and shortly after Clark’s critique, the first W3C working drafts for Roles and States and Properties for Accessible Rich Internet Applications (ARIA) were published. Almost a year later, the role attribute was introduced as a XHTML 1.1 module. Remember, the “X” in “XHTML” stands for “extensible”—more on that later. The proposals were pushed through the W3C procedures at unusual speed and are expected to become recommendations in the second quarter of 2007. It’s awesome how efficient the W3C can be under the right circumstances.
Semantic sugar#section2
In today’s web interfaces, menus and breadcrumb navigation are usually built with list items, and the markup includes different sections for a page’s main content and its sidebar. In Web 2.0 applications, anything can be a button or a control interface (a slider, for example). The accessibility problem is that there’s no way for a screen reader to know about the functionality of those elements. The XHTML role attribute fills the gap by adding some semantic sugar
:
<ul role="navigation"> […] </ul>
This provides a semantic, machine-readable role attribute that a user agent can map to the OS Accessibility API. The attribute semantically identifies the element and can be read by machines and by those humans who venture into the source code. User agents can map the role to an appropriate platform accessibility API, allowing assistive technologies to interpret the element correctly.
Roles come in two flavors: XHTML and WAI‑ARIA. A basic set is defined in the XHTML 1.1 Role Attribute Module. It is extended by the WAI‑ARIA Role RDF taxonomy. WAI‑ARIA roles have the wairole prefix, like in role="wairole:slider".
Roles are further divided into widgets and structural roles. Widget roles include progressbar, slider, button, tree, textfield, checkbox, alert, and dialog. So if you want to use a fancy layer instead of a system dialog box, you can tell screen readers what it is by using role="dialog". More cool widget examples can be found at mozilla.org.
Common structural roles include main, secondary, group, section, liveregion (in which content is changed by AJAX or some other technique), tab, navigation, menubar, toolbar, breadcrumbs, search, or banner.
Added meaning#section3
The role attribute provides information on what the object is. The States and Properties module (ARIA-State) adds meaning about relationships and current states:
<input type="text" name="email" aaa:required="true" />
<div role="wairole:button" aaa:controls="price"> » Change sort order</div> <h2 id="price" aaa:sort="descending">price</h2>
Other states include checked, disabled, expanded, haspopup, invalid, readonly, describedby and labelledby as well as the level of an element in a tree structure, the valuenow, valuemin and valuemax of a slider, and whether or not a menu item is currently the activedescendent.
Where am I?#section4
Assistive technologies need to know what object they are working with and which item has focus. Currently, only links and form elements can have focus. ARIA-State extends common text containing elements with the tabindex attribute, allowing these elements to receive focus either through scripting or via tab navigation.
For example, currently the only way to give focus to a flickr text input is by clicking on it with a mouse. With tabindex="0", it would become keyboard accessible. Moreover, the tabindex value can be negative. Elements with a negative tabindex can receive focus via scripting, but are excluded from tab order. This feature was introduced by Microsoft in Internet Explorer 5.01 and has been implemented in Firefox from version 1.5 on.
As a reminder, here is a table with the values and behavior of tabindex:
| Can get focus | Tab navigable | |
|---|---|---|
no tabindex |
default (only form elements and links) | default |
tabindex="-1" |
yes | no, authors have to program element.focus() in the event of onkeydown for arrow or other keys |
tabindex="0" |
yes | yes, in the order as elements appear in the source code |
positive, e.g. tabindex="100" |
yes | yes, the tabindex specifies the tab order of elements. These elements get focus before any elements with tabindex="0" or without tabindex. |
How to use it#section5
Do we have to wait another ten years until other browsers support these techniques? Actually, no. You can start using roles, states, and properties right away. Currently only Firefox 1.5 or later and three major screen readers (Window Eyes 5.5+, Jaws 7.0+, ZoomText) support them, but the extra attributes won’t hurt other browsers.
While some of the new attributes are already included in XHTML 2, we have to extend XHTML 1.x. There are three ways to bolt them on:
- XML Schema namespaces
- DOM Scripting
- DTD extension
XML schema namespaces#section6
The most common method to extend XHTML is through namespaces. That’s fairly easy:
<html xmlns="http://www.w3.org/1999/xhtml" xmlns:wairole="http://www.w3.org/2005/01/wai-rdf/ » GUIRoleTaxonomy#" xmlns:x2="http://www.w3.org/2002/06/xhtml2" xmlns:aaa="http://www.w3.org/2005/07/aaa">
Firefox 2.0 already recognizes the role attribute, so you don’t need to bring in the role attribute through the XHTML 2 namespace (line 3) for this browser, but you should keep it in for backward compatibility.
Note the misleading historic name for the States and Properties module: here, aaa does not stand for maximum accessibility as defined in the Web Content Accessibility Guidelines, but for “Accessible Adaptable Applications,” later known as “Accessible Rich Internet Applications” (ARIA).
Sadly, the W3C validator throws an error as soon as you start adding namespaces. Why is that? In XHTML 1.0 the xmlns attribute has a fixed datatype and is specified to be http://www.w3.org/1999/xhtml. Period. No exceptions. In XHTML 1.1 it’s supposed to work, but the validator still throws the error.
Advantage: Easy to implement.
Disadvantage: Does not validate as XHTML 1.0.
DOM scripting#section7
HTML 4 does not support namespaces to extend attributes. However, DOM 2 does support namespaces, even in HTML 4, so we can use DOM Scripting to add roles, states, and properties.
In this workaround, role and state information is embedded in the class attribute. IBM has created a well documented JavaScript library to parse the class attribute into namespaced attributes on the element. axs acts as the delimiter, followed by the role and subsequent state-property pairs.
<body> <div id="slider" class="myslider myselector2 axs slider » valuemin-0 valuemax-50 valuenow-33" tabindex="0"></div> <script type="text/javascript" src="enable.js"></script> <script type="text/javascript">initApp();</script> </body>
Advantages: Progressive enhancement; the only way to implement roles and states in HTML 4.
Disadvantages: Works only with JavaScript (7.4 KB); each element can be associated only with a single role, not multiple values; supports no other values than those of the WAI‑ARIA Role and ARIA-State taxonomies; the generic function name without object literal notation can cause conflicts with other initApp functions.
DTD extension#section8
We all know XHTML 1.1 is modular and extensible, but only a few über-geeks seem to know how to extend the DTD (fortunately, there are validators for debugging your customized DTD). First you bring in the Role Attribute module, then you extend common elements with the role attribute, and then you bring in the States and Properties module including the XHTML 1.1 driver. See an example DTD.
Implement your customized DTD as usual. You only need to adapt the URI and the your name as the maintainer (“ALA” in the example):
<?xml version="1.0" encoding="utf-8"?> <!DOCTYPE html PUBLIC "-//ALA//DTD XHTML 1.1 for » Accessible Adaptable Applications with Role Attribute 1.0//EN" » "http://learningtheworld.eu/dtd/xhtml-role-state.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
Then we need to bring in the WAI‑ARIA Role taxonomy. If you prefer to avoid namespaces, you can add it with a link element in the head:
<link rel="meta" href="http://www.w3.org/2005/01/wai-rdf/ » GUIRoleTaxonomy#" type="application/rdf+xml" » title="WAI‑ARIA Role Taxonomy" />
I don’t want to get into the old MIME type debate, but if you decide to serve the pages with the XHTML MIME type, avoid HTML entities. Browsers like Firefox do not read the DTD. Instead, they parse the DTD URI for known strings, and when they find something they know, you get XHTML in all its glory. Otherwise, it’s just XML. Alas the only named entities known in XML are <, >, &, and ", all other entities throw an error. Use Numeric Character References (NCR) instead, thus becomes   etc. (I use a PHP script for the translation.)
The bundle of ARIA-State with the XHTML driver isn’t a bad idea, but it’s inconsistent with the functionality of all other modules, which come as single entities. It also complicates the implementation of both XHTML-Role and ARIA-State, whereas creating a custom, validating DTD for the role attribute alone is easy. I’m confident these problems will be resolved when the draft becomes a candidate recommendation, as the W3C Protocols and Formats Working Group is very responsive.
Advantages: Validates easily with XHTML-Role; validates with a little tweaking of ARIA-State.
Disadvantages: At the time of this writing, overly complex; only an option with XHTML 1.1.
Conclusion#section9
Whether you start experimenting with the new attributes immediately or wait until the drafts become standards, you have the opportunity to get ready for them now and become an early adopter. So early, in fact, that you are invited to shape the implementation of the extension:
Those types of landmark roles are exposed by Firefox to assistive technologies, and are in the DOM. While currently none of the assistive technologies do anything with those roles, they could. We don’t currently have any plans to do anything with them in Gecko / Firefox, but we’d listen to ideas. If you have a solid idea of what should be done with those roles, please file an RFE (Request For Enhancement) bug under bugzilla.mozilla.org, Product = Core, Component = Disability Access.
—Aaron Leventhal (IBM / Mozilla)
Further reading#section10
-
- Roadmap for Accessible Rich Internet Applications (WAI–ARIA Roadmap)
- XHTML Role Attribute Module
- Roles for Accessible Rich Internet Applications (WAI–ARIA Roles)
- States and Properties Module for Accessible Rich Internet Applications (WAI–ARIA States and Properties)
Reading the article I didn’t find out the advantage of using WAI-ARIA over building accessible pages the “traditional” way. If you structure your page using the normal XHTML elements and if you use meaningful alt-attributes and so on, people with disabilities can already navigate your page. And this is also in line with building clean XHTML and pages accessible for search engines.
WAI-ARIA seems to be an additional task “only” improving accessibility and not improving the rest of the website. Instead it only complicates things (at least at this time) as the article explained.
Many current web applications are being built with toolkits such as Dojo that do not use standard (X)HTML user-interface widgets. This reflects both a desire (right or wrong) to be able to create a consistent widget look across platforms and browsers /and/ the fact that many widgets, such as tree controls and live regions, have no standard (X)HTML form. So it’s good that we can make custom widgets accessible, even if building new widgets into new (X)HTML versions and styling options into new CSS versions is a better long-term solution for most widgets.
It’s not progressive, and it’s not an enhancement.
Although it’s true that devices outside the limited browser/AT combinations that support this won’t be negatively affected by the attributes themselves, they will be affected by the lack of functionality. If we build applications that rely on this stuff, we’re cutting down our target userbase even further – Opera and Safari are gone, as are older versions of Mozilla browsers, as are (more importantly) other readers, like Hal and Supernova, and older versions of JAWS and Window Eyes (remember that readers are very expensive, and we can’t just expect users to upgrade, in the way we maybe-can for browswers themselves; and the technology that makes this work is a fairly recent implementation).
By further implication, if we rely on this approach we’re also cutting out the possibility of a non-scripted interface – if we can’t do it with forms, we’re precluding that right from the start.
So this is not progressive enhancement at all – it’s not progressing from a basic foundation, it’s merely force-raising the technology bar even higher (as if Ajax itself isn’t already doing that enough!), and doing so using an unproven and non-compliant technique.
I think this is a fascinating idea, and may turn out to be exactly the right approach to solving the accessibility issues arising from the rush toward RIAs. But this certainly not suitable for any kind of real-world useage now, only for experimentation.
I agree to James that this is not the best way to add accessibility to web pages. We should stick to the standards that are in place and that do work. Nothing against innovation (not at all), but this seems to me like a big step backwards. There are many readers available that work ok with structured XHTML. Why reinvent the wheel?
WAI roles can be used to enhance DHTML widgets with accessibility information. It’s true that this is an experimental technology and the spec is not finalized (same as with XMLHttpRequest and CSS 2.1). However, adding role information shouldn’t necessarily render those DHTML widgets less usable in user agents that do not support WAI roles, and doesn’t in any way preclude offering a non-scripted alternative. For example, you could dynamically replace a traditional form interface with fancy DHTML widgets. WAI roles will soon be used, through the IAccessible2 and AT-SPI accessibility frameworks to be supported by future Firefox versions, by (at least) future versions of Window-Eyes, JAWS, NVDA, Orca, and Fire Vox. That list includes a free option for all major desktop platforms (Windows, Mac OS X, Linux, Solaris), so access should not typically depend on an expensive upgrade (although we musn’t be glib about the costs in time and trouble for users to install and learn additional software, even when free). That list also represents an unusual level of support from assistive technology vendors for any new web technology. It seems practical reason enough for careful consideration, whatever the theoretical technical merits of WAI roles vs. traditional widget elements/attributes.
From the concerns I see in the discussion …
> If you structure your page using the normal XHTML elements
> and if you use meaningful alt-attributes and so on, people
> with disabilities can already navigate your page.
True, if you can make that choice that’s fine. What if your work for an organization that is on the leading edge of AJAX development, and isn’t interested in using semantic HTML. They want to use Javascript for widgets and even have live updates on the page based on real-world events?
If you work at a place that is going to use web 2.0 and DHTML widgets, you’ll need some way to make that accessible. There is no other way to do that besides ARIA. Yes it’s hard but that’s why we’re putting it into Dojo. Other toolkits will hopefully follow.
We may eventually get an easier solution like HTML 5. Then again that may take 7-9 years, if CSS 2 teaches us something. It would be great if HTML 5 has powerful widgets like tree views and spreadsheets with the accessibility built right in. But, in the mean time people will still be going nuts with Javascript.
In reality, custom widgets will always be something developers will want the freedom to make. Microsoft recognized this when the developed MSAA (Microsoft Active Accessibility) for Win32, which allowed developers to make owner-drawn custom controls accessible. You can’t have a widget set that pleases everyone, so it’s important to provide developers with a way to make their fancy custom widgets accessible. Otherwise accessibility is seen as holding back innovation.
> This is not a progressive enhancement
It does not change behavior or accessibility in places that don’t support it.
Because ARIA is the only solution being proposed for all the wild stuff going on out on the Web now, I expect it has a place on the web.
> using an unproven and non-compliant technique.
We have proven that it works, please see the widget samples. The only thing non-compliant is the use of tabindex=”-1″. If that’s important to you, wait for the activedescendant support in Firefox 3, which is compliant, and is an alternative the use of tabindex=”-1″.
As far as backwards compatibility with older screen readers, it works with older versions of Window-Eyes and JAWS as long as they work with Firefox at all. This is because we expose the new widgets so that they look exactly like the old widgets.
Should everyone jump on ARIA right now? Probably not, but if a few start to use it that will help move things along. We’ll get there eventually anyway, but some killer apps with it will help pressure some of the big vendors to support it. That’s important, so that Web 2.0 stops being just a disaster for accessibility with no way to fix it.
I may be completely off-base with my thinking here, but why can’t something like Microformats be used in a similar way to solve many of these problems?
Well, microformats have traditionally been used for marking up or embedding data not creating custom widgets, but the draft standard for embedding WAI information into HTML 4.01 using the class attribute is very close to how microformats work:
http://www.w3.org/WAI/PF/adaptable/HTML4/
Traditional microformats haven’t relied on UA and assistive technology implementations to get off the ground. It’s important for accessibility solutions to have backing from standards organizations so that conformance requirements are clear, so that anyone can implement them, and so that they can be made a W3C UAAG (User Agent Accessibility Guidelines) conformance requirement to be promoted to procurers. I have some doubts about whether the anything-goes model of the current microformats movement is particularly appropriate for that reason.
First we need to get this standard out the door. The idea of having a Microformat version should be looked at once we’re done with that.
The article unfortunately doesn’t really communicate exactly how this impacts development.
In the current methods of adding screen reader support (see an example at http://juicystudio.com/article/making-ajax-work-with-screen-readers.php with excellent descriptions), it takes a lot of scripting in order to dynamically inform a screen reader that things have changed. These methods also rip the user out of whatever they’ve started reading or writing at that time, and drop their cursor wherever the change occurs. The later versions of Jaws don’t quite do that, but in order to support a broader user base, you need to do it that way…Jaws costs a lot of money for an individual to keep paying for every year.
With WAI-ARIA, this gets handled just by adding an attribute of aaa:live, and you can fully control the urgency with which the screen reader will read the updated DOM elements! This not only keeps the user in their current context, but allows “polite” live elements to wait for the user to complete their current task before the user needs to hear it. Errors and other urgent information can either user “assertive” or “rude” in the worst case scenarios.
This doesn’t even touch on some of the benefits of the other attributes available, but just the aaa:live attribute itself makes screen reader support infinitely easier to implement and much, much more flexible.
You can see some good examples on the Firevox (open source, cross platform Firefox screen reader) site: http://firevox.clcworld.net/tutorial/tutorial.html
Yes, this very new working draft has some time and work before it exist as a specification. But it needs support from developers in order to take off some of its rough edges, and for the more widely-used screen readers to start paying closer attention. WAI-ARIA can only help developers and we have every reason to help push this project forward.
Trying to adhere to these standards puts Dojo ahead of the toolkit pack, in my opinion.
It’s long, but I red iit in one read. Good stuff
Finally the article has been “translated into German”:http://www.barrierekompass.de/weblog/index.php?itemid=541 and published at the Barrierekompass website. Thanks for all the positive feedback and comments, BTW. 😉
It would be great to see more updates on ARIA from Alistapart, this looks like the most recent mention and nearly two years old!
A nice semi-tech article could really make a difference, aria-required / aria-invalid for form elements? Strike me as really useful attributes for accessible JS.