Don’t Use Tabindex Greater than 0

Animated GIF

Tabindex had the potential to be a useful attribute. A developer could set the order in which focus is moved on a page as a user tabs through the form (or links, or content). It became a stop-gap for forms and pages that relied too heavily on absolute positioning and didn’t flow naturally. The problem is that it is often set by developers who don’t have any idea of what the user expects.

This mis-use has effectively guaranteed that using tabindex values greater than zero is a bad idea. If, as a developer, you have to use tabindex on a form, then the page itself probably isn’t laid out well and will only confuse keyboard users and, more importantly, users of assistive technology.

Browsers take any element with a positive tabindex value and promote it to the front of the pack for tabbing through the page. Only after a browser gets through all elements with a tabindex does it then fall back to source order. It doesn’t matter if your tabindex is one million, it will still trump everything on the page that doesn’t have a tabindex.

This is such a well-known issue that the W3C HTML Working Group is working on new language to deprecate values greater than zero. There is even a bug filed against the HTML specification to that effect.

For more detail I encourage you to read Léonie Watson’s piece, Using the tabindex attribute.

Tabindex Best Practices

Here are some tips to use tabindex properly.

tabindex="-1"

Setting tabindex="-1" allows you to set an element’s focus with script, but does not put it in the tab order of the page. This is handy when you need to move focus to something you have updated via script or outside of user action.

tabindex="0"

Setting tabindex="0" will take an element and make it focusable. It doesn’t set the element’s position in the tab order, it just allows a user to focus the element in the order determined by its location with the DOM.

tabindex="1" (or any value > 0)

Do not set a tabindex="1" or any value greater than zero (or any positive value).

The Example

The example in the animated GIF above is unfortunate in that the site developers themselves don’t set a tabindex (I found this at User Experience Impossible: The Line Between Accessibility and Usability on the GSA‘s DigitalGov site). Instead, for reasons I cannot explain, they use a CAPTCHA on the comment form. The implementation they chose, however, inserts its own tabindex values.

This means that as the user starts tabbing through the page, he or she is first sent to the text entry field on the CAPTCHA in the comments section.

Even as a sighted mouse-user, I was confused how I got there as I tabbed into the page. It takes five more tabs to get to the link that allows the user to skip to the content (which appears first on the page).

This also creates a problem for a user who is filling out the comment form, as tabbing from the Name and then Email fields puts the user on the privacy link for the CAPTCHA, but not into the field where he or she can type the text to submit the form. Some users may never know there is a CAPTCHA there depending on how they got to the comment form.

Paul J. Adam shows the offending code in a tweet, which I will steal and display here since I’m too lazy to screen-capture it:

@heydonworks @webaxe @aardrian pic.twitter.com/gBsaWC9t4k

— Paul J Adam (@pauljadam) November 18, 2014

I don’t want to beat up the DigitalGove folks, but this is a great example of how a perfectly functional page (regardless of how I feel about the hover versus focus styles) can be ruined by not testing it after adding third-party widgets.

Bonus: Don’t Use CAPTCHA

There’s a lot written about this. I’ll just link to this from the W3C: Inaccessibility of CAPTCHA

User testing quote (5 minutes ago): "If you put a Captcha on it, you're on the shit list."

— Dennis Lembrée (@dennisl) November 18, 2014

Update: November 19, 2014 at 1:25pm

Update: November 19, 2014 at 6:25pm

Follow-up notes on reporting this

The comments I posted on the DigitalGov page are still in moderation queue, even though comments posted well after mine have been approved. You can see them still in moderation in the screen capture.

Given my suspicion that they won’t be posted (since I’ve heard nothing back from the initial conversation with the Twitter account), I’ll post the comments here. The first was a reply to a site admin following up on a comment from another user noting that the keyboard navigation of the page is broken. My second comment is a follow-up.

The First Comment

The Second Comment

Update: December 3, 2014

Update: October 23, 2016

#HTML5 now warns web developers about positive value tabindex use and tabindex="0" on non interactive elements – thanks @patrick_h_lauke pic.twitter.com/es4VxnjBmC

Update: May 29, 2019

Scott O’Hara has identified an interesting aspect of Shadow DOM and tabindex:

[…P]ositive tabindex values on elements within the Shadow DOM, do not have an impact on the light DOM’s document tabbing order.

This does not mean it is ok to use positive values. It simply means Shadow DOM lives more in the shadows than I thought.

Update: July 3, 2024

I collapsed a bunch of old and irrelevant sections above and hid the opening animated GIF, without any effort to address styles when expanded. I can do that in my rebuild.

This update concerns some content on Google’s web.dev site that a junior dev asked me to explain because it was counter to the advice I offer in this article from 10 years ago.

The first is Modify DOM order with tabindex, whose very title suggests the impossible. You cannot re-order the DOM with the tabindex attribute. But this nugget stood out to me:

tabindex="5": Any tabindex greater than 0 brings that element to the front of the natural tab order. If there are multiple elements with a tabindex greater than 0, the tab order starts from the lowest value that is greater than zero and works its way up. Using a tabindex greater than 0 is considered an anti-pattern.

The strongest warning against positive tabindex values in the entire piece is anti-pattern. The only WCAG warning in the article is about keyboard traps in modals, not focus order concerns. For an article released in June 2024 (last month), this is a huge disappointment, especially since I know it confused someone who needed good information to do their job.

The second web.dev article is Accessibility for web developers from February (5 months ago). It includes this nugget:

• A tabindex value greater than 0 places the element in a manual tab order. All elements in the page with a positive tabindex value are visited in numerical order, before elements in the natural tab order.

This one contains no warning but instead can be taken as guidance to force something to the top of the tab-stack (I made that up) with no consideration for focus order nor meaningful sequence.

While I have mostly shied away from filing issues on Google’s own content (because it’s free labor that they also ignore for years), in this case I need to show the junior dev this is an issue and let them see how Google does or does not address it.

• 350944652: Insufficient tabindex warning
• 350916215: Another insufficient tabindex warning