Tab order doesn't match visual order

What is this issue?

The order elements receive keyboard focus in (the focus order, the order a user pressing Tab moves through the page in) doesn’t match the order a sighted user would naturally read the page in, top to bottom, left to right (or right to left, in right-to-left languages). The browser’s default tab order follows DOM order, so this mismatch happens whenever something has decoupled visual position from document position: a positive tabindex value creating a separate priority sequence, or a CSS layout property repositioning content on screen without moving it in the underlying markup.

The result is a focus indicator that appears to jump around the page unpredictably from a sighted keyboard user’s point of view, even though the browser is technically following a consistent rule, just not the visual one the user expects.

Why does this matter?

A predictable tab order is what lets a keyboard user build a mental map of a page and navigate it efficiently without watching every single Tab press land. When that order breaks from the visual layout, the user loses that map: they can’t predict where Tab will send them next, so they have to visually hunt for the focus indicator after every keystroke instead of anticipating where it’s headed.

On a form specifically, a scrambled tab order can also cause real data-entry errors: a user typing quickly and trusting the tab sequence to move them field to field in visual order can end up filling in the wrong field entirely if focus jumped somewhere unexpected, especially on fields with similar-looking content like address lines or phone number segments.

Who is affected?

• Keyboard users: lose the ability to predict where the next Tab press will send them, forcing a visual search for the focus indicator after every keystroke instead of confident, rhythmic navigation.
• Screen reader users: hear content announced in an order that doesn’t match what a sighted user experiences, which breaks any shared frame of reference when troubleshooting a page together with a sighted colleague.
• Cognitive disabilities: users who rely on a consistent, predictable structure to reduce mental load while navigating lose that predictability entirely, adding a layer of “figure out where I am” work to every interaction on the page.

What users experience

Aisha has ADHD and relies on a predictable tab order to stay oriented while filling out longer forms without losing her place. On a multi-column checkout form, the developer used CSS order to visually stack the shipping fields above the payment fields on mobile, but never reordered the underlying HTML. Pressing Tab after entering her shipping address sends focus to a payment field three rows down instead of the next shipping field directly below it. She loses track of which fields she’s already filled in, second-guesses whether she already entered her card number, and has to scroll back through the entire form to visually verify before continuing.

How do I fix it?

Remove any positive tabindex values (tabindex="1", tabindex="2", and so on) first, since they’re the most common and most disruptive cause. This works because removing them restores the browser’s default behavior (following DOM order), which is inherently predictable without any further code changes, whereas positive values create a separate, hard-to-maintain priority sequence that has to be kept manually in sync with the visual layout forever.

When the mismatch comes from CSS instead, reorder the elements in the HTML source itself to match the intended reading order, rather than relying on order, absolute positioning, or similar properties to fix the visual arrangement alone. This is more durable than any CSS-only workaround because tab order and visual order stay linked automatically from then on: there’s no second place that has to be kept in sync every time the layout changes.

Code Examples

<button tabindex="2">Second visually</button>
<button tabindex="1">First visually</button>

<button>First visually</button>
<button>Second visually</button>

Removing the tabindex values and putting the buttons in the DOM in their intended visual order fixes both problems from the same source: the tab order now follows the browser’s default, predictable rule, and there’s no separate priority sequence left to fall out of sync the next time either button moves.

Common Mistakes

Mistake: “Using tabindex to control the order gives us more precise control, so it’s the better approach.” Positive tabindex values do give precise control at the moment they’re written, but that control has a cost: every future layout change has to remember to update every affected tabindex value in sync, and missing even one creates exactly this rule’s failure. DOM order gives the same precision with none of the ongoing maintenance burden, since the browser derives it automatically from source order.

Mistake: “The visual order looks right, so the tab order must be fine too.” Visual order and tab order are controlled by entirely separate mechanisms, CSS for the former, DOM order (or tabindex) for the latter, and neither one guarantees the other. A page can look perfectly laid out to a sighted user while its tab order jumps around in a sequence that has no relationship to what’s on screen.

Mistake: “This is a minor issue since keyboard users can just Tab a few extra times to get where they’re going.” A scrambled tab order isn’t extra Tab presses in a knowable direction: it’s an unpredictable sequence the user can’t anticipate, which is a fundamentally different and more disruptive problem than simply needing more keystrokes to reach the same destination.

How RedFlag Detects This

Automated: axe-core rule, runs on every scan. RedFlag calls axe-core’s tab-order-wrong rule as part of every scan, restricted to the WCAG 2.0/2.1/2.2 A and AA rule set (extension/content.js’s AXE_SCAN_OPTIONS). The rule inspects the page’s focusable elements for structural signals that the resulting tab sequence diverges from DOM and layout order, most reliably positive tabindex values creating a priority sequence distinct from source order.

False negative: a CSS-only mismatch (order or positioning that visually rearranges content with no tabindex involved) is harder for a structural DOM check to confirm with certainty, since evaluating whether the visual order genuinely diverges from tab order requires layout information a purely structural check may not fully capture; some CSS-caused cases pass silently. False positive: none typical for this check when positive tabindex values are the trigger, since their presence is unambiguous. Manual step: Tab through the flagged area yourself and confirm the sequence you experience actually diverges from the visual layout, since the automated result flags the technical cause, not a confirmed user-facing mismatch.

Manual Testing

1. Open the page in Chrome or Firefox using only the keyboard.
2. Tab through the page from the top and track where the focus indicator lands at each step.
3. Compare that sequence against the visual layout, top to bottom and left to right.
4. Flag any point where Tab jumps to an element that isn’t the next one in visual reading order.
5. Inspect any flagged element’s tabindex attribute and its DOM position relative to its visual position to identify the specific cause.

Related WCAG Success Criteria

2.4.3 Focus Order: Components must receive focus in an order that preserves meaning and operability. This rule is the most direct expression of that requirement: a tab order that contradicts the visual reading order fails to preserve the meaning a sighted user’s reading order conveys.

Related Issues

Manual check flagged an incorrect tab order is this rule’s manually-confirmed counterpart: the finding a human reviewer records during a full guided keyboard walk, covering the subtler cases this page’s automated structural check can’t reliably catch on its own.

Element has a positive tabindex documents the single most common root cause of this rule’s failures in isolation, with its own dedicated detector and fix guidance.

Element in the focus order has no matching interactive role is a related but distinct focus-order defect: a Tab stop with no explanatory role, rather than a Tab stop landing in the wrong position.

CSS flex or grid order does not match DOM order documents the specific CSS-driven cause behind this rule’s harder-to-detect false negatives: the same underlying mismatch, described from the CSS side rather than the tab-sequence side.

References

• W3C Understanding 2.4.3: Focus Order
• MDN: tabindex
• MDN: CSS order property