Updated:

Tabindex: What it is, how it works, and when to use it

by Whitney Lewis

Tabindex is an HTML attribute that controls keyboard focus and can hurt or support accessibility depending on how you use it.

It can add focus to non-interactive elements, rearrange the focus order, and remove focus from interactive elements.

Just because tabindex can add, rearrange, and remove focus, doesn’t mean it should. This is where the first rule of ARIA, don’t use ARIA, comes into play with tabindex.

What this rule really means is to avoid using tabindex unless it’s needed. It should always be a well-thought-out decision and not added willy-nilly because it might be needed.

In this article, you’ll learn about:

Rather watch the video? Watch When and how to use tabindex for better accessibility (video).

What tabindex is and how it works

Tabindex is a global HTML attribute. It can be attached to any HTML element to control its focus.

Focus refers to keyboard focus. When keyboard users tab through a page, the visible focus indicator should navigate to the next interactive element. In this screenshot of Pope Tech’s main navigation, the focus indicator is the green outline around Resources. It would move when a user tabs through the page.

Interactive HTML elements like links, form fields, buttons, and navigation items are automatically in a page’s tab (or focus) order and get this focus.

Tabindex is the HTML attribute that gives developers control to do one of these three things to the already existing tab/focus order:

  • Add non-interactive elements to the tab order.
  • Remove interactive elements from the tab order.
  • Rearrange the existing tab order, which is originally set by the HTML order.

How tabindex works

The tabindex attribute accepts a number to know what to do to the HTML element:

  • A negative value: Typically -1 removes the interactive element from the tab order sequence.
  • Zero: Adds an element to the tab order. The element is added where it is in the existing HTML order.
  • A positive value: Positive values rearrange the existing tab order.

IMPORTANT: You’ll usually only use tabindex=”0” and tabindex”-1” to support accessibility. You shouldn’t use positive values to rearrange the tab order. Instead, adjust the source code so it’s in the right order, and make presentation adjustments with CSS.

In this code example, the link is removed from the tab order sequence.

<a href="#" tabindex="-1">...</a>

This div is added to the tab order in the order it appears in the HTML.

<a href="...">First interactive element</a>
<div tabindex="0">This is now interactive and goes second</div>
<a href="...">Third interactive element</a>

These divs use positive values to rearrange their order, so it’ll go in the order of the tabindex and not the HTML order.

<div tabindex="2">I'll go second.</div>
<div tabindex="1">I'll go first.</div>
<div tabindex="4">I'll go fourth.</div>
<div tabindex="3">I'll go third.</div>

Back to top

Tabindex’s impact on accessibility

Tabindex directly affects keyboard accessibility. It hurts accessibility when it breaks how users expect keyboard navigation to work, and helps accessibility when it maintains those expectations.

Keyboard users’ expectations are:

  • All interactive elements (links, buttons, and form inputs) are part of the tab order (they can tab to them).
  • Non-interactive elements (headings, text, images) are not part of the tab order.
  • The tab order aligns with the page’s visual order.

As for screen reader users, their expectations for tab order are the same. While they will navigate the page using headings, regions, or other non-interactive elements, their screen reader tools already have ways to do this. So, it does not need to be built-in using tabindex.

This means if you use proper HTML for the typical webpage, keyboard and screen reader navigation already exist.

It also means that if you build a custom and interactive component, you have an HTML attribute, tabindex, that can add that component to the tab order, maintaining expectations and keeping it accessible.

Back to top

When to use tabindex

Here are three scenarios where tabindex supports keyboard accessibility and helps maintain keyboard interaction expectations.

Set the focus on elements using tabindex="-1"

Setting the tabindex value to -1 removes an interactive element from the tab order. But, it also makes it so you can set that element’s focus with JavaScript (with the focus() method).

This is helpful for elements that users wouldn’t navigate to directly using tab, but need keyboard focus set to them. For example, a modal screen that needs focus when it appears, or a form submission error message that needs focus after a form with errors is submitted.

Form submission error example

This new user form had errors when it was submitted. There is an error message above the form field telling the user the issues.

The <div> that has the error message text also has the tabindex attribute set to -1. Now, you can use JavaScript to set the focus to that error message instead of the top of the page.

<div id="error-heading" tabindex="-1" class="card-header">
     <i aria-hidden="true" class="fa-solid fa-triangle-exclamation"></i> Hang on, let's address these errors first 
</div>

Setting the focus to the right spot on the page is helpful for keyboard and screen reader users:

  • Keyboard users can now select tab and are right where they need to be – in the error message and form. Otherwise, they might have to start at the top of the page and tab to get back to the form.
  • Screen reader users now hear the error message right away and know there is an issue. Otherwise, their focus would be somewhere else, so the screen reader wouldn’t announce the error text, making it easy to miss that there was an issue.

