How to Use Tabindex for Better Keyboard Navigation: Complete Guide (2026)

Why Tabindex Matters for Accessibility

Keyboard navigation isn't a niche concern. It's how users with motor impairments, blind users on screen readers, power users, and anyone with a temporarily injured hand interact with your site. tabindex is the attribute that decides whether they can use it at all.

• WCAG 2.1.1 Keyboard (Level A): every interactive element must be operable through a keyboard interface. A custom <div> with a click handler and no tabindex silently excludes every keyboard user.
• WCAG 2.4.3 Focus Order (Level A): focus order must preserve meaning and operability. Positive tabindex values reorder elements in a way that almost always conflicts with the visual reading order — a direct failure.
• WCAG 2.4.7 Focus Visible (Level AA): the focus indicator must be visible. tabindex="-1" can hide elements from the natural sequence; if you focus them programmatically, you also need to make the focus ring visible.
• Screen-reader navigation: screen readers usually traverse content in DOM order regardless of tabindex. Positive values create a mismatch where keyboard-only users land somewhere different from screen-reader users — a deeply confusing experience.
• Maintenance cost: a form with tabindex="1" through "7" needs renumbering every time someone adds, removes, or reorders a field. DOM source order needs nothing.

How the Three Tabindex Values Actually Work

Most tabindex bugs come from misunderstanding what each value does. Here is the precise behaviour the browser applies.

<!-- BAD: positive tabindex creates a manual queue
     that breaks DOM order and screen-reader parity. -->
<form>
  <label>Name <input type="text" tabindex="3" /></label>
  <label>Email <input type="email" tabindex="1" /></label>
  <label>Phone <input type="tel" tabindex="2" /></label>
  <button type="submit" tabindex="4">Submit</button>
</form>

<!-- GOOD: rely on DOM source order. tabindex="0"
     only on the custom widget, tabindex="-1" only
     on the programmatic focus target. -->
<form>
  <label>Email <input type="email" /></label>
  <label>Name  <input type="text"  /></label>
  <label>Phone <input type="tel"   /></label>

  <!-- Custom widget: not focusable by default,
       so it needs tabindex="0". -->
  <div role="button" tabindex="0" onClick={submit}>
    Submit
  </div>
</form>

<!-- Skip-link target: focusable from JS but not
     in the Tab order. -->
<main id="main-content" tabindex="-1">…</main>

How to Check Tabindex Issues on Your Site

tabindex problems are usually invisible until a keyboard user tries to navigate. A combination of automated scanning and manual Tab-key testing surfaces them quickly.

• Greadme deep scan — flags every element with positive tabindex, every interactive ARIA role missing keyboard focusability, and pairs each finding with an AI-generated fix or one-click GitHub PR.
• Greadme crawler scan — runs the same checks across every indexable page, so you can spot which page templates carry the legacy positive-tabindex patterns.
• Greadme AI visibility analyzer — tells you whether failing keyboard accessibility is dragging down rankings that AI search engines source from.
• Manual keyboard test: press Tab from the address bar and walk through every interactive element. Focus order should match visual reading order; nothing should be skipped, and no focus indicator should disappear.
• Open-source axe-core — the engine behind most accessibility scanners; it checks tabindex rules and ARIA focusability locally during builds.
• Screen reader walkthrough: NVDA, JAWS, or VoiceOver. If the screen-reader order and Tab order disagree, you almost certainly have a positive tabindex somewhere.
• Chrome DevTools Accessibility pane — inspect each element's computed accessibility tree, including its tabindex value and whether it is reachable via keyboard.

10 Tabindex Best Practices

Common Tabindex Mistakes and Fixes

Tabindex Values Compared

A direct side-by-side reference for which value to reach for in each situation.

FAQ

What does tabindex="0" do?

It makes an element that is not normally focusable (like a <div>) part of the keyboard Tab sequence, at its DOM position. Use it on custom interactive widgets. It is redundant — and considered noise — on elements that are focusable by default such as <button> or <a href>.

What does tabindex="-1" do?

It removes the element from the Tab sequence but lets JavaScript move focus to it via element.focus(). The standard use cases are skip-link targets, modal containers, error-summary panels, and route-change landing points in single-page apps.

Why is positive tabindex considered an anti-pattern?

Three reasons. It almost always conflicts with visual and source order, which violates WCAG 2.4.3 Focus Order. Once a user passes the last positive value, focus jumps back to the start of the natural order — confusing and disorienting. And screen readers usually walk the DOM regardless, so keyboard-only and screen-reader users end up on different paths through the same page.

Does tabindex affect screen readers?

Mostly no — screen readers navigate by DOM order, headings, landmarks, and the accessibility tree, not by tabindex. Positive values are typically invisible to them, which is exactly why they create a mismatch with keyboard-only users.

Should I add tabindex="0" to every interactive element?

No. Add it only when the element is not already focusable. Native form controls, links, and buttons are focusable by default; adding tabindex="0"to them is redundant and clutters the markup. Reserve it for custom widgets that the browser doesn't recognise as interactive.

How does tabindex affect AI search engines like ChatGPT and Perplexity?

Indirectly but meaningfully. Generative search systems most often surface pages that already rank well in traditional search, and Google factors keyboard-accessibility signals into its quality and Page Experience evaluations. A page where positive tabindex creates broken Tab order is more likely to fail those checks, lose ranking, and never be sourced by AI Overviews or chat-based answer engines.

How do I fix a focus order that doesn't match visual order?

Reorder the DOM so source order matches the visual layout, then remove every positive tabindex. Use CSS Grid's orderproperty only when truly necessary, and verify with a manual Tab walkthrough that focus follows the same path as a sighted user's reading flow.