Never change context when a select changes
SCR19 is a sufficient technique, and it is unusual in describing what a handler may do rather than what it must not. An onchange handler on a select is allowed to update other parts of the page, repopulating a second dropdown or filtering a list. It is not allowed to navigate, submit, or otherwise move the user somewhere they did not ask to go. Choosing an option sets a value. It does not press Go. There is a placement rule inside this technique that almost nobody carries, and it decides whether an implementation works. The element your handler updates has to sit after the trigger in reading order, so assistive technology reaches the new content on the way past instead of leaving it stranded above. W3C also scopes the technique to data already present in the page, with no server round trip, so a select that fetches is doing something SCR19 does not describe.
How we find it in an audit
Reviewers work every select from the keyboard alone, arrowing down the list rather than clicking it open. That single change of method exposes the defect immediately. Browsing with arrow keys fires onchange on each press, so a select wired to navigate jumps away on the first option rather than the chosen one. A scanner can flag the suspicious handler. It stops there. Whether the page actually moves is something a person has to watch happen. Then we check the placement, comparing where the updated element sits in the DOM against where the trigger sits.
How affected users experience it
A keyboard user opens a dropdown and presses the down arrow to hear what the options are. The first press changes the value. The handler fires, and the site loads a page nobody chose. For a screen reader user the page they were reading is now gone, replaced by one they have to orient themselves in from scratch. Getting back means finding the select again and taking the same risk a second time. Browsing the list, which is how a keyboard is meant to work, has become the thing that breaks it.
Passes vs. fails
Passes
<select id="region" onchange="filterProducts(this.value)"></select>
<div id="results"></div>
<button onclick="go()">Show region page</button>
<!-- #results sits after the trigger, so a screen reader meets the update on the way past. -->Fails
<select onchange="location.href = this.value">
<!-- The first arrow key press navigates, before the user has seen the other options. -->How this gets tested
The W3C publishes test rules that define what a checker looks for here.
- Meta element has no refresh delayA tool can check this
- Meta element has no refresh delay (no exception)A tool can check this
Other ways to satisfy this rule
8 guides on this site are filed under 3.2.2 On Input. W3C lists this one as sufficient for that rule on its own. Implement it correctly, in a way your readers' software actually supports, and the rule is met.
- G13sufficientSay what a control will do before it does it
- G80sufficientUse a submit button, not automatic submission
- H32sufficientGive every form a real submit button
- H84sufficientPair select menus with a real action button
- PDF15sufficientGive PDF forms an explicit submit button
- F36failureDo not auto-submit when the last field changes
This guide is our interpretation of W3C technique SCR19: Using an onchange event on a select element without causing a change of context. W3C publishes its techniques as guidance rather than as the standard, and says so on every one of them. The success criterion is what conformance is measured against, and a technique is one documented way to meet it.