User input is how people configure an interface before deciding to take action. Typing into a field, selecting an option, or checking a box should feel safe; users expect to explore and adjust settings without triggering irreversible changes.
Problems occur when changing the value of a control immediately causes a major change, such as navigation, submission, or content replacement, without warning. For many users, especially those using screen readers, keyboards, or touch input, these changes can be confusing, disorienting, or difficult to recover from.
WCAG addresses this by requiring that input-driven changes be predictable and clearly communicated in advance.
WCAG Success Criterion
3.2.2 On Input (Level A)
Changing the setting of any user interface component does not automatically change the context unless the user has been advised of the behaviour before using the component.
This is a Level A requirement and applies to all interactive content, including scripted and custom components.
A Simple Mental Model
WCAG separates choosing from confirming:
- Choosing a value should be safe
- Confirming an action may cause a change
Users should not lose context simply because they explored an option.
What WCAG Means by “Input” vs “Activation”
Input (changing a setting)
- Typing text into a field
- Selecting an option in a dropdown
- Checking or unchecking a checkbox
- Changing a radio button selection
Activation (confirming an action)
- Clicking a button or link
- Pressing Enter or Space on a control
For keyboard and assistive technology users, pressing Enter or Space is equivalent to clicking. This is intentional activation and may cause navigation or submission.
Changing a value alone is not.
What WCAG Means by “Change of Context”
A change of context is a significant shift that affects orientation or task flow, such as:
- Navigating to a new page or route
- Opening a new window or modal
- Automatically submitting a form
- Replacing content in a way that disrupts focus or continuity
- Moving focus to an unexpected location
These changes are allowed only if users are clearly warned before interacting with the control.
What This Criterion Requires
When users change the value of a control:
- Nothing major should happen unless they were told it would
- Users must not be surprised by navigation, submission, or loss of context
A change of context may occur on input only if the user has been advised beforehand, or if it happens after explicit activation.
Realistic Examples: Failure vs Success
✅ Success
Explicit Activation
The dropdown lets users select an option, then click a Go or Apply button.
Navigation happens only after activation.
Warned Behavior
Text before the control states:
“Changing this option will update the results below.”
The page updates without navigation or focus loss.
❌ Failure
Navigation on Dropdown Change
A dropdown automatically navigates to a new page as soon as an option is selected.
The user never confirmed the choice and was not warned.
Auto-Submitting Field
A form submits immediately when a user finishes typing in a field.
In screen readers, submission may occur before the user hears what changed.
How to Warn Users Correctly
Warnings must be available before interaction and must be reliable.
Acceptable approaches include:
- Visible text placed immediately before the control
- Persistent helper text associated with the control
- aria-describedby pointing to an explanation of what will happen
Not acceptable:
- Placeholder-only warnings
- Hover-only tooltips
- Messages that appear after the change occurs
Why This Fails in Real Projects
Most SC 3.2.2 failures are accidental and occur in scripted interfaces, such as:
- JavaScript change handlers triggering navigation
- Auto-submitting filters or search fields
- Single-page applications changing routes on selection
- Custom ARIA widgets that behave like links on input
- Mobile select menus that redirect immediately
These patterns prioritise speed over predictability.
Safe vs Unsafe Input Behaviour
Safe After Input
- Showing or hiding related fields
- Updating helper text or validation messages
- Preparing data for submission
- Filtering results with advance warning
Unsafe After Input
- Navigating to a new page
- Submitting a form
- Opening dialogs or new windows
- Replacing content in a way that breaks task flow
Unless users are warned, these behaviours fail the criterion.
Common Failure Patterns
- Dropdowns that redirect immediately
- Filters that reload the page without notice
- Forms that auto-submit on value change
- SPA route changes tied to input events
- Assuming “users expect this behaviour.”
Expectation must be explicit, not assumed.
Assistive Technology Perspective
Screen readers announce changes after they occur.
If navigation or submission happens on input, users may never hear:
- What they selected
- Why the page changed
- How to return
In NVDA or VoiceOver, a selection change may be announced only after the context has already shifted.
Relationship to Other Criteria
- 3.2.1 On Focus — prevents changes when focus moves
- 3.2.3 Consistent Navigation — ensures navigation patterns repeat
- 2.4.3 Focus Order — preserves logical movement
On Input governs what happens after a value changes, not when focus moves.
How to Test
- Use the page with keyboard only
- Change values in dropdowns, checkboxes, and fields
- Observe whether:
- Navigation occurs
- Forms submit automatically
- Content is replaced, or focus is lost
- Check whether users were warned before interacting
- Confirm that major changes require explicit activation
If input alone causes an unexpected context change, the criterion fails.
Rule Description
Changing the value of a user interface component must not automatically cause navigation, submission, or other disorienting context changes unless users are clearly advised beforehand.
Wrapping Up
Input is about configuration, not commitment. WCAG 3.2.2 protects users from being surprised by their own choices. Users must be free to explore options, correct mistakes, and adjust settings without triggering disruptive changes.
Together with On Focus (3.2.1), this criterion forms the foundation of predictable interaction and prevents some of the most common Level A failures found in accessibility audits.
