Thursday, April 12th, 2007

Accessible Web 2.0 Applications with WAI-ARIA

Category: Accessibility

Martin Kliehm has written up a nice overview of what is going on in the world of accessible Web 2.0 applications.

The article documents the Accessible Rich Internet Applications (ARIA) work, primarily done by Becky Gibson, Aaron Leventhal, and Richard Schwerdtfeger.

One of the core problems is that anything can be an input of some time. What we see as a slider could just be <div class="slider"> and how would a screen reader know what to do there?

This is where roles come in:

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

I have been playing more and more with the graceful failback side of Ajax, and how microformats can help out. It seems to be able adding semantics to our simple building box (CSS classes and such).

Posted by Dion Almaer at 8:22 am

3.7 rating from 22 votes


Comments feed TrackBack URI

How is generic markup + a role better then specific markup?

i.e. why role=”wairole:slider” and not or ?

You could still style it and script it to act as you want.

Comment by David Dorward — April 12, 2007

How is generic markup + a role better then specific markup?

i.e. why role=”wairole:slider” and not <slider> or <wai:slider>?

You could still style it and script it to act as you want.

(Second attempt since I assumed this was a text input and the only clue otherwise is grey on grey text after

Comment by David Dorward — April 12, 2007

David: Because not everybody can see your styles. WAI-ARIA helps developers write very simply hints in markup and scripts to let assistive technologies know how the user interacts with elements and widgets in a given interface.

In short: much, much easier to support screen readers and other assistive technologies, and much, much better user experiences for those using them.

Comment by Shawn Lauriat — April 12, 2007

Look at Bindows ( – an Ajax development framework that includes the best in industry support for Section-508 accessibility.

Bindows components come with accessibility descriptions and instructions by default. In addition, developers can also create new accessible custom components or customize the built-in behavior to comply with various application specific requirements.

Bindows 508-compliant web applications still have the same rich Windows look and feel.
Checkout, try the accessibility tests and read about using Bindows to revamp existing web application or web page and become 508 compliant.

Comment by Ran Meriaz — April 12, 2007

many of the widget roles mentioned exist as actual elements in WHATWG’s spec, stuff like nav, menu, and what not. i mean since the world doesnt actually use XHTML its good to know that these elements are coming to existing nonetheless

would love to see better javascript support in line-mode b rowsers like w3m and links, i know blind users who practically live in the emacs minibuffer, having a sort of commandline prompt to a web GUI operating a higher level would be useful..

Comment by carmen — April 12, 2007


So what do we end up with?

Instead of adding a element, we use a div with a role attribute that says it is a foo and not a div.

Then what happens next time something new is added? Use a div with a role attribute to say it is a foo and then a realrole attribute to say that its actually a bar. So that clients that support the new spec know its a bad, older clients know its a foo (which is close to being bar) and still older ones get a div?

Meanwhile we’re encoding the semantics of a document in multiple layers, which complicates authoring.

Comment by David Dorward — April 13, 2007

So, with WAI-ROLES, html authors can supply standardized metadata that lets assistive technology identify the type of some element.

Being abe to convey type information certainly helps, but there seems to be a more fundamental disconnect between the job of a screen reader, for instance, and a truly rich, dynamic, custom application. Assuming that developers limit functionality to basic “bindows” style apps, then perhaps support for type-specific handling is all that’s needed, but for applications that don’t follow any predefined rules (e.g. truly custom applications), then type information isn’t enough. I’d expect there would need to be some way to convey arbitrary semantic and functional behavior and define AT-specific callbacks. However, programming anything more sophisticated than sparse metadata becomes intrusive to normal development, and this suggests that AT-aware applications might be better serviced via AT-specific custom applications rather than making one app serve two different interfaces.

Invariably, there will be interface modes that are incongruent with the natural and distinctive expectations of assistive technology.

Stairways are good interfaces for walking persons but ramps or elevators are more appropriate for wheelchair-bound persons.

To expect one interface to support radically different usages is inappropriate except for the most basic and simple of applications. Simple websites or applications constrained by basic types and behaviors may be accounted for via AT-aware type mappings, but beyond that, I doubt there is an elegant way to present arbitrary rich applications interfaces to incongruent audiences with metadata alone.

I think this is just being realistic. If two applications need to be written, they should be written instead of imposing an inauthentic approximation on developers that only addresses a small part of the overall problem.

Comment by Joe Hanink — May 6, 2007

Leave a comment

You must be logged in to post a comment.