WCAG 2.2 success criterion, Level A

WCAG 3.2.2 On Input

Changing a setting, such as picking an option from a list or ticking a box, must not submit a form, load a new page or move the person somewhere else, unless they were told that would happen before they used the control.

Number: 3.2.2
Level: A
Added in: WCAG 2.2
Guideline: 3.2 Predictable
Principle: Understandable

What it asks

Many people change a control to see what it does. They pick a country from a list, tick a box, or type a character, expecting to look at the result and change their mind. This rule says that changing a control’s setting must not, by itself, cause a change of context: a new page, a new window, focus moved to another control, or content rearranged so much that the person loses their place. Submitting a form counts, because it loads a new page.

There is one way through. The site may cause a change of context on input if it tells the person beforehand, in a place they will meet before using the control. A line above a country select saying "Choosing a country takes you to that country’s site" is enough. A warning that appears after the fact is not.

The classic failure is the select that submits the moment an option is chosen, which a sighted mouse user never notices and a keyboard user cannot get past, because pressing the arrow key to see the options changes the selection and fires the submit. Others are a radio button that navigates when chosen and a form that moves to the next step on the last keystroke of a code. It is Level A.

Its official name is success criterion 3.2.2 On Input, at Level A. It was added in WCAG 2.2, under guideline 3.2 Predictable and the principle Understandable. The W3C’s normative text says, in part:

“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.”

From WCAG 2.2, W3C. Full explanation: Understanding 3.2.2 On Input.

Who it helps

Keyboard users, who change a select’s value with the arrow keys as they move through the options. If each change submits, they cannot reach the option they wanted. Screen reader users, who hear the options one by one in the same way.

People with cognitive disabilities and anyone who is easily disoriented, who need the page to stay put until they ask it to move. And people with motor disabilities, for whom a slip of the hand that fires a page load is costly to undo.

What passes and what fails

These pass

A country select with a "Go" button beside it, so nothing happens until the button is pressed.
A filter checkbox that updates the list of results below it without moving focus or loading a page.
A language select with a sentence above it saying that choosing a language reloads the page in that language.
A set of radio buttons that shows or hides a related field when chosen, keeping focus where it was.

These fail

A country select that reloads the page as soon as an option is selected, with no warning and no button.
A radio button that navigates to a new page the moment it is chosen.
A sort-order select at the top of a listing that submits the form on change.
A six-box verification code that moves to the next step automatically on the last digit, with no notice.

How to test it by hand

List every control whose setting can be changed: selects, checkboxes, radio buttons, text fields, sliders and switches.
Using the keyboard only, change each one. For a select, use the arrow keys with the list closed, which is how many keyboard users change it.
Note any new page, new window, submitted form, moved focus or large change to the content that happens on the change alone, before any button is pressed.
For each one, look for an advance notice: text before the control, in its label or in the instructions, that says what will happen.
A control that changes the context with no advance notice fails.

What automated testing can decide

What a machine can decide

As with 3.2.1, this can be observed. Automated testing can change a control’s setting the way a keyboard user would and note whether the page moved, a form was submitted, a window opened, focus jumped or the content changed in a large way. Each of those is a fact about the control rather than an opinion.

What it cannot

Whether the person was "advised beforehand" is a judgement about words and where they sit. A tool can find text near the control, but deciding whether it is a clear enough warning, and whether it comes before the control in the order someone will meet it, takes a person. A control whose setting cannot be changed safely during testing is left undecided rather than counted as a pass.

How Dreven handles it

Dreven finds the controls on your pages that caused a change of context when their setting was changed and shows you what happened, with a picture of the page before and after and any nearby text that might count as a warning.

A reviewer decides each result, and the report says which controls were covered, so a pass is never read as wider than what was tested.

No automated check makes a site conform. In Dreven, a person reviews the results and signs the report.

3.2.1 On Focus (Level A). The same rule for reaching a control, where no warning can excuse it.
2.1.1 Keyboard (Level A). Everything must be usable from a keyboard, and an auto-submitting select is not.
3.3.4 Error Prevention (Legal, Financial, Data) (Level AA). A form that submits by itself is also a form nobody got to check.
4.1.3 Status Messages (Level AA). Content that updates in place in response to a change should be announced as a status message.

Questions people ask

Can a select submit a form when an option is chosen?

Only if the person is told beforehand, in text they will meet before using the select. Without that, it fails. The simplest fix is a button next to the select that submits the form, so the choice and the action are separate.

Does filtering a list on change fail 3.2.2?

Not usually. Updating results below the control, while the person stays where they are, is not a change of context. Loading a new page, moving focus elsewhere or rearranging the whole page is.

Where should the warning go?

Before the control, in the order a person will meet it: in the label, in instructions above the form, or in a sentence just before the control. A message that appears after the change has already happened does not count.

Do auto-advancing code boxes fail 3.2.2?

A field that moves focus to the next box as you type is a change of context on input. It fails unless the person is told beforehand that it will happen. Letting people paste the whole code into one field avoids the problem and helps with 3.3.8 as well.

All WCAG 2.2 criteria, in plain words