/Opinion/ Ajax and accessibility, part two
16/01/2009 | Filed under Discover > Opinion
In the second of a two-part opinion piece, Alastair Campbell explains how ARIA can make JavaScript more accessible
Last month we saw how JavaScript, and specifically Ajax, could create problems for access technologies such as screen readers and magnifiers. Some of the new controls and updates to the page cause issues that are hard to work around, but there is a new hope.
An upcoming spec from the Web Accessibility Initiative improves the situation. It’s called ARIA (Accessible Rich Internet Applications) and it provides ways to make the new fangled JavaScript and Ajax widgets work with access technologies. Support has grown quickly, with all the main browsers and many screen readers starting to use it. It works by simply adding attributes to HTML elements. For example, you could define a ‘tree’ menu with:
<ul role=”tree” tabindex=”0” >
<li role=”treeitem”>First item</li>
[…]
</ul>
The role defines what type of control it is, the tabindex is used to allow keyboard navigation. Roles defined in the spec should cover most situations, such as menu, toolbar, slider, tooltip and tree. You can also define your own.
With ARIA you don’t use the tabindex attribute to define the tab order, but to add or remove things from it. An unordered list cannot normally be focused on when using a keyboard, but adding tabindex=”0” will mean that you can, and in the normal order. Using a value of -1 (or less) will enable you to remove things from the tab order, and this can be done dynamically with JavaScript.
You can also say when something has a state, such as checked, expanded and selected. For things that are not links or traditional form controls, this will be vital to match the visual representation. Current methods for making sure someone using a screen reader knows of an update are tricky, but with ARIA, updates to the content can also be announced through the live attribute. This can be off, polite, assertive or rude. For example, this HTML section’s updates will be announced:
<div id=”myLiveRegion1” aria-live=”assertive”>
[updating content]
</div>
At the moment adding ARIA attributes does make your HTML invalid. Given ARIA is only applicable where you’re using JavaScript functionality, it makes sense to apply the attributes via the scripting.
Yahoo took just this approach when applying ARIA attributes to its menu control, where it mapped the current class names to roles and states. Yahoo also cleverly manipulated the tabindex to remove hidden options until they’re visible.
Creating advanced functionality with JavaScript tends to require a library, which brings advantages when including accessibility. Yahoo and Dojo have both announced they’ll build support into their JavaScript frameworks, and jQuery has an extension that enables you to easily add ARIA attributes. Google has also entered the fray, with its AxsJAX JavaScript framework for adding ARIA-based enhancements to existing applications. With the Firevox extension for Firefox you can test ARIA-enabled sites right now.
These implementations won’t do everything for you, but they enable you to add functions that support ARIA. The Yahoo menu example uses this to add the ARIA state to its drop-down:
oMenuItemLabel.setAttribute(“aria-haspopup”, true);
So when the item is selected and the drop-down appears, assistive technologies know what they should do with it. The Dojo framework has announced it will be making its default widgets use ARIA out of the box.
These features are ready to try right now. Just download the Firevox (reader) extension to Firefox.
Alastair Campbell is director of user experience at Nomensa.
Bookmark with:
Comments
Aaron Leventhal / 18/01/2009 / 20:03 / http://accessgarage.wordpress.com
> Using a value of -1 (or less) will enable you to remove things from the tab order, and this can be done
> dynamically with JavaScript.
More importantly, tabindex="-1" allows you to make an element focusable via mouse or script. This enables the development of desktop-style keyboard navigation for complex composite controls like trees and grids/spreadsheets. For example, Dojo and other keyboard-enabled widget sets provide arrow key navigation within container widgets, rather than requiring the user to tab to each item (this would be quite laborious inside something like a spreadsheet.
In addition to the Fire Vox screen reading extension, a number of other full-featured screen readers support ARIA in Firefox, including NVDA, Orca and JAWS. However, Firefox is not the only browser that will have ARIA support -- IE, WebKit and Opera teams are working on support as well.
Authors can get more information at http://codetalks.org (a community-supported documentation wiki) or ask on the free-aria Google group.
Geoff Vines / 04/02/2009 / 15:51
Am I misunderstanding Alastair when he says - "An unordered list cannot normally be focused on when using a keyboard".
Of course it can. You can define style attributes for 'focus' and 'active' so that menu options change in the same way as when rolled over by a mouse cursor.
Also giving 'tabindex' numbers controls the sequence that items are visited when using the [Tab] key of the keyboard.
I use these techniques with my menus all the time.
Alastair Campbell / 16/02/2009 / 18:16 / http://alastairc.ac/
Hi Geoff,
If you use the keyboard only with your browser (generally with tab), you can only focus on links and form controls. Setting the styles doesn't make them able to be focused on. In your case, I assume you must be focussing on the links, not the list items.
Using tabindex to set the overall order through a page is generally a bad idea (e.g. http://www.netmag.co.uk/zine/the-accessibility-test/www-huntforproperty-ie)
Where ARIA is improving the situation dramatically is that specifying tabindex="0" makes something focusable in the source order (i.e. avoiding the prolems above), and -1 means focus on it with scripts:
http://www.w3.org/WAI/PF/aria-practices/#kbd_focus
