Keyboard Accessibility¶

The design property that every interactive function in a GUI can be operated with the keyboard alone — making the keyboard a channel-redundant, complete alternative to the pointer, and the upstream contract every assistive technology depends on.

Core Idea¶

Keyboard accessibility is the design property that all interactive functionality in a graphical user interface can be operated using only a keyboard or keyboard-equivalent assistive technology — no pointer device required. The structural commitment is channel-redundant action: every action path through the interface is reachable via two independent input channels, pointer and keyboard, such that removing the pointer channel leaves no action unreachable.

The specific apparatus is the focus model: at every moment exactly one focusable element holds keyboard focus; Tab and Shift+Tab move focus through a defined traversal order; focused elements carry a visible focus indicator; and focus is correctly managed across state transitions so that when a modal opens it receives focus and when it closes focus returns to the triggering element. An interface satisfies keyboard accessibility when it guarantees completeness — every action the pointer can perform, the keyboard can also perform — and practicality — the keyboard path to each action does not impose prohibitive traversal cost. WCAG 2.x Guideline 2.1 codifies keyboard accessibility as a non-negotiable conformance criterion because keyboard completeness is the upstream contract on which screen readers, switch scanners, sip-and-puff devices, and voice-control software all depend: those assistive technologies drive the keyboard interface, and any action unreachable by keyboard is unreachable by all of them.

Structural Signature¶

Sig role-phrases:

the interactive controls — every action-bearing element of the GUI that must be operable
the two control channels — pointer and keyboard as functionally redundant input paths to every action
the focus model — the global invariant: exactly one element focused, a defined Tab/Shift+Tab order, a visible focus indicator, focus handed off and restored across state transitions
the keyboard interaction model — the per-control behavior for Tab, Enter, Space, Esc, and the arrow keys
the keyboard-only walk — the single runnable diagnostic: can every task be completed using only those keys?
the upstream contract — the keyboard channel that screen readers, switch scanners, sip-and-puff, and voice control all drive, so certifying it certifies all of them and one gap severs every device at once
the completeness guarantee — every action the pointer can perform, the keyboard can too; failing it is modality lock-in
the practicality guarantee — the keyboard path imposes no prohibitive traversal cost; passing completeness but failing this is reachable-yet-unusable (parity at fifty tab stops)
the GUI-bound cargo — the focus model, Tab key, WCAG 2.1, ARIA patterns have no referent off-substrate, where only the parent channel-redundancy lesson travels

What It Is Not¶

Not a convenience for keyboard power users. Serving home-row enthusiasts is a side benefit, not the point. The keyboard channel is the upstream contract on which screen readers, switch scanners, sip-and-puff devices, and voice control all depend, so a single keyboard-unreachable action is the same action missing for an entire population of assistive-technology users at once — not a nicety for people who dislike the mouse.
Not satisfied by mere reachability. Completeness — every pointer action also reachable by keyboard — is necessary but not sufficient. An action sitting behind fifty tab stops satisfies parity while remaining unusable, so the concept imposes cost-parity: the question is not only "can the keyboard reach this?" but "at what traversal cost?" Reachable-yet-unusable is a distinct defect from severance, and bare parity does not clear it.
Not the whole of accessibility. Keyboard accessibility is one conformance criterion (WCAG Guideline 2.1), sitting beside contrast, alt text, captioning, and the rest under the accessibility umbrella. It owns channel completeness over the focus model; it does not own those separate criteria, and treating it as synonymous with "accessible" scopes the diagnosis wrongly.
Not about the keyboard input device as such. The obligation is channel completeness over the focus model, not catering to one piece of hardware. The keyboard is the representative channel because every assistive technology drives it; certifying it certifies them all, so the concern is the contract, not the physical keys.
Not the general redundancy prime. The substrate-spanning move — provide an alternative control channel that can complete every action the primary can, at acceptable cost — is carried by functional_redundancy_degeneracy and redundancy, and recurs in failover datacenters and redundant flight controls. Keyboard accessibility is that pattern specialized to human input via the focus model, Tab key, and ARIA; invoking it for a failover system borrows the alternate-channel shape while leaving the GUI machinery behind.

