tabindex

What is the tabindex attribute?

The tabindex attribute is a global HTML attribute that determines whether an element can receive keyboard focus and where that element sits in the page's tab order. You can add it to almost any HTML element, and its value tells the browser whether to include that element in sequential keyboard navigation and, if so, when a user tabs to it relative to everything else on the page.

At a glance

Why is tabindex important when it comes to accessibility?

Interactive HTML elements already have a built-in place in the tab order. Links, buttons, form fields, and other native controls are focusable by default, and the browser moves keyboard focus between them in the same sequence they appear in the source code. tabindex becomes significant once you step outside that default behavior.

Keyboard users and screen reader users rely on tab order to reach the interactive parts of a web page. If an interactive element has no way to receive focus, or if focus jumps around in an order that doesn't match what's on screen, those users lose track of where they are and what they can do next.

Custom components built from non-interactive elements, such as a <div> acting as a button, need a tabindex value before keyboard users can reach them at all. Used carelessly, though, the same attribute can just as easily break the natural tabbing order it's meant to protect – something worth including in your accessibility testing checklist.

How does tabindex work?

The tabindex attribute takes one of three kinds of values, and each one tells the browser something different:

• tabindex="0" adds an element to the natural tab order, in its normal source-order position. This is the standard way to make a non-interactive element, like a custom dropdown or a <div> with a click handler, focusable without disturbing the logical sequence of everything else on the page.
• A positive tabindex value, such as tabindex="1" or tabindex="2", pulls an element out of source order entirely. The browser visits every element with a positive value first, in ascending numerical order, before it moves on to the elements in natural document order. If multiple elements share the same positive tabindex value, they're ordered by their position in the HTML document relative to each other.
• A negative value, almost always tabindex="-1", removes an element from sequential keyboard navigation. Users tabbing through the page skip over it entirely, but it can still receive focus programmatically, for example, via JavaScript's .focus() method.

Any valid integer technically works, but in practice, developers only ever need these three. Interactive elements such as links with an href attribute and native form fields already have a place in the tab order. Adding tabindex="0" to them changes nothing, but a negative or positive value will still remove or reorder them.

Beyond removing elements from the tab order, tabindex="-1" is also how you set keyboard focus on content that has no native way to receive it, such as a visible heading or a form submission error message.

Moving focus there programmatically after a page update informs screen reader users exactly where to look next, without adding that heading or message to the regular tab sequence.

tabindex only ever controls focus and tab order. Native interactive elements come with built-in roles that announce their function automatically, but tabindex never adds one on its own, which is why a custom component still needs an explicit role alongside it to get the full web accessibility benefit.

A tabindex example

A common use case is a custom interactive component built from a non-interactive element, alongside a form that moves focus to an error message on submission:‍

<div role="button" tabindex="0" onclick="submitForm()" onkeydown="if (event.key === 'Enter' || event.key === ' ') { event.preventDefault(); submitForm(); }">
  Submit
</div>

<div id="form-error" tabindex="-1" hidden>
  Please fill in all required fields.
</div>

‍The <div> acting as a button uses tabindex="0" to make it focusable in normal document order, role="button" so screen readers announce it as a button, and a key handler so it responds to Enter and Space like a native button.

The error message stays hidden until a failed submission. The script then reveals it and moves focus to it with .focus(). The tabindex="-1" makes that possible without adding the message to the tab order.

tabindex="0" vs. positive tabindex

Here is a table to help clarify the rules.

As a rule, use tabindex="0" when an element genuinely needs to join the tab order. Save a positive tabindex value for the rare case where the visual layout and the source code can't be brought into agreement any other way, and expect to revisit it the next time the page changes.

Common mistakes or misconceptions

• Reaching for a positive tabindex value first. Reordering focus with numbers feels like a quick fix, but it creates a parallel tab order that's easy to forget. The next developer who adds a field in the "wrong" place might unwittingly break keyboard accessibility for everyone after it.
• Adding tabindex to non-interactive elements without a role or key handler. tabindex="0" makes an element focusable, but focus alone doesn't make it operable. A focusable <div> still needs an ARIA role so assistive technologies announce what it does, and a keydown listener so it responds to Enter or Space the way a user expects when they tab to it.
• Using tabindex instead of semantic HTML. Most HTML elements that need keyboard focus already have it built in. A native <button> or <a> comes with keyboard handling and the correct tab order for free; a styled <div> with tabindex has to recreate all of that by hand.
• Forgetting the visible focus indicator. Adding tabindex gets an element into the tab order, but keyboard users still need to see where focus has landed. Removing the browser's default focus outline in CSS without replacing it leaves keyboard users with no visible cue at all.