I've long been meaning to take a closer look at WAI-ARIA, so last week's YDN talk at Skills Matter by YUI developer Todd Kloots seemed like an excellent opportunity to learn the basics. With them starting at half six, forcing me to travel halfway across London in the middle of rush hour, I often miss the start of Skills Matter events and this one was no exception - though this time the main problem was that they are now at new offices and I went to the old one first.

The talk was split into four parts, followed by some Q & A:

• How ARIA solves problems of perception
• How ARIA solves problems of context
• How ARIA solves problems of discoverability
• Tips and tricks for working with ARIA

How ARIA solves problems of perception

One of the problems faced by screen reader users is working out what a page element they come across is for and what state the element is in. A sighted user can look at a web page and easily see an area devoted to navigation and an area for main content, what things are toolbars and buttons and what state they're in (eg. bold mode in a text formatting toolbar).

How ARIA solves problems of context

HTML has only a limited palette of context setting elements - headings, lists and form grouping elements, such as h1 and fieldset can be used to indicate section breaks in your content. But if you wanted to indicate a tab control or a toolbar to assistive technology there's no standard markup to do that.

To address this ARIA has landmark roles, as we saw earlier, but it also allows you to indicate which sections of your page should be treated as a document and which should be treated as an application. In document mode, the screen reader responds to its own keyboard shortcuts for browsing, in application mode you can provide keyboard shortcuts for working with your widgets. ARIA also provides recommendations for keyboard shortcuts to use.

Todd discussed two ways of making sure your widget is keyboard accessible without drowning the user in choices. For example, if you have a toolbar widget you may not want the keyboard user to have to tab through every item on the toolbar every time they encounter it. It would be better if they could tab to select the toolbar but then tab again to skip over it if they didn't need any toolbar functions at this time. The two techniques are to use aria-activedescendent or to use a roaming tab index - set a tabindex of -1 on all the child elements of your widget and then adjust focus programmatically in response to key strokes. Todd has previously published a blog post which describes both focus management techniques in detail, he currently prefers the roaming tabindex approach because of its backwards compatibility (though watch out for the known focus event delegation issues).

How ARIA solves problems of discoverability

After you've created a keyboard accessible widget using ARIA roles and states you need to make sure users can actually discover your widget - all your good engineering work goes to waste if users never realise the functionality is there. This is where aria-live and aria-describedby are useful.

A live region allows text to be spoken to the user without that text gaining focus, thus losing the reader's place in the content. Depending on the nature of the message it can either be polite, assertive or rude - ranging from waiting until a pause or interrupting the user whatever they may be doing. An auto-complete list would be an ideal candidate for a live region - Todd demonstrated how live regions work on the Yahoo! Suggest feature on their search page.

The aria-describedby property allows you to link to a longer description of what your widget does, so you can inform the user, the first time they focus on your widget, of how to access the functionality of your widget as well as what to expect when they interact with it - again this was demonstrated in the suggest feature on Yahoo! search.

Tips and tricks for working with ARIA

The key tip if you're going to delve in ARIA is to install a screen reader and test things yourself! There are free ones for various platforms (eg. Windows and Linux). If you're unsure where to start, read this tutorial about setting up a test environment with NVDA and Firefox.

The second tip was more of a warning - ARIA gives developers a great deal of control over the end user experience, because it allows them to bypass the virtual buffer of the screenreader and talk directly to the user. This brings with it a risk - having all web browsing mediated by the screen reader made for a consistent user experience, now there's the potential for every site to be different leading to user confusion.

Q & A

There was an interesting question and answer session at the end. The first question was about the new semantic elements in HTML5 and whether screen readers were taking advantage of them yet - not so much, Todd felt that mush of ARIA is available today to far more users. Further questions brought up the frightening prospect of web developers having to take into account not just compatibility across various browsers but also a second dimension of cross screenreader compatibility and finally if any of the popular Javascript libraries had built in support for ARIA (YUI 3 has built in support).
http://skillsmatter.com/podcast/os-mobile-server/aria

All in all this was an excellent talk, 5 out of 5. One of the most technically detailed talks I've attended at Skills Matter - far more stuff was discussed than I've managed to fit into this blog post. If you're interested I recommend you watch the video.