Steve Falkner did a good presentation to the WSG last week, outlining how and why AJAX can work with screen readers (primarily Jaws and Windows eyes).
One tiny little point I wanted to pick up on was whether it was a waste of time to update AJAX content if you’ve attached an event to an element that isn’t a link or form control. The reason being that you can’t tab to these elements anyway so they aren’t keyboard accessible.
However, there is a trick I uncovered out a few years ago, that has since been included into the ARIA spec:
I used a value of -1 originally (around 2002?) to prevent screen reader users getting caught in Flash, as before the accessibility improvements you could easily get stuck in Flash elements.
However, although not strictly legitimate HTML (from memory values are supposed to be from 0 and up), it functions as a cross-browser mechanism for allowing keyboard focus.
This actually works quite well across some browsers now: IE 5.0+, and Firefox 1+. (It also works with Safari & Voiceover, although you have to be told to select it, there is no notification.)
If other browsers support soon, the principle is:
- No tabindex
- Default (current) behaviour of the element.
- Not in tab order, but is focusable via scripts.
- In tab order based on the location in the source order.
tabindex="30"(any number over 0)
- In tab order at the specified location, before anything without tabindex or with a tabindex of 0.
To be clear, it probably isn’t a good idea to use this, any command the user can select should probably be a based on a link or form control such as a button. Also, changing the tab order by using positive values is often very confusing, as it won’t match the reading order of the page. Still, a useful little trick to have in mind.
I almost mentioned this technique at the presentation, but Steve was so let down by technology (JAWs and projectors don’t mix!) it seemed ungrateful to do so. Plus I wanted to check it worked first.