We’ve written a lot about how you can make your website more accessible with WAI ARIA roles, particularly ARIA’s Landmark roles. As a bonus you can also use the roles to style elements.

Hopefully you’re using ARIA roles given that they’re such a simple, easy win with pretty much no downside, but have you ever wondered exactly how ARIA roles help people using assistive devices? In the video above accessibility consultant Leonie Watson gives a quick demo of exactly how screen readers benefit from landmark roles.

If you’re sold be sure to read up on our earlier coverage, including this post on how to add landmark roles to your site. The site Watson mentions in the video is also a great ARIA resource. Also have a look at accessibility guru Steve Faulkner’s recent post over on the The Paciello Group blog.

And note that, as Faulkner writes, “over time the necessity of explicitly assigning landmarks will lessen as browsers build in ARIA landmark roles to newer HTML element semantics.” For now though, even if you’re already using the new elements, it doesn’t hurt to add the roles as well.

We’ve covered how you can make your webapps more accessible using WAI-ARIA — the W3C’s emerging specification for Accessible Rich Internet Applications — but did you know ARIA can also help style your pages?

Web developer Jeremy Keith recently took a look at how ARIA’s “landmark roles” can be used, not only to make your pages more accessible, but for styling purposes as well. Consider HTML5′s header and footer tags. The average page has a main header and footer and then may also use the same tags within an article tag, for example, to wrap a headline, dateline and other auxiliary information.

So how do you target just the main header and footer tags without also styling the inner tags? Well, you could drop some IDs in your page, something like <header id="main">. But ideally the ID attribute is not simply a styling hook to be thrown around at the designer’s whim.

Keith points out a better way: using ARIA’s landmark roles. To stick with the same example, you could write something like this:

<header role="banner">
    ...header code here
</header>

Now you can target that specific header tag with CSS’s attribute selector:

header[role="banner"] {
    your styles here
}

Not only have you avoided the plague of otherwise meaningless ID attributes, you get the accessibility benefits too — ARIA roles are supported in JAWS, NVDA and Voiceover. It’s a win-win solution: more accessible code with styling hooks built in.

Be sure to read through Keith’s post for some landmark role examples. Also see our early post on building a more accessible web with WAI-ARIA, and of course, read through the WAI-ARIA role spec, which has more examples and guidelines for when and where to use them.

Italian Masks photo by Peter Lee/Flickr/CC

See Also:

• Can WAI-ARIA Build a More Accessible Web?
• Microdata: HTML5′s Best-Kept Secret
• Using Microformats in HTML5

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:

• Microdata: HTML5’s Best-Kept Secret
• W3C’s Unicorn Validator Checks Multiple Standards at Once
• Using Microformats in HTML5
• Add Semantic Value to Your Pages With HTML 5