WCAG (Level A) SC 3.2.1 On Focus (w3.org)
Issue description
WCAG 3.2.1, “On Focus” aims to prevent unexpected changes of context when users navigate a web page using a keyboard. This is important because sudden, unexpected changes can be disorienting and disruptive, especially for people with cognitive disabilities or those who rely on assistive technologies.
Read our other documentation regarding focus: WCAG (Level A) SC 2.4.3 Focus Order, WCAG 2.2 (AA) SC 2.4.11 Focus Not Obscured (Minimum), and WCAG (Level AA) SC 2.4.7 Focus Visible.
Many websites have elements that, when they receive keyboard focus, trigger changes that can be unexpected and confusing for users. This can include:
- Navigation changes: Focusing on a link or button automatically navigates the user to a different page or section, without them explicitly activating the link.
- Content updates: Focusing on an element causes content to be loaded, updated, or replaced, potentially disorienting the user.
- Pop-up windows: Focusing on an element triggers a pop-up window to appear, interrupting the user’s flow.
- Form submission: Focusing on a form field automatically submits the form, potentially leading to unintended consequences.
Why on focus matters
- Predictability: Users should be able to anticipate what will happen when they navigate with a keyboard. Unexpected changes can be jarring and make it difficult to understand the functionality of the page.
- Control: Users should have control over when actions are performed or when navigation occurs. Automatic changes on focus can take away that control.
- Accessibility: Unexpected changes can be particularly disruptive for users of assistive technologies, as it can interfere with their ability to navigate and understand the content.
WCAG requirements
This guideline requires that when any user interface component receives focus, it does not initiate a change of context. This means that focusing on an element should not:
- Navigate to a new page or section.
- Update or replace content.
- Open a pop-up window.
- Submit a form.
Exceptions
- User expectations: Changes of context are allowed if they are expected by the user based on the component’s purpose (e.g., focusing on a link in a menu is expected to open a new page).
- User control: Changes are allowed if the user has been advised of the behavior and has a mechanism to turn it off.
Essentially, this guideline ensures that keyboard focus does not trigger unexpected actions or changes, providing a more predictable and user-friendly experience for everyone.
Related requirements
The following WCAG source criteria are often related to this as well. They can provide additional insights into specific challenges you may be encountering.
- WCAG (Level A) SC 2.4.3 Focus Order
- WCAG (Level AA) SC 2.4.7 Focus Visible
- WCAG 2.2 (AA) SC 2.4.11 Focus Not Obscured (Minimum)
- WCAG 2.2 (AAA) SC 2.4.12 Focus Not Obscured (Enhanced)
- WCAG 2.2 (AAA) SC 2.4.13 Focus Appearance
Who this issue impacts
Follow the links for additional information on user impairments:
Suggestions for remediation
Remediating WCAG 3.2.1, “On Focus” involves ensuring that interactive elements don’t trigger unexpected changes of context when they receive keyboard focus. Here’s how:
Prevent automatic actions on focus
- Navigation: Links and buttons should not automatically navigate to a new page or section when they receive focus. Navigation should only occur when the user explicitly activates the link (e.g., by clicking it or pressing Enter).
- Content updates: Avoid automatically loading, updating, or replacing content when an element receives focus. Content changes should be triggered by user actions.
- Pop-up windows: Prevent pop-up windows from appearing when an element receives focus. Pop-ups should only be triggered by explicit user actions (e.g., clicking a button).
- Form submission: Ensure that forms are not automatically submitted when a form field receives focus. Submission should only occur when the user explicitly clicks a submit button or presses Enter in a designated submit field.
Use user activation as the trigger
- Explicit actions: Trigger changes of context only when the user performs an explicit action, such as clicking a mouse, pressing Enter, or tapping a touchscreen.
- Avoid focus-based triggers: Avoid using JavaScript event handlers like
onfocusto trigger actions that change the context. Instead, use event handlers likeonclickoronkeydownthat respond to user actions.
Provide user control
- Inform users: If a component has a behavior that might cause a change of context on focus, inform the user about this behavior.
- Offer a way to disable: Provide a mechanism for users to disable this behavior if they prefer. This could be a setting in the user preferences or a control within the interface.
Testing
- Keyboard-only testing: Test the website using only the keyboard to ensure that no unexpected changes occur when navigating between interactive elements.
- Assistive technology testing: Test with screen readers to verify that focus does not trigger unexpected actions or changes in context.
Examples
- Dropdown menu: Ensure that navigating through a dropdown menu with the arrow keys doesn’t automatically navigate to the linked page. The link should only be followed when the user presses Enter or clicks on it.
- Form submission: Prevent a form from being submitted when the user tabs to the submit button. The form should only be submitted when the user explicitly presses Enter while the button has focus.
- Content update: If focusing on an image loads a larger version of the image, provide a separate button or link to trigger this action instead of doing it automatically on focus.
By implementing WCAG (Level A) SC 3.2.1 On Focus, you can ensure that keyboard focus doesn’t trigger unexpected changes, providing a more predictable and accessible experience for all users.
