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 HCI accessibility defect in which the sequence by which an interface advances programmatic focus across its interactive elements — under keyboard Tab navigation, screen-reader linearization, or assistive-technology traversal — diverges from the conceptual order the task requires, so that a non-visual or keyboard-only user encounters controls, fields, or announcements in a sequence that does not carry the structure needed to complete the task or that places confirmation actions before the content they confirm.

The mechanism is a mismatch between two distinct orderings: the traversal order, determined by DOM source order or explicit tabindex values, and the semantic task order, which reflects the logical sequence of form fields, wizard steps, or interactive elements as the task's underlying structure demands them. When developers use CSS absolute positioning, flexbox order reversal, or visual reordering to achieve a desired visual layout without correspondingly adjusting DOM order or tabindex, the visual layout and the traversal sequence desynchronize. A screen reader announces elements in DOM order; a keyboard user tabs in DOM or tabindex order; both encounter the page in the traversal sequence, not the visual one. The failure is invisible to reviewers who evaluate the interface visually, because the visual layout appears correct — the defect exists only in the non-visual linearization. WCAG 2.4.3 (Focus Order, Level A) addresses this directly, requiring that interactive elements receive focus in an order that preserves meaning and operability. Concrete failure modes include: a multi-column form whose right-column fields appear in the DOM after all left-column fields, separating paired fields by many tab stops; a modal dialog whose Close button appears in DOM before the dialog content, causing a screen reader to announce it before the user knows what they are closing; a wizard whose Next button receives focus before the question it advances; a kiosk whose Pay button is reached before Review.

Structural Signature¶

Sig role-phrases:

the focusable set — the finite collection of interactive nodes eligible to receive programmatic focus
the traversal order — the sequence focus actually advances in, fixed by DOM source order or explicit tabindex (and the AT linearization built from it)
the semantic task order — the logical sequence the form fields, wizard steps, or interactive elements require to complete the task
the visual-reordering cause — the typical culprit: CSS absolute positioning or flexbox order reversal achieving a layout without correspondingly adjusting DOM order or tabindex
the ordering divergence — the defect itself: the specific tab stops where traversal order departs from task order
the visual-review blindness — the failure lives entirely in the non-visual linearization, so a correct-looking screen can still be broken; for a sighted mouse user the two orders coincide
the focus-vs-reading-order split — within non-visual access, what receives focus next versus what is announced next are distinct sequences that fail independently
the premature-confirmation hazard — the safety-critical sub-case where a confirm/commit control (Close, Next, Pay) is reached before the content it acts on
the affected channel and outcome — the access modality where the mismatch bites (keyboard, screen reader, voice) and its result (error, exclusion, abandonment, unsafe action), resolved by resynchronizing DOM/tabindex to task order

What It Is Not¶

Not a visual-layout bug. The defect is not something a reviewer can see by looking at the rendered screen. It lives entirely in the non-visual linearization — the sequence a screen reader announces or a keyboard user tabs through — and a correct-looking layout can still be broken. For a sighted mouse user visual order and traversal order coincide, which is exactly why the gap stays invisible until the two orderings are deliberately held apart.
Not a discoverability problem. Focus-order failure is not about controls being hard to find or unknown to the user. It assumes the controls are discoverable and operable; the defect is that they are reached in the wrong order — the traversal sequence diverges from the semantic task order — so the user encounters known elements in a sequence that fails to carry the structure the task requires.
Not the same as reading order. Within non-visual access, focus order (what receives focus next, what a keyboard user reaches) is a distinct sequence from reading order (what is announced next). The two can fail independently and call for different fixes; treating them as one collapses two diagnoses, and a focus-order defect may exist where reading order is fine, or vice versa.
Not the general linearization-meaning mismatch. The portable parent pattern — a one-dimensional order that encodes some structure other than the one the consumer needs — is broader than this defect and travels to checklists, curriculum sequencing, and build-system topological sorts. Focus-order failure is the HCI-specific specialization, bound to programmatic focus, DOM/tabindex/CSS reordering, screen-reader linearization, and WCAG 2.4.3; a cockpit checklist asking step 4 before step 3 is the parent pattern, not this mechanism.
Not a multi-step workflow defect. The failure is the within-interface traversal inside a single step or screen, not the cross-step organization of a task flow. It concerns the order in which focus advances across the focusable nodes presently on the page, not whether the wizard's steps are sequenced correctly at the workflow level.

