All posts tagged ‘ARIA’

File Under: HTML5, Web Standards

Video: How ARIA’s Landmark Roles Work

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.

Styling Webpages With ARIA’s ‘Landmark Roles’

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:

File Under: HTML5, Web Standards

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.

Continue Reading “Can WAI-ARIA Build a More Accessible Web?” »