Focus must be visible

What it is

Wherever keyboard focus sits, there must be a visible indicator that does not depend on pointer position—typically a focus ring, a high-contrast outline, or a clear background shift. Without it, Tab still moves focus, but users lose the coordinate of “where the next hop starts.” Visible does not mean “can be found if you hunt.” It means, at ordinary contrast and viewing distance, no guessing.

Why it happens

Pointer users know what they are aimed at from cursor shape and hover. Keyboard users have no such cursor; the focus indicator is the only location signal. Removing the default outline leaves focus present in the tree and identical on screen to the unfocused state. People can only reverse-engineer location by tentatively pressing Space or Enter, which may submit a form or fire a destructive action. The indicator must also separate from the control’s other visual states: if selected, error, and disabled share a colour with focused, keyboard users cannot tell “already chosen” from “just passing through.” Focus visibility solves location uncertainty, not general text contrast—but if contrast is too low, the indicator is equivalent to none.

Studying it

With the mouse disabled, have people complete a multi-step form or toolbar and record time spent locating focus, erroneous activations, and whether they can point to “focus is here.” Independent variables include presence of an indicator, whether it shares colour with the selected state, and background complexity; dependent measures include localisation time and mis-hits. Accepting focus styles with mouse clicking misses the problem: the pointer already supplies location. Use a keyboard-only condition, and repeat on dark backgrounds, photographic backgrounds, and dense toolbars.

Where it stops holding

Custom canvases (maps, design tools) may use their own selection box for “object selected” and still need a second expression for “keyboard focus is on this object”; the two must not collapse into one box. On touch-first devices where a keyboard is only occasionally attached, pointer users dislike a persistent ring. Showing it only after keyboard use is acceptable, but once keyboard input appears the indicator must return. Low-vision users need a thicker ring, not a one-pixel brand-coloured line.

Applying it

• Give every focusable control an indicator distinguishable from unfocused, selected, and error states. Do not delete the outline for a cleaner look.
• If the ring should not appear during pointer use, show it after keyboard navigation is detected and do not hide it again while that keyboard user remains.
• In a keyboard-only walkthrough, each Tab press must make focus nameable at a glance; any hop that requires search or guess fails the indicator.

Related

• Same group: C6.05.1 Tab order should match visual reading order · C6.05.3 Overlays must capture focus and return it on close · C6.05.4 Hidden elements must not remain in the focus sequence
• Adjacent: C6.22 Focus order and keyboard navigation · C1.19 Cursor shapes as state expression
• Search: focus visible · focus ring · keyboard focus