Scope of Application¶

Keyboard accessibility lives within the HCI and accessibility-engineering subfields, wherever a graphical user interface is operated by a keyboard or keyboard-equivalent assistive technology; its reach is bounded to that GUI-and-keyboard substrate. The broader channel-redundancy lesson — an alternative control channel that can complete every action the primary can — travels off-substrate (to failover datacenters, redundant flight controls) under the parent primes functional_redundancy_degeneracy and redundancy, so the map below holds to genuine GUI accessibility contexts where the focus model itself is the apparatus.

Web and application accessibility — the home turf, where WCAG 2.x Guideline 2.1 codifies keyboard operability of all functionality as a non-negotiable conformance criterion across desktop and web UIs.
Assistive-technology compatibility — the upstream contract: screen readers, switch scanners, sip-and-puff devices, and voice-control software all drive the keyboard interface, so certifying the keyboard channel certifies all of them at once.
Custom-widget and design-system engineering — building tab order, focus indicators, focus trapping/restoration, and per-control keyboard interaction models into reusable components (the ARIA Authoring Practices interaction patterns).
Keyboard power-user productivity — the same machinery also serves users without disabilities who prefer keyboard-only operation without lifting their hands from the home row.
Mobile and touch contexts — the equivalent principle applied to switch control and external Bluetooth keyboards on touch-first platforms.

Clarity¶

Naming keyboard accessibility as a property of the whole interface exposes the failure mode of modality lock-in: a control built only for the pointer — a hover-only menu, a custom drag handle, a click-to-focus element with no tab stop — that looks complete because it works with a mouse, while silently severing an entire population of users from the action. The clarifying force is a single sharp diagnostic the designer can run: can every task be completed with only Tab, Shift+Tab, Enter, Space, Esc, and the arrow keys? That question turns "is this accessible?" from an open-ended worry into a finite, walkable check over the focus model — focus order, focus indicator, focus trapping, focus restoration — and locates each defect at a specific element rather than as a vague property of the product.

It also sharpens a distinction that "the keyboard works too" tends to flatten: completeness versus practicality. An action path can be technically reachable by keyboard yet sit behind fifty tab stops, satisfying parity while remaining unusable — so the concept forces the practitioner to ask not merely "can the keyboard reach this action?" but "at what traversal cost?", making cost-parity a requirement above bare reachability. And by identifying the keyboard channel as the upstream contract on which screen readers, switch scanners, sip-and-puff devices, and voice control all depend, it reframes the stakes: a single keyboard-unreachable action is not one feature missing for one input method but the same action missing for every assistive technology that drives the keyboard interface at once.

Manages Complexity¶

"Is this interface accessible?" is, taken whole, an unbounded question. An application has an open-ended population of controls, custom widgets, modals, menus, route changes, and error states, and a parallel population of assistive technologies — screen readers, switch scanners, sip-and-puff controllers, voice control — each with its own behavior. Asked across the full product of those two populations, accessibility looks like a sprawling matrix: every feature against every input method, every one a separate worry. Keyboard accessibility collapses that matrix along two cuts. First, it folds the assistive-technology axis to a single representative channel: because screen readers, switch scanners, and the rest all drive the keyboard interface, the keyboard is the upstream contract, and certifying the keyboard channel certifies all of them at once — the analyst tracks one channel, not a dozen devices. Second, it reduces the per-feature question to the state of one global invariant, the focus model: at every moment exactly one element holds focus; Tab and Shift+Tab traverse a defined order; the focused element shows a visible indicator; focus is correctly handed off and restored across state transitions.