Scope of Application¶

Focus-order failure lives across the accessibility subfields of HCI — every interface modality with a traversal-order question, where the sequence focus advances can diverge from the task's semantic order; its reach is within that one substrate of interfaces with a focus/announcement traversal. The general linearization-meaning mismatch (a checklist asking step 4 before step 3, a build-system topological-sort failure) is carried by the parent linearization_meaning_mismatch pattern, and belongs to Knowledge Transfer.

Web accessibility — the canonical home, tab order and screen-reader linearization diverging from visual layout, governed by WCAG 2.4.3 (Focus Order, Level A).
Screen-reader linearization — where DOM source order is the announced order, so CSS-driven visual reordering desynchronizes what is seen from what is heard.
Mobile interfaces — the same focusable-set-versus-task-order question under touch and assistive-technology traversal on small screens.
Kiosk and public-service interfaces — hardware-wired focus advancing in panel order rather than task order, including the safety-critical Pay-before-Review case.
Voice UI and IVR menus — where the announced option order can diverge from the user's mental model of the task.
AR/VR interfaces — spatial focus traversal that must still carry the task's structure for non-visual or assisted users.

Clarity¶

Naming focus-order failure makes visible a defect class that visual review is structurally blind to. Because the failure lives entirely in the non-visual linearization — the sequence a screen reader announces or a keyboard user tabs through — and the rendered layout can look entirely correct, a reviewer who evaluates the interface by looking at it will not see it at all. The label tells that reviewer that a correct-looking screen can still be broken, and redirects the inspection to the traversal sequence rather than the pixels: walk the focusable elements in DOM and tabindex order, not in the order the eye reads them. It also pins the cause precisely — a desynchronization between traversal order (set by source order or explicit tabindex) and semantic task order (the logical sequence the form, wizard, or step demands) — so the practitioner knows the culprit is typically a visual reordering, via absolute positioning or flex order, that was never matched in the DOM.

The concept also sharpens two distinctions a sighted reading silently conflates. First, it pulls apart the visual order from the traversal order: for a sighted mouse user these coincide, so the gap between them is conceptually invisible until the failure mode is named and the two are held separate. Second, within non-visual access it distinguishes focus order (what receives focus next, what a keyboard user reaches) from reading order (what is announced next), two related sequences that can fail independently and call for different fixes. Together these turn the diffuse complaint "this form is hard to use with a screen reader" into a checklist-actionable question — enumerate the focusable nodes, traverse them, and mark every step where traversal order diverges from task order, including the safety-critical cases where a confirmation or Pay control is reached before the content it confirms.

Manages Complexity¶

"This form is hard to use with a screen reader" is a diffuse complaint with no obvious purchase: it implicates the whole interface, several assistive-technology channels at once (keyboard tabbing, screen-reader linearization, AT traversal), and a rendered layout that typically looks entirely correct, so a reviewer has no principled place to start and visual inspection is structurally blind to the defect. Focus-order failure compresses that diffuseness to a single comparison between exactly two orderings over the same finite set of nodes: the traversal order, fixed by DOM source order or explicit tabindex, and the semantic task order, fixed by the logical sequence the form, wizard, or step demands. The reviewer therefore stops reasoning about pixels and the open-ended space of "screen-reader usability" and instead tracks two sequences, reading the defect off their divergence via a finite, checklist-actionable procedure — enumerate the focusable elements, walk them in traversal order, and mark every step where traversal order departs from task order. The high-dimensional "why is this hard, and where, and for whom?" collapses to the low-dimensional "where do these two orderings disagree?", with the cause pinned in advance: a visual reordering (absolute positioning, flex order reversal) that was never matched in the DOM. The branch structure the construct exposes does the rest of the organizing work. First, the visual-versus-traversal fork: for a sighted mouse user the two coincide, which is exactly why the gap is invisible until the failure is named and the orderings are held apart — telling the reviewer to traverse in DOM and tabindex order, not in the order the eye reads. Second, within non-visual access, the focus-order-versus-reading-order fork: what receives focus next and what is announced next are distinct sequences that fail independently and call for different fixes. Third, a safety-critical sub-branch the same two-ordering check surfaces directly — the cases where a confirmation or Pay control is reached before the content it confirms (a Close button announced before the dialog, a Next button focused before its question, Pay before Review) — so the single divergence diagnostic flags not only ordinary task-structure breaks but the higher-severity premature-confirmation ones along the way.

