I am a minimalist. I believe that simple solutions are better. So, when it comes to tabindex, I rarely invite “him” to the accessibility party. Why? Because if you will just write the source code in the same order you need the items for the visual presentation, then tabindex is not necessary. But there are two decent reasons for using tabindex.
- tabindex = “0” to add something that is not a link or a form field to the tab order.
- tabindex = “-1” to keep something out of the default tab order, but make it focusable using the javascript focus(). Remember to use progressive enhancement.
When you specify the tab index on visible elements, remember the following:
- Elements with tabIndex=0 are ordered based on the source
- Any element with tabIndex>0 appears before all elements with tabIndex=0
- Any elements with the same tabIndex are ordered based on the source order
These features work in Internet Explorer, Firefox, Opera and Chrome, but they are undocumented. So, always play it safe. Build the core functionality in with pure HTML. Add CSS to enhance the presentation. Add javascript to enhance the experience. Have your source code order match the visual presentation order (after CSS is applied). Remember that all form fields and links are automatically in the tab order (so tabindex is redundant on these elements if you just have good source code order). When in doubt, leave tabindex out!
I hate it when the tab order is wrong or when tabbing never gets you to an option that should be selected before you can move on.
Great post. Very succinct and accurate.
A perfect nugget of wisdom on tabindex – thank you.
Tabindex on all elements of a page is a nightmare but I love the use of tabindex=”-1″ to remove duplicated images from the default order see handling repeated adjacent links.
But there is a downside: I was doing some testing last week and one thing worth noting as tabindex is not so well supported on mobile so best to avoid tabindex=”0″ and tabindex=”-1″ there. I tested this in iPhone 4, iPad, Android 2.2 and Nokia C5. Hopefully this will change.
How do you remove instances of tabindex=”1″ from a site? I mean, you shouldn’t leave them in when you discover them, but when you have pages of legacy stuff… What to do? Ideas?
Also, when I find them (on legacy pages), I think I should remove that entirely. I do not believe there’s a need for the 0 or -1 options.
While I agree with KISS method as a general principle, I suspect the future is not going to be too kind to the ‘avoid focus’ aesthetic. If you look at the way that websites are pushing more AJAX-ified models and the advent of HTML5, I see a push towards modal content as the norm. Modal content points at a ‘contextual principle’ where linear formats are replaced by relationship-centric UI.
The work I’m doing right now provides widgets that are spread across the UI in a manner that makes perfect sense for a visual user. Unfortunately, it would be a complete a11y failure without a strong focus management architecture. It’s a pain in the neck, to be sure, but without it I don’t see the linear format model working out very well in the long run. In my opinion the more interactive the page, the greater the likelihood for JavaScript focus management needs to play a principle role.
I’ve got a completely compliant page I’m developing on a local Apache install that includes tabindex attributes and properly ordered values. However after tabbing through the entire page and returning to Firefox’s GUI I can not return to the rendering engine’s tabindex order!
I also tried adding a tabindex value of 0, 1, and 2 for example (where as I started with the value of 1) and the only difference was that the anchor with the tabindex value of 0 was the only link that would gain focus and then pressing tab again would cycle back to Firefox’s GUI!
What trick am I missing here exactly?