Navigation using the Tab key should be restricted to elements on the page that users can interact with.

Why is this an issue?

The misuse of the tabIndex property can lead to several issues:

• Navigation Confusion: It can confuse users who rely on keyboard navigation, as they might expect to tab through interactive elements like links and buttons, not static content.
• Accessibility Issues: It can create accessibility problems, as assistive technologies provide their own page navigation mechanisms based on the HTML of the page. Adding unnecessary tabindexes can disrupt this.
• Increased Tab Ring Size: It unnecessarily increases the size of the page’s tab ring, making navigation more cumbersome.

How to fix it

If the element is not meant to be interactive, remove the tabIndex property or set it to -1 so it is skipped by sequential keyboard navigation.

If the element is meant to be interactive, prefer a native interactive element such as <button> or <a href>. When a custom widget is required, give it the appropriate interactive role, keep it keyboard reachable, and implement the keyboard behavior that role expects.

Code examples

Noncompliant code example

<div tabIndex={0}>Save</div>

Compliant solution

<button type="button">Save</button>

Compliant solution

<div
  role="button"
  tabIndex={0}
  onClick={save}
  onKeyDown={event => {
    if (event.key === 'Enter' || event.key === ' ') {
      save();
    }
  }}
>
  Save
</div>

Exception

This rule accepts tabIndex={0} on elements with role="tabpanel". This matches the WAI-ARIA Tabs pattern, which allows the tabpanel itself to receive focus when its first meaningful content is not focusable.

<div role="tabpanel" tabIndex={0}>
  {content}
</div>

Resources

Documentation

• eslint-plugin-jsx-a11y - Rule no-noninteractive-tabindex
• MDN web docs - tabindex
• The a11y project - Use the tabindex attribute
• MDN web docs - ARIA: button role
• WAI-ARIA Authoring Practices Guide - Tabs pattern