When should I use tabindex values on website elements?

Think of tabindex as a way to affect whether an element can receive keyboard focus and how it relates to sequential Tab navigation. The simplest choice is usually no tabindex at all. Links with href, buttons, inputs, selects, and textareas are normally focusable without it. [S1]

For example, a regular button can be written as a button, without a tabindex attribute. Adding tabindex="0" to that button generally adds nothing needed for Tab access. Prefer the element’s native behavior rather than adding tabindex as a blanket accessibility fix. This guidance is about HTML behavior; it does not determine whether the page’s interaction or visual design is accessible.

First ask whether it should actually behave as an interactive control. If it performs an action, a native button or link is generally the clearer starting point. If a non-interactive element truly needs to be included in the regular Tab sequence, tabindex="0" makes it sequentially focusable in its position in the document. [S1]

For instance, if a custom widget has a focusable container, tabindex="0" places it in the normal sequence according to document order—not at a hand-picked numeric position. That attribute alone does not supply the widget’s behavior or establish that it works correctly for keyboard users. Check the full interaction, not just whether the element receives focus.

Use tabindex="-1" when an element should be focusable through code but should not be added to the sequential Tab order. By contrast, tabindex="0" lets the user reach the element through normal Tab navigation, following its position in the document. [S1]

A possible use is a page section heading that receives focus after an in-page action, so a person can begin reading at the new section without making every heading a Tab stop. Treat that as a design example, not a guarantee that a particular focus-management pattern is right for every page. Verify that focus moves at the intended moment and that the person can continue navigating sensibly. MDN also cautions against using tabindex on a dialog element. [S1]

Positive values such as tabindex="1" put those elements into a numeric focus order ahead of elements with tabindex="0". That can make the keyboard path harder to follow, especially when someone edits the page and its numbered elements no longer match the intended sequence. MDN recommends using only 0 and -1, avoiding positive values, and preferring a logical document order. [S1]

For a review, try this decision rule:

1. If it is a native link or form control, remove an unnecessary tabindex.
2. If it should join normal Tab navigation, consider 0 and check the document order.
3. If it should be reached by code but skipped by Tab, consider -1.
4. If it has a positive value, reconsider the design rather than renumbering around it.
5. Test the whole keyboard path and the interaction. The cited guidance explains tabindex behavior, but does not prescribe a framework-specific focus-management implementation. [S1]

Example review note: “The button is natively focusable, so remove its tabindex. Keep the section heading at -1 only if the page intentionally moves focus there; test that transition and continued navigation.”