Skip to content

Focus-Order Failure

The accessibility defect in which an interface advances programmatic focus (Tab navigation, screen-reader linearization) in a sequence that diverges from the task's semantic order — invisible to visual review, and sometimes placing a confirmation control before the content it confirms.

Core Idea

Focus-order failure is the accessibility defect in which the sequence by which an interface advances programmatic focus — under keyboard Tab navigation or screen-reader linearization — diverges from the conceptual order the task requires. The mechanism is a mismatch between the traversal order (set by DOM source order or tabindex) and the semantic task order. When developers reorder elements visually via CSS without adjusting the DOM, the layout and traversal desynchronize, so a non-visual user encounters controls in a sequence that fails to carry the task's structure.

How would you explain it like I'm…

Mixed-Up Button Order

Some people use a computer without looking at the screen, and the computer reads the buttons to them one at a time. Focus-Order Failure is when the computer reads things in a mixed-up order, like a storybook whose pages are shuffled. The page might look fine, but if you hear the 'Pay' button before you hear what you're buying, that's a problem.

Tab Key Mix-Up

Some people move around a website using only the keyboard's Tab key, or with a screen reader that reads the page out loud. The computer visits the buttons and boxes in a set order, and that order can be different from how things look on the screen. Focus-Order Failure happens when that hidden order doesn't match the order you need to do the task. For example, a 'Close' button might be read before you even know what window you're closing. Someone just looking at the page wouldn't notice anything wrong, because it looks correct.

Tab Order vs. Task Order

A focus-order failure is an accessibility defect where the order in which keyboard Tab or a screen reader moves through a page's interactive elements differs from the logical order of the task. Two orderings are involved: the traversal order, set by the page's underlying code order (the DOM) or tabindex values, and the task order the user actually needs. Designers sometimes rearrange things visually with CSS without changing the code order, so the page looks right but is traversed wrongly. Examples include a dialog that announces its Close button before its content, or a wizard where focus lands on Next before the question. Because the layout looks correct, visual reviewers often miss it. WCAG 2.4.3, a Level A rule, requires focus order that preserves meaning and operability.

 

Focus-Order Failure is a human-computer interaction accessibility defect in which the sequence of programmatic focus across interactive elements, under Tab navigation, screen-reader linearization, or other assistive traversal, diverges from the task's conceptual order. It arises from a mismatch between traversal order, determined by DOM source order or explicit tabindex, and semantic task order, the logical sequence of fields, steps, or controls. Visual reordering techniques such as CSS absolute positioning or flexbox order reversal change the layout without changing the DOM, desynchronizing what sighted users see from what keyboard and screen-reader users encounter. Screen readers announce in DOM order and keyboard users tab in DOM or tabindex order, so they experience the traversal sequence, not the visual one. The defect is invisible to purely visual review. WCAG 2.4.3 (Focus Order, Level A) requires focus order that preserves meaning and operability. Typical failures: a two-column form whose right-column fields come after all left-column fields in the DOM, a modal whose Close button precedes its content, a wizard's Next button before its question, or a kiosk's Pay before Review.

Scope of Application

The defect lives across HCI accessibility subfields — every interface modality with a traversal-order question.

  • Web accessibility — the canonical home, tab order diverging from layout, governed by WCAG 2.4.3.
  • Screen-reader linearization — where DOM source order is the announced order.
  • Mobile interfaces — the same focusable-set-versus-task-order question under AT traversal.
  • Kiosk and public-service interfaces — hardware-wired focus, including Pay-before-Review.
  • Voice UI and IVR menus — where announced option order can diverge from the mental model.

Clarity

Naming focus-order failure makes visible a defect class that visual review is structurally blind to: the failure lives entirely in the non-visual linearization while the rendered layout looks correct. The label redirects inspection from the pixels to the traversal sequence and pins the cause — a visual reordering never matched in the DOM. It sharpens two conflated distinctions: visual order versus traversal order, and focus order versus reading order.

Manages Complexity

"This form is hard to use with a screen reader" is a diffuse complaint with no purchase. Focus-order failure compresses it to a single comparison between exactly two orderings over the same finite set of nodes: traversal order and semantic task order. The reviewer reads the defect off their divergence via a finite checklist. The branch structure does the rest — the visual-versus-traversal fork, the focus-versus-reading fork, and a safety-critical premature-confirmation sub-branch.

Abstract Reasoning

The kit is built on one comparison between two orderings over the focusable set. It licenses diagnosis (mark every step where traversal order departs from task order), boundary-drawing (redirect inspection from pixels to linearization, since the two coincide only for sighted mouse users), a focus-versus-reading-order split with cause inference, a safety-critical flag (a confirm control reached before its content is a premature-confirmation hazard), and intervention (resynchronize DOM and tabindex to the task order).

Knowledge Transfer

Within HCI and accessibility the defect transfers as mechanism intact across modalities sharing its two-ordering structure — web, mobile, kiosk, AR/VR, voice — changing only the traversal channel and reordering culprit; every member is an interface with a traversal question, which is why it is a domain-specific abstraction. Beyond HCI the named defect does not travel, but the general pattern it instantiates — a linearization encoding some structure other than the one the consumer needs — recurs as co-instances (checklists, curriculum sequencing, build topological sorts). That parent, Linearization-Meaning Mismatch, carries the cross-domain lesson; the focus-traversal machinery and WCAG framing stay home.

Relationships to Other Abstractions

Local relationship map for Focus-Order FailureParents appear above the current abstraction, mutual partners to the right, and children below. Node labels state whether each abstraction is prime or domain-specific; colors identify relation types.Focus-Order FailureDOMAINPrime abstraction: Linearization-Meaning Mismatch — is a decomposition ofLinearization-M…PRIME

Current abstraction Focus-Order Failure Domain-specific

Parents (1) — outgoing typed relations

  • Focus-Order Failure is a decomposition of Linearization-Meaning Mismatch Prime

    Focus-Order Failure is the interface-accessibility application of Linearization-Meaning Mismatch in which DOM or tabindex order conflicts with semantic task order.

Hierarchy paths (4) — routes to 4 parentless roots

Neighborhood in Abstraction Space

Focus-Order Failure sits in a sparse region of the domain-specific corpus (84th percentile for distinctiveness): few abstractions share its structure, so a faithful description tends to retrieve it precisely.

Family — Unclustered & Miscellaneous (2769 abstractions)

Nearest neighbors

Computed from structural-signature embeddings · 2026-10-25