On Focus

Why it matters

Tab is a walk-through key. To reach the control they want, a keyboard user has to pass through every control in front of it, so anything that fires on the way past fires by accident. Turn passing through into acting and exploring the page becomes a minefield. That is not a polish problem. It is the thing that has to be true before keyboard navigation can exist at all. And focus is not only a keyboard idea, because clicking into a text field focuses it too, so a mouse user can trip the same wire.

Who this rule protects

Keyboard and screen reader users pass through every control on the way to any control, so a page that acts on focus touches almost everything they try to do. People with motor impairments are hit twice, since a tremor or a switch makes an unintended focus more likely in the first place. Users with cognitive disabilities lose their place when a page moves on its own instead of waiting to be asked.

How to check it yourself

1. 1Tab across every interactive element on the page and press nothing else. Not Enter, not Space, not an arrow key.
2. 2Watch for the four things that count as a context change. A new window or tab, a changed viewport, focus jumping somewhere you did not send it, or the page rearranging enough that it reads as somewhere new.
3. 3Click into text fields with a mouse as well. Focus arrives that way too, and the rule covers any component receiving focus however it arrives.
4. 4Leave the benign changes alone. A tooltip, a highlighted row or a submenu opening on focus changes content without changing context, and the criterion is met automatically when that is all that happens.
5. 5Check whether anything loses focus the moment it gets it. Tab to it, then look at where focus actually sits, because a scripted blur sends it back to the top of the document and takes keyboard access with it.

Failures we see most often

• A help dialog opens whenever a field receives focus and pulls focus into itself, so a keyboard user tabbing past that field is caught by it every single time.
• A jump menu navigates to a new page the moment an option receives focus from the arrow keys, before the user has confirmed anything.
• A form submits itself as soon as focus lands in its last field, so moving away to reread the instructions sends it.
• A script calls blur on an element the instant it receives focus, usually to hide the focus ring. That removes the outline, removes the focus, and leaves the control operable by mouse only.
• A single-page app routes to a new view on focus. Nothing reloads and nothing announces it, and to the user it looks exactly like landing on a different page.

Who this one is for

Read from this rule's own note above, so the grouping and the note cannot disagree.

• Blind and screen reader userspeople who cannot see the screen
• Motor and keyboard-onlypeople who cannot use a mouse, or cannot use one precisely
• Cognitive and learningpeople for whom the difficulty is understanding, remembering, or staying with it

How to fix it

• Trigger changes on activation, never on focus. Enter, Space and click are activation. Arriving is not.
• Let a select be arrowed through freely and act only when the user confirms. Escaping or tabbing out of it should leave the page exactly where it was.
• Where a widget has to open something, open it on the press that asked for it, and leave focus where the user put it unless they asked to be moved.
• Never script focus away from an element that just received it. If the focus ring is the problem, restyle the ring, because a visible focus indicator is its own requirement and both can be satisfied at once.

Passes vs. fails