Abstract Reasoning¶

Focus-order failure licenses an accessibility-review reasoning kit built on a single comparison between two orderings over the same finite set of focusable nodes.

Diagnostic — detect the defect from the divergence of traversal order and task order. The signature move enumerates the focusable elements, walks them in traversal order (set by DOM source order or explicit tabindex), and marks every step where that order departs from the semantic task order the form, wizard, or step demands. Reason FROM a divergence between the two sequences TO a focus-order defect localized to specific tab stops — for instance, paired fields separated by many tab stops because a right column was authored after the entire left column. The diffuse complaint "this form is hard to use with a screen reader" becomes the precise, checklist-actionable "where do these two orderings disagree?"

Boundary-drawing — redirect inspection from the pixels to the linearization. Because the failure lives entirely in the non-visual linearization while the rendered layout can look correct, the move tells the reviewer that visual inspection is structurally blind to it and that a correct-looking screen can still be broken. Reason FROM the fact that for a sighted mouse user visual order and traversal order coincide TO the conclusion that the gap is invisible until the two are deliberately held apart — so the inspection must traverse in DOM and tabindex order, not in the order the eye reads. The move relocates the evaluation from what is seen to what is announced or tabbed.

Diagnostic — separate focus order from reading order, and infer the cause. Within non-visual access the move distinguishes two sequences that fail independently: focus order (what receives focus next, what a keyboard user reaches) versus reading order (what is announced next), each calling for a different fix. Reason FROM which channel exhibits the drift TO which ordering is broken. It also pins the cause in advance: reason FROM an observed visual-versus-DOM mismatch TO a visual reordering — CSS absolute positioning, flexbox order reversal — that achieved a layout without correspondingly adjusting DOM order or tabindex, identifying the typical culprit before deeper investigation.

Diagnostic — flag the safety-critical premature-confirmation sub-case. The same two-ordering check surfaces a higher-severity branch directly: cases where a confirmation or commit control is reached before the content it confirms — a Close button announced before the dialog it closes, a Next button focused before its question, a Pay control reached before Review. Reason FROM a confirming element appearing earlier in traversal than the content it acts on TO a premature-confirmation hazard, so the single divergence diagnostic distinguishes ordinary task-structure breaks from the safety-critical ordering errors that invite confirming an unread action.

Interventionist — resynchronize the DOM and tabindex to the task order. The corrective move reasons FROM realigning source order (or correcting tabindex) so that traversal order matches the semantic task order TO restored operability for keyboard and screen-reader users, with the fix targeted at exactly the steps the divergence diagnostic marked. The predicted effect is that the non-visual linearization once again carries the structure the task requires, closing the gap that visual review could never see.

Knowledge Transfer¶

Within HCI and accessibility, focus-order failure transfers as mechanism, intact, across the interface modalities that share its two-ordering structure. The traversal-versus-task-order divergence diagnostic, the pixels-to-linearization redirection, the focus-order-versus-reading-order split, the premature-confirmation safety branch, and the resynchronize-the-DOM-and-tabindex fix all carry without translation from web pages (WCAG 2.4.3) to mobile, to kiosk and public-service interfaces, to AR/VR, and to voice/IVR menus, where the announced option order can diverge from the user's mental model. Only the traversal channel and the reordering culprit change — DOM and tabindex and CSS reordering on the web, hardware-wired focus order on a kiosk, menu sequence in a voice UI — while the underlying defect (a traversal sequence that fails to carry the structure the task requires, invisible to visual review) is the same. This is the home domain, and it is broad, but every member is an interface with a traversal-order question, which is why focus-order failure is a domain-specific (HCI/accessibility) abstraction rather than a substrate-spanning prime; even the seemingly-far cases the literature lists (medical devices, education platforms, control rooms) are still HCI substrates.

