Every function must be completable from the keyboard

What it is

If a function can be done only with a pointer, it does not exist for someone who uses a keyboard. The criterion is keyboard access: every action that changes state, submits data, or reaches new content must be completable without a mouse, trackpad, or touchscreen. The question is whether the function set is closed, not whether some button happens to be in the tab sequence.

A large shortcut map is not the same thing. Shortcuts accelerate. Access means Tab, arrows, Enter, Escape and Space can carry a whole task from start to finish.

Why it happens

Keyboard users are not one population. Some cannot move a pointer stably; some use switch hardware that the system maps onto Tab and activate; some live in a screen reader’s focus mode, where the keyboard is both reading and acting. All three share one premise: operable objects have been placed in a set the keyboard can reach.

Native platform controls (links, buttons, form fields) enter that set by default. Product functions often live elsewhere: objects on a canvas, actions that appear only on hover, state that changes only after a drag. Pointer users see those entries; the keyboard caret never arrives. The failure is not “keyboard support could be nicer”. A whole edge is missing from the task graph — the function is closed to one input channel.

Studying it

The evaluation is a keyboard-only task walkthrough: disable the pointer and run a task list (register, search, filter, submit, sign out) end to end. Under WCAG-EM sampling, walk at least one primary task on each template class, not only the home page.

Independent variables: task type (browse / fill / manipulate objects), native versus custom widgets. Dependent variables: completion, the step where the path dies, keystrokes to finish the same task.

Keystroke count is not the pass line; completion is. Switch scanning makes every choice expensive, but this leaf asks whether the task is possible at all. A lab page that works and a live checkout iframe that does not are not interchangeable — sampling has to include checkout, sign-in and editors.

Where it stops holding

Static content with no interaction is out of scope. Real-time play or tools whose task is continuous pointer tracking (a brush stroke, orbiting a 3D view) may keep that tracking on the pointer, but save, undo, tool switch and exit still need keyboard paths. Touch-first mobile apps are not scored on a desktop Tab model when no keyboard is attached; once a keyboard or switch control is connected, the same functions must still be reachable. If a third-party embed owns checkout or login, a missing keyboard path is a product failure, not “not our code”.

Applying it

• List every task a user can complete. Turn the pointer off. Walk each task from entry to submit. Any step that only works by hover, drag or a canvas click is a miss.
• Prefer native links, buttons and fields. Treat custom widgets as a separate case; looking clickable is not the same as being in the tab sequence.
• How to check: disable the trackpad and complete one checkout or publish. If a hand has to reach for the pointer, this criterion has failed.

Related

• Same group: J3.01.2 Custom controls need explicit keyboard support · J3.01.3 Mouse-only interactions are the usual miss
• Nearby: J1.01.2 Operable: functions must be triggerable by any input method · J2.06 Focus visibility · J3.08 Switch access and scanning
• Search terms: keyboard access · keyboard operable · keyboard-only