In a benefits application, document actions appear only on pointer hover; why does that fail across input modalities, and what would you do instead?

## Input modalities differ in what they can do An **input modality** is a way of operating an interface: a mouse or trackpad pointer, a finger on a touchscreen, a stylus, a keyboard, voice control, or a switch device. A design that relies on something only one modality can do works only for that modality. Pointer hover is the classic case. | Modality | Has a hover phase? | How it targets a control | What happens to hover-only actions | |---|---|---|---| | Mouse or trackpad | Yes | Moves a pointer, then clicks | Visible, but only once the pointer crosses the row | | Touch | No | Touches the control directly | Hidden; may appear only after a first tap, which feels broken | | Keyboard | No, it has focus instead | Moves focus, then activates | Hidden unless focus reveals them too | | Voice control | No | Speaks the visible name of a control | Cannot be spoken, because no control with that name is shown | | Switch access | No | Steps through controls in sequence | Unreachable unless they join the sequence | Some styluses report hover and some touch environments emulate it on a first tap, but neither can be relied on. ## Why hover-only actions fail In a benefits application, each uploaded document row shows 'Replace' and 'Remove' only while the pointer is over it. That fails in four ways: 1. **Touch users** see a row with no actions. Replacing a blurred payslip, a key recovery path, looks impossible. 2. **Keyboard users** can reach the row, but unless focus reveals the same actions, they cannot reach them. 3. **Voice-control users** cannot say 'click Replace', because nothing on screen carries that name. 4. **Everyone** has a discoverability problem: nothing signals that actions exist until the pointer happens to cross the row. The usual argument for hover-reveal, a cleaner-looking list, rarely outweighs these costs on a task where replacing the wrong document is common. ## Better patterns - **Persistent, labelled actions** on each row: the most robust choice when rows have one or two actions. - **One visible 'more actions' control** per row, opening a menu on tap, click, key press or spoken name: good when there are several actions. - **Row activation opens a detail view** holding the actions, when each document has enough detail to deserve its own view. - **Reveal on focus as well as hover**, if a hover reveal is kept for density. This is a minimum for keyboard users, but it does nothing for touch or voice. Hover can still **enhance**: a highlight showing which row the pointer is on is helpful. It just cannot be the **only** way to find or reach an action. ## The general rule: one universal path, then accelerators Design each action with a **primary path** that any modality can use: a visible, named control operated by a single activation. Then add modality-specific **accelerators** for people who benefit from them: - hover highlights and contextual menus for pointers; - swipe or long-press gestures on touch; - keyboard shortcuts; - drag and drop, alongside a way to do the same thing without dragging. Native mobile platforms face exactly the same trade-off. A swipe-to-remove gesture on a document row is a hidden accelerator with no signifier; it is fine as long as a visible action exists too. A design system shared across web and native mobile should therefore specify hover behaviour as an enhancement that some platforms will simply not have. ## What the standards say Accessibility standards encode parts of this rule. Their detail belongs to accessibility practice, but an interaction designer should know they exist. Under WCAG 2.2: - **2.1.1 Keyboard** (Level A) requires all functionality to be operable through a keyboard interface, except where the underlying function depends on the path of the user's movement. - **2.5.1 Pointer Gestures** (Level A) requires functionality operated by multipoint or path-based gestures to be operable with a single pointer without such a gesture, unless the gesture is essential. - **2.5.7 Dragging Movements** (Level AA, new in 2.2) requires anything done by dragging to be achievable with a single pointer without dragging, with narrow exceptions. - **1.4.13 Content on Hover or Focus** (Level AA) applies when hover or focus reveals additional content: that content must be dismissible, hoverable and persistent. These are floors. Designing around a universal primary path meets them as a side effect, and it also serves people who never use assistive technology, such as someone holding a phone in one hand on a crowded bus.