Beyond HCI the honest characterization (case B) is that the named defect does not travel, but the more general pattern it instantiates genuinely recurs across domains as co-instances — and it is that parent, not "focus-order failure," that should carry the cross-domain lesson. The general pattern is a linearization-meaning mismatch: any time an interface or apparatus imposes a one-dimensional order on a structured, parallel, or multi-dimensional underlying content, that linearization either carries the structure the consumer needs to act on or it does not. Stated that way, the same shape recurs well outside assistive technology — a surgical or aviation checklist whose retrofitted panel asks step 4 before step 3, instructional sequencing that presents a concept before its prerequisite, narrative ordering in a legal argument that buries the premise after the conclusion, even a topological-sort failure in a build system that schedules a dependency after its dependent. The cockpit-checklist case the literature lists as a "sibling" is exactly this: a sequence-meaning mismatch that is an instance of the general pattern, not of the focus mechanism, since it has no programmatic focus, no DOM, no screen-reader linearization.

So the division is clean. The portable content — "a linearization that encodes some structure other than the one the consumer needs will produce errors, exclusion, or unsafe premature action; check whether the imposed order carries the required structure" — should ride the general linearization_meaning_mismatch (or sequence-structure-mismatch) pattern, under each domain's own ordering vocabulary, when the lesson is needed in checklist design, curriculum sequencing, legal rhetoric, or build orchestration. Focus-order failure's own contribution — the two HCI-canonical channels (keyboard tab order and screen-reader linearization), the DOM/tabindex/CSS-reordering cause, the WCAG 2.4.3 standard, the focus-versus-reading-order distinction, and the assistive-technology severity framing — is the accessibility-specific cargo that specializes the general pattern and stays home. The general linearization-meaning-mismatch pattern travels via that parent; the named accessibility defect, with its focus-traversal machinery, stays in HCI, the boundary Structural Core vs. Domain Accent makes precise below.

Examples¶

Canonical¶

The defining instance is the CSS-reordered form, the exact pattern WCAG 2.4.3 (Focus Order) was written to catch. Consider a sign-in card whose HTML source lists, in order, a Submit button, then a username field, then a password field, but whose stylesheet uses a flexbox order property (or flex-direction: row-reverse) to render them visually as username, password, Submit — top to bottom, looking perfectly normal. A sighted mouse user clicks each in the visual order and notices nothing. But a keyboard user pressing Tab lands on Submit first, before either credential field; a screen reader announces "Submit button" before the user has encountered anything to submit. Nothing about the rendered screen reveals the defect; it exists only in the traversal sequence the DOM dictates.

Mapped back: The three controls are the focusable set; DOM order (Submit, username, password) is the traversal order while username→password→Submit is the semantic task order, and the flexbox order restyling is the visual-reordering cause creating the ordering divergence. Because the layout looks right, the case exhibits the visual-review blindness, and Submit being reached before the fields is the premature-confirmation hazard in its purest form.

Applied / In Practice¶

Public-sector accessibility programs bake this diagnostic into practice. The UK Government Digital Service, in the GOV.UK Design System and its guidance, explicitly tells teams not to use positive tabindex values and to make DOM order match the intended reading and interaction order, precisely so that Tab traversal and screen-reader linearization follow the task. Accessibility audits under these rules routinely catch multi-column patterns — for example a two-column form whose right-column fields are all authored in the DOM after the entire left column, so keyboard users must tab through every left field before reaching the paired right one — and the remedy applied is to reorder the source (or restructure the columns) so traversal matches the task.

Mapped back: The audit is the diagnostic run in the field: enumerate the focusable set and walk the traversal order against the semantic task order, flagging the ordering divergence that visual-review blindness would miss. The GDS rule against positive tabindex targets the visual-reordering cause preemptively, and the source-reorder remedy is the canonical resynchronize-DOM-to-task-order fix for the affected keyboard and screen-reader channels.

Structural Tensions¶

T1: A crisp two-ordering comparison versus a contested task order (the ground truth the diagnostic assumes). The concept's power is that it collapses "this form is hard with a screen reader" into a finite check: enumerate the nodes, walk the traversal order, mark where it departs from the semantic task order. But traversal order is read off the DOM, whereas task order is a judgment about what sequence the task logically demands — and that judgment is often genuinely contested. A two-column form has no single canonical order (row-major or column-major?); a Close button reached early may be a defect or an intended escape hatch; wizard fields can admit several defensible sequences. So the objective-looking divergence diagnostic silently rests on a subjective task-order model, and two reviewers with different mental models will flag different steps. The check is only as determinate as the ground truth it imports. Diagnostic: Is the "task order" being compared against an established, user-validated sequence, or one reviewer's assumption about how the task should flow?