What the designer then walks is finite and local. The open worry "is the product accessible?" becomes a bounded checklist run element by element — is this element a tab stop in a sensible order, does it show a focus indicator, does this modal trap focus and restore it on close, does this custom widget have a defined keyboard interaction model — and each failure localizes to a specific element rather than hanging over the product as a vague property. The whole check reduces to one runnable diagnostic: can every task be completed with only Tab, Shift+Tab, Enter, Space, Esc, and the arrow keys? The qualitative verdict then reads off a two-branch test. Completeness: every action the pointer can perform, the keyboard can too — fail it and the branch is modality lock-in, an action severed for the entire assistive-technology population at once. Practicality: the keyboard path to each action does not impose prohibitive traversal cost — pass completeness but fail this and the action is reachable-yet-unusable, parity satisfied at fifty tab stops. The move is from an unbounded feature-by-device accessibility matrix to a single channel obligation governed by one invariant, walked as a finite per-element checklist with a two-branch pass/fail read directly off completeness and cost.

Abstract Reasoning¶

Keyboard accessibility licenses a tight set of reasoning moves, all anchored in two structural facts: that the keyboard is the upstream contract on which every assistive technology depends, and that the focus model is a single global invariant whose state can be read at any element.

Diagnostic — run the keyboard-only walk to localize severance, and read a missing tab stop as an assistive-technology-wide outage. The characteristic inference begins with one runnable probe — can every task be completed using only Tab, Shift+Tab, Enter, Space, Esc, and the arrow keys? — and treats each point where the walk stalls as a located defect at a specific element, not a vague property of the product. A hover-only menu that the walk cannot open, a custom drag handle with no keyboard interaction model, a click-to-focus element absent from the tab order: each is diagnosed as modality lock-in at that control. The load-bearing second step is amplification through the upstream contract: because screen readers, switch scanners, sip-and-puff devices, and voice control all drive the keyboard interface, a single keyboard-unreachable action is inferred to be unreachable by the entire assistive-technology population at once — so the move reasons from one failed tab stop to a whole class of users severed, never treating it as one input method's minor gap.

Diagnostic of the invariant — read focus state to predict screen-reader and scanner behavior without testing each device. Because the focus model is a single invariant (exactly one element focused; a defined Tab order; a visible indicator; correct hand-off and restoration across transitions), the analyst infers downstream assistive-technology behavior from the focus state alone. A modal that opens without moving focus into itself predicts a screen-reader user stranded outside the dialog; focus that fails to return to the triggering element on close predicts the user dumped at the top of the document; a focus order that does not match reading order predicts a scanner traversing controls in a nonsensical sequence. The move is to certify one channel — the keyboard's focus model — and infer the fate of the dozen devices that ride on it, rather than test each device against each feature.

Interventionist — restore the invariant at the failing transition, and predict the channel re-opens for all assistive technology. Each fix targets a specific clause of the focus model and carries a predicted effect that spans every device on the contract. Add a tab stop and a keyboard interaction model to a pointer-only widget, and predict the action becomes reachable simultaneously for screen-reader, switch, and voice users. Trap focus inside an open modal and restore it on close, and predict the screen-reader user is kept within the dialog and returned to context. Add a visible focus indicator, and predict the sighted keyboard user regains the orientation the pointer user never lost. Because the keyboard is upstream, the move treats a single keyboard repair as a multi-device repair, and a fix that does not unblock the assistive technologies localizes the fault to a different clause of the invariant than the one addressed.

Boundary-drawing — separate completeness from practicality, and pointer-channel from keyboard-channel obligations. Two lines the concept forces. First, completeness versus practicality: an action reachable by keyboard satisfies parity, but an action reachable only behind fifty tab stops satisfies parity while remaining unusable — so the move is to refuse to certify on reachability alone and to impose cost-parity, asking not merely "can the keyboard reach this?" but "at what traversal cost?" An item passing completeness but failing cost is classified as reachable-yet-unusable, a distinct defect from severance. Second, the boundary of the contract itself: keyboard accessibility owns the obligation that every pointer action have a keyboard equivalent, but it does not own pointer-only conveniences that have no action consequence, nor the separate criteria (contrast, alt text, captioning) that sit beside it under the accessibility umbrella. The move is to scope the diagnosis to channel completeness over the focus model and not let it sprawl into every accessibility concern.

