Can WAI-ARIA Build a More Accessible Web?

Accessibility in web design has come a long way since the days of table-based layouts with single-pixel .gif spacers. But even current best practices are far from perfect. Today, we’ll tell you a bit more about these accessibility troubles as they relate to dynamic web apps — fitting, as today is Blue Beanie Day. For [...]
Can WAI-ARIA Build a More Accessible Web?

Accessibility in web design has come a long way since the days of table-based layouts with single-pixel .gif spacers. But even current best practices are far from perfect.

Today, we’ll tell you a bit more about these accessibility troubles as they relate to dynamic web apps — fitting, as today is Blue Beanie Day. For four years now, design guru Jeffrey Zeldman has encouraged web authors to wear a blue beanie on November 30 to show their support for web standards. Also, you’re encouraged to take a picture of yourself wearing a blue beanie and upload it to a Flickr pool. So, with standards quite literally on the brain, we’ll tackle the topic of rich web apps.

One of the coolest things about web apps is that elements refresh inside the browser without reloading the page. But most screen readers used by those with disabilities can’t parse these changes, so users who rely on them will remain unaware of any dynamically refreshed elements on the page. That’s just one of the many problems that WAI-ARIA, an emerging specification for Accessible Rich Internet Applications from the W3C, is hoping to solve.

At its core, WAI-ARIA is a means of annotating page elements with the roles, properties, and states that define exactly what those elements do. Take a navigation element as a simple example. In HTML5 we might do something like this:

<nav>
    <ul>
        <li>Home

        <li><a href="/about/">About</a></li>
        ...etc...
    </ul>
</nav>

While it might seem that the nav tag would defining the nav element’s “role,” not every browser will understand it (just because the browser can display it, does not mean it understands the tag). Also, the purpose of a navigation element may be obvious to most users, but to a screen reader being used by somebody who can’t see, the navigation strip could be just a jumble of words. Leveraging WAI-ARIA’s syntax, we can double up to ensure screen readers will know that this chunk of code is navigation:

<nav role="navigation">
    <ul>
        <li>Home</li>
        <li><a href="/about/">About</a></li>
        ...etc...
    </ul>
</nav>

The role="navigation" attribute is what’s known as a landmark role and is designed to let non-visual browsers know where they are.

It seems simple, and indeed when the spec is finished and fully supported by all the major screen readers, WAI-ARIA promises to make the web more accessible without overly complicating your markup. Unfortunately, there are numerous problems with WAI-ARIA at the moment, which make support uneven and can be confusing for web authors trying to do the right thing.

Our friends at A List Apart recently waded into the confusion and uneven support with two great posts on WAI-ARIA and how you can use it (and not use it) on your sites. The first article, The Accessibility of WAI-ARIA, dives into what WAI-ARIA is, what it’s trying to do, and why it’s not yet a panacea.

The second piece is more hands-on. ARIA and Progressive Enhancement looks at how ARIA fits within the progressive enhancement approach to web design. That is, when starting with valid HTML and enhancing it with CSS and JavaScript, how can you also work the WAI-ARIA attributes into your code?

The ARIA and Progressive Enhancement article also has a very informative table listing the varying levels of support in the latest versions of popular screen readers. Unfortunately, one of the main problems with WAI-ARIA today is that there’s no way to know the level of support a user agent has. Unlike CSS or JavaScript, there’s no reliable way to test which features a user agent supports (if any).

As Derek Featherstone writes in his ALA piece:

The problem that we have right now is that ARIA is an all or nothing deal. And writing scripts that respect both an ARIA supported methodology and a non-ARIA methodology is going to be incredibly difficult, because we have no reliable way of knowing the status of a user agent’s support for ARIA—it depends on something we can’t detect: the right combination of browser, assistive technology, and full ARIA implementation.

For more information on the various levels of support in screen readers and web browsers, have a look at Accessible Culture’s article, HTML5 plus ARIA “Sanity Check.” The post highlights some of the bugs, pitfalls and gotchas in current screen readers, as well as some workarounds and other non-ARIA solutions.

As Detlev Fischer writes in the first of the two ALA articles, “as long as older screen reader/browser combinations incapable of interpreting WAI-ARIA still constitute a significant part of the installed base, web designers who care for accessibility should use WAI-ARIA markup only to enrich their sites.”

In other words, use WAI-ARIA, but don’t rely on it. Make sure you have fallbacks in place until the spec is finalized and browser/reader support more widespread.

Unicorn photo from Wikimedia Commons/CC

See Also:

We will be happy to hear your thoughts

Leave a reply

TechEggs
Logo