T2: Invisibility as the concept's reason to exist versus invisibility as perpetual regression (the defect no one can see). Naming the failure is valuable precisely because it lives entirely in the non-visual linearization: a correct-looking screen can be broken, and visual review is structurally blind to it. But that same invisibility is a standing liability. Because sighted developers and reviewers literally cannot perceive the defect, it silently reappears with every visual restyle, and it resists cheap detection on both fronts — visual inspection misses it by construction, and automated tools can catch tabindex misuse but cannot verify that traversal matches a semantic order that only human judgment defines. So the property that makes the concept necessary is the property that makes the defect chronic: it is reintroduced by the very layout work that motivated the original mismatch, and requires deliberate non-visual traversal to catch each time. Diagnostic: Is there a standing non-visual traversal check in the workflow, or is detection relying on someone happening to tab through a screen whose defect is invisible to sight and to linters alike?

T3: Resynchronize the DOM versus the visual layout that caused the divergence (the fix competes with the design intent). The prescribed remedy — realign source order or correct tabindex so traversal matches task order — is stated as if it were free. But the divergence usually arose because a developer used CSS absolute positioning or flex reordering to achieve a visual layout that the natural DOM order would not produce, and simply reordering the source can undo that layout. Responsive multi-column designs, right-to-left flows, and visually-optimized arrangements can genuinely want a rendered order that differs from the ideal traversal order, so "just fix the DOM" can force a choice between the visual design and the accessible sequence, or a deeper restructure to satisfy both. The clean fix understates that visual and traversal order sometimes have legitimately competing requirements. Diagnostic: Can the DOM be reordered to match task order without sacrificing the visual layout, or do the two genuinely want different sequences here, forcing a restructure rather than a reorder?

T4: Focus order versus reading order (a sharpening that also doubles the check). Distinguishing what receives focus next (keyboard traversal) from what is announced next (screen-reader reading order) is a real clarity gain — the two fail independently and call for different fixes, and collapsing them merges two diagnoses. But the split cuts the other way too: a single "traversal" audit is now actually two audits, and a reviewer who verifies focus order can pass a screen whose reading order is still broken, or fix reading order while focus order remains wrong. The very independence that makes the distinction worth drawing means neither check certifies the other, and the premature-confirmation hazard can hide in whichever sequence went unexamined. Diagnostic: Has both focus order (what is tabbed to) and reading order (what is announced) been walked separately, or does a pass on one channel hide a failure on the other?

T5: Autonomy versus reduction (a named accessibility defect or the linearization-meaning parent). Focus-order failure is a specific, standard-backed HCI defect — bound to programmatic focus, DOM/tabindex/CSS reordering, screen-reader linearization, WCAG 2.4.3, and the focus-versus-reading distinction — and that accessibility-specific cargo is exactly what makes it actionable in situ. But its portable content is one level up: a one-dimensional order that encodes some structure other than the one the consumer needs will cause error, exclusion, or unsafe premature action, carried by the parent linearization_meaning_mismatch. A cockpit checklist asking step 4 before step 3, a curriculum presenting a concept before its prerequisite, a build-system topological-sort failure — these are co-instances of the parent, not of the focus mechanism (no DOM, no screen reader). Diagnostic: Resolve toward linearization_meaning_mismatch when the lesson is needed in checklist, curriculum, or build-orchestration design; toward the named focus-order failure when auditing an actual interface's keyboard and screen-reader traversal in situ.

Structural–Framed Character¶

