WCAG Principle: Understandable
Guideline 3.2: Input Predictable (Make Web pages appear and operate in predictable ways)
Conformance Level: A (Minimal Requirement)
What is Success Criterion 3.2.1?
When any user interface component receives focus, it does not initiate a change of context.
This guideline ensures that nothing unexpected happens when a user navigates to an element on a web page, whether by tabbing with a keyboard or clicking with a mouse.
In simpler terms, this rule prevents the webpage from changing context just because an element receives focus. For example:
- A form should not auto-submit when you tab to a field.
- A new window shouldn’t pop up just because you clicked into a dropdown menu.
- Focus shouldn’t jump somewhere else when you land on an element.
How does it make your website accessible?
This success criterion ensures predictable and consistent behavior when users navigate through interactive elements. Here’s how:
- Prevents confusion: Sudden changes in context—like forms submitting automatically or new windows opening—can disorient users, especially those with cognitive disabilities or visual impairments.
- Improves keyboard navigation: Many users rely on keyboards to navigate. A predictable focus order ensures they can move through the content without interruptions or surprises.
- Supports assistive technologies: Screen readers and other tools depend on logical, steady navigation. Unexpected changes can break their flow, making it harder for users to understand or control the interface.
- Reduces errors: Users with motor impairments may accidentally trigger changes if focus behavior isn’t carefully controlled. Preventing unintended actions improves their experience and reduces frustration.
Who benefits?
- Keyboard-only users
- Screen reader users
- People with cognitive disabilities
- People with motor impairments
- All users
How to Meet Success Criterion 3.2.1
Common mistakes on websites
- Triggering automatic actions, like submitting forms or opening new windows, when an element receives focus.
- Moving focus to another element without user input, often due to scripts tied to “onfocus.”
- Using focus alone to trigger navigation or page changes, instead of requiring activation (e.g., a click or key press).
- Interrupting keyboard navigation by trapping focus within an element or breaking the focus flow.
- Creating inconsistent behavior where some elements trigger actions on focus while others do not.
How to fix mistakes
- Replace focus-based event triggers like ‘onfocus’ with user-activated events such as ‘onclick’, ‘onkeypress’, or ‘onkeydown’. This ensures changes happen only when users explicitly interact with elements.
- Use ARIA roles and attributes carefully to avoid causing unexpected behavior when elements receive focus. For instance, improper use of ‘aria-activedescendant’ or role changes can unintentionally shift focus.
- Validate focus management. For instance, if JavaScript modifies focus (e.g., element.focus()), ensure it aligns with user expectations and logical navigation. Also, avoid automatic focus shifts unless explicitly needed (e.g., after form submission).
- Verify that all interactive elements follow a logical and predictable tab order. Use the ‘tabindex’ attribute sparingly and avoid values greater than 0, as they disrupt the natural navigation flow.
- Use automated tools like WAVE or ARIA (our free accessibility compliance scanner) to catch focus-related issues. Then manually test with the ‘Tab’ key, keyboard shortcuts, and screen readers.
Helpful tips for developers
- Not providing a “skip to main content” link at the beginning of pages.
- Broken skip links or links that redirect to the wrong section/content.
- Placing repetitive content at the start of each page without a bypass option.
- Using only visual cues, like color changes, to indicate skip options, which screen readers and keyboards can’t detect.
How to test if your site meets conformance
- Identify the buttons, links, form fields, dropdowns, modals, or any other web elements that receive focus.
- Use the Tab key to move through each interactive element. Confirm that no unexpected actions, like opening a new window, submitting a form, or shifting focus, occur when focus lands on an element.
- Open Developer Tools in your browser, select an interactive element and run element.focus() in the Console. Verify that no changes in context occur when focus is applied.
- Use a screen reader like NVDA (for Windows devices) or VoiceOver (for iOS devices) to navigate through the page using the Tab key, and listen for unexpected changes.
- Interact with dropdowns, accordions, modals, and forms. Confirm that changes, like opening a menu or submitting data, only happen when triggered by a click or key press.
- Verify focus behavior on desktops, tablets, and mobile devices. Ensure interactions remain consistent and predictable across all platforms.
If steps 2, 3, 4, 5, and 6 are true, your website meets this success criterion.
Bad and Good Examples of On Focus (Code Snippets)
Code example that fails success criterion 3.2.1
In this example, the form submits automatically when the input field receives focus.
<form action="/submit" method="post">
<label for="name">Name:</label>
<input id="name" type="text" onfocus="this.form.submit()">
</form> This code snippet fails to meet success criterion 3.2.1 because the form auto-submits when the user tabs to the input field. This unexpected behavior disrupts navigation and creates a poor experience for keyboard and screen reader users.
Code example that meets success criterion 3.2.1
<form action="/submit" method="post">
<label for="name">Name:</label>
<input id="name" type="text">
<button type="submit">Submit</button>
</form> Here, the form only submits when the user explicitly activates the button. This is good accessibility practice because the form submission requires the user to press the “Submit” button.
Frequently Asked Questions
What is the primary goal of Success Criterion 3.2.1?
The primary goal of SC 3.2.1 is to ensure that user interface components do not automatically initiate a change of context when they receives focus. This means that simply focusing on an element should not cause unexpected actions like navigating to a new page or opening a new window.
Why is preventing context changes on focus important for accessibility?
Unexpected changes can disorient users, especially those with visual impairments, cognitive limitations, or those relying on keyboard navigation. Ensuring that focus does not trigger unexpected actions helps maintain a predictable and user-friendly experience for all users.
Can I use 'onfocus' events in my code without violating this criterion?
Yes. You can use ‘onfocus’ events, but they should not trigger changes of context. Instead, it’s better to use activation events, such as ‘onclick’ or ‘onkeypress’, to initiate changes. This ensures that users have control over when actions occur.
