Keyboard paths must be functionally equivalent to mouse-reachable paths, not visual presentation only

What it is

Every task completable with a pointer must also be completable with a keyboard, to the same result—not merely “it looks clickable.” Delete-on-hover, drag-only reorder, and rename-only-from-the-context-menu do not exist for people without a pointer or without precise pointing. Functional equivalence is harder than whether a focus ring is drawn: focus can tour the screen and the path is still cut if there is no actuator along the way. The question is not whether Tab order is pretty; it is whether the task closes.

Why it happens

Pointer events (hover, drag, contextmenu, double-click) are often wired straight into business logic. Keyboards have no hover; drag needs a grab-with-Space then move-with-arrows mode; a context menu needs Shift+F10 or a dedicated key. If the business only listens for pointer events, focus can rest on the element and still emit no command. Custom widgets leak here: a div painted as a button has onclick and no Enter/Space. CSS can look “clickable” without creating a keyboard operator. Equivalence failures cluster on secondary actions (delete, sort, bulk); the primary button is often done.

Studying it

List tasks (create, edit, sort, delete, open menu, submit), run them with a pointer and with a keyboard, and for each record: completable, step-count gap, and whether an undocumented shortcut was required. Code “can focus” separately from “can activate.” Automation can find click handlers with no keyboard listener; drag-reorder and marquee select still need a human. Recruit people who actually use a keyboard; do not only ask mouse users to “try not touching the mouse.”

Where it stops holding

Continuous spatial tasks such as painting or 3D tumbling are hard to match for efficiency; equivalence means “can finish to the same result,” and slower is allowed. Touch products lack hover, which does not automatically add a keyboard delete path. Shortcuts can accelerate an equivalent path; they cannot be the only path—people who do not memorize them still need to Tab there. Read-only presentation (static figures, plain text) has no pointer actions and no equivalence duty.

Applying it

• For every command bound to onclick, drag, or contextmenu, add a keyboard activation: Enter/Space, a grab-and-move mode, the menu key.
• Actions that appear only on hover must also appear when focused, or live in an explicit menu.
• Do not end a keyboard user's path with “please use a mouse for this step.”
• Verify by unplugging the mouse or disabling the trackpad and completing the core task list with the keyboard the product claims to support. Any control that appears only under a pointer is a cut path.

Related

• Same group: C6.22.1 Composite widgets typically move among internals with arrow keys; Tab only enters and leaves · C6.22.2 Skip links let keyboard users bypass repeating navigation and reach main content · C6.22.3 Roving tabindex keeps only one composite member in the Tab sequence; the rest move by arrows
• Adjacent: C6.05 Focus order · C6.03 Shortcut systems
• Search: keyboard equivalence · pointer-only actions · operable