Focus-order failure sits at the framed-leaning position on the structural–framed spectrum: it is a defect wholly constituted by human-designed interface artifacts and a standards regime, yet it specializes a genuinely portable structural skeleton, so it does not reach the framed pole where a purely practice-internal verdict like ad hominem lives. On evaluative_weight it carries a mild framed charge: to name something a "focus-order failure" is to classify it as a defect — a fault, a WCAG 2.4.3 violation — not a neutral mechanism the way "feedback" is, but the charge is engineering-normative (a departure from a conformance spec) rather than a rich moral or dialectical verdict, so it registers framed only softly. On human_practice_bound it is emphatically framed: the concept is constituted by the practice of building and traversing interfaces and dissolves the instant that practice is removed — take away the DOM, the tab key, the screen-reader linearization, the very notion of "focus" advancing across "focusable nodes," and there is nothing left, because none of these exist observer-free in nature the way a lithosphere rebounds with every geophysicist absent. Institutional_origin is equally pronounced: the entry is an artifact of a specific engineering tradition — the WCAG standard, the tabindex/DOM machinery, the GOV.UK Design System guidance — distinctions drawn inside web-accessibility practice, not facts someone merely named. On vocab_travels it scores low: DOM source order, tabindex, flexbox reordering, screen-reader linearization, focus-versus-reading order are all pinned to the HCI substrate and lose their referents off it. And on import_vs_recognize it patterns as parent-instance rather than named-mechanism recognition: a cockpit checklist that asks step 4 before step 3 is not "focus-order failure" recognized in a new substrate but a co-instance of the broader mismatch pattern — it has no programmatic focus at all.

The one genuinely portable structural skeleton is linearization_meaning_mismatch — a one-dimensional traversal order imposed on structured, parallel content that encodes some ordering other than the one the consumer needs, producing error, exclusion, or unsafe premature action. That skeleton is substrate-spanning and recurs as mechanism in checklists, curriculum sequencing, legal rhetoric, and build-system topological sorts, which is exactly what tempts a structural reading. But it does not pull focus-order failure off the framed side, because that mismatch pattern is precisely what the entry instantiates from its umbrella, not what makes "focus-order failure" itself travel: the cross-domain reach belongs to linearization_meaning_mismatch, while the domain-accented specifics — the DOM/tabindex/CSS cause, the WCAG standard, the screen-reader channel, the focus-versus-reading split — stay home in accessibility. Its character: a mildly-evaluative, thoroughly practice-and-standard-constituted interface defect, structural only in the linearization-meaning-mismatch skeleton it borrows from its umbrella and pins to programmatic focus.

Structural Core vs. Domain Accent¶

This section decides why focus-order failure is a domain-specific abstraction and not a prime — its portable content sits one level up, in the parent pattern it instantiates, while its actionable machinery is bound to the interface substrate.

What is skeletal (could lift toward a cross-domain prime). Strip away the DOM, the tab key, and the screen reader and a thin relational structure survives: a one-dimensional traversal order is imposed on a structured, parallel, or multi-dimensional content, and that imposed order encodes some sequence other than the one the consumer needs to act — so following it produces error, exclusion, or unsafe premature commitment. The portable pieces are abstract — a set of elements, a linear order actually walked over them, a distinct order the task logically demands, and the divergence between the two — and this is genuinely substrate-spanning, which is exactly why it recurs in the catalog as the parent the entry instantiates, linearization_meaning_mismatch. That skeleton is the core focus-order failure shares with a mis-sequenced checklist or a build-system topological-sort error; it is not what makes the HCI defect distinctive.

What is domain-bound. Almost everything that makes it focus-order failure in particular is web-accessibility furniture and none of it survives extraction: programmatic focus advancing across a focusable set; the traversal order fixed by DOM source order or explicit tabindex; the visual-reordering cause (CSS absolute positioning, flexbox order, row-reverse); the screen-reader linearization channel; the focus-order-versus-reading-order split; the WCAG 2.4.3 (Focus Order, Level A) conformance standard and GOV.UK Design System guidance that classify it as a defect; and the resynchronize-the-DOM-and-tabindex fix. The decisive test: remove the interface artifact and the assistive-technology traversal that reads it, and there is nothing left to be "out of order" — a cockpit checklist that asks step 4 before step 3 exhibits the parent mismatch but has no programmatic focus, no DOM, no screen reader, so it is not this defect at all. The mechanism is constituted by the very interface-and-standards practice the prime bar asks it to shed.

