Keyboard Trap¶

The accessibility failure where a keyboard-only user moves focus into a UI element that receives focus but never yields it — an absorbing state in the focus-navigation graph, invisible to mouse users because a click supplies the exit edge they lack.

Core Idea¶

A keyboard trap is the web and UI accessibility failure mode in which a user navigating an interface by keyboard alone — a screen-reader user, a user with motor disabilities using switch access or sip-and-puff input, or a power user preferring keyboard-only operation — moves focus into a UI element or region from which they cannot exit using keyboard input. The interface continues to accept keyboard events as input to the trapped element but does not forward standard focus-movement keys (Tab, Shift+Tab, Escape) outward to the focus-management layer that would advance focus through the rest of the page or close the containing widget. The user is stranded: every available keyboard action either operates within the trap or is silently consumed by it, with no reachable path to any other element of the interface, including any control that would dismiss, close, or navigate away from the trapping widget.

The structural commitment is an asymmetry of focus entry and focus exit in a navigation graph. An interactive element that receives focus on Tab entry creates a node in the interface's directed navigation graph; that node must have outgoing edges — keyboard-triggered transitions that move focus outward — to be accessible. A keyboard trap is an absorbing state in that graph: a node (or subgraph) that is reachable from the rest of the graph via inbound Tab transitions but has no keyboard-reachable outbound transitions back into the navigable region. For a mouse user, this is invisible: a click anywhere outside the element exits it trivially. For a keyboard-only user, the navigation graph is the entire interface; an absorbing state is a no-exit room.

The failure appears in several implementation patterns. A custom modal dialog that correctly contains focus within itself while open becomes a keyboard trap when no keyboard-reachable close affordance exists and the Escape key is not wired to dismiss. Third-party embedded widgets — date pickers, rich-text editors, video players, OAuth-flow iframes — frequently implement Tab cycling within the widget without forwarding Tab past the last child or Escape to a close handler, trapping any user who Tabs into them. Iframes in some browser/OS combinations do not yield Tab focus to the parent page, requiring mouse interaction to exit. Plugin-hosted content (historically Flash, embedded PDF viewers, media players) captured keyboard input without participating in the host page's tab order. Custom controls that implement tabindex for focus receipt but omit any keydown handlers for focus exit produce the same absorbing state.

The WCAG 2.1.2 "No Keyboard Trap" success criterion at Level A is directly targeted at this failure, requiring that if focus can be moved to a component using keyboard, focus can also be moved away using only keyboard, and documenting that if more than standard navigation keys are required (e.g., Escape to close), the method must be described to the user. The intervention is structural: wire Escape to close any modal or composite widget; wire Tab past the last child and Shift+Tab before the first child to advance and retreat focus through the surrounding tab order; provide an explicit keyboard-reachable close affordance within every focus-containing container; prefer native HTML form controls and dialog elements whose browser-level Tab behaviour is correct; and include keyboard-only and screen-reader navigation testing in every acceptance cycle so traps are caught before deployment.

Structural Signature¶

Sig role-phrases:

the keyboard-only user — a screen-reader, switch/sip-and-puff, or keyboard-preferring user whose entire interface is the focus-navigation graph
the navigation graph — the interface recast with focusable elements as nodes and keyboard-triggered focus transitions as edges
the focusable container — an element or region wired to receive focus on Tab entry, creating an inbound edge
the missing exit transitions — Tab past the last child does not advance, Shift+Tab before the first does not retreat, Escape does nothing, and no keyboard-reachable close affordance exists
the absorbing state — the container as a node reachable by inbound Tab but with no keyboard-reachable outbound edge: a no-exit room
the exhausted action modality — every available keyboard action operates within or is silently consumed by the trap, with no input affordance mapping to exit
the WCAG 2.1.2 invariant — the checkable structural criterion: if focus can be moved to a component by keyboard, it can be moved away by keyboard
the outbound-edge intervention — wire Escape to close, forward Tab/Shift+Tab through the surrounding order, supply a keyboard-reachable close affordance, prefer native dialog/form controls, and make keyboard-only testing part of every acceptance cycle

What It Is Not¶

