3.2.2 On Input
- Level A
- Understandable
- Since WCAG 2.0
Summary
This criterion protects anyone who does not see the whole screen at once or who works through a form control by control: screen reader users hearing one field at a time, magnifier users viewing a small slice of the page, keyboard users arrowing through options, and people with cognitive disabilities who lose their place when the interface changes underneath them. If simply choosing a dropdown option, ticking a checkbox, or typing a character launches a new page, submits the form, or throws focus somewhere else, these users are disoriented before they have finished making their choice.
The auditor's mental model has two questions. First, did changing a setting (selecting an option, toggling a checkbox, entering text), as opposed to deliberately activating a button or link, cause a change of context: a new page or window, a form submission, a focus move, or a rearrangement of content significant enough to disorient? Second, if it did, was the user told beforehand, in text available before or alongside the component, that this would happen? A change of context on input is not automatically a failure; an unannounced one is.
Official wording
Changing the setting of any user interface component does not automatically cause a change of context unless the user has been advised of the behavior before using the component.
EN 301 549 mapping
- Web pages
- Clause 9.3.2.2
- Software and native apps
- Clause 11.3.2.2
Clauses 9.3.2.2 (web) and 11.3.2.2 (software) apply this criterion unchanged, so the same requirement binds web pages and native app user interfaces.
Clause references are to EN 301 549 V3.2.1 (2021-03), the harmonised European standard. Descriptions are our own summary, not the text of the standard.
In practice
Web
Operate every form control on the page, not just the ones that look suspicious. For each select, set of radio buttons, checkbox, and text input: change its value with the keyboard (arrow keys, space, typing) and with the pointer, then watch what happens. The failure signatures are a page navigation, a form submission, a new window or tab, or focus jumping to another element the moment the value changes. Keep the browser developer tools network panel open; an unexpected document request fired on change is the classic sign of a jump menu or auto-submitting filter form.
Country and language selectors deserve special attention. A select that reloads the page in a new locale the instant an option is chosen is the textbook failure, and it is worse with a keyboard: in some browsers, arrowing through the options fires a change event on every option, so the user is navigated away before ever reaching the country they wanted. The fix patterns you should see are an explicit Go or Apply button, or advisory text before the control stating that selection will reload the page.
Check where any advisement lives. To count, the warning must be available before the component is used: visible text preceding or labelling the control, or text programmatically associated with it (for example via its accessible description). A tooltip that only appears after the damage is done, or a note below a control that a screen reader user reaches after operating it, does not advise anyone in time.
Filters are the main source of false positives. A set of checkboxes that re-queries and updates a results list in place, lower on the same page, without moving focus or navigating, is usually a change of content, not a change of context: the user's viewport, focus, and page have not changed. Grade that as a pass here, and check separately whether the update is announced (see 4.1.3 below).
iOS
The European standard applies this criterion unchanged to native software, so grade iOS apps against the same rule as web pages: changing a setting must not trigger an unannounced context change.
Work through every screen's controls: segmented controls, switches, steppers, pickers, and text fields. The common failure spots are a segmented control or switch that immediately pushes a new screen or dismisses the current one when its value changes, and settings toggles that launch a confirmation flow or paywall on activation without any advance notice in the label or surrounding text. Selecting a value in a picker should set the value; it should not navigate. Run VoiceOver while testing: a context change that a sighted tester barely registers (a quiet screen swap) is a hard disorientation for a VoiceOver user whose focus is torn away mid-form.
One-time-code entry is the honest, difficult case. Many apps auto-advance focus between OTP boxes as each digit is typed, and submit automatically on the final digit. Both are changes of context triggered by input: focus moves, and the form submits, without the user pressing anything. Grade by advisement and predictability. If the screen says something like "enter the 6-digit code; it verifies automatically", or the interface is a single labelled code field whose stated behaviour makes auto-submission predictable before the user types, the user has been advised and it passes. Silent auto-submission on the last digit of six visually separate boxes, with no text setting the expectation, is a fail under this criterion, however common the pattern has become. Do not wave it through because "everyone does it"; report it, and note that adding one line of advisory text resolves it.
Android
The same rule applies unchanged to Android apps under the European standard.
Exercise every spinner (dropdown), switch, chip group, radio group, and text field, with touch and with a keyboard or switch device where the app supports one. Failure spots mirror iOS: a spinner selection that immediately starts a new activity or fragment navigation, a settings switch that launches a separate flow the instant it is toggled, and sort or filter spinners that reload the whole screen rather than updating the list in place. OTP screens built as six single-character fields with auto-advance and submit-on-last-digit are graded exactly as described for iOS: pass if the behaviour is stated or predictable from the on-screen instructions, fail if it is silent.
Test with TalkBack running. Listen for whether the advisement text (if any) is actually reachable before the control in reading order, and watch whether accessibility focus is yanked to a new screen when a value changes. Layout Inspector in Android Studio can help confirm whether a "new page" is genuinely a navigation or just an in-place content update, which decides whether a change of context occurred at all.
Pass and fail examples
Passes:
- A country select with a Go button next to it: nothing happens until the user explicitly activates the button, so no context change occurs on input at all.
- A language selector preceded by the visible text "choosing a language reloads this page": the page does reload on selection, but the user was advised before using the control.
- A set of filter checkboxes that updates the results list in place further down the same page, without moving focus or navigating: a content update, not a change of context.
- An OTP screen whose instruction reads "enter the 6-digit code, verification starts automatically": auto-submission on the final digit is announced before the user types.
- A radio group where choosing "business account" reveals two extra fields directly beneath it: revealing related fields in place does not disorient and is not a change of context.
Fails:
- A country dropdown that navigates to a regional site the moment an option is selected, with no warning text: keyboard users arrowing through the list may be redirected before reaching their country.
- A "subscribe to newsletter" checkbox that submits the entire form when ticked.
- A jump-menu select used as navigation, firing
window.locationon change with no adjacent button or advisory text. - A native app toggle labelled only "dark mode" that immediately dismisses the settings screen and returns the user to the home screen when switched.
- Six separate OTP digit boxes that silently submit the form on the last digit, with no instruction anywhere that entry triggers verification.
Not a fail under this criterion:
- A button or link that navigates when pressed: activating a control the user deliberately triggered is a requested action, not a change of setting, and is out of scope here.
- A control that fires a context change when it merely receives focus, before any value changes: that is graded under SC 3.2.1 On Focus.
- Filter results updating in place with no announcement to screen reader users: the silent update is a status message concern under SC 4.1.3 Status Messages, not an On Input failure.
- A form that asks for the same information twice within one process: file that under SC 3.3.7 Redundant Entry.
Commonly confused with
- On Focus, SC 3.2.1. The sibling criterion at the same level. 3.2.1 covers context changes triggered by a component simply receiving focus (tabbing onto it); 3.2.2 covers changes triggered by changing its value. Tab onto the select and nothing should happen (3.2.1); arrow to a different option and nothing unannounced should happen (3.2.2). File the finding by which event fired it.
- Status Messages, SC 4.1.3. When a filter or option updates results in place, 3.2.2 is usually satisfied because no context changed, but if screen reader users get no announcement that the results changed, that silence is a 4.1.3 finding. Auditors often misfile the silent update as a 3.2.2 fail; it is not.
- Change on Request, SC 3.2.5. The Level AAA criterion goes further: context changes happen only when the user requests them, with no "advised beforehand" escape hatch. An announced auto-reload passes 3.2.2 and can still fail 3.2.5. Do not apply the AAA bar in a Level A or AA audit.
- Redundant Entry, SC 3.3.7. Both live in the Understandable principle and both surface in forms, but 3.3.7 is about re-asking for information already provided, not about what happens when a value changes. A form can fail both for unrelated reasons.
- Activation versus setting. Pressing a button, link, or submit control is activation: the user asked for the action, so any resulting navigation is fine under this criterion. 3.2.2 only concerns components whose setting changes: selects, checkboxes, radios, toggles, text entry. Filing "clicking Save navigated away" under 3.2.2 is a misfile; nothing is wrong.
How AUDITSU tests this
AUDITSU's audit walkthrough covers On Input on every screen that contains form controls. The per-screen questions direct you to operate each select, checkbox, radio group, toggle, and text field, with the keyboard on web and with the screen reader running on mobile, and to record what happens when the value changes: nothing, an in-place update, or a change of context. Where a context change occurs, the walkthrough asks whether advisory text was available before the component, and you grade pass, fail, or not applicable per screen with the evidence (the control, the trigger, and the missing or present advisement) attached to the finding.
Because the European standard applies this criterion unchanged to both web content and native software, the same walkthrough questions and the same grading apply whether the audit target is a website or an iOS or Android app.
For the full guided workflow, see the audit platform.