Why this does not clear the prime bar. A prime's vocabulary travels and its cross-domain transfer is recognition of the same mechanism, not analogy. Focus-order failure's transfer is bimodal. Within HCI it travels intact — the two-ordering divergence diagnostic, the pixels-to-linearization redirection, the focus-versus-reading split, the premature-confirmation safety branch, and the DOM/tabindex fix all carry without translation from web pages to mobile, kiosk, voice/IVR, and AR/VR interfaces; only the traversal channel and the reordering culprit change while the defect stays the same. That is recognition of one mechanism across a broad-but-single substrate — every member is an interface with a traversal-order question. Beyond HCI, the named defect does not travel: a surgical checklist, a curriculum presenting a concept before its prerequisite, a legal argument burying the premise after the conclusion, a build system scheduling a dependency after its dependent are co-instances of the parent pattern, reached only by dropping the focus machinery and renaming the ordering — analogy, not the focus mechanism recognized anew. And when the bare structural lesson — check whether an imposed linear order carries the structure the consumer needs — is genuinely required in checklist design, curriculum sequencing, legal rhetoric, or build orchestration, it is already carried, in more general form, by linearization_meaning_mismatch, under each domain's own ordering vocabulary. The cross-domain reach belongs to that parent; the named entry carries accessibility-specific cargo — the focus-traversal channels, the DOM/tabindex/CSS cause, the WCAG standard — that should stay home. It clears the domain-specific bar comfortably for HCI and accessibility, but its only substrate-spanning content is already the parent's, which is what keeps it below the prime bar.

Relationships to Other Abstractions¶

Current abstraction Focus-Order Failure Domain-specific

Parents (1) — more general patterns this builds on

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

Focus-Order Failure → Linearization-Meaning Mismatch → Representational Structure Mismatch → Representation → Abstraction

Show alternative paths (3)

Not to Be Confused With¶

Reading order (screen-reader linearization). The sequence in which content is announced — what a screen reader reads next — as distinct from focus order, the sequence in which interactive nodes receive focus, which is what a keyboard user tabs to next. Within non-visual access these are two orderings that fail independently and call for different fixes. Tell: is the drift in what is spoken next as the reader traverses static and interactive content (reading order), or in which control the Tab key lands on next (focus order)?
Focus Visible failure (WCAG 2.4.7). The distinct defect where the focus indicator is not perceivable — the user cannot see which element currently holds focus. It concerns whether the current focus is visible, not whether focus advances in the right sequence. Tell: can the user tell where focus is right now (a 2.4.7 question), or is focus moving through the elements in the wrong order (focus-order failure, 2.4.3)?
Keyboard trap (WCAG 2.1.2). The defect where focus enters a component and cannot advance or escape by keyboard — the traversal is blocked rather than mis-sequenced. Focus-order failure assumes focus moves freely but in the wrong order; a keyboard trap is focus that cannot move on at all. Tell: does Tab progress through the controls but in a task-breaking sequence (focus-order failure), or does it get stuck on an element with no way forward (keyboard trap)?
Positive tabindex misuse. A cause, not the defect itself: assigning tabindex values greater than zero forces a custom traversal sequence that overrides DOM order. It is one of the specific culprits that produces the ordering divergence, standing in a part-to-whole relation to the failure. Tell: is the object the authoring practice that created the mismatch (positive tabindex), or the resulting divergence of traversal order from task order (the failure)?
Task-flow / wizard step-sequencing defect. A wrong ordering at the workflow level — the steps of a multi-step task presented in the wrong sequence. Focus-order failure is the within-screen traversal across the focusable nodes present on a single step, not the cross-step organization of the flow. Tell: is the wrong order between the stages of the task (workflow defect), or between the controls inside one screen or step (focus-order failure)?
The linearization-meaning-mismatch parent (umbrella). The broad, substrate-spanning pattern focus-order failure instantiates — any one-dimensional order imposed on structured content that encodes a sequence other than the one the consumer needs, recurring in cockpit checklists, curriculum sequencing, and build-system topological sorts. Those co-instances have no programmatic focus, DOM, or screen reader. Tell: is there interface traversal machinery — focus advancing across focusable nodes read by assistive technology (focus-order failure) — or merely an abstract imposed order over structured content (the parent pattern)? (Treated fully in a later section.)

Neighborhood in Abstraction Space¶

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

Family — Surface Form & Underlying Structure (23 abstractions)

Nearest neighbors

Computed from structural-signature embeddings · 2026-07-12