Add scrollable containers with CSS overflow property to tab order using tabindex=”0″

The CSS overflow property hides content that is outside the element’s padding box. Some overflow values make it so there is a scrolling, which is an interactive feature that a keyboard user should be able to perform with only their keyboard.

In most browsers, users can’t tab to a CSS overflow element by default. This means the keyboard user wouldn’t be able to focus on the scrollable area to scroll it.

To fix this, give the container tabindex="0". Now, a keyboard user can tab to the container and then use their keyboard to scroll.

The scrollable container also needs a label and HTML semantics that explain what the content is. This helps screen reader users know what’s in the scrollable section and navigate to it if needed. You’ll add:

  • An accessible label – Label the scrollable section with an id and associated aria-labeledby if there is a visible heading. If there isn’t a visible heading, try aria-label.
  • HTML semantics that explain what the content is – Use HTML sectioning elements, or if the user needs to return to the content easily, you can use a landmark role or group role.

Terms of use example

A common scrollable overflow area are terms of use boxes.

In this example, the terms of use scrollable container has tabindex set to 0 so keyboard users can focus on it. It also has aria-labelledby and role as group so screen reader users hear an accessible label and it’s semantically emphasized for screen readers.

<div aria-labelledby="terms-of-use" role="group" tabindex="0" style="overflow: scroll; height: 10rem;">
  <h2 id="terms-of-use">Terms of Use</h2>
  ...
</div>

Building a custom, interactive component

If you’re creating a custom and interactive component, add tabindex="0", so it is part of the user’s tab order, or tabindex="-1" so you can set the focus to it when needed. This helps maintain a keyboard user’s expectations that interactive elements are part of the tab order or tabbable when needed.

Custom components should be functionality that doesn’t already exist in HTML. For example, there is already an HTML button element that is automatically added to the tab order and has other accessibility functionality built into it. In this case, use the HTML button element, don’t create a custom button with a <div>.

Tabs example

An example of a custom, interactive component that doesn’t have existing HTML is tab interactions.

A tab interaction typically uses both tabindex="-1" and tabindex="0".

It uses tabindex"-1" on the tab list, or the buttons used to navigate to the different tabs. This makes it so the developer can use JavaScript to set focus to the active tab as the user interacts with it.

The tab interaction also uses tabindex="0" on the tab panel. The tab panel is the container that holds the content.

Check out the ARIA tabs pattern examples for more details.

Back to top

Find and review tabindex instances on your own website

You can quickly check for tabindex on your own website with the free WAVE extension or Pope Tech’s free plan (no credit card required).

Find tabindex with Pope Tech

If you want to find accessibility results across multiple pages at once, Pope Tech’s free plan is a great starting point. Follow these steps to find tabindex with Pope Tech:

  1. If you don’t have an account, activate your free plan (no credit card required).
  2. Add your website.
  3. Crawl and scan up to 25 pages to get your accessibility results.
  4. Go to your Dashboard in the left main navigation to explore your data.
  5. In your Automated Scorecard widget, select ARIA results.
  6. Select Details for ARIA tabindex.
  7. Select Details for your website.
  8. Review each instance of tabindex on that website by reviewing the Code or opening the page in a new tab with WAVE already opened.

Watch the video to learn how to drill down to your tabindex results:

Find tabindex with WAVE

WAVE checks one page at a time. It’s a great tool to use on the fly or as part of a publishing process. Follow these steps to find tabindex with the WAVE extension:

  1. Install the WAVE extension.
  2. Navigate to a page you want to check.
  3. Activate WAVE by selecting the extension. If you don’t see the WAVE extension, use your browser’s Extension Manager to add it to your extension bar.
  4. Select the Details tab.
  5. Uncheck all results except for tabindex, which is in the ARIA results at the bottom.
  6. Review the tabindex value next to the tabindex icon on the webpage, or select the tabindex icon and then Code to review the HTML.

Review tabindex instances

Once you’ve found tabindex instances, review them to make sure they’re needed. You can use these questions to help review:

  • Is this an interactive HTML element (<button>, <a href>, <input>) that’s already built into the tab order? If yes, it doesn’t need a 0 or positive value tabindex attribute.
  • Is this a non-interactive HTML element with tabindex set to 0 or a positive number? If yes, it probably doesn’t need the tabindex attribute. Some non-interactive elements, like ones with CSS overflow, need a tabindex so keyboard users can access and interact with them. But, if it’s a heading or paragraph and there is no interaction around it, it doesn’t need tabindex.
  • Is tabindex set to -1? If yes, check if the element needs focus set to it at some point (like when a modal or error message appears).

Back to top

If you’re interested in learning more about HTML that can break or support accessibility (depending on how you use it), check out these resources: