A common concern of most Ajax applications has been around their resulting accessibility. While, arguably, it’s possible to design some form of a usable web page without the use of JavaScript it should be possible – with the additional scripting information – to provide a better experience to users. It’s at this point that the ARIA specification comes into play. A large set of interaction is defined within it which is able to help web applications communicate directly to a screen reader in an effective manner.

To get a feel for what this interaction looks like, take the example of ARIA Live Regions (more info). With this functionality it would be possible to keep a live-updated list of users and allow the screen reader to keep up-to-date.

Observe the following ARIA-marked-up HTML:

<b>Active Users:</b> <p id="users-desc">A list of the currently-connected users.</p> <ol aria-live="polite" aria-relevant="additions removals" aria-describedby="users-desc" id="users"> <li>John</li> <li>Mary</li> <li>Ted</li> <li>Jane</li> </ol>

A couple settings are used to make this piece of HTML particularly interactive to the screen reader (the actual JavaScript that will update this list is left out – but needless to say nothing, in particular, is needed beyond simple DOM insertion and removal).

aria-live=”polite” How polite the live area is (as in, how likely is it to butt in to what the user is currently listening to/interacting with). The default is ‘polite’ – in that it waits until all forms of user interaction have been completed before describing the updates to the user.

aria-relevant=”additions removals” Only notify the user about new node additions and removals. Since we wish to provide the user with a live list of users we can expect them to be both transitioning online and offline – this will give us the appropriate level of updates to make this possible.

aria-describedby=”users-desc” A pointer to the element that describes the contents of the live area. If the user

wishes to know more about what the contents of the field represent this element can be read to them.

What’s most important about all of this, though, is that ARIA isn’t just a pipe dream of functionality: It’s implemented, today, in Firefox 2 and even more-so in the upcoming Firefox 3.

The Google Reader team recently took advantage of this and added full ARIA support to their application. It’s safe to say that Google Reader is not a trivial application by any stretch, allowing this to demonstrate the feasibility of ARIA within large-scale web application projects.

In the course of their implementation they built a tool, AxsJAX, which injects ARIA usability enhancements into many pages using a bookmarklet, greasemonkey, or Fire Vox (a Firefox screenreader). They started by seeding a number of Google applications with this drop-in accessibility support (along with a few others, including the XKCD web comic).

I continue to be impressed with what can be accomplished with ARIA – and seeing the work that Google has been putting forth by implementing this functionality in their applications has been incredibly enlightening and encouraging.