Mouse-only interactions are the usual miss

What it is

Primary buttons being tabbable does not mean the keyboard path is intact. The functions that stay locked out are usually mouse-only interactions: actions that appear only on pointer hover, menus that listen only to right-click, controls that reveal only after a drag, overlays that bind mouseenter and ignore focus. The rest of the page “works from the keyboard”; these entries never join that path.

The miss is common because it is invisible in a pointer walkthrough — testers hold a mouse, so the entries appear on cue.

Why it happens

A pointer has a state the keyboard does not: hover. Stashing secondary actions (edit, delete, more) behind hover keeps the layout quiet. The cost: keyboard focus can sit on the row and the actions still stay hidden; or they appear but cannot be tabbed to, because they live in an absolutely positioned layer armed only by pointer-events. Right-click and drag are the same shape — bound to pointer buttons and pointer travel, not to focus.

A second miss is the wrong event name. onMouseEnter opens a submenu; onFocus does nothing; the submenu stays shut as a keyboard user passes the parent. The code can say “the menu component supports keyboard”; the events say it only wired the pointer. A walkthrough that only exercises top-level nav reports a false “keyboard works”.

Studying it

Build a pointer-exclusive entry inventory. Start from “how I actually use the mouse”, not from the page tree: trailing row icons, hover action bars on cards, tooltips on chart points, canvas context menus, splitters that appear only while dragging. Then disable the pointer and ask whether each entry still has a second path in.

False negative to watch: the tester reaches the row by keyboard, then moves the mouse “to help” the actions appear. Notes must separate “focus revealed it” from “the pointer revealed it”.

Where it stops holding

Touch devices have no hover. If mobile already replaced hover actions with persistent buttons, desktop keyboard users may still hit the hover branch in the same codebase — re-test with an external keyboard. Informative hover (explanation only, no actions) is out of scope; once the hover layer contains a button or link, it is a function entry. In drawing or maps, continuous tracking of “the tool is where the pointer is” may stay on the pointer; tool switching and property edits must not live only on right-click.

Applying it

• Actions that appear only on mouse-over must also appear on focus, or have a persistent, tabbable entry on that object.
• Give right-click menus an equivalent visible button or ⋯ control that sits in the tab sequence.
• Do not open submenus on mouseenter / mouseover alone; focus into the parent must open them, focus out must close them.
• How to check: keep hands off the trackpad and perform every action that “normally only shows up under the mouse” on each row, card and data point. Any gap is a mouse-only miss.

Related

• Same group: J3.01.1 Every function must be completable from the keyboard · J3.01.2 Custom controls need explicit keyboard support
• Nearby: J3.05 Single-pointer alternatives · J3.07 Drag alternatives · C1.06 Hover states and their absence on touchscreens
• Search terms: mouse-only · hover-only · pointer-exclusive