A prime suspect in the crime of allowing “too much accessibility” has to be the TABINDEX attribute.
How many web authors realise that if you give the TABINDEX attribute to just a few form fields or links on a web page, you could ruin the logical tab order for the entire page? I’m afraid the answer is: far too few.
To be frank, I’ve rarely seen the TABINDEX attribute applied without it creating more problems than it solves.
Without the application of any TABINDEX attributes, pressing the tab key takes users from one link or form field to the next, in the order that they appear in the code. In reality this will probably also be the most logical order, as the code usually involves grouping links and field controls into logical divisions.
But, who would use their keyboard tab key to navigate around a web page?
- Screen reader users, who may be unable to see the screen clearly enough to recognise anything on it, including the mouse pointer, but whose screen reader will read aloud each link or form control label when it has focus.
- Mobility impaired people, may be unable to use a mouse, but they can reach every link and form field on the page using the tab key.
- Screen magnification users, who may only be able to see a credit card sized portion of the page, but whose magnified view-port follows the focus, around active regions, as they tab to them.
- Technology impaired people, who may have a broken mouse, or perhaps don’t have one at all.
… to name but a few.
So, what happens when the TABINDEX attribute is applied?
- Firstly, links and form elements that have been given a TABINDEX attribute, receive focus before any other active elements on the page.
They will receive focus in the ascending order of the numeric value given to eachTABINDEX attribute. - Then, after the TABINDEX assigned elements, any remaining links or form elements will receive focus in their natural (code) order, starting from the top of the page.
So when only some of the focusable elements are given TABINDEX values, confusion can reign if the web author doesn’t make sure that the relationships and dependencies between elements remains logical.
Here are a few instances, taken from live web sites to show the problems this can cause:
Example 1: in a form, all form elements are given a TABINDEX value, but adjacent links, leading to help information relating to each form field, are not.
Effect 1: In this real-life example, it was impossible to follow the logical tab sequence from “help link”, to related form field. On the page this was found, there were, in fact, 47 tab depressions needed to reach any “help link” from its related form field.
Example 2: The “Search” input field and “Go” button, are the only elements given TABINDEX values on a page, With a “content first”, “navigation last” code order.
Effect 2: Screen reader users are robbed of being able to establish any relationship between headings and their subordinate links. They may use heading navigation to find “Related links”, for instance, and would expect to be able to tab from there to reach the first in this list of links. However, because the “search” is lower in the code, its TABINDEX priority is still effective, so a tab from the heading “Related links” takes users to the search input field.
Obviously this problem would equally apply if TABINDEX were applied to the navigation links in a “content first” layout. Much better to provide a skip link to the navigation and let the natural tab order rule. OK?
Example 3: In an “A to Z” page, almost every link is given a TABINDEX value. However some have been left out, possibly added later, in a rush.
Effect 3: Links without the TABINDEX attribute may never be located, as they would only be reached by someone tabbing beyond the last of the links in the “Z” group.
Example 4: Throughout a site, the TABINDEX value "1" is given to the search input box, and TABINDEX "2" to the search “Go” button. Now, you aren’t going to believe this, but I promise it’s true, on a forms page within the site, the first two fields of the page form are also given TABINDEX values "1" and "2".
Effect 4: You’ve guessed it . The tab order is “search”, “first name”, “go”, “last name” etc. How logical is that
Moral: ideally spend more time working on providing a logical order within the code and leave the TABINDEX attribute on the shelf. If you absolutely must use it, test the page thoroughly for logical tab order, with your mouse unplugged.
Geoff Vines | 05/10/2006 at 17:00 | Permalink
It has also been my experience that in Opera, and it may be true of some I haven’t tried, tabbing only works if you have given elements a tabindex number.
Bim | 05/10/2006 at 21:51 | Permalink
That’s true, certainly of navigating through links in Opera (but it does allow tab to field elements).
Even so, with the keyboard shortcuts that Opera provides for navigating through links for keyboard users , the TABINDEX attribute is still not a necessity.
I think that Opera users who need to use their keyboard for navigation would soon find the shortcuts, or they’d be unable to move through most sites on the web.
The options are:
Ctrl + 9: to open a searchable link list, also navigable by arrow keys.
F9 to ensure that focus is on the page, then either:
A: to move forward through links; Q: to move backward; or
Shift + arrow keys to move spatially, vertically or horizontally, to the nearest adjacent link.