Focus is the programmatic and visual indicator of which element is currently active and ready to receive input. As users navigate a page, especially with a keyboard or assistive technology, focus moves from one element to the next.
For many users, focus is how they understand where they are on a page. Screen readers announce focus changes, keyboard users rely on it to move forward, and alternative input users depend on it to explore content safely.
When simply moving focus causes something to happen, such as navigation, form submission, or a dialog opening, users lose control. WCAG requires that focus itself never trigger a change of context.
WCAG Success Criterion
3.2.1 On Focus (Level A)
When any user interface component receives focus, it does not initiate a change of context. This is a Level A requirement and applies to all content, including custom components created with scripting.
What WCAG Means by “Focus”
Focus is a state, not an action. An element receives focus when it is selected and ready for interaction. Focus can move when a user:
- Tabs through the page with a keyboard
- Navigates using a screen reader
- Clicks into a form field
- Uses assistive technologies that simulate keyboard input
Important distinctions for beginners:
- Focus is programmatic, not just visual
- Screen readers announce focus changes
- Focus is different from hover (mouse-only)
- Focus is different from activation (clicking or pressing Enter)
An element can receive focus without being activated.
What WCAG Means by “Change of Context”
A change of context is a significant shift in what the user is interacting with or perceiving, such as:
- Navigating to a new page
- Opening a new window, modal, or dialog
- Submitting a form
- Automatically moving focus elsewhere
- Replacing large sections of content
These changes are allowed only after an explicit user action, such as clicking a button or pressing Enter, not simply because focus moved.
What This Criterion Requires
Users must be able to move focus around the page safely.
When an element receives focus, it may:
- Show a visual focus indicator
- Become ready for input
- Be announced by a screen reader
But it must not:
- Navigate automatically
- Submit a form
- Open a dialog or popup
- Shift focus away on its own
If something changes the page, the user must clearly choose to make that change.
Realistic Examples: Failure vs Success
Failure: Navigation on Focus
A dropdown menu automatically redirects to a new page as soon as an option receives focus while tabbing.
The user never activated the option, they only moved focus.
Success: Activation Required
The same dropdown allows users to move through options using the keyboard.
Navigation happens only when the user presses Enter or Space.
Failure: Dialog Opens on Focus
A help dialog opens automatically when a form field receives focus, stealing focus away from the field.
As a keyboard user tabs through the page, focus is repeatedly hijacked.Success: Help on Demand
A help button next to the field opens the dialog only when activated, not when the field receives focus.
Why This Fails in Real Projects
Most failures of SC 3.2.1 are unintentional.
Common causes include:
- JavaScript listening to
onfocusorfocusinevents - Custom widgets that treat focus as selection
- Single-page applications that change routes on focus
- Menus, carousels, or tooltips that auto-open on focus
These patterns often look fine visually, but break keyboard and screen reader navigation.
Safe vs Unsafe Focus Behavior
Safe on Focus
- Visual focus styling (
:focus) - Screen reader announcements
- Highlighting the active element
- Preparing a control for interaction
Unsafe on Focus
- Navigation or page reload
- Form submission
- Opening modals or dialogs
- Replacing content
- Moving focus automatically
Styling on focus is expected. Behavioural changes are not.
Common Failure Patterns
- Submitting a form when a field receives focus
- Navigating when a menu item is focused but not activated
- Opening popups, dialogs, or tooltips on focus
- Automatically shifting focus elsewhere
- Assuming native controls are always safe after scripting them
Once behaviour is added, even native controls can fail this criterion.
Relationship to Other Criteria
- 3.2.2 On Input — covers changes after user input
- 2.4.3 Focus Order — ensures focus moves logically
- 2.4.7 Focus Visible — ensures users can see focus
On Focus specifically prevents changes from occurring before the user activates a control.
How to Test
- Navigate the page using only the keyboard (Tab / Shift+Tab)
- Observe what happens as elements receive focus
- Confirm that:
- No navigation occurs
- No dialogs open
- No content updates unexpectedly
- Activate controls intentionally (Enter / Space)
- Verify that changes happen only after activation
If focus alone causes a change of context, the criterion fails.
Rule Description
User interface components must not trigger navigation, dialogs, form submission, or other context changes simply by receiving focus.
Wrapping Up
Focus is not an action; it is preparation.
WCAG 3.2.1 exists to protect user control.
When focus is safe and predictable, users can explore content confidently without fear of triggering unwanted changes. This benefits keyboard users, screen reader users, and mouse users alike, and prevents some of the most disruptive accessibility failures seen in real-world audits.