Order-of-events — certify the upstream contract first, because everything downstream inherits its gaps. The dependency ordering carries predictive content: since assistive technologies are built on the keyboard interface, the move is to establish keyboard completeness before auditing any specific device, predicting that a keyboard gap will reproduce as a gap in every downstream tool, while a keyboard-complete interface gives each downstream tool a sound foundation to build on. Reversing the order — certifying a screen reader against a keyboard-incomplete interface — predicts wasted effort, because the underlying severance will surface again through every other assistive technology that shares the contract.

Knowledge Transfer¶

Within HCI and accessibility engineering the concept transfers as mechanism, intact. The focus-model invariant (exactly one element focused; a defined Tab order; a visible indicator; correct hand-off and restoration across state transitions), the completeness-versus-practicality cut, and the single runnable keyboard-only walk carry without translation across UI frameworks and platforms, and the per-element checklist and the ARIA Authoring Practices interaction patterns port with them. The upstream-contract argument is what makes this transfer powerful: because screen readers, switch scanners, sip-and-puff devices, and voice control all drive the keyboard interface, certifying the one keyboard channel certifies all of them, so the diagnostic ("can every task be completed with Tab, Shift+Tab, Enter, Space, Esc, and the arrows, at acceptable traversal cost?") and the fixes (add a tab stop and interaction model to a pointer-only widget; trap and restore focus across a modal; add a focus indicator) recur identically wherever there is a GUI operated by a keyboard or keyboard-equivalent — desktop and web applications, and the mobile cognate of switch control and external Bluetooth keyboards. It also serves keyboard-preferring power users without disabilities by the same machinery. This is genuine within-domain mechanism transfer: same focus model, same walk, same per-element localization.

Beyond the GUI-and-keyboard substrate the case is the third category, and clean: the portable structural move is not "keyboard accessibility" but the more general channel-redundant action pattern — provide a designated alternative control channel that can complete every action the primary channel can, so loss of the primary leaves no task unreachable. That genuinely recurs across domains as co-instances of functional_redundancy_degeneracy (different components performing the same function — here, keyboard and pointer as functionally redundant input channels) and redundancy (extra capacity for failure tolerance): disaster-recovery failover sites that must be able to serve every request the primary served, redundant flight controls, dual-control medical devices, offline-capable apps that must complete every task without the network. Where the cross-domain lesson is needed — "if the primary control channel fails, can the secondary complete every task, and at what cost?" — it should be carried by functional_redundancy_degeneracy + redundancy, not by "keyboard accessibility" as named, because this entry's distinctive cargo (the focus model, the Tab key, WCAG Guideline 2.1, ARIA patterns, the assistive-technology population riding the keyboard) is GUI-bound and has no referent once the "channels" are datacenters or flight-control linkages rather than input modalities. So invoking "keyboard accessibility" for a failover system borrows the alternate-channel-completeness shape while leaving the focus-model machinery behind; the honest move is to mark it as a specialization of the redundancy primes and route the general lesson there. As a prime this entry would be functional_redundancy_degeneracy applied to human input — exactly the boundary drawn in Structural Core vs. Domain Accent.

Examples¶

Canonical¶

The defining construction is a correctly built modal dialog, the textbook case in the ARIA Authoring Practices. When the user activates a "Delete account" button, three things must happen for keyboard completeness: focus moves into the dialog (typically onto its first control or heading); focus is trapped so that pressing Tab and Shift+Tab cycles only among the dialog's controls and never escapes to the dimmed page behind it; and pressing Esc (or activating Cancel/Confirm) closes the dialog and returns focus to the original "Delete account" button. Run the keyboard-only walk — Tab, Shift+Tab, Enter, Space, Esc, arrows — and every step of opening, operating, and closing the dialog succeeds with no pointer. Omit the focus trap and a keyboard user tabs invisibly out of the dialog onto controls they cannot see.

