Focus-order failures are found by walking with a keyboard, not by inspecting source order

What it is

DOM order in source, a tabindex list, a snapshot of the accessibility tree — all of them can look fine, while the path a finger takes with Tab is a different road. The instrument for detecting focus-order failures is the keyboard walk itself: pointer away, Tab from browser chrome into the page, follow stop by stop to the end. Code inspection is a hypothesis. Traversal is the measurement.

Automation can list focusable nodes. It cannot list “focus is under the sticky header”, “Shadow DOM spliced the sequence wrong”, “the visual next step actually runs through a hidden menu first”. Those appear only on the keypress.

Why it happens

Focus sequence is a runtime product. Source order is only one input. Also in the mix: user-agent defaults for native controls, positive and negative tabindex, disabled / inert / hidden, flattening of shadow trees, nested browsing contexts in iframes, and nodes clipped by overflow: hidden that remain focusable. Static review sees what the author intended, not the sequence after composition.

There is a physical layer too. A focus indicator sitting under a sticky bar or a cookie wall can leave source order perfect while the person cannot see where they are — an order-experience failure found only by watching the screen while Tabbing. Screen magnification shrinks the viewport to a patch and enlarges the error: focus jumps off-screen, the code is still “in order”.

Studying it

Treat keyboard traversal as lab equipment, not a release-week ritual. The protocol can be thin: disable the pointer; enter from the address bar; screenshot each Tab stop with its focus indicator; lay the shots against the visual expected path. For one URL cover at least three runtime states: fresh load, a menu opened and closed, a form submitted into failure. Those three sequences often disagree, while the HTML in the repo is one document.

Use automation as a pre-filter: flag positive tabindex and off-screen focusable nodes. A clean pre-filter still needs a human walk. Under WCAG-EM, walk a full cycle on each template class. Do not sample only isolated controls in a component storybook — isolated controls have no sticky header and no footer bounce.

Where it stops holding

Keyboard unit tests on a single control in a component library are necessary and not a substitute for a full-page walk: most order bugs live between controls, or between a control and a third-party script. Screen-reader browse-mode shortcuts travel a virtual buffer, not the Tab sequence; listening through a page once does not replace a keyboard walk. Touch devices have no Tab ring; attach an external keyboard or turn on Switch Access. Tapping through with a finger is not this method.

Applying it

• Make “pointer off, Tab the whole template” a required step on every template class. Do not let lint stand in for it.
• During the walk, the eye follows the focus indicator. Covered, off-screen, or into a closed menu counts as fail even when DOM order looks right.
• How to check: take a template that already “passed source review” and walk it from the keyboard only. Jumps the review never mentioned mean the wrong instrument was used.

Related

• Same group: J3.02.1 Focus order must match visual order · J3.02.2 Overlays must capture focus and remain escapable · J3.02.3 An inescapable focus trap is a blocking defect · J3.02.4 Dynamically inserted content desynchronizes focus unless it is moved on purpose · J3.02.5 Focus order must update as content expands or hides · J3.02.7 Nested overlays that each capture focus can deadlock
• Nearby: J5.08 Limits of automated checking · J5.07 Compatibility testing · J5.14 Testing with disabled users
• Search terms: keyboard-only testing · WCAG-EM · tab traversal