What it asks for, in plain English
Choosing an option in a dropdown, ticking a box or typing in a field must not automatically do something big, such as submitting the form, opening a new window or jumping to a different page, unless the person has been told that is what will happen before they do it.
It is fine for a field to reveal more fields, filter a list in place or update a total. Those keep the person where they are. What is not fine is a country dropdown that reloads the whole page on every change, or a radio button that submits the form.
If you really want the automatic behaviour, say so in text next to the control ("Choosing a region reloads the page"), or add a button so the person triggers it themselves.
This is an independent explanation. The binding wording is the W3C Recommendation, and the W3C's own Understanding 3.2.2 page has the full intent, techniques and definitions.
Who it affects
A screen reader user choosing from a dropdown with the arrow keys passes through each option on the way to the one they want; if every change submits the form, they never get past the first option.
Someone with a cognitive disability or anxiety finds the page replaced underneath them with no idea what they did, and loses what they had typed.
A person using screen magnification sees only part of the screen and does not notice the whole page changed because they picked a sort order.
Example
<form action="/results">
<label for="sort">Sort by</label>
<!-- JavaScript submits the form the moment the value changes -->
<select id="sort" name="sort">
<option>Newest</option>
<option>Cheapest</option>
<option>Top rated</option>
</select>
</form>
Arrowing from Newest to Top rated with a keyboard submits the form twice on the way. There is no warning and no button.
<form action="/results">
<label for="sort">Sort by</label>
<select id="sort" name="sort">
<option>Newest</option>
<option>Cheapest</option>
<option>Top rated</option>
</select>
<button type="submit">Apply</button>
</form>
The page changes when the person presses Apply, and not before.
How to check it
- Find every dropdown, radio group and checkbox that controls something: sort order, country, language, view.
- Change each one with the keyboard only, using the arrow keys. The page should not reload, submit or navigate until you press a button or Enter.
- Type in each text field. Nothing should submit or navigate while you are still typing.
- Where a change does cause something big, check there is a plain warning next to the control before you use it.
What Websight checks for 3.2.2
Websight has no automated check for this criterion. It lists it in the manual checklist that comes with every report, so it is not forgotten.
Only a person can check this. A scanner cannot tell what a change handler does. Websight lists it in its manual checklist.
Practical tips
- Add an Apply or Go button to any select that submits a form; it is one line and removes the problem.
- Live filtering is fine if focus stays put and the results update in place; announce the new count (see 4.1.3).
- Put any warning before the control, not after it, so a screen reader hears it first.
Other criteria in guideline 3.2, Predictable
- 3.2.1 On Focus (level A)
- 3.2.3 Consistent Navigation (level AA)
- 3.2.4 Consistent Identification (level AA)
- 3.2.6 Consistent Help (level A)