Mapped back: The dialog's buttons are the interactive controls, reachable through both the two control channels. Move-in, trap, and restore are the three clauses of the focus model; completing the whole open-operate-close sequence with only the keys is the keyboard-only walk confirming the completeness guarantee.

Applied / In Practice¶

Robles v. Domino's Pizza is the field case that made the stakes legal. Guillermo Robles, who is blind, used a screen reader — software that drives the keyboard interface — and could not complete an order on Domino's website and app because interactive elements were not reachable that way. He sued under the Americans with Disabilities Act; the Ninth Circuit held the ADA applied, and in 2019 the U.S. Supreme Court declined to hear Domino's appeal, letting the ruling stand. A single set of keyboard-unreachable controls had severed not one input method but every assistive technology built on the keyboard channel.

Mapped back: The screen reader's dependence on the keyboard is the upstream contract: because Robles's assistive technology drove the keyboard interface, controls missing from it failed the completeness guarantee for him entirely — modality lock-in. The case shows why one keyboard gap is an assistive-technology-wide outage, not a minor omission, giving the abstract contract real institutional consequence.

Structural Tensions¶

T1: Completeness versus practicality (reachability against traversal cost). The concept demands two distinct things of the keyboard channel: completeness — every pointer action also reachable by keyboard — and practicality — the keyboard path imposing no prohibitive traversal cost. The tension is that these pull apart in real interfaces: an action can satisfy parity perfectly while sitting behind fifty tab stops, technically reachable and practically unusable. Completeness is a clean binary the keyboard-only walk can certify; practicality is a graded cost with no bright-line threshold, so an interface can pass the auditable criterion and still fail the human one. Certify on reachability alone and you ship a keyboard-complete interface no keyboard user can bear; demand low traversal cost everywhere and you impose a subjective standard the conformance criterion cannot pin down. Diagnostic: Is this action being certified on whether the keyboard can reach it (completeness) or on what it costs to reach it (practicality) — and is a reachable-yet-fifty-tab-stops path being counted as a pass?

T2: Upstream contract as leverage versus single point of failure (certify all, or sever all). The keyboard's status as the upstream contract every assistive technology drives is the concept's most powerful property: certify the one keyboard channel and you certify screen readers, switch scanners, sip-and-puff, and voice control all at once, collapsing a device-by-feature matrix to a single channel obligation. But the identical property makes every keyboard gap catastrophic: a single keyboard-unreachable action is not one input method's minor omission but the same action missing for the entire assistive-technology population simultaneously — the Robles severance. The tension is that the shared dependency which lets one fix repair a dozen devices is exactly what lets one defect break all of them, so the channel is both the point of maximum leverage and the point of maximum fragility. Diagnostic: Is the keyboard channel here being treated as the single contract whose certification covers every assistive technology — and is each gap being scored as the population-wide outage it actually is, not a lone input method's edge case?

T3: Focus-model proxy versus residual device behavior (certify one channel, infer the dozen). The focus model is a single global invariant, so the analyst can read focus state at any element and infer downstream screen-reader and scanner behavior without testing each device — a modal that opens without moving focus predicts a stranded screen-reader user. This is the efficiency that makes the whole approach tractable. But the inference is not airtight: assistive technologies have their own quirks, virtual-cursor modes, and heuristics that the bare focus model does not fully capture, so a keyboard-complete interface can still misbehave with a specific screen reader in ways the focus-model walk did not predict. The tension is that certifying the representative channel is a genuine proxy for the population yet not identical to it, so leaning entirely on the focus-model walk can miss device-specific failures, while testing every device against every feature abandons the compression that was the point. Diagnostic: Does the accessibility claim here rest on the focus-model walk alone (efficient, representative) or has it been checked against actual assistive-technology behavior for the residual quirks the invariant does not capture?

