On Input
Changing a setting must not change the context on its own, unless you told the user it would before they touched the control. Changing a setting means changing something that sticks after you stop interacting with it. Ticking a checkbox. Typing in a field. Picking a different option in a list. Following a link is activation rather than a setting change, and so is a button that submits a form or moves focus into a panel it just opened. A button that toggles its own state is a setting change, though, so the line runs through buttons rather than around them. The escape is real and the timing is what matters in it. The user has to be told before they use the control, and W3C's own example puts that description at the start of the form rather than beside the field.
Why it matters
Every user works a form on the same assumption, which is that they fill it in and then they submit it. A control that submits or navigates by itself breaks that assumption mid-thought. Screen reader users get the worst of it, because they find out after the fact. And there is a quieter harm that lands on everybody. Once a control has taken you somewhere you did not ask to go, the back button stops doing what you expect. A user who could not see the change has no way to work out where they now are.
Who this rule protects
Screen reader users learn about a context change only once it has happened, because nothing warned them. People with low vision may not see a new window appear at all. People with reading or intellectual disabilities, and anyone who finds visual cues hard to read, need the change said in words rather than shown. Users with cognitive disabilities lose their thread when the page acts without being asked.
How to check it yourself
- Change every select, radio and checkbox on your key forms and watch what happens with no button press. A page load, a submission and a new window all count.
- Watch for focus moving too. Focus is a context change in its own right, so a field that jumps you forward on the last keystroke is in scope even though nothing was submitted.
- Arrow through native selects with the keyboard rather than clicking them. In most browsers each arrow press changes the value, so a change handler runs on every one of them.
- Where a control genuinely has to act on its own, check the reader meets the warning before they reach the control. At the top of the form counts, and so does next to the field. A note in the confirmation email does not, because it arrives after the thing it was meant to prevent.
- Leave alone what the rule leaves alone. Links, submit buttons, and fields that appear or vanish when a select changes are not setting changes, and filtering a list in place is not a context change either. A button that toggles on and off is a setting change, so check that one like any other control.
Failures we see most often
- A country selector reloads into a different storefront the moment its value changes, with no warning and no Apply button.
- A form submits itself when the last field is filled, so a user who moves focus away to reread the instructions sends it half finished.
- A sort dropdown reloads the page while a keyboard user is still arrowing through it, because each arrow press changes the value and the change handler runs every time.
- A quiz advances to the next question the instant a radio is picked, leaving no way back to change an answer.
- A phone-number field jumps focus to the next box automatically and nothing on the form says it will. The same behavior passes when the form says so up front, which is the whole difference this rule turns on.
Who this one is for
Read from this rule's own note above, so the grouping and the note cannot disagree.
- Blind and screen reader userspeople who cannot see the screen
- Low visionpeople who can see the screen but not easily
- Cognitive and learningpeople for whom the difficulty is understanding, remembering, or staying with it
How to fix it
- Give any selector that changes something significant its own Apply or Continue button, so the change happens when the user says so.
- Keep the handler and drop the context change where you can. Filtering the list below a dropdown in place is fine. Reloading the page is what fails.
- Where the behavior has to be automatic, describe it at the top of the form and again beside the control, in the words the user needs before they act.
- Preserve whatever the user already typed when the change does happen. Losing it is a redundant-entry problem rather than this rule's, and it is the part users actually complain about.
Step-by-step fix guides (8)
Passes vs. fails
Passes
Choosing Canada changes nothing until the buyer presses Update, and when the prices change the cart is still sitting there.
Fails
Choosing Canada from the country dropdown reloads the storefront and empties the cart before the buyer has finished reading the other options.
In audits and lawsuits
Country and currency selectors that reload the storefront are the classic finding here, and in e-commerce they usually take the cart with them. The first question on any finding is whether the rule applies at all, because teams file activation as a setting change all the time. A button that opens a panel and moves focus into it is activation, and it is not a failure of this rule. A button that toggles its own pressed state is the one to watch, because that state persists after the press and the rule counts it like any other setting. A select that reloads the page on change is a setting change, and it is. Fields appearing and disappearing when a select changes are neither, since the structure holds and the context does not move. No automated rule exists for this criterion, so every finding here is one a person sat down and tried.