On Tuesday I had the pleasure of attending Todd Kloots Yahoo! Dev talk on “More Accessible User Interfaces with ARIA”, apart from the added bonus of being located in the new Skills Matter conference and events centre. Todd made a very good presentation and a solid introduction to ARIA for those not aware of it. Rather than boring the audience with long spouts of text from the W3C ARIA spec he instead chose a more hands on approach showing everyday examples of ARIA on widgets he had developed with Yahoo and the YUI, whilst at each point stopping to show alternative options of implementation and which were the best practices and why he thought they were.
For those of you who are not familiar ARIA (or “Accessible Rich Internet Applications”) is a way further conveying a specific elements role within a webpage or application through the use of enhanced semantics. This allows for screen readers and assistive technologies to more accurately define to the user how to interact with a websites controls, in turn creating a richer user experience. It is especially useful to define the use of more advanced user interface controls (that are becoming increasingly more popular ) made using javascript and ajax, that have states that constantly change.
For the more interested developers out there, ARIA is applied to your applications by placing extra attributes within your elements tags, most commonly using the role=”" attribute. One of the most important aspects of ARIA is the ability to apply multiple attributes to an element (as you would do with ID’s or Classes). This is because each element can have multiple properties:
- It’s Role: role=”menu”
- It’s State: aria-disabled=”true”>
- It’s Properties: aria-haspopup=”true”
A simpler way of describing this may be to show you an example of the markup one would use of a simple two panel tabbed interface.
<ul role="tablist">
<li role="presentation"><a href="" role="tab">Tab 1</a></li>
<li role="presentation"><a href="" role="tab">Tab 2</a></li>
<ul>
<div role="tabpanel">
<p>Content</p>
</div>
<div role="tabpanel">
<p>Content</p>
</div>
Although this is clear when visually displayed like that, the only true way of showing ARIA in use is to see (and more importantly hear) it working within a supported browser or screen reader. Though, as with all new or unfinished W3C specs, browser support and implementation varies across all vendors, with JAWS and Window-Eyes supporting the most amount of roles and states attributes. This leads us to the question of ‘is it worth all the hassle?’, my own personal answer: YES, being a big supporter of progressive enhancement, as long as it aids a better user experience for some of your users then it is worth the small amount of extra time to implement it.
Overall, Todd’s talk was very insightful and good to see how Yahoo! are going about creating much richer user experiences for people with specific needs, and even more so educating others about the best practices which can hopefully lead to a more accessible web!
I will certainly be trying to force and implement the use of ARIA in future projects here at UVd, so keep your eye out for more info and posts around the subject in the near future. Though in the mean time I have included some further reading to feed your ARIA thirst, and start trying out ARIA yourself. But as Todd said himself:
Reading the documentation only gets you so far.
So try actually testing your new aria goodness with a screen reader, two of the links below are to help your setup a screen reader testing environment on your machine.
Enjoy!
Further reading:
WAI-ARIA Best Practices
YUI Configuring screen readers
How to use NVDA and Firefox to test your web pages for accessibility
This post was written by Patrick on November 20, 2009 at 2:52 pm
