Recently Tenon received a support request from a customer complaining that their site had thousands of issues in Tenon about their use of tabindex. The customer believed that their use of tabindex was a good thing because the tab order made sense. Here’s a cleaned-up version of the response I sent to them:
It creates maintenance headaches
The longer the tabindex values exist on the site, the more likely that maintenance of the site will cause the tabindex values to become inaccurate. Websites are never really “done”. Once they go into production, maintenance, changes, and bug fixes happen. Along the way, things move around, new links are added, old links are removed and over time someone slips and the tabindex values become out of sync with the desired interaction order.
It strips away user control
The use of an explicit tab order undermines the user’s ability to control their interaction with the site. Web pages that dictate an explicit tab order tend to do so for one of two reasons: to overcome a bad tab order or due to a misunderstanding of how the tab order should work. Using tabindex to fix a bad tab order is the wrong approach. Modifying DOM order so that the tab order matches the visual order might be difficult, but the pay off is much greater than using tabindex.
There’s another piece of using explicit tabindex that people often misunderstand when they use it: Users don’t just load up the site and start tabbing through the page. While sighted keyboard-only users might do this, the reality is that very few of the so-called “sighted keyboard-only users” truly use only the keyboard. People with motor impairments might do other things, such as use specialized pointing devices or voice dictation software. Depending on the UI and the tasks they’re there to perform, they might swap back and forth between voice dictation and keyboard. Or they might use their specialized pointing devices and keyboard.
Blind screenreader users don’t just load the page and start tabbing through it, either. Again, depending on the UI and the tasks they’re there to perform, they might pull up a list of headings on the page in order to see what the page is about. Or, they might even just hit “H” to get taken to the first heading on the page. In fact, I’d argue that they’re just as likely to hit the “H” key as they are to hit the “Tab” key as their first keystroke on the page.
It may cause a mismatch between visual order and interaction order
An element with an explicit tabindex value greater than “0” will receive keyboard focus before focusable elements with no tabindex value (or tabindex="0"). In other words, tabindex="0" says “put this in the tab order where it would normally occur based on its source order” while an explicit tabindex value greater than “0” causes the item to be placed at that number within the tab order (barring any gaps in the order, which will be ignored).
After tabbing through all of the things that have a tabindex greater than “0” the user will navigate to all other focusable elements in the order in which they appear in the DOM. In doing so, they will skip over the things that have already received focus. In some cases, this may cause a mismatch between the visual order and the focus order. For a sighted/ partially sighted keyboard-only user, this mismatch between what get focus vs. what they expect to get focus will be confusing.
It may make user support difficult
Last, an explicit tab order can cause frustration when doing user support. Customers with disabilities who reach out to the company for support may be given directions for workarounds that don’t match reality. Well-meaning support staff might say “The X-link is the 5th link on the page” when in reality it isn’t the 5th but something else.
We feel that the above reasons make it clear that tabindex creates more problems than it solves and that the use of tabindex should be avoided.