How to fix: Positive tabindex values

The tabindex attribute controls whether and when an element receives keyboard focus. WCAG Success Criterion 2.4.3 Focus Order requires that focus move through a page in an order that preserves meaning and operability, which in practice means following the logical reading order. A positive tabindex (1, 2, 3, and so on) breaks this: it yanks those elements to the front of the tab sequence, ahead of every element using the natural DOM order.

The result is a tab order that no longer matches what users see. Pressing Tab might jump from a field in the header to a button in the footer to something in the middle, because the browser visits all positive-tabindex elements first, in numeric order, before falling back to source order for everything else. One stray tabindex="1" can throw the entire page's focus sequence into disarray, and the values become a brittle list you have to renumber every time the layout changes.

There are only two values you should normally use. tabindex="0" puts a custom interactive element into the natural focus order at its place in the DOM. tabindex="-1" removes an element from the tab sequence but still allows you to move focus to it programmatically (for example, focusing a dialog when it opens). To change the order in which things receive focus, reorder the markup or use CSS that does not disturb the DOM order, rather than reaching for positive numbers.

Keyboard-only users, including many people with motor disabilities and anyone navigating without a mouse, are affected directly. A scrambled tab order makes the page unpredictable: focus jumps around the screen, skips expected stops, and is easy to lose entirely.

Screen reader users feel it too, because their reading and interaction flow is tied to focus order; when focus order and visual order diverge, the page stops making sense as they move through it. Sighted keyboard users (power users filling out forms) also lose efficiency when Tab does not go where they expect.

A broken focus order is a Level A failure under SC 2.4.3, the most basic conformance tier, and WCAG 2.1 Level AA, the de-facto ADA benchmark in U.S. court rulings, includes every Level A criterion. So a positive tabindex sits inside the standard plaintiff firms cite, and keyboard-operability problems are a recurring theme in ADA website complaints.

Web accessibility litigation keeps climbing and disproportionately hits businesses under $25 million in revenue. The good news is this is almost always a deletion, not a redesign: removing positive tabindex attributes and letting DOM order drive the sequence (with tabindex="0" or "-1" where genuinely needed) resolves the issue and usually simplifies your markup.

1. Find every element with a tabindex attribute and note the ones whose value is greater than 0.
2. Remove the positive tabindex values; in almost all cases the element should simply follow the natural DOM order.
3. If the focus order is genuinely wrong after removal, fix it by reordering the elements in your HTML so the source order matches the intended order.
4. Use tabindex="0" only to add a custom interactive element (not a native one) to the natural tab order, and tabindex="-1" only for elements you focus programmatically.
5. Tab through the page and confirm focus moves in a logical, visible order, then re-scan.

<input type="text" name="first" tabindex="2">
<input type="text" name="last" tabindex="3">
<button tabindex="1">Submit</button>

<input type="text" name="first">
<input type="text" name="last">
<button>Submit</button>

AccessKnight selects every element that has a tabindex attribute, reads the attribute, and parses it as an integer. Any element whose tabindex value is greater than 0 is flagged, with a fix recommending tabindex="0" or "-1" instead. Values of 0 and -1 (and elements with no tabindex at all) are treated as valid and are not reported, because only positive values override the natural focus order.