WCAG 2.2 - Success Criterion
3.2.1 On Focus
Description
When any user interface component receives focus, it must not initiate a change of context. A change of context is a major change in the content of a web page that can disorient users if triggered unexpectedly, including changes such as opening a new window, moving focus to a different component, submitting a form, or significantly rearranging the page's content. This criterion ensures that focus alone - without an explicit user action such as a click or keypress - does not cause such disruptive changes.
How To Test
- Using only the keyboard (Tab, Shift+Tab), move focus through all interactive elements on the page: links, buttons, form fields, and custom widgets.
- Observe whether receiving focus on any element triggers a change of context, such as page navigation, a new window, a form submission, or a significant content change.
- Pay particular attention to
<select>menus, custom comboboxes, and auto-suggest inputs - verify that focus alone does not submit or navigate. - Check that modal dialogs, tooltips, and popups triggered by focus do not move focus away from the current control unexpectedly.
- Use a screen reader (e.g., NVDA + Firefox) and tab through the page, listening for unexpected announcements indicating a context change.
Testing Tools
- axe DevTools — Scan for missing link text, label associations, and heading structure issues.
- NVDA — Navigate links and form fields using Tab and arrow keys to verify purpose is announced clearly.
- VoiceOver (macOS) — Alternative screen reader to test link names, form labels, and heading hierarchy.
Demo
This markup auto-navigates the moment the user changes the <select> value - including when keyboard users press arrow keys to browse options, before they have made a choice.
<!-- Fail: context change triggered by input, not explicit action -->
<label for="country-fail">Choose a country:</label>
<select id="country-fail"
onchange="window.location = this.value">
<option value="/en/">English</option>
<option value="/fr/">Français</option>
<option value="/de/">Deutsch</option>
</select>
The same select requires an explicit "Go" button press to navigate. Focus alone - or arrow key browsing - causes no context change.
<!-- Pass: navigation requires explicit activation -->
<label for="country-pass">Choose a country:</label>
<select id="country-pass">
<option value="/en/">English</option>
<option value="/fr/">Français</option>
<option value="/de/">Deutsch</option>
</select>
<button type="button"
onclick="window.location = document.getElementById('country-pass').value">
Go
</button>
Code
Demo 2: Help Dialog on Focus
A help dialog launches the moment a user tabs into or focuses on a form field, without any explicit activation. This blocks access to the field until the user closes the dialog.
<!-- Fail: Help dialog triggered by focus -->
<input id="email-fail"
type="email"
onfocus="showHelpDialog()">
The same form field has no focus trigger. Help information appears only when the user explicitly clicks a dedicated help button, leaving the field accessible.
<!-- Pass: Help triggered by explicit button click -->
<input id="email-pass"
type="email">
<button type="button"
onclick="showHelpDialog()">
Help
</button>
Code
Fail Explanation
A common failure occurs when a <select> element or a custom dropdown automatically submits a form or navigates to a new URL as soon as a user tabs into it. Another failure is a pop-up dialog or new browser window that launches the moment a component receives keyboard focus. These behaviors are especially harmful for keyboard-only users and screen reader users, who cannot predict or prevent focus from triggering consequential actions and may become confused about where they are in the page or workflow.
Pass Explanation
A page passes when receiving keyboard focus on any interactive component merely highlights or visually indicates that component without triggering navigation, form submissions, new windows, or other context-shifting events. Any meaningful action should require an explicit activation step - such as pressing Enter, Space, or clicking - so that users retain full control over when changes occur.
Notes
There is an important distinction between a context change and a simple content update: appearing inline hints, expanding tooltips, or highlighting are generally not context changes and do not fail this criterion. The focus is on major, disorienting changes that interfere with the user's ability to predict the result of their navigation.
Techniques
WCAG techniques used in this demo: G107
Suggested Solutions & References
Curated from 5 real-world audit findings.