Functions triggered only on hover are undiscoverable to keyboards and screen readers

What it is

If a function’s only trigger is pointer enter, keyboards and screen readers cannot discover it. Those devices do not produce “the cursor slid into a rectangle”: the keyboard moves focus, the reader walks a linearized accessibility tree. When hover is spent as a desktop freedom, the edge of that freedom is that enter is missing from those two input vocabularies.

This is only discovery: without an enter event, the function is not in their world. It is not how to make a whole app keyboard-operable, and not how a reader walks headings and landmarks.

Why it happens

Pointer enter is a spatial event bound to hit-testing. Tab moves focus; focus can rest on a control, but by default it does not dispatch pointer enter, and it does not paint nodes that exist only inside :hover. A screen reader browses the accessibility tree: a button, a hint, a menu that is never on the tree, or is inserted only on hover, has never existed for the reader. Storing capability in the enter event stores it in a signal only a mouse or trackpad will emit. Keyboard and reader users are not “a bit slower”; they do not have that wire.

So the repair is not “shorten the hover delay.” However short, someone without a pointer still cannot emit enter. The same function has to hang on focus, on resident chrome, or on a name the reader can speak. Desktop freedom can keep serving the pointer; it cannot be the only dispatcher.

Studying it

Run a keyboard-only protocol: disable the pointer, allow only Tab, arrows, Enter, and shortcuts. Walk the same task with a screen reader (browse mode and focus mode). Record which steps need hover before an object appears or before a name appears.

Independent variables: whether the function hangs only on enter, whether focus reveals the same content, whether a matching node is on the accessibility tree. Dependent variables: keyboard-path dead-ends, names or controls the reader never speaks, false conclusions that the function does not exist.

Parking the mouse “helpfully” on the focused object measures the failure away. During the test the pointer has to leave the window or be hidden.

Where it stops holding

An interface that already mirrors the same preview on focus is discoverable to the keyboard; the reader still depends on that content entering the accessibility tree—the two channels have to be checked apart. Decorative hover highlight that carries no action fails as a weak cue, not as a lost function. Switch control and voice control also do not emit pointer enter; the failure shape is kin to the keyboard and is not developed here. Discoverability failure on touch is a migration problem with a different mechanism: touch has contact events, it just has no enter.

Applying it

• Any action or copy that appears only on pointer enter must also appear when focus lands on the same object, with a name on the corresponding accessibility-tree node.
• Do not let “a button appears when the mouse moves over it” be the only entrance to a command; the same command belongs in the menu bar or in resident chrome.
• Verify by hiding the pointer and finishing every primary task from the keyboard, then hearing the same path in a reader. Any step that needs “move the mouse over it, or this control / this sentence does not exist” is hover-only, and discovery has already failed.

Related

• Within the group: K2.06.1 Hover allows preview and hints without commitment · K2.06.2 Hover-dependent designs cannot migrate to touch · K2.06.3 A product that spans form factors needs two schemes · K2.06.4 Hover can progressively reveal secondary information so the first view is not crowded · K2.06.5 Hover delay must filter pass-through mouse movement · K2.06.7 If hover-state information is indispensable, the interface is missing persistent cues
• Adjacent: J3.01 Keyboard Access · J5.01 Screen Readers · D1.12 Distinguishing focus, hover, and selection
• Search terms: hover-only · keyboard discoverability · pointer-enter dispatcher