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.
WAI-ARIA, the W3C’s specification for Accessible Rich Internet Application, provides web developers with a means of annotating page elements with the roles, properties, and states that define exactly what those elements do. The added definitions help screen readers and other assistive devices navigate through your website.
We’ve previously looked at how WAI-ARIA can help you build more accessible websites, and showed you how the role attribute can help browsers understand what an HTML element is being used for. Nice as both of those techniques are, neither is much help if browsers and screen readers don’t support them.
Still, despite the lack of the support in Window Eyes 7.5, WAI-ARIA roles are largely ready for prime time. That means you can start using roles in your HTML5 today. For example, you might have something like this for the main navigation on your site:
While it might seem that the nav tag would define 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:
Of course there are other benefits to adding roles to your page, like the ability to style the elements with CSS. Sticking with the example above, we could target this specific nav element using code like this:
Using roles to style your CSS eliminates the need for extra IDs or classes and often makes for more readable CSS since the role definitions are easy to understand, even years later.
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 code here
Now you can target that specific header tag with CSS’s attribute selector:
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.
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:
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:
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.