T4: Bounded criterion versus the whole of accessibility (tractability against false completeness). Scoping keyboard accessibility to channel completeness over the focus model is what turns an unbounded "is this accessible?" into a finite, walkable, per-element checklist — the concept's core service. But that same bounding invites treating a keyboard-accessible interface as an accessible one, when keyboard accessibility is a single WCAG criterion sitting beside contrast, alt text, captioning, and cognitive load. The tension is that the property which makes the diagnosis tractable (a narrow, well-defined channel obligation) is the property that makes it dangerous when over-read (passing it feels like passing accessibility). Keep the scope narrow and the check stays runnable but partial; broaden "keyboard accessible" toward "accessible" and the diagnosis sprawls back into the unbounded matrix it escaped. Diagnostic: Is a passing keyboard-only walk being treated as evidence of keyboard completeness (correct) or of accessibility generally (a scope error that ignores contrast, alt text, and the rest)?

T5: Modality lock-in versus the pointer-using tester (a severance invisible to the shipper). A pointer-only control — a hover menu, a custom drag handle, a click-to-focus element with no tab stop — looks complete because it works flawlessly with a mouse, so it passes every check the mouse-using designer naturally runs while silently severing the entire assistive-technology population. The tension is structural: the failure mode is invisible to exactly the person most likely to ship it, because their own input channel conceals it. The keyboard-only walk is the discipline that surfaces it, but it requires the tester to deliberately abandon the pointer they instinctively reach for — an unnatural act that the interface's mouse-success actively discourages. The defect hides behind the very channel the builder uses to verify their work. Diagnostic: Has this interface been walked with the pointer removed entirely (Tab, Shift+Tab, Enter, Space, Esc, arrows only), or only tested by a builder whose mouse conceals the modality lock-in?

T6: Autonomy versus reduction (a GUI accessibility property or the instance of its channel-redundancy parents). Keyboard accessibility is a specific, named HCI property with real home-bound machinery — the focus model, the Tab key, WCAG Guideline 2.1, ARIA interaction patterns, the assistive-technology population riding the keyboard — and it transfers as mechanism across web, desktop, and mobile GUIs. But its portable structural move is not "keyboard accessibility": it is channel-redundant action — provide a designated alternative control channel that can complete every action the primary can, so loss of the primary leaves no task unreachable — carried by functional_redundancy_degeneracy and redundancy. That pattern recurs in failover datacenters, redundant flight controls, dual-control medical devices, and offline-capable apps, none of which inherit the focus model or the Tab key. The tension is between a property concrete enough to certify a modal dialog and the recognition that its cross-domain lesson (if the primary channel fails, can the secondary complete every task, at what cost?) belongs to the redundancy primes. Diagnostic: Resolve toward functional_redundancy_degeneracy + redundancy when carrying the alternate-channel-completeness lesson to failover, flight controls, or offline modes; toward keyboard accessibility itself when the focus model, Tab order, and assistive-technology contract of a GUI are the concrete object.

Structural–Framed Character¶

