Manual check flagged an incorrect tab order

What is this issue?

This finding comes from RedFlag’s guided keyboard walkthrough: a numbered badge overlays every focusable element on the page in the order it would receive keyboard focus, with an off-screen anchor placed first so the reviewer’s very first real Tab press always lands on badge 1. A person tabbed through the actual page, watched where each numbered badge fell relative to the visual layout, and recorded a fail at the point where the sequence stopped making visual sense.

Unlike the automated version of this problem, this finding carries no single structural cause by definition; if a positive tabindex or another clean structural signal were present, RedFlag’s automated tab-order-wrong check would likely have already flagged it during the scan. This finding exists specifically for the cases that check can’t catch: layout-driven sequence problems from CSS Grid, multi-column flows, or complex component nesting that only become obvious when a person actually tabs through the real page.

Why does this matter?

A page can pass every automated accessibility rule and still be genuinely hard to use with a keyboard, because “does this tab order make sense to a human tracking it visually” is fundamentally a judgment call, not a structural condition. This finding exists because that judgment call matters just as much as anything a scanner can catch: a confusing sequence blocks real keyboard users regardless of whether any single line of code technically caused it.

Multi-column and grid-based layouts are exactly where this shows up most, because a layout that looks perfectly organized to a sighted user reading left-to-right, top-to-bottom can still send keyboard focus bouncing between columns in an order no automated structural check would flag as wrong, since nothing about the DOM is technically broken; it’s just laid out in a way that produces a bad visual-to-tab-order mapping.

Who is affected?

• Keyboard users: experience the exact same disorientation an automated tab-order-wrong finding describes, just from a layout-driven cause instead of a tabindex value, which is equally disruptive and equally invisible to a purely structural scan.
• Cognitive disabilities: users who depend on a predictable, visually-consistent tab sequence to stay oriented while completing a task lose that predictability the moment a complex layout scrambles the order, even when nothing in the underlying code is technically “wrong.”

What users experience

Yusuf has a mild cognitive disability that makes it hard to hold a mental map of a page while multitasking, so he relies heavily on the tab sequence matching what he sees to stay oriented. On a three-column pricing comparison table built with CSS Grid, the DOM lists all of column one’s cells, then column two’s, then column three’s: technically valid, structurally unremarkable, and invisible to an automated scan. But visually the columns sit side by side, so tabbing through it sends his focus from the top of column one straight to the top of column two, skipping past the middle and bottom rows of column one entirely from his point of view. He loses track of which plan he was comparing and starts over from the top.

How do I fix it?

Reorder the elements in the DOM to match the intended visual reading order, the same fix that resolves the automated version of this problem. This works because it addresses the root mismatch directly: once source order and visual order agree, the tab sequence a keyboard user experiences naturally matches what they see, with no CSS-only workaround needed to keep the two in sync going forward.

For grid and multi-column layouts specifically, this often means restructuring markup that was written column-by-column into markup written row-by-row (or in whatever order actually matches the intended reading path), then using CSS purely for visual positioning rather than relying on it to also imply structure. Where a full DOM restructure isn’t practical short-term, tabindex="0" combined with careful sequencing, or CSS Grid’s own grid-column/grid-row placement properties instead of visual-only reflow, can realign the two without a full markup rewrite.

Code Examples

<!-- DOM lists column-by-column; grid displays them side by side -->
<div class="pricing-grid">
  <div class="plan">Basic <button>Choose</button></div>
  <div class="plan">Basic feature list…</div>
  <div class="plan">Pro <button>Choose</button></div>
  <div class="plan">Pro feature list…</div>
</div>

<!-- DOM order now matches the intended visual reading path -->
<div class="pricing-grid">
  <div class="plan">
    <h3>Basic</h3>
    <p>Basic feature list…</p>
    <button>Choose</button>
  </div>
  <div class="plan">
    <h3>Pro</h3>
    <p>Pro feature list…</p>
    <button>Choose</button>
  </div>
</div>

Grouping each plan’s heading, details, and button together in the DOM, instead of splitting them across separate column-by-column blocks, makes the tab sequence follow one complete plan at a time, matching how a sighted user actually reads the grid, rather than following an internal DOM structure that happened to render correctly but tab through incorrectly.

Common Mistakes

Mistake: “Our automated scan didn’t flag a tab order problem, so the tab order must be fine.” Automated scanning only catches structural causes like positive tabindex. A confusing tab sequence produced entirely by CSS layout choices, with no single non-compliant attribute anywhere in the markup, passes every automated check while still failing a real person tabbing through the page, which is exactly why this manual-check category exists.

Mistake: “Grid layouts are inherently accessible because CSS Grid is a modern, standards-based layout system.” CSS Grid being modern and standards-compliant says nothing about whether the DOM order backing it matches the visual arrangement it produces. A perfectly valid, well-supported Grid layout can still scramble tab order badly if the underlying markup wasn’t written with reading order in mind.

Mistake: “This is subjective, so there’s no real way to fix it correctly.” “Does this feel right” is a judgment call, but the target it’s judging against isn’t subjective; it’s whether the tab sequence matches the same visual reading order a sighted user would naturally follow. That’s a concrete, testable target even though confirming it requires a human walkthrough rather than a script.

How RedFlag Detects This

Manual check: RedFlag prompts a guided manual review; no automated flagging. RedFlag’s extension drives a real keyboard Tab-order walk, overlaying a numbered badge on every focusable element in the order it receives focus, with an off-screen anchor placed first so the reviewer’s initial Tab press always lands on badge 1. The reviewer tabs through the actual rendered page and records a pass, fail, or needs-review verdict per element, which the extension persists and raises as a violation on a fail.

False negative: not applicable in the usual automated sense: a reviewer who doesn’t notice a subtle sequence problem during the walkthrough simply won’t record it, the same limitation any human review process has. False positive: not applicable either, since there’s no algorithmic pass/fail to be wrong about; the verdict is whatever the reviewer determined while walking the real page. Manual step: this entire rule is the manual step; there is no automated pre-filter to double-check, only the guided walkthrough itself.

Manual Testing

1. Open the RedFlag extension’s guided tab-order walkthrough on the page in question, or manually Tab through it in Chrome or Firefox with no mouse.
2. Watch where each Tab press sends focus relative to the visual layout, paying particular attention to multi-column and grid-based sections.
3. Note the first point where the sequence diverges from the visual reading order a sighted user would naturally follow.
4. Trace that element’s position in the DOM relative to its visual position to identify whether CSS layout, DOM structure, or both are responsible.
5. Reorder the DOM (or adjust the layout approach) and repeat the walkthrough to confirm the sequence now tracks the visual order.

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 manually-verified branch of the same criterion the automated tab-order-wrong check covers; both test the identical requirement, sourced from different detection methods.

Related Issues

Tab order doesn’t match visual order is this rule’s automated counterpart, catching the structural causes (like positive tabindex) a scan can detect on its own, while this page covers the layout-driven cases that require a human to confirm.

Element has a positive tabindex documents the single most common structural root cause worth ruling out first, before assuming a mismatch is purely layout-driven.

Element in the focus order has no matching interactive role is a related but distinct focus-order defect that often surfaces during the same guided walkthrough, covering a Tab stop’s missing semantics rather than its position.

CSS flex or grid order does not match DOM order documents the specific CSS mechanism most likely to be the layout-driven cause behind a finding on this page.

References

• W3C Understanding 2.4.3: Focus Order
• MDN: CSS Grid Layout
• W3C Understanding 1.3.2: Meaningful Sequence