Overly similar focus, hover, and selection styles obscure the current mode

What it is

State distinguishability means focus, hover, and selection appear differently enough, and in ways consistent with meaning, that people know their current interaction mode: where keyboard commands will land, what a pointer is exploring, and which objects belong to an action set. If all three use nearly identical pale fill or highlight border, people see only “something lit up” and cannot predict consequences of a key, click, pointer movement, or batch command.

Why it happens

Visual state is external memory for operating rules. People use it to decide whether to continue keyboard navigation, whether they are previewing clickability, and whether a command target is fixed. Similarity collapses different lifetimes and consequences: transient hover looks like persistent selection, singular focus looks like a batch set, and selected objects look like mere pointer passage. People then diagnose through extra clicks, repeated movement, and undo, losing efficiency and confidence. State is a visible mode explanation, not decoration.

Studying it

Construct dynamic scenes where states occur alone and together: select several items, move focus, sweep a pointer over selected and unselected items, change to touch or keyboard, and ask participants to predict the next key, click, or batch outcome. Measure prediction accuracy, error, hesitation, and exploratory actions. Static comparison reveals similar color but not understanding; observe whether states remain correctly interpreted as they appear, persist, and disappear over time.

Where it stops holding

Different does not require unrelated colors or strong decoration for every state. Excessive difference harms consistency, creates noise, and lets low-consequence hover overpower selection. At least one reliable dimension must distinguish semantics and lifecycle—outline, fill, persistence, icon, text, or input-mode cue can combine. Devices without hover still need focus and selection distinguished; losing one state is not an excuse to abandon state design.

Applying it

• Specify trigger, affected object, lifetime, and command consequence for focus, hover, and selection, then assign coexisting visual cues from those semantics.
• In component libraries, show isolated and overlapping state examples across light/dark backgrounds, dense lists, keyboard use, and multi-selection—not only a default screenshot.
• Match intensity to consequence: persistent selection and keyboard focus must support more accurate judgment than exploratory hover without hiding one another.
• Validate through behavior prediction. People should name whether they are browsing, keyboard-locating, or selecting without acting; needing to try is insufficient distinction.

Related

• Within the group: D1.12.1 Focus is independent of pointer · D1.12.2 Hover exists only on pointer devices · D1.12.3 Selection may differ from focus
• Adjacent: D1.03 Selection and highlighting · D1.04 Focus indicators · D1.05 Hover feedback
• Search terms: state distinguishability · interaction mode · focus hover selection