← All criteria

Understandable · Level A · 3.2.1

On Focus

Simply moving keyboard focus onto something — tabbing to it, not activating it — should never trigger a change of context: no auto-submitting forms, no popping open new windows, no silently jumping focus somewhere else. Those things are allowed on deliberate activation (Enter, Space, a click), just not on arrival.

  • Blind
  • Low vision
  • Cognitive
  • Motor
The problem, in practice — select the image to enlarge it
A signup form compared with focus that unexpectedly changes context versus focus that doesn't. 'Focus causes an unexpected change of context' shows tabbing into an email field auto-submitting the form, focusing a 'More details' link opening a new window on its own, and focusing a 'Help' link silently moving focus elsewhere to an unrelated notice, none of which the user asked for. 'Focus does not change context' shows the same three controls where tabbing into the email field does nothing until the user activates Subscribe, focusing the link opens nothing until activated, and focusing 'Help' simply keeps focus on the link until activated. Paired examples below contrast a dropdown menu that opens on focus and an accordion and tab set that expand or switch on focus, against versions of each that only open, expand, or switch when the user presses Enter, Space, or clicks.

How to recognize it

Tab through a page without pressing Enter or Space — just move focus — and watch for anything that changes beyond the visible focus indicator. The classic failure is a dropdown that navigates to a new page the instant an option receives focus while arrow-keying through it, before the user has committed to anything by pressing Enter. A related one: a form that submits itself the moment focus lands on the last field. Another: a custom widget that silently redirects focus somewhere else the instant it receives it, so tabbing forward jumps around unpredictably instead of proceeding in order. This doesn't rule out a dropdown or submenu that reveals more content on focus — that's fine, as long as it doesn't move focus itself, navigate, or open something new. Revealing content is not the same as changing context.

How to fix it

Trigger context changes — navigation, form submission, opening a new window, moving focus elsewhere — only on deliberate activation, never on focus alone. A <select> that changes pages should respond to an actual committed selection (a change event fired by choosing and confirming a value), not fire mid-navigation while someone is still arrow-keying through the options to see what's there. A component that needs to reveal more content when focused — a submenu, extra detail — can do that freely, as long as revealing it doesn't also move focus or change the page out from under the user.

Example

Avoid

select.addEventListener('focus', () => {
  window.location = select.value;
});
<form>
  ...
  <input onfocus="this.form.submit()">
</form>
<div tabindex="0" onfocus="document.getElementById('other').focus()"></div>

Prefer

select.addEventListener('change', () => {
  window.location = select.value;
});
<form>
  ...
  <button type="submit">Submit</button>
</form>
<div tabindex="0" onfocus="showTooltip()"></div>
<!-- reveals content, doesn't move focus or navigate -->

Resources