3.2.1 On Focus
- Level A
- Understandable
- Since WCAG 2.0
Summary
Keyboard users, screen reader users, and switch access users cannot glide a pointer past an element: to reach the control they want, they must land focus on every control in between. This criterion makes that journey safe. Merely focusing something must never teleport the user: no navigation to a new page, no form submission, no focus jumping elsewhere, no new window, and no major replacement of the page's content. If landing on an element commits the user to something, people who navigate sequentially are punished for the act of travelling.
The auditor's mental model: focus is inspection, not activation. The criterion has been at Level A since WCAG 2.0 and turns on the defined term "change of context", which covers exactly four things: a change of user agent, a change of viewport (a new window, or the page substantially replaced), a change of focus, or a change of content that changes the meaning of the page. Anything short of that on focus is allowed: showing a tooltip, applying a highlight, revealing a hint, or scrolling the focused element into view are all fine, because they do not disorient the user or move them somewhere else.
Official wording
When any user interface component receives focus, it does not initiate a change of context.
EN 301 549 mapping
- Web pages
- Clause 9.3.2.1
- Software and native apps
- Clause 11.3.2.1
Clauses 9.3.2.1 (web) and 11.3.2.1 (software) apply this criterion unchanged, so the same requirement binds web pages and native app user interfaces.
Clause references are to EN 301 549 V3.2.1 (2021-03), the harmonised European standard. Descriptions are our own summary, not the text of the standard.
In practice
Web
Test with the keyboard alone. Put the pointer aside, press Tab (and Shift+Tab) through every interactive element on the page, and watch for anything that happens beyond the focus indicator appearing: the URL changing, a form submitting, focus leaping to a different element, a new window or tab opening, or the main content being swapped out. Every one of those on focus alone is a fail. In browser devtools, inspecting for focus and focusin event listeners on suspect elements tells you where to look, but the graded evidence is the observed behaviour.
The classic fail is the navigation dropdown built on a select or listbox that navigates as soon as an option receives focus: a keyboard user pressing the down arrow to browse the options is redirected on the first press and can never reach the later ones. Grade what triggers the redirect. If merely moving through the options (moving focus or highlight) fires it, that is a 3.2.1 fail; if the redirect fires only when a value is actually committed, the finding belongs under SC 3.2.2 On Input instead.
Also probe the entry points people forget: fields that open a date picker overlay in a way that steals focus, login fields that spawn a help popup when tabbed into, and single-page app widgets that re-render whole regions when a control is focused. A tooltip or description appearing next to the focused field is not a change of context; replacing the page's primary content is.
iOS
The criterion applies unchanged to native software under the European standard, so grade apps to the same rule. Test with two focus mechanisms. First, connect a hardware keyboard (enable Full Keyboard Access in Settings under Accessibility, Keyboards) and Tab or arrow through every screen: moving keyboard or switch focus onto a control must not activate it, push a new view controller, present a modal, or move focus somewhere else. Switch Control follows the same traversal, so a focus-triggered action strands switch users the same way.
Second, run VoiceOver and swipe through the screen element by element. VoiceOver focus landing on an element must never activate it: landing is announce-only, and activation happens only on an explicit double tap. Any element that fires its action, opens a screen, or repositions accessibility focus simply because VoiceOver reached it is a fail. Accessibility Inspector's audit will not catch this behaviour, so it must be observed on device.
The recurring iOS failure spot is the auto-advancing form: a field that submits the form, jumps focus onward, or pushes the next screen when it merely gains focus. Note the boundary carefully, because code-entry fields that advance after a digit is typed are reacting to input, not focus, and file under SC 3.2.2 if unexpected.
Android
The same rule applies to Android under the European standard. Test with a hardware keyboard or switch access first: Tab and arrow through every screen and confirm that input focus landing on a control never activates it, starts a new activity, opens a dialog, or submits a form. Spinners and custom pickers deserve particular attention, since a spinner that acts as each entry is highlighted during traversal recreates the classic dropdown fail.
Then test with TalkBack: swipe through the screen and confirm that moving accessibility focus is announce-only. An element that triggers its click action, navigates, or throws accessibility focus elsewhere when TalkBack reaches it fails. Watch for views that abuse onFocusChange or accessibility focus events to fire behaviour meant for onClick, and for forms that auto-advance or auto-submit when a field gains focus rather than when a value is entered. Layout Inspector will not show you this; it is behavioural, so traverse every screen on device and log what fires.
Pass and fail examples
Passes:
- Tabbing onto a button shows a visible focus ring and a tooltip describing it: new content appeared, but the meaning of the page is unchanged and nothing moved.
- Focusing a form field reveals inline format hints below it ("DD/MM/YYYY"): supplementary content, not a change of context.
- Tabbing to an element below the fold scrolls it into view: bringing the focused element into the viewport is expected behaviour.
- A navigation dropdown where arrowing through options only moves the highlight, and the site navigates when the user presses Enter or clicks a Go button.
- A VoiceOver or TalkBack swipe lands on a "Delete account" button and announces it; nothing happens until the user explicitly activates it.
Fails:
- A select-based navigation menu that redirects the moment arrow keys move focus or highlight onto an option: keyboard users are ejected on the first arrow press.
- A search field that submits the form when it receives focus.
- Tabbing into a promotional region opens a new window or full-screen overlay on focus alone.
- Focusing the first field of a form jumps focus to a different field or control the user did not choose.
- Moving VoiceOver or TalkBack focus onto a list item activates it and pushes a new screen.
Not a fail under this criterion:
- A dropdown that navigates when the user changes its committed value: that is a change of context on input, graded under SC 3.2.2 On Input.
- Focus moving through the page in a confusing or illogical sequence: order problems belong to SC 2.4.3 Focus Order, not here, provided each focus stop is inert.
- A tooltip that appears on focus but covers the field's content and cannot be dismissed: the appearance is fine under 3.2.1; the obscuring and dismissal behaviour is graded under SC 1.4.13 Content on Hover or Focus.
- A one-time cookie banner that appears on page load: it was not initiated by any component receiving focus.
Commonly confused with
- SC 3.2.2 On Input. The cleanest boundary in the pair: 3.2.1 covers what happens when a component merely receives focus; 3.2.2 covers what happens when the user sets its value. A dropdown that redirects while you arrow through it fails 3.2.1; one that redirects when you commit a selection fails 3.2.2. Identify the trigger before filing.
- SC 2.4.3 Focus Order. If focus lands somewhere unexpected because the sequence is wrong, that is a focus order finding. 3.2.1 fires only when receiving focus causes something: an inert but oddly ordered tab sequence is 2.4.3 territory alone.
- SC 1.4.13 Content on Hover or Focus. Content appearing on focus is permitted under 3.2.1, but 1.4.13 governs how that content behaves: it must be dismissible without moving focus, and must not trap or obscure. A tooltip complaint is usually a 1.4.13 finding, not a change of context.
- SC 3.2.5 Change on Request. The Level AAA criterion asks that all changes of context happen only on explicit request. In a Level A or AA audit, do not import that stricter bar: 3.2.1 forbids context changes on focus specifically, not every automatic change.
How AUDITSU tests this
AUDITSU's audit walkthrough covers On Focus on every screen you review. The keyboard questions have you traverse the full screen with Tab, arrow keys, or switch access and record whether any element triggered navigation, submission, a focus jump, a new window, or a content swap on focus alone; the screen reader pass, run with VoiceOver or TalkBack active, has you confirm that landing on each element is announce-only. Each question records a pass, fail, or not applicable result per screen with evidence attached, so a focus-triggered redirect is tied to the exact screen and control that caused it.
Because the criterion applies unchanged to web and software under the European standard, the walkthrough asks the same questions of websites and native apps, swapping only the traversal tool. For the full guided workflow, see the audit platform.