WCAG 2.2 - Success Criterion
3.2.2 On Input
Description
Changing the setting of any user interface component must not automatically cause a change of context unless the user has been informed of the behavior beforehand. Examples of a change of context include: form submission, navigation to another page, a significant rearrangement of page content, a new window opening, focus moving to a different component, or any other major alteration that could confuse or disorient the user. This criterion places the responsibility on the page author to avoid unexpected context changes triggered solely by user input.
How To Test
- For all form inputs, select boxes, radio buttons, and other form controls, enter or change a value without submitting the form explicitly.
- Observe whether changing the value triggers a change of context - such as form submission, page navigation, or significant content reorganization.
- Pay special attention to autocomplete and autofill functionality - verify that these features do not overwrite user input unexpectedly.
- Check custom widgets that respond to input events (
onchange,oninput,onkeyup) for unexpected context changes. - Use a screen reader to confirm that input changes are announced correctly and do not cause unexpected navigation or page reorganization.
Testing Tools
- axe DevTools — Scan for missing link text, label associations, and heading structure issues.
- NVDA — Navigate links and form fields using Tab and arrow keys to verify purpose is announced clearly.
- VoiceOver (macOS) — Alternative screen reader to test link names, form labels, and heading hierarchy.
Demo 1: Sort order changes on select change
- Microphone — €65
- Keyboard Stand — €89
- Audio Interface — €149
- Monitor Speakers — €220
Change the sort order — the list reorders immediately without any confirmation.
- Microphone — €65
- Keyboard Stand — €89
- Audio Interface — €149
- Monitor Speakers — €220
Change the sort order — the list stays the same until you click Apply.
Code
<!-- ❌ onchange immediately reorders — user loses their place -->
<select
onchange="sortResults(this.value)"
>
<option>Price (low–high)</option>
<option>Price (high–low)</option>
</select>
<!-- No Apply button — selection change IS the action --><!-- ✓ Select stores the choice; Apply button triggers the sort -->
<select id="sort-select">
<option>Price (low–high)</option>
<option>Price (high–low)</option>
</select>
<button onclick="sortResults(select.value)">Apply</button>Code
Demo 2: OTP field auto-advancing focus
Enter verification code
Type a digit — focus jumps to the next box automatically, bypassing your control.
Single input — user types all 4 digits without focus being moved by the page.
Code
<!-- ❌ oninput moves focus to next field — context change on input -->
<input maxlength="1"
oninput="if (this.value) nextField.focus();"
>
<input maxlength="1"
oninput="if (this.value) nextField.focus();"
>
<!-- Repeated for each digit — user never controls focus --><!-- ✓ Single input — user types freely, no forced focus movement -->
<input type="text" inputmode="numeric"
maxlength="4" pattern="\d{4}">Code
Fail Explanation
A common failure occurs when changing a form input value automatically triggers a change of context without explicit user action. Examples include:
- A dropdown that submits a form immediately when the value changes, without a separate submit button
- A text field that auto-corrects, auto-formats, or overwrites the user's input while they are still typing
- A radio button group or checkbox that triggers form submission on selection change
- A date picker that navigates to a different page when a date is selected
These failures prevent users from correcting mistakes, changing their minds, or reviewing their selections before commit. They are particularly problematic for users with motor disabilities, cognitive disabilities, or those using screen readers who may not immediately notice that their input has been modified.
Pass Explanation
A page passes when user input is preserved exactly as entered, and any changes require explicit activation (clicking a button, pressing Enter). If the page offers helpful features like autocomplete or auto-formatting, these must not override the user's actual input - they should appear as suggestions in a separate area (dropdown, list, dialog) that the user can accept or dismiss. Users retain full control: they can review their input, correct mistakes, and choose when to commit their changes.
Notes
This criterion applies specifically to unintended changes of context. Some input changes that provide immediate visual feedback (like filtering a list as you type, or showing matching results in real-time) are not considered changes of context if the user remains focused on the same page and can continue interacting predictably. The distinction is whether the change is major and disorienting versus providing immediate, in-context feedback.
WCAG Techniques
- Failure: F36, F37
- Success Techniques: H32, SCR24
Techniques
WCAG techniques used in this demo: G80, H32, H84