Keyboard focus must always be visible
Aliases: focus indicator · keyboard navigation · active element
What it is
Visible keyboard focus is a perceptible indication of the element that will receive the next keyboard command. It is neither pointer hover nor selected content: focus is the target for Tab, arrow keys, Enter, and Space. Whether it moves through sequential navigation, script updates, a dialog, validation error, or a return to a page, people should locate it immediately. Invisible focus turns keyboard interaction into commands sent to an unknown object.
Why it happens
Pointer users infer a target from cursor position. Keyboard users require the focus state supplied by the system to bind action to object. Focus moves continuously while views scroll, redraw, and transition; if its cue is clipped, obscured, or does not enter the viewport with it, the spatial model breaks. This affects more than mouse-free access: an efficient keyboard workflow collapses into repeated Tab presses, guessed order, or a switch to a pointer when the landing point disappears.
Studying it
Use keyboard-only tasks through forms, menus, tables, dialogs, and dynamically loaded regions. Record lost focus, unintended activation, backtracking, and switches to a mouse. Cover forward and reverse Tab, arrow navigation within composites, hidden content, dialog open/close, and focus restoration after asynchronous change. Automation can find focusable elements and order, but not whether people can see and interpret focus; observe at different zoom levels, scroll positions, and high-contrast settings.
Where it stops holding
Visibility does not make every element a Tab stop. Decoration, duplicate links, noninteractive content, and genuinely hidden regions should not add stops. Nor can a visually active or selected item impersonate focus if it will not receive keyboard commands. Components may need to move focus when opening a layer, deleting the current item, or changing route; failure is a move without a visible new destination that fits the task.
Applying it
- Specify focus entry, internal movement, exit, and restoration after removal for each keyboard-operable component.
- Keep the indicator unclipped in scroll containers and overlays; reveal the target when focus leaves the viewport.
- On dialog open, place focus at a meaningful start; on close, return it to the trigger or semantic equivalent.
- Complete consequential flows by keyboard only and ask testers to name the current target at every step. Any need to guess or use a mouse to recover is a failure.