WCAG 3.2.2, called On Input and set at Level A, means that choosing an option, ticking a box or typing in a field must not by itself trigger a big change, like loading a new page, opening a window or throwing focus somewhere else, unless the person was told beforehand. Users decide when things happen, usually by pressing a clearly labelled button.
The classic failure is a language or country dropdown that reloads the page the moment its value changes. For a mouse user that feels fine. For someone moving through the options with arrow keys, the page reloads on the first press and they never reach the option they wanted.
Quick facts
Level
AAdded in
WCAG 2.0Principle
Understandable, guideline 3.2 PredictableTrigger
Changing the value or state of a control, not just focusing itAllowed
Big changes the user was warned about in advance, or that wait for a submit buttonFast test
Change every select, checkbox, radio and field with the keyboard and watch what moves
A quick example of the problem
Picture a shop page with a "Sort by" menu. A keyboard user tabs to it and presses the down arrow to hear the choices. In many browsers that single press changes the value, a script fires, and the page reloads sorted by price. Focus is now back at the top. They try again, the same thing happens, and they give up.
Nothing was broken from the developer's point of view. The control simply acted on input instead of waiting for the user to confirm. That is what this criterion forbids.
What WCAG 3.2.2 means by a change of context
The rule only cares about a change of context, a term WCAG uses for major changes that can disorient someone who cannot see the whole screen at once. These count:
- a new page loads, or a new window or tab opens
- keyboard focus moves to a different component
- the page content changes so much that its meaning is different, like swapping a whole form for another one
Small updates in place are a change of content, not of context, and they are allowed. Ticking "Ship to a different address" and seeing three new fields appear below the box is fine. So is a price total updating when the quantity changes.
Also note what does not trigger the rule: only changing a setting counts. Simply moving focus onto a control is covered by the neighbouring rule, 3.2.1, which deals with focus alone. The W3C Understanding document for On Input has more cases.
Failures you will meet, with fixes
| Pattern | What the user experiences | Repair |
|---|---|---|
| Language or region select that navigates on change | The page reloads on the first arrow key press | Add a "Go" or "Apply" button next to the select |
| Form submits itself when the last field is filled | New content appears before the user has checked their entries | Wait for a submit button |
| Radio button that opens a new window | A window appears with no warning and focus is lost | Use a link, or say "opens in a new window" in the label |
| Phone or card number split into boxes that jump focus | Focus leaps to the next box after a set number of digits, surprising users who correct a typo | Use one field, or explain the auto advance beside the fields |
| Filter checkbox that reloads the results page | Focus resets to the top on every tick | Update results in place, keep focus on the checkbox and announce the new count |
Telling people in advance is allowed, but a warning that sits far from the control or appears only after the change does not help. Put it right before the control in the reading order.
Testing on input step by step
- Make a list of every control that holds a value: selects, checkboxes, radios, toggles, sliders and text inputs.
- Reach each one with Tab and change it using the keyboard only. For a select, use the arrow keys while it is closed, since that is where most failures show.
- After each change, ask: did a new page load, did a window open, did focus move, did the meaning of the page change?
- If yes, look before the control for text that announced the behaviour. No warning means a failure.
- Repeat with a screen reader on one or two key forms, because you will hear whether focus jumped or the page reloaded.
Code: a select that waits for the user
The failing pattern is a select whose change event runs a script that sends the browser to a new address. The fix is plain HTML: a form with a real submit button, so nothing happens until the user asks.
Passes: the choice is applied only when the button is pressed.
<form action="/set-language" method="get">
<label for="lang">Language</label>
<select id="lang" name="lang">
<option value="en">English</option>
<option value="hi">Hindi</option>
</select>
<button type="submit">Change language</button>
</form>If a design really needs instant action, the label itself must say so, for example "Language (page reloads when you choose)". Instant updates that stay on the same page and keep focus where it is, such as filtering a list in place, do not need a warning.
Who this rule protects
Screen reader users only perceive one part of the page at a time. When a page reloads or focus jumps, they lose their place and must work out where they landed. People with low vision using magnification face the same issue, since the change may happen outside the zoomed area.
Keyboard users are affected because arrow keys change selects and radios one step at a time. People with cognitive disabilities benefit too: predictable controls that act only when asked are easier to learn and trust.
How 3.2.2 connects to other criteria
- 3.2.1 (Level A): merely landing on a control must not change context, while 3.2.2 deals with changing its value.
- 3.2.5 (Level AAA): a stricter cousin in which every context change waits for a user request.
- Rule 3.3.2 on labels: where you place the advance warning when a control does act on input.
- Logical focus sequence, 2.4.3: if focus moves after a change, it must still land somewhere logical.
- Announcing updates, 4.1.3: when filters update results in place, announce the new count without moving focus.
Custom selects built from div elements add their own risks; see the rule on names, roles and values, and track everything in the WCAG checklist.
Questions people ask
What is on input in WCAG?
The on input wcag rule, numbered 3.2.2, covers what happens when a user changes a control's value. That change must not cause a new page, a new window, a focus jump or a change in the page's meaning unless the user was warned first.
What level is 3.2.2 WCAG?
Level A, the base tier. WCAG 2.0 introduced it, so any AA target, in any version, includes it.
Is showing extra fields after a checkbox a failure?
No. Revealing related fields next to the control is a change of content, not of context. Focus stays put and the meaning of the page is the same, so it passes.
Does auto advancing focus between code boxes fail 3.2.2?
Moving focus is a change of context, so doing it automatically as someone types fails unless they were told beforehand. A single input field avoids the problem, and is also easier for pasting codes.
Is opening a new tab from a link covered by on input?
No. Activating a link is a request by the user, not a change of a setting, so 3.2.2 does not apply. It is still kind to say in the link text that it opens a new tab.