Not user error. "They couldn't figure out how to leave" relocates the fault to the person; the defect is the interface's — an element wired to receive focus but not to yield it, an absorbing state with no keyboard-reachable outbound edge. The failure lives in the state-space-versus-modality joint, not in the stranded user.
Not "works for me." The trap is invisible from the default mouse-testing posture, where a click anywhere exits any element trivially; the mouse supplies an exit edge the keyboard user lacks. A non-reproduction from a mouse user is expected, not evidence the bug is absent — for a keyboard-only user the focus graph is the interface.
Not an intended focus trap. Containing focus inside an open modal is correct, accessible practice. The defect is containment without a keyboard-reachable exit (no Escape wiring, no reachable close affordance, no Tab forwarding past the last child) — so the fix is to add the missing outbound edge, never to abandon focus management altogether.
Not lock-in. Lock-in is a forward-looking switching cost — leaving is expensive but possible. A keyboard trap is an instantaneous absence of any exit transition: not cost-of-leaving but absence-of-leaving, a no-exit room rather than an expensive door.
Not focus theft. Focus theft is an inbound edge firing involuntarily — focus jumping to an unexpected element. A keyboard trap is the opposite condition: focus is where the user put it but has no outbound edge. Different mechanism, different remedy.
Not tab-order discontinuity. A discontinuity is a mislabelled or skipped edge — focus advancing in a surprising order — but exit still exists. The trap is the stronger failure where no keyboard-reachable exit edge exists at all.
Not the inert background region. A region deliberately made non-focusable behind an open modal is the trap's harmless complement — a node correctly given no inbound edge — not a failure. The trap is a node with an inbound edge and no outbound one; the inert region has neither and strands no one.

Scope of Application¶

Keyboard trap lives within HCI and accessibility engineering — wherever an interface is navigated by focus-driven keyboard or switch input and a focusable container receives focus without yielding it; its reach is within that domain, the habitats being the implementation patterns that produce an absorbing state in the focus graph. The cross-substrate analogues (a phone-tree branch with no "back," a bureaucratic dead-end) belong to the parent absorbing_state_under_restricted_modality, of which this is the focus-graph instance.

WCAG 2.1.2 "No Keyboard Trap" — the Level A success criterion written directly for this failure, requiring that focus movable to a component by keyboard be movable away by keyboard; the canonical conformance home of the concept.
Modal-dialog implementations — the intended focus trap (focus contained while a modal is open) becoming the failure when no keyboard-reachable close affordance exists and Escape is not wired to dismiss.
Third-party embedded widgets — date pickers, rich-text editors, video players, and OAuth-flow iframes that cycle Tab internally without forwarding it past the last child or Escape to a close handler.
Iframe / cross-origin focus management — a focused iframe in some browser/OS pairings refusing to yield Tab to the parent page, requiring mouse interaction to exit.
Plugin-hosted content — legacy Flash, embedded PDF viewers, and media players capturing keyboard input without participating in the host page's tab order.
Custom keyboard widgets — developer-built spinners, combo-boxes, and listboxes wired for tabindex focus receipt but omitting the keydown handlers that would forward focus out.
Switch / scan access devices — single-key-input methods where the user's only action is "advance," making an absorbing state especially severe since no alternate exit input exists.
Mobile screen-reader navigation — TalkBack/VoiceOver swipe-to-advance focus rings stuck in modal-like regions without exit gestures wired.

Clarity¶

The label's first clarifying move is to make a modality-relative failure visible to developers who do not experience it. For a mouse user the trapping widget is unremarkable — a click anywhere outside exits it trivially — so the defect is literally undetectable from the default testing posture, and bug reports read as "works for me." Naming keyboard trap, and recasting the interface as a navigation graph in which the keyboard user's only edges are focus transitions, exposes the asymmetry that matters: an element wired to receive focus but not to yield it is an absorbing state, and for someone whose entire interface is that graph it is a no-exit room. The concept thus relocates the fault from the user ("they couldn't figure out how to leave") to the interface (a missing outbound transition), and gives the bug a shape that automated focus-graph analysis and keyboard-only test passes can actually catch.

