What does 'keyboard operable' demand of a custom control, and who besides keyboard users is blocked when it is pointer-only?

## Parity is per action, not per control "Keyboard operable" is not "can be focused". **2.1.1 Keyboard (Level A)** requires that all functionality is operable through a keyboard interface, without requiring specific timings for individual keystrokes. *All functionality* is the load-bearing phrase: the unit of parity is the **action**, not the widget. A control that can be reached and activated but whose value cannot be changed, or a menu that opens but will not close, has satisfied nobody. The inventory to walk for any custom control: 1. **Reach it** -- it is a stop in the focus order, in a position that matches where it reads. 2. **Know you are on it** -- something on screen shows which control has focus; an interface that moves focus invisibly is unusable even when every action works. 3. **Understand what it is and what state it is in** before committing to an action. 4. **Activate it** with the ordinary activation keys for that kind of control. 5. **Adjust it** -- pick among options, move a value, reorder, expand and collapse. 6. **Cancel and dismiss** -- every way out that a pointer has. 7. **Leave it**, forward and backward, without reaching for a pointer. Pointer affordances map onto keyboard equivalents that have to exist: | What the pointer does | What must also be possible | | --- | --- | | Tap or click to activate | activation from the keyboard while the control has focus | | Hover to reveal extra content | the same content revealed on focus, dismissible and persistent | | Drag to reorder or set a value | a keyboard command performing the same reorder or change | | Long press for a secondary menu | a key that opens the same menu | | A path-based or multi-point gesture | a single-pointer alternative, and a keyboard route | | Scroll inside a sub-region | keys that scroll that region once focus is inside it | WCAG carries several of these as criteria in their own right: the ones on pointer gestures and on dragging movements require single-pointer alternatives, and the one on content revealed by hover or focus requires that such content be dismissible, hoverable and persistent. They exist because a design assuming a steady, accurate pointing device excludes far more people than the phrase "keyboard user" suggests. ## Who is actually blocked The standard says **keyboard interface**, not keyboard, and the distinction is deliberate. The keyboard interface is the abstraction assistive technology drives, so making a control keyboard operable is what makes it work for a long list of people who may never touch a keyboard: - Somebody using a **switch device**, where scanning selects and activates through that same interface. - Somebody using **voice control**, whose spoken command has to resolve to a focusable control with a name and then activate it. - Somebody using an **on-screen keyboard**, an alternative keyboard, a head pointer or **eye-gaze** input. - Somebody with a **tremor or limited fine motor control**, for whom a precise drag or a long press is unreliable even with a pointing device in hand. - Somebody who cannot see where the pointer is and therefore cannot aim it. - Somebody whose pointing device has failed, or who is working one-handed on a moving train -- the situational cases that make this everybody's problem eventually. A control that can only be driven by dragging is therefore not a niche gap. It is the single interaction with no fallback for any of those groups at once. ## Composite controls: one stop, inner navigation A group of closely related controls -- a set of tabs, a toolbar, a list of options, a grid of days -- is conventionally **one stop in the focus order**, with the arrow keys moving between the items inside it. That is not decoration: it keeps the number of stops proportional to the number of *tasks* rather than the number of controls, which stops a dense screen becoming a hundred-press corridor. Adopt whichever convention you like, but adopt it consistently: a user's expectation of how a kind of widget behaves is itself part of operability. If a control defines a shortcut that is a single character with no modifier, the standard requires it can be turned off, remapped, or made active only while the relevant control has focus. Otherwise it fires under anybody dictating text by voice. ## A worked check A council waste-collection service builds a bulky-item booking screen where the user drags each item onto one of the next 14 collection days. It reviews well and demonstrates beautifully. With the pointing device unplugged the flow dies at step 4 of 6: the items are reachable, the days are reachable, and no keyboard route associates one with the other. Because a claim over a multi-step process requires every step to conform, the other five stop counting too: one pointer-only interaction takes down an otherwise clean flow. The repair is not a keyboard shortcut bolted onto the drag; a shortcut is discoverable only by people who already know it exists. It is a second, equal route to the same outcome -- select an item, choose a day from a list, confirm -- offered to everyone rather than hidden behind an accessibility mode. Once it exists the drag becomes an accelerator instead of the only door, which is why the fix survives the next redesign: everybody uses the accessible path, so everybody tests it.