On Focus

What it asks

Receiving focus must never trigger a “change of context.” WCAG defines a change of context as: navigating to a new page, opening a new window, moving focus to a different component, or significantly rearranging the page content. Focus is the keyboard equivalent of moving the mouse over an element — it must remain passive.

The user must drive context changes through deliberate activation: pressing a button, hitting Enter on a link, submitting a form.

How to meet it

• Never call window.open, location.href = …, or form.submit() from a focus event handler.
• Tooltips and small reveal-on-focus disclosures are fine — they don’t constitute a change of context. Major content swaps do.
• For autocomplete suggestions, moving focus to an option does not violate this SC as long as the suggestion list itself is the expected behavior.
• If you must reveal additional UI when an element is focused (like input help text), keep it adjacent and non-disruptive.
• Test with the keyboard: Tab through every interactive element. Anything that “jumps” or auto-submits on focus is a failure.

Common failures

• A dropdown that auto-submits when an option receives focus via arrow keys.
• Tab focusing on a link that triggers an immediate navigation through an onfocus handler.
• Date pickers that close themselves the instant the next field receives focus, before the user has finished interacting.
• Sign-in forms that auto-submit when the password field gains focus from a password manager.

Why it matters

Keyboard users navigate by moving focus through the page sequentially. If focus triggers a context change, the user is suddenly somewhere they did not intend to go — and for screen-reader users, this is disorienting because the announcement queue suddenly shifts. The rule is simple: focus orients, activation acts.