Its second service is to draw a line that a careless reading erases: between an intended focus trap and the failure. Containing focus inside an open modal is correct, accessible practice — the defect is not containment but containment without a keyboard-reachable exit (no Escape wiring, no reachable close affordance, no Tab forwarding past the last child). Holding that distinction keeps developers from "fixing" the problem by abandoning focus management altogether, and separates keyboard trap cleanly from neighbours it gets confused with: focus theft (focus moving involuntarily), tab-order discontinuity (focus skipping or jumping), and the deliberately inert background region (the trap's harmless complement). The sharpened question the practitioner can now ask of any focus-containing container is exact and checkable: from every element reachable by keyboard, is exit also reachable by keyboard? — the structural invariant that WCAG 2.1.2 encodes and that defines an accessible navigation graph.

Manages Complexity¶

The places this failure hides are, listed out, a miscellany with no obvious common test: a custom modal with no Escape wiring, a third-party date picker that cycles Tab among its own cells, an embedded rich-text editor or video player that swallows focus-movement keys, an OAuth-flow iframe that will not yield Tab to the parent in some browser/OS pairings, legacy plugin content that captured the keyboard outside the host's tab order, a hand-rolled combo-box wired for tabindex receipt but with no keydown exit handler. Audited widget by widget and browser by browser, each is its own special case with its own quirks, and the combinatorial product of widgets × containers × browsers is too large to certify by inspection. The keyboard-trap concept collapses that whole catalogue by recasting the interface as a single object — a directed navigation graph whose nodes are focusable elements and whose edges are keyboard-triggered focus transitions — so the implementation details become incidental and the only property that matters is graph-theoretic. The analyst stops tracking modal-versus-iframe-versus-plugin idiosyncrasies and tracks one invariant evaluated at every focus-containing node: does this node, reachable by inbound Tab, also have a keyboard-reachable outbound transition back into the navigable region, or is it an absorbing state? From that single check the qualitative verdict reads off directly — an element wired to receive focus but not to yield it is a no-exit room for the keyboard-only user, accessible otherwise — with no need to reason about why each particular widget fails. This is exactly the invariant WCAG 2.1.2 encodes ("if focus can be moved to a component by keyboard, it can be moved away by keyboard"), and because it is a reachability property of a graph it is mechanisable: a focus-graph analysis or a keyboard-only test pass enumerates the focusable containers and reads exit-reachability off each, catching every member of the catalogue and any not-yet-seen widget by the same test rather than by per-widget folklore. The branch structure is equally compressed and matters because it routes the fix: the same reframing sorts the genuine failure from the things it is confused with — an intended focus trap (containment is correct; the defect is containment without a keyboard-reachable exit), focus theft (an inbound edge firing involuntarily), tab-order discontinuity (mislabelled edges), and the deliberately inert background region (a node correctly given no inbound edges, the trap's harmless complement) — so that the response is "add the missing outbound edge" rather than the over-correction of abandoning focus management altogether. The intervention space collapses to that one structural prescription instantiated a few ways (wire Escape to close, forward Tab past the last child and Shift+Tab before the first, supply a keyboard-reachable close affordance, prefer native controls whose browser-level exit behaviour is already correct), and the modality reframing fixes responsibility on the interface's missing edge rather than on the user — turning a scatter of "works for me" non-reproductions into one checkable graph invariant.

Abstract Reasoning¶

Keyboard trap licenses reasoning moves that all proceed from recasting the interface as a directed navigation graph — nodes are focusable elements, edges are keyboard-triggered focus transitions — and checking one graph invariant. The most distinctive is a diagnostic move that is modality-relative and overturns a default non-reproduction. When a defect reads as "works for me," the analyst reasons that the report came from the default testing posture of a mouse user, for whom a click anywhere exits any element trivially, so the trapping widget is literally undetectable from that vantage. Recasting the keyboard-only user's experience as the graph itself — their only edges are focus transitions — the analyst infers the fault is an element wired to receive focus but not to yield it: an absorbing state, reachable by inbound Tab but with no keyboard-reachable outbound transition. The reasoning relocates the fault from the user ("they couldn't figure out how to leave") to the interface (a missing outbound edge), and predicts the failure is invisible to mouse testing precisely because the mouse supplies an exit edge the keyboard user lacks.

The governing move is a boundary-drawing check of a single structural invariant evaluated at every focus-containing node: from every element reachable by keyboard, is exit also reachable by keyboard? Reasoning from this reachability property, the analyst reads the verdict off each node directly — a node with an inbound Tab edge and no keyboard-reachable outbound edge is a no-exit room, accessible otherwise — without reasoning about why any particular widget fails. Because the property is graph reachability, the analyst treats it as mechanisable: a focus-graph analysis or a keyboard-only test pass enumerates the focusable containers and reads exit-reachability off each, so the same check catches a modal, an iframe, a plugin, a custom combo-box, and any not-yet-seen widget by one test rather than per-widget folklore. This is the invariant WCAG 2.1.2 encodes, so the analyst reasons from a checkable structural criterion rather than from a catalogue of implementation quirks.

