WCAG 3.2.1: On Focus
Keyboard users move focus through a page just to see what is there. That exploration has to be safe. This criterion requires that merely focusing a component never initiates a change of context — no new windows, no stolen focus, no navigation, no form submission. Looking is not the same as acting; focus is looking.
The success criterion, in full
When any user interface component receives focus, it does not initiate a change of context.
One sentence, no exceptions. “Change of context” is a defined term covering four kinds of major change: user agent, viewport, focus, and content that changes the meaning of the page. Content changes that do notalter the page’s meaning — a tooltip, an outline, revealed hint text — are allowed on focus.
Who this helps
Keyboard-only users
Tab and Shift+Tab are how they survey a page. If focusing a control fires an action, every keystroke risks launching something they never chose — navigation becomes a minefield.
Screen reader users
Focus position is reading position. A context change on focus yanks them to a different window or page mid-sentence, with no visual cues to reconstruct where they went.
People with low vision
Magnification shows a small slice of the page. A new window or focus jump happening off-screen is invisible — the user simply finds themselves lost.
People with cognitive or attention disabilities
Predictability is load-bearing. Interfaces that mutate on mere focus break the mental model that exploring is safe and acting is deliberate.
Remember that focus arrives in more ways than a deliberate Tab press: scripts call element.focus(), screen readers move focus while reading, and browsers restore focus after dialogs close. A focus handler with side effects fires in all of those situations — which is exactly why it must stay side-effect free.
What is a “change of context”?
WCAG defines a change of context as a major change that, if made without user awareness, can disorient users who cannot view the whole page at once. Four categories qualify:
- Change of user agent: Another application or browser takes over the interaction.
- Change of viewport: A new window or tab opens, or the view jumps so different content fills the screen.
- Change of focus: Focus moves to a different element than the one the user reached — including into a spawned dialog.
- Content change that changes the meaning of the page: Navigation to a new page, form submission, or a substantial rearrangement of content.
Equally important is what does not qualify: focus outlines and style changes, tooltips and hint text appearing beside the field, an accordion label highlighting, live-region announcements. These are changes of content, not context. Show all the help you like on focus — just do not move the user anywhere. (How hover/focus-triggered content must behave is covered by 1.4.13 Content on Hover or Focus.)
Pass and fail examples
Pass: hint text appears on focus
Focusing the password field reveals the password requirements below it. Focus stays in the field, nothing else moves — a content change that helps rather than disorients.
Pass: dialog opens on activation, not focus
Tabbing onto “Delete account” does nothing but show a focus ring. Only pressing Enter or clicking opens the confirmation dialog and moves focus into it. Exploration and action stay separate.
Fail: popup window on focus
Tabbing onto a promotional link spawns a new window with an offer. The keyboard user was passing through on the way to the navigation — now they are in another window they never asked for.
Fail: focus jumps as soon as it lands
A form’s onfocus handler redirects focus from a “disabled-looking” field to another element the developer prefers. Screen reader users can now never inspect that field — focus refuses to stay where they put it.
Fail: form submits when the last field is focused
To “streamline” checkout, focusing the final input triggers submission of the form. Keyboard users tabbing through to review their entries submit a half-checked order.
Code examples
Never open windows or navigate from a focus handler
<!-- ✗ Fails: receiving focus opens a new window -->
<a href="/offer" onfocus="window.open('/promo', '_blank')">Special offer</a>
<!-- ✗ Fails: receiving focus navigates -->
<input type="text" onfocus="location.href='/signup'" />
<!-- ✓ Passes: focus is inert; action happens only on activation -->
<a href="/offer">Special offer</a>Reveal help on focus without changing context (React)
Showing adjacent content on focus is allowed and useful. Focus stays in the input; the hint is tied to it with aria-describedby.
function PasswordField() {
const [showHint, setShowHint] = useState(false)
return (
<div>
<label htmlFor="pw">New password</label>
<input
id="pw"
type="password"
aria-describedby="pw-hint"
onFocus={() => setShowHint(true)} // ✓ content change only
onBlur={() => setShowHint(false)}
/>
{showHint && (
<p id="pw-hint">
Use at least 12 characters with one number and one symbol.
</p>
)}
</div>
)
}Open dialogs from activation events, not focus events
// ✗ Fails: tabbing onto the button opens the dialog and moves focus
helpButton.addEventListener("focus", () => {
helpDialog.showModal() // focus jumps into the dialog uninvited
});
// ✓ Passes: the dialog opens only when the user activates the button
helpButton.addEventListener("click", () => {
helpDialog.showModal() // moving focus into a user-requested dialog is fine
});
// (click fires for Enter and Space on a native <button> too)Common failures
- Opening a new window, tab, or modal dialog the moment an element receives focus.
- onfocus handlers that call element.focus() on something else, bouncing users away from fields they are trying to inspect.
- Submitting a form when a particular field (often the last one) receives focus.
- Navigating to another page when a link or menu item is merely focused, before any activation.
- Custom dropdowns or comboboxes that expand and move focus into their list as soon as the trigger is tabbed onto.
- Focus-triggered content that obscures or replaces the main content so thoroughly the page's meaning changes.
- Third-party chat, survey, or ad widgets that grab focus when their container is focused during normal tabbing.
How to test for 3.2.1
- 1
Tab through the entire page — and only tab
Starting at the top, press Tab through every focusable element without pressing Enter, Space, or clicking. Watch for anything beyond styling: no new windows, no navigation, no focus jumping, no submissions, no substantial content rearrangement.
- 2
Shift+Tab back through
Reverse direction. Focus handlers sometimes behave differently when elements are entered from the other side (e.g. redirect-on-focus loops become obvious).
- 3
Watch the focus indicator like a hawk
After each Tab press, confirm focus is on the very next focusable element. If it ever lands somewhere unexpected, an onfocus handler moved it — a change of context.
- 4
Grep the code for focus handlers
Search for onfocus, addEventListener('focus'/'focusin'), and framework equivalents (onFocus). Review each: revealing adjacent content is fine; window.open, location changes, form.submit(), or .focus() calls on other elements are failures.
- 5
Repeat with a screen reader running
NVDA and VoiceOver move focus differently (virtual cursor, forms mode). Walk the page and confirm no component hijacks the experience when the screen reader focuses it.
Pair this test with 2.4.3 Focus Order and 2.4.7 Focus Visible — one keyboard pass through the page can verify all three. The complete WCAG 2.2 checklist sequences them for you.
Frequently asked questions
What does WCAG 3.2.1 On Focus require?
When any user interface component receives focus, it must not initiate a change of context. Simply tabbing to (or programmatically focusing) a link, button, field, or widget must never open a new window, move focus somewhere else, navigate to another page, submit a form, or substantially rearrange the page. Focus must be a safe, read-only operation: users explore with it, then act deliberately with Enter, Space, or a click. It is a Level A criterion, part of Guideline 3.2 Predictable, present since WCAG 2.0.
What exactly is a 'change of context'?
WCAG defines it as a major change in the content of the page that, if made without user awareness, can disorient users who cannot view the whole page at once. Four kinds count: a change of user agent (e.g. another application takes over), a change of viewport (new window or tab, focus jumping elsewhere), a change of focus itself, and a change of content that alters the meaning of the page (loading a new page, radically rearranging content). Smaller updates — an outline appearing, a tooltip showing, text being revealed nearby — are changes of content but not changes of context.
Is showing a tooltip or hint on focus a failure?
No. Content appearing on focus is fine as long as the user's context is preserved: focus stays where it is, no window opens, the page's meaning does not change. Tooltips, inline hints, and expanding descriptions are legitimate focus behaviors — they are governed by 1.4.13 Content on Hover or Focus, which regulates how such content must be dismissible and persistent, not whether it may appear. A modal dialog opening on focus, by contrast, moves focus and changes context, so it fails 3.2.1.
Why does On Focus matter so much for keyboard and screen reader users?
Because for them, focus is how they read the page. A sighted mouse user only points at things they intend to use; a keyboard user must move focus through elements just to discover what exists, and a screen reader user's focus movement is their reading position. If merely landing on a control fires an action, these users cannot explore safely — every Tab press becomes a gamble. Users with cognitive disabilities and low vision (who may not see the popup or the new tab appear) are similarly disoriented by context changes they never requested.
Does 3.2.1 forbid moving focus into a dialog I open on a click?
No. The criterion restricts what happens when a component receives focus, not what happens on activation. Clicking a button (or pressing Enter on it) is an explicit user action, and opening a dialog then moving focus into it is expected, appropriate behavior. The failure pattern is context change triggered by focus alone — tabbing onto the button and having the dialog leap open before the user pressed anything.
How is 3.2.1 different from 3.2.2 On Input?
They are siblings in Guideline 3.2 Predictable, covering successive moments of interaction. 3.2.1 covers receiving focus: tabbing onto a component must change nothing. 3.2.2 covers changing a setting: typing in a field, picking a select option, or toggling a checkbox must not automatically cause a change of context unless users were warned beforehand. Together they guarantee that both exploring the page and operating its controls are predictable, with actions only committed by explicit activation.
Related Success Criteria
Changing settings of a component does not automatically cause context changes.
Navigational mechanisms are repeated in the same relative order.
Components with the same functionality are identified consistently.
Changes of context are initiated only by user request.
Help mechanisms appear in the same relative order across pages.