Every function must be triggerable from an input method the person can use

What it is

Unplug the mouse. Can checkout still finish? A slider that counts as consent only when dragged to the end, a map that pinches and does not button-zoom, a delete control that appears only on hover — the function exists on screen, but the actuation contract is written for one kind of body. Operable asks whether the input method the person actually has can issue the command. Seeing the control, and understanding it, are different questions.

This is also wider than “make the hit target bigger.” Switch scanning, voice control, and keyboards fail the same class of design: the interface honours only one way of firing.

Why it happens

Every function sits behind an input contract: which pointer, how many fingers, whether motion must follow a path, whether it must complete inside a time window. If the contract is “hover, then click” or “slide along an arc,” people who can only activate a single point — keyboard, switch, voice, eye-gaze — never get to send that command. The button can be perfectly drawn; the circuit is not wired to their switch.

The second layer is time and path cost. “Can be Tabbed to” is not yet operable: switch scanning may walk forty controls to reach Next; voice may have to speak a name that is not on screen. Operable is stricter than “a non-pointer event exists.” The substitute path has to fire the same result, not open a stripped side door. In POUR it sits next to perceivable: the signal may already be in a channel, and the hand still cannot reach the switch.

Studying it

Keyboard-only traversal is the cheap contract check: disable the pointer and complete a whole task. Switch Access exposes scan-step cost. Voice Control / Voice Access, spoken against visible text, shows whether names resolve. For path gestures, record whether a single-point or non-path control exists.

Independent variables: input apparatus (pointer / keyboard / switch / voice), gesture type (click / path / multi-finger), presence of an alternative control. Dependent variables: task completion, steps to first hit, whether the alternative and primary paths are equivalent, interruptions by timeouts or focus traps.

“The mouse can click it” is not evidence of operability. Automation may flag a missing tabindex; it will not flag eighty scan steps, or a spoken name that is not the visible word.

Where it stops holding

In drawing, performance, or 3-D sculpting, the path is the content, not a decorative gesture; the alternative is often a different editor, not a fake stroke on the same canvas. In games, aiming and timing may be the play; operable becomes a wider time window or aim assist, not the deletion of play. A document with no interactive controls has nothing to fire. An emergency cut-off that any input can brush against puts operability in conflict with accidental activation — that is a case for limiting stray firing, not for removing the keyboard channel.

Applying it

• For every command in a task, provide at least one trigger that is not path-based, multi-finger, or hover-only: keyboard, a click, a visible button.
• Time-limited actions need to be turned off, adjusted, or extended; focus that can enter must be able to leave.
• The name voice control speaks must be the words on screen, not an internal code.
• How to check: finish checkout with the pointer off and only a keyboard; speak the visible label with system voice control and see if it hits; turn on switch scanning and count steps to the main action. Every step the primary path can do and the substitute cannot is a contract still written for one body.

Related

• Same group: J1.01.1 Information must still be gettable when a sensory channel is missing · J1.01.3 Presentation is not the same as being able to understand the information and the action · J1.01.4 Content has to remain parsable by the assistive technologies people actually use
• Nearby: J3.01 Keyboard access · J3.05 Single-pointer alternatives · J5.04 Voice control
• Search terms: operable · POUR · keyboard only