A second boundary-drawing move separates the genuine failure from look-alikes, and it is load-bearing because it routes the fix and prevents an over-correction. The analyst reasons that containment of focus inside an open modal is correct, accessible practice — the defect is containment without a keyboard-reachable exit (no Escape wiring, no reachable close affordance, no Tab forwarding past the last child) — so the response is to add the missing outbound edge, not to abandon focus management altogether. From the same graph framing the analyst distinguishes the trap from focus theft (an inbound edge firing involuntarily), from tab-order discontinuity (mislabelled or skipped edges), and from a deliberately inert background region (a node correctly given no inbound edge — the trap's harmless complement), assigning each a different remedy.

The interventionist move reasons forward from "the absorbing state needs an outbound edge" to a fixed structural prescription with a predicted effect, instantiated a few ways: wire Escape to close any modal or composite widget; forward Tab past the last child and Shift+Tab before the first child to advance and retreat focus through the surrounding tab order; supply an explicit keyboard-reachable close affordance within every focus-containing container; and prefer native HTML form and dialog controls whose browser-level exit behaviour is already correct over custom controls that omit keydown exit handlers. Each move is reasoned as installing the missing outbound transition, and the analyst predicts that adding any one keyboard-reachable exit converts the absorbing state back into a pass-through node. The reasoning closes with a process prediction: because the failure is invisible to the default mouse posture, it will keep shipping unless keyboard-only and screen-reader navigation are made part of every acceptance cycle — so the analyst reasons that the test posture, not just the code, must change. The recurring habit the concept installs is to ask of any focus-containing container not "does it work?" but, for every element reachable by keyboard, whether exit is reachable by keyboard too.

Knowledge Transfer¶

Within accessibility and UI engineering the concept transfers as mechanism, because its load-bearing object — the interface recast as a directed navigation graph with one graph-reachability invariant ("from every keyboard-reachable element, is exit also keyboard-reachable?") — is implementation-agnostic. The same check, the same WCAG 2.1.2 criterion, and the same structural prescription (wire Escape to close, forward Tab past the last child and Shift+Tab before the first, supply a keyboard-reachable close affordance, prefer native dialog and form controls) carry without translation across the failure's hiding places: custom modals, third-party date pickers and rich-text editors and video players, OAuth-flow iframes that will not yield Tab in some browser/OS pairings, legacy plugin content, hand-rolled combo-boxes, and into the mobile screen-reader analogue (TalkBack/VoiceOver swipe-to-advance rings stuck in modal-like regions) and switch/scan access (where the user's only input is "advance," making an absorbing state especially severe). The modality reframing — for a keyboard-only or switch user the focus graph is the interface — and the disability-as-mismatch framing (the fault is the interface's missing edge, not the user) carry across all of these too. The vocabulary does not strain because they are one substrate: focus-driven UI navigation.

Beyond UI the honest account is a shared abstract mechanism — case (B). Strip the accessibility idiom and a substrate-neutral structure remains: an actor enters a state from which the actor's available modality of action includes no affordance that exits, while the actor's modality of perception keeps receiving input that re-enters or cycles within the state — an absorbing state relative to a restricted action set. That structure genuinely recurs across distinct substrates as co-instances, not resemblances — a phone-tree branch with no "back," "operator," or "main menu" option; a bureaucratic process step whose only forward routes are unreachable to the claimant and whose help-desk paths loop; a carceral or immigration administrative state with no procedural exit accessible to a person's lawful options; a database record stuck in an error queue with no automatic re-entry; a conversational move (defensive denial, sealioning) whose available rhetorical affordances make productive exit impossible; a recommendation loop whose next-content options all return to the same cluster; a save state with no feasible action set. In each, the general pattern — an actor stranded in a state their action modality cannot exit, with the fault living in the state-space-versus-modality joint rather than in the actor — is the thing that travels and carries a real, transferable lesson: audit reachable states for a modality-reachable exit, and locate the defect in the missing transition, not in the stranded actor. What does not travel is the entire named apparatus of keyboard trap: Tab, Shift+Tab, Escape, focus management, tab order, screen readers, and WCAG 2.1.2 are HCI furniture that does not survive extraction. So when the cross-domain lesson is wanted, the honest move is to carry the parent — an absorbing state under a restricted modality of access (the emergent absorbing_state_under_restricted_modality, of which keyboard trap is the focus-graph instance) — not the term "keyboard trap," whose machinery is substrate-bound. The disability-rights origin of the concept is, usefully, what makes the joint nature of the failure explicit, which is exactly why it serves as a good pedagogical seed for the broader pattern while remaining itself a domain-specific abstraction (see Structural Core vs. Domain Accent).

Examples¶

Canonical¶

Consider a custom "newsletter signup" modal built from generic div elements rather than the native dialog element. When it opens, the developer correctly contains focus inside it — good practice, since a keyboard user should not Tab out into the dimmed page behind. But the close button is a clickable icon with no keyboard handler, Escape is not wired to dismiss, and Tab past the last field cycles back to the first rather than forwarding out. A mouse user clicks the X or the page behind and moves on; a keyboard-only user who Tabs into the modal can never leave — every Tab, Shift+Tab, and Escape is consumed inside. Recast as a navigation graph, the modal is an absorbing state: reachable by inbound Tab, with no keyboard-reachable outbound edge. This is exactly the failure WCAG 2.1.2 "No Keyboard Trap" (Level A) forbids.

Mapped back: The modal is the focusable container with a valid inbound edge; the unwired Escape, unreachable close icon, and self-cycling Tab are the missing exit transitions. Together they make it the absorbing state in which the exhausted action modality leaves the keyboard-only user stranded — the precise condition the WCAG 2.1.2 invariant checks for.

Applied / In Practice¶

Public-sector accessibility law makes the fix a shipping requirement. In the UK, the Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations 2018 require government services to meet WCAG 2.1 AA — which includes the Level A "No Keyboard Trap" criterion — and to publish an accessibility statement. The Government Digital Service responds structurally rather than per-bug: its GOV.UK Design System ships pre-built, keyboard-tested components (Escape wired to close, correct Tab forwarding, reachable close affordances), and teams are instructed to test every service with the keyboard alone and with screen readers before release. Rather than trust that each hand-rolled widget yields focus, the program supplies native-behaving components and bakes keyboard-only testing into the acceptance cycle — applied across an entire government's digital estate.

Mapped back: Shipping components with Escape-to-close and Tab forwarding, and preferring native-behaving controls, is the outbound-edge intervention deployed at scale. Requiring conformance to WCAG 2.1 AA operationalizes the WCAG 2.1.2 invariant as law, and mandatory keyboard-only and screen-reader test passes ensure the failure is caught from the keyboard-only user's vantage rather than the default mouse posture.

Structural Tensions¶

T1: Intended containment versus the trap (the fix that must not overshoot). Containing focus inside an open modal is correct, accessible practice — a keyboard user should not Tab out into the dimmed page behind. The defect is not containment but containment without a keyboard-reachable exit: no Escape wiring, no reachable close affordance, no Tab forwarding past the last child. The two look nearly identical in the code, and the diagnosis cuts both ways: a developer who reads "keyboard trap" as "focus containment is bad" over-corrects by abandoning focus management altogether, producing the different failure of a modal that leaks focus to the background. The remedy is precisely surgical — add the one missing outbound edge, keep the containment — and the concept earns its keep only if the line between the intended focus trap and the failure is held sharp. Diagnostic: Is focus being contained (correct) or contained with no keyboard-reachable exit (the failure) — and does the proposed fix add an exit edge or delete the containment?

T2: Modality-relative invisibility versus the default test posture (the bug the reporter cannot see). For a mouse user the trapping widget is unremarkable — a click anywhere outside exits it trivially — so the defect is literally undetectable from the default testing posture, and reports read as "works for me." This is a double bind: the very actor most likely to file a bug is the one for whom the bug does not exist, because the mouse supplies an exit edge the keyboard user lacks. The consequence is that the failure keeps shipping not because the code is hard to fix but because the test channel that would catch it is absent. The concept's payoff is therefore procedural as much as structural: it predicts that no amount of mouse-driven QA will surface the trap, and that the test posture itself — keyboard-only and screen-reader passes in every acceptance cycle — must change. Diagnostic: Was this "non-reproduction" produced from a mouse posture, where an exit edge is always supplied, or from a keyboard-only pass where the focus graph is the whole interface?

T3: The mechanisable graph invariant versus environment-dependent traps (when the static read misses the live failure). Recasting the interface as a directed navigation graph turns a miscellany of widget quirks into one reachability property — from every keyboard-reachable node, is exit keyboard-reachable? — that a focus-graph analysis can read off mechanically. But some traps are not properties of the static DOM at all: an iframe that will not yield Tab to the parent, or legacy plugin content that captures the keyboard, fails only in particular browser/OS pairings and only once rendered live. A static enumeration of focusable containers can pass while the running combination strands the user, because the missing edge is contributed by the host environment, not the markup. The tension is between the invariant's clean mechanisability and the empirical fact that exit-reachability must sometimes be observed at runtime across environments, not proved from source. Diagnostic: Is exit-reachability being verified against the static focus graph, or exercised in the live browser/OS/plugin combination where the missing edge actually appears?

T4: Formal exit-reachability versus discoverable exit (the undocumented Escape). WCAG 2.1.2 permits more than standard navigation keys — Escape to close a composite widget — provided the method is described to the user. This opens a gap between formal and functional conformance: a widget whose only exit is an unadvertised Escape keypress satisfies the graph invariant (an outbound edge exists) yet functions as a trap for any user who does not know the edge is there and finds Tab, Shift+Tab, and the visible controls all cycling inward. Adding exotic exit keys to satisfy the letter of the criterion can leave the spirit unmet; the safest exits are the ones the interface makes reachable and announces. The tension is that the invariant scores an edge as present the moment it exists in the mapping, while a user only benefits from an edge they can find. Diagnostic: Is the exit edge merely present in the focus graph, or is it also discoverable — a visible, reachable close affordance or a documented key — from inside the container?

T5: Native controls versus custom widgets (correctness bought against expressiveness). The most reliable prescription is to prefer native HTML dialog and form controls, whose browser-level Tab and Escape behaviour is already correct, over hand-rolled controls that omit keydown exit handlers. But the widgets that most often trap — date pickers, rich-text editors, video players, combo-boxes — are exactly the rich interactions native elements do not fully provide, which is why they are custom in the first place. So the safe default collides with the demand for expressive UI: every step toward a bespoke control re-opens the exact absorbing-state risk the native element foreclosed, and every retreat to native controls narrows what the interface can do. The concept does not dissolve this trade-off; it locates it, telling the builder that custom expressiveness carries a specific, testable liability — a possibly missing outbound edge — that native controls discharge for free. Diagnostic: Does this interaction genuinely require a custom control, and if so, has the outbound-edge check that native controls pass automatically been re-performed by hand?

T6: Autonomy versus reduction (its own named failure or the focus-graph instance of its parent). "Keyboard trap" is a canonically named HCI failure with its own apparatus — Tab, Shift+Tab, Escape, focus management, tab order, screen readers, and the WCAG 2.1.2 criterion — none of which survives extraction from the domain. What travels beyond UI is the substrate-neutral parent it instantiates: absorbing_state_under_restricted_modality, an actor stranded in a state whose available action modality contains no exit affordance while perception keeps re-entering it, the fault living in the state-space-versus-modality joint rather than in the actor. A phone tree with no "back," a bureaucratic dead-end, a save state with no feasible action set are co-instances of that parent, not of keyboard trap — there is no Tab key in a phone tree, only an absorbing state under a restricted modality. The tension is between a domain-specific label that earns its own study (and whose disability-rights origin usefully makes the joint nature explicit) and the recognition that its cross-domain cargo already belongs to the parent. Diagnostic: Resolve toward the parent (absorbing_state_under_restricted_modality) when carrying the lesson outside focus-driven UI; toward "keyboard trap" when diagnosing a focusable container's exit-reachability in situ.

Structural–Framed Character¶

Keyboard trap is best placed framed-leaning: it is a named accessibility failure mode — an evaluative defect-verdict, practice-bound, and standards-codified — resting on a clean graph-reachability kernel. The five criteria mostly point framed. Evaluative_weight is high: "keyboard trap" names a failure, a defect, a WCAG 2.1.2 violation — to apply the label is to convict an interface of stranding a user, a fault-finding verdict rather than a neutral description; the entry's whole force is diagnosing and forbidding a defect. Human_practice_bound is high: focus, Tab, Escape, screen readers, and the assistive-technology population are artifacts of the interface-design practice, and the failure exists only inside focus-driven UI; strip that practice and there is no keyboard trap. Institutional_origin is framed for the named criterion: WCAG 2.1.2 "No Keyboard Trap" and the disability-rights conformance apparatus are authored standards, not facts read off nature — though the underlying absorbing-state structure is not itself an institutional invention. Vocab_travels is low for the distinctive layer: Tab/Shift+Tab/Escape, focus management, and WCAG furniture have no referent once the "modality" is a phone tree or a bureaucratic process. Only import_vs_recognize has structural texture: within focus-driven UI the concept transfers as literal mechanism, and beyond it the parent carries genuine co-instances (phone-tree dead-ends, bureaucratic no-exits) — as the parent, not as keyboard trap.

The portable structural skeleton is an absorbing state under a restricted modality — an actor stranded in a state whose available action modality contains no exit affordance while perception keeps re-entering it, the fault living in the state-space-versus-modality joint rather than in the actor (in graph terms, a node with an inbound edge and no modality-reachable outbound edge). That kernel is a genuine substrate-neutral structure (graph reachability), which keeps the entry off the pure framed pole. But it is precisely what keyboard trap instantiates from its umbrella absorbing_state_under_restricted_modality, not what makes "keyboard trap" itself travel: the cross-domain reach belongs to that parent, while the Tab/Escape/focus-management/WCAG apparatus stays home in HCI. Its character: a standards-codified accessibility defect-verdict, structural only in the absorbing-state graph-reachability skeleton it specializes from its umbrella and framed in the focus-navigation-and-WCAG machinery that gives "keyboard trap" its identity — and notably, its disability-rights origin is what makes the state-space-versus-modality joint explicit, which is exactly why it serves as a good pedagogical seed for the parent while remaining framed itself.

Structural Core vs. Domain Accent¶

This section decides why the keyboard trap is a domain-specific abstraction and not a prime, and it carries the case for its domain-specificity in one place.

What is skeletal (could lift toward a cross-domain prime). Strip the accessibility idiom and a thin relational structure survives: an actor enters a state whose available modality of action contains no exit affordance, while its modality of perception keeps receiving input that re-enters or cycles within the state — an absorbing state relative to a restricted action set, with the fault in the state-space-versus-modality joint rather than in the actor. The portable pieces are abstract — a graph of states with an inbound edge into a node, a restricted set of actions available to the actor, and the absence of any action-reachable outbound edge. That skeleton is genuinely substrate-neutral — graph reachability under a restricted modality — and recurs as co-instances in phone-tree branches with no "back," bureaucratic dead-ends with no procedural exit, error queues with no re-entry, and recommendation loops that always return to the same cluster, which is exactly why the entry instantiates the emergent absorbing_state_under_restricted_modality. That recurrence is mechanism, but it is the core the keyboard trap shares, not what makes it distinctive.

What is domain-bound. Everything that makes the failure a keyboard trap in particular is HCI furniture and does not survive extraction. The restricted modality is specifically keyboard/switch focus navigation; the edges are Tab, Shift+Tab, and Escape focus transitions; the container is focus-wired (tabindex receipt); the missing exits are unwired Escape, an unreachable close affordance, non-forwarding Tab; the affected users are the screen-reader / switch / sip-and-puff population; and the invariant is codified as WCAG 2.1.2 "No Keyboard Trap" Level A. The decisive test: remove the focus-driven UI substrate — take a phone tree, a bureaucratic process, a save state with no feasible action set — and there is no Tab key, no focus, no WCAG criterion, only an absorbing state under a restricted modality; the concept does not become a looser keyboard trap, it becomes its parent. The Tab/Escape/focus-management/WCAG apparatus is the accent that stays home.

Why this does not clear the prime bar. A prime is a relational structure whose vocabulary travels and whose transfer is recognition of the same mechanism, not analogy. The keyboard trap's transfer is bimodal. Within focus-driven UI it transfers as mechanism intact — custom modals, third-party embedded widgets, cross-origin iframes, plugin-hosted content, custom keyboard widgets, switch/scan access, mobile screen-reader navigation — because its load-bearing object (the interface as a navigation graph with one exit-reachability invariant) is implementation-agnostic, so the WCAG 2.1.2 check and the outbound-edge intervention carry without translation. Beyond UI the named failure does not transfer: a phone-tree dead-end or a bureaucratic no-exit is a co-instance of the parent absorbing-state pattern, not of "keyboard trap," whose Tab/Escape/focus machinery would have to be dropped. And when the bare structural lesson is needed cross-domain — audit reachable states for a modality-reachable exit, and locate the defect in the missing transition, not in the stranded actor — it is already carried, in more general form, by the absorbing_state_under_restricted_modality parent the keyboard trap instantiates. The cross-domain reach belongs to that parent; "keyboard trap," as named, packs the focus-navigation and WCAG apparatus that should stay home in HCI. (Its disability-rights framing usefully makes the state-space-versus-modality joint explicit, which is why it is a good pedagogical seed for the parent even while remaining a domain-specific instance of it.)

Relationships to Other Abstractions¶

Current abstraction Keyboard Trap Domain-specific

Parents (1) — more general patterns this builds on

Keyboard Trap is a decomposition of Absorbing State Under Restricted Modality Prime

Removing focus-navigation and WCAG vocabulary leaves the exact live prime: a reachable state with no exit in the actor's available action modality.

Hierarchy path (1) — routes to 1 parentless root

Keyboard Trap → Absorbing State Under Restricted Modality → State and State Transition → Phase Space

Not to Be Confused With¶

Intended focus trap. The correct, accessible practice of containing keyboard focus inside an open modal so the user cannot Tab out into the dimmed page behind it. A keyboard trap is containment without a keyboard-reachable exit — no Escape wiring, no reachable close affordance, no Tab forwarding. The two look nearly identical in code; the difference is whether an outbound edge exists. Misreading the trap as "containment is bad" prompts the over-correction of abandoning focus management entirely. Tell: does the contained focus have a keyboard-reachable way out (intended focus trap, correct), or none at all (keyboard trap, the defect)?
Focus theft. The opposite condition: focus moves involuntarily — an inbound edge firing unbidden, jumping the user to an unexpected element. A keyboard trap leaves focus where the user put it but supplies no outbound edge. Different mechanism (spurious inbound vs missing outbound), different remedy. Tell: did focus jump somewhere the user did not send it (focus theft), or is it stuck where the user placed it with no way out (keyboard trap)?
Tab-order discontinuity. A weaker failure: focus advances in a surprising or illogical order (mislabelled or skipped edges), but an exit still exists. A keyboard trap is the stronger failure where no keyboard-reachable exit edge exists at all. One is a disordered path; the other is a dead end. Tell: does keyboard navigation eventually leave the region, just in a confusing order (discontinuity), or never leave it (keyboard trap)?
Lock-in. A forward-looking switching cost — leaving is expensive but possible (data migration, contractual friction). A keyboard trap is an instantaneous absence of any exit transition: not cost-of-leaving but absence-of-leaving, a no-exit room rather than an expensive door. Tell: is exit possible but costly (lock-in), or not possible at all via the available modality (keyboard trap)?
Keyboard accessibility. The positive property that a keyboard trap violates: all functionality operable — reachable and leavable — by keyboard. The keyboard trap is one specific failure of the exit half of that property (an absorbing state in the focus graph). Property-vs-its-failure (part/whole) relation. Tell: is the referent the whole design property of keyboard-operable functionality (keyboard accessibility), or the specific no-exit defect that breaks it (keyboard trap)?
Absorbing state under a restricted modality (the parent). The substrate-neutral umbrella the keyboard trap instantiates — an actor stranded in a state whose available action modality contains no exit affordance while perception keeps re-entering it, the fault in the state-space-versus-modality joint. This is what carries to phone-tree dead-ends, bureaucratic no-exits, error queues with no re-entry, and recommendation loops; the keyboard trap is its focus-graph instance. Tell: strip away Tab/Escape/focus and WCAG and what remains — "an actor cannot exit a state via its available action modality" — is the absorbing_state_under_restricted_modality parent, treated more fully elsewhere; carry it (not "keyboard trap") outside focus-driven UI.

Neighborhood in Abstraction Space¶

Keyboard Trap sits in a moderately populated region (41^st percentile for distinctiveness): it has near-neighbors but no dense thicket of look-alikes.

Family — Interface Legibility & Navigability (12 abstractions)

Nearest neighbors

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