Keyboard accessibility is best placed framed-leaning: it is a prescriptive, standards-codified design property — evaluatively charged, practice-bound, and institution-authored — resting on a genuine channel-redundancy kernel. The five criteria mostly point framed. Evaluative_weight is high: keyboard accessibility is a requirement, a WCAG "non-negotiable conformance criterion"; failing it is named "modality lock-in" and "severance," a defect to be certified against — so the entry renders design verdicts and normative pass/fail judgments, not neutral descriptions of a mechanism. Human_practice_bound is high: GUIs, keyboards, focus models, and the whole assistive-technology population are human-designed artifacts, and the property exists only inside the practice of interface engineering; strip that practice away and there is no keyboard accessibility, and it reaches no substrate lacking a GUI-and-keyboard. Institutional_origin is high: the entry is codified furniture of accessibility-standards bodies — WCAG Guideline 2.1, the ARIA Authoring Practices, even legal enforcement (Robles v. Domino's) — a criterion authored and legislated, not read off nature. Vocab_travels is low for the distinctive layer: the focus model, the Tab key, ARIA patterns, and the assistive-technology contract have no referent once the "channels" are datacenters or flight-control linkages. Only import_vs_recognize has structural texture: within GUIs the property transfers as literal mechanism across web/desktop/mobile, and the parent carries the genuine cross-domain co-instances (failover sites, redundant flight controls, offline-capable apps) beyond it.

The portable structural skeleton is channel-redundant action — provide a designated alternative control channel that can complete every action the primary can, at acceptable cost, so loss of the primary leaves no task unreachable. That kernel is a genuine substrate-general structural pattern, which keeps the property off the pure framed pole. But it is precisely what keyboard accessibility instantiates from its umbrella — functional_redundancy_degeneracy and redundancy — not what makes "keyboard accessibility" itself travel: the cross-domain reach belongs to those redundancy parents, while the focus model, Tab order, WCAG/ARIA apparatus, and assistive-technology contract stay home in HCI. Its character: a prescriptive, standards-codified GUI design property, structural only in the channel-redundancy skeleton it specializes from its umbrella (functional redundancy applied to human input) and framed in the focus-model-and-WCAG machinery that gives "keyboard accessibility" its identity.

Structural Core vs. Domain Accent¶

This section decides why keyboard accessibility 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 HCI content and a thin relational structure survives: provide a designated alternative control channel that can complete every action the primary channel can, at acceptable cost, so loss of the primary leaves no task unreachable. The portable pieces are abstract — a set of actions, a primary channel, a functionally redundant secondary channel, and a completeness-at-acceptable-cost guarantee across the two. That skeleton is genuinely substrate-general — it recurs as co-instances in disaster-recovery failover sites, redundant flight controls, dual-control medical devices, and offline-capable apps — which is exactly why the entry instantiates the catalog's functional_redundancy_degeneracy (different components performing the same function) and redundancy (extra capacity for failure tolerance). That recurrence is mechanism, but it is the core keyboard accessibility shares, not what makes it distinctive.

What is domain-bound. Everything that makes the property keyboard accessibility in particular is GUI furniture and does not survive extraction. The two channels are specifically pointer and keyboard; the apparatus is the focus model — exactly one focused element, a defined Tab/Shift+Tab order, a visible focus indicator, focus hand-off and restoration across state transitions; the per-control behavior is the keyboard interaction model (Tab, Enter, Space, Esc, arrows); the diagnostic is the keyboard-only walk; and the whole thing is codified as WCAG Guideline 2.1 with ARIA Authoring Practices patterns and an assistive-technology population (screen readers, switch scanners, sip-and-puff, voice control) riding the keyboard as the upstream contract. The decisive test: once the "channels" are datacenters or flight-control linkages rather than input modalities, the focus model, the Tab key, WCAG 2.1, and ARIA patterns have no referent — invoking "keyboard accessibility" for a failover system borrows the alternate-channel-completeness shape while leaving all the GUI machinery behind. The focus-model apparatus is the accent that does not lift.

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. Keyboard accessibility's transfer is bimodal. Within the GUI-and-keyboard substrate it transfers as mechanism intact — web and desktop applications, custom-widget/design-system engineering, mobile switch-control and Bluetooth-keyboard contexts — because each shares the focus model and the assistive-technology contract, so the keyboard-only walk, the completeness-versus-practicality cut, and the fixes carry without translation. Beyond that substrate the named property does not transfer as mechanism: failover sites, redundant flight controls, and offline apps are co-instances of the redundancy parents, not of "keyboard accessibility," whose focus-model cargo has no referent there. And when the bare structural lesson is needed cross-domain — if the primary control channel fails, can the secondary complete every task, and at what cost? — it is already carried, in more general form, by the functional_redundancy_degeneracy and redundancy parents the property specializes. The cross-domain reach belongs to those redundancy parents; "keyboard accessibility," as named, packs the focus model, the Tab key, and the WCAG/ARIA apparatus that should stay home in HCI.

Relationships to Other Abstractions¶

Current abstraction Keyboard Accessibility Domain-specific

Parents (1) — more general patterns this builds on

Keyboard Accessibility is a decomposition of Functional Redundancy (Degeneracy) Prime

Keyboard Accessibility is functional redundancy specialized to a keyboard channel that must reproduce every action available through the pointer channel.

Children (1) — more specific cases that build on this

Accessibility Domain-specific is part of Keyboard Accessibility

Accessibility contains Keyboard Accessibility as its channel-completeness obligation for interactive functions operated without a pointer.

Hierarchy paths (12) — routes to 8 parentless roots

Keyboard Accessibility → Functional Redundancy (Degeneracy) → Redundancy → Reserve → Economy Of Force → Allocation → Scarcity → Constraint

Show alternative paths (11)

Not to Be Confused With¶

Keyboard trap. A specific failure of keyboard accessibility, not a synonym: a focusable container the keyboard user can enter but cannot exit (an absorbing state with no keyboard-reachable outbound edge). Keyboard accessibility is the positive property (every action reachable and leavable by keyboard, at acceptable cost); a keyboard trap violates its exit half. Part-of-a-property (failure) relation. Tell: is the referent the whole property that all functionality be keyboard-operable (keyboard accessibility), or the specific defect of a focus container that will not yield focus (keyboard trap)?
Accessibility / WCAG generally. The super-set: accessibility spans contrast, alt text, captioning, cognitive load, and much more; keyboard accessibility is one conformance criterion (WCAG Guideline 2.1) owning channel completeness over the focus model. Treating "keyboard accessible" as "accessible" is a scope error. Tell: is the referent the entire umbrella of accessibility criteria (accessibility/WCAG), or specifically the keyboard-operability-of-all-functionality criterion (keyboard accessibility)?
Screen-reader compatibility. A property of the downstream assistive technology that rides the keyboard channel, not the channel itself. Keyboard accessibility is the upstream contract; a screen reader drives the keyboard interface, so certifying the keyboard channel is necessary for (but distinct from) full screen-reader support, which additionally needs semantics, names, roles, and announcements. Tell: is the concern whether the keyboard can operate every control (keyboard accessibility, the upstream contract), or whether a screen reader correctly announces and navigates (screen-reader compatibility, downstream)?
Keyboard shortcuts / power-user hotkeys. Convenience accelerators (Ctrl+S, single-key commands) that speed operation for expert users — an efficiency layer, not a completeness guarantee. Keyboard accessibility requires that every action be keyboard-operable at acceptable traversal cost, for the assistive-technology population; shortcuts are optional extras. Tell: is the feature an optional accelerator for some actions (shortcuts), or the obligation that all actions be keyboard-reachable and leavable (keyboard accessibility)?
Focus management. A component mechanism within keyboard accessibility — the moment-to-moment handling of which element holds focus, hand-off, and restoration (the focus model). Keyboard accessibility is the whole channel-completeness property that focus management partly implements; correct focus management is necessary but does not by itself guarantee every action is reachable at acceptable cost. Tell: is the referent the technique of moving and restoring focus (focus management), or the end property that all functionality be keyboard-operable it serves (keyboard accessibility)?
Functional redundancy / redundancy (the parents). The substrate-neutral umbrella keyboard accessibility instantiates — provide a designated alternative control channel that can complete every action the primary can, at acceptable cost, so loss of the primary strands no task (functional_redundancy_degeneracy, redundancy). This is what travels to failover sites, redundant flight controls, and offline-capable apps; keyboard accessibility is its human-input specialization. Tell: strip away the focus model and WCAG apparatus and what remains — "an alternative channel completes every action the primary can" — is the redundancy parent, treated more fully elsewhere; carry it (not "keyboard accessibility") for failover or offline modes.

Neighborhood in Abstraction Space¶

Keyboard Accessibility sits in a moderately populated region (51^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