Level A

Changing the setting of a UI component -- filling a field, ticking a checkbox, picking from a dropdown -- must not automatically change context unless the user was warned before the control

3.2.2 On Input

In Plain Language

3.2.2 On Input (Level A) is a one-sentence rule: changing the setting of a user-interface component must not automatically cause a change of context, unless the user was advised of the behavior before using the component[1]. "Changing the setting" means filling in a text field, ticking a checkbox or radio, picking an <option> in a <select>, or moving a slider. "Change of context" means navigating to a new URL, opening a new window, shifting focus to another component, or significantly re-rendering the page so that the user's orientation is lost.

The fix is structural: trigger the context change from an explicit activation (a Submit button, an Apply link), or place a persistent warning in the DOM before the control explaining what will happen. In-page updates -- filtering a list, sorting a table, toggling a view -- are not changes of context and are allowed.

Distinct from 3.2.1 On Focus: 3.2.1 covers the passive act of receiving focus (tabbing onto a control), while 3.2.2 covers the active act of changing the control's value. A <select> that navigates on Tab fails 3.2.1; a <select> that navigates on arrow-key selection fails 3.2.2.

Why It Matters

  • Keyboard users navigate a native <select> with arrow keys, which fires a change event on each option as focus moves through the list. An onchange handler that calls window.location or form.submit() navigates away before the user reaches the option they wanted -- the control is unusable without a mouse. This is WCAG Failure F37 verbatim[1].
  • Screen-reader users get no visual cue that the page changed. An auto-submit on checkbox toggle reloads the DOM, the virtual buffer resets, and focus lands wherever the new page decides -- often the document root. The user has to re-orient from scratch.
  • Users with cognitive and learning disabilities rely on predictable form behavior. A control that commits on change violates the basic read-before-act pattern: the user cannot review their choices because selecting one sends the form.
  • Users making accidental inputs -- switch users, tremor, voice control that mis-recognises -- need a separable confirmation step. Auto-submit collapses input and confirmation into a single event, so a mis-tap is an irreversible commit.

Examples

Do: Require a submit button after selection

✔ Changing the select does not reload the page -- the user must click Apply

<label for="sort-select">Sort by:</label>
<select id="sort-select">
  <option>Date (newest)</option>
  <option>Date (oldest)</option>
  <option>Name A-Z</option>
</select>
<button type="submit">Apply</button>
<!-- No context change until the user clicks Apply -->
Don't: Auto-navigate on select change

<select onchange='location=this.value'>

✘ Changing the dropdown immediately navigates to a new page

✘ Keyboard users scrolling with arrow keys trigger navigation on every option

<!-- FAILS: navigates on every change -->
<label for="nav-select">Go to section:</label>
<select id="nav-select"
  onchange="window.location = this.value">
  <option value="/about">About</option>
  <option value="/contact">Contact</option>
</select>
<!-- Arrow keys in the select trigger immediate navigation -->
Do: Warn the user before a context change

Changing the language below will reload the page in your selected language.

✔ The user is warned before the control that changing it will reload the page

<p class="notice">
  Changing the language below will reload the page
  in your selected language.
</p>
<label for="lang-select">Language:</label>
<select id="lang-select"
  onchange="switchLang(this.value)">
  <option>English</option>
  <option>Espanol</option>
</select>
<!-- Context change is acceptable -- user was warned -->
Don't: Auto-submit a form when a checkbox changes

<input type='checkbox' onchange='this.form.submit()'>

✘ Checking the box immediately submits the form and reloads the page

✘ No warning was given that this would happen

<!-- FAILS: form submits on checkbox change -->
<form action="/update-prefs">
  <label>
    <input type="checkbox"
      onchange="this.form.submit()">
    Enable notifications
  </label>
</form>
<!-- Page reloads without warning when box is checked -->

How to Fix It

  1. Move the context change to an explicit activation. Replace auto-commit with a <button type="submit"> labelled Apply, Go, Filter, or Update. The setting changes are buffered in the form state; nothing navigates until the user clicks the button or presses Enter in a text field. This is the W3C sufficient technique for 3.2.2 and is the default fix[1].
  2. Delete onchange handlers that navigate, submit, or open windows. Grep for onchange="window.location, onchange="this.form.submit()", onchange="window.open", and addEventListener('change', ...) listeners whose handler body calls any of those. These map directly to Failures F36 (auto-submit) and F37 (new window on setting change) in the Understanding document.
  3. If the design genuinely requires commit-on-change, advise the user first. Place a persistent text warning in the DOM before the control -- not a tooltip, not an aria-describedby hint revealed on focus, but visible text that precedes the control in both visual and DOM order. A language switcher on a public site is the canonical case: "Selecting a language reloads the page in that language." The warning must be readable before the user interacts, not after.
  4. Prefer in-page updates over navigation. Filtering a product list, sorting a table, or toggling a dark-mode switch can update the DOM in place without a full reload or route change. An in-place update is not a change of context under WCAG and does not require a warning or submit button. Reserve navigation for operations that genuinely need a new URL.
  5. Test each <select> with arrow keys. Focus the control, then press the Down arrow repeatedly. If any arrow press reloads the page, navigates, opens a window, or submits a form, the control fails 3.2.2 for keyboard users. The same test catches radio groups that commit on arrow navigation.
  6. Do not confuse this with 3.2.1 On Focus. If the failure fires on Tab (no value changed), it is 3.2.1. If it fires on changing the value, it is 3.2.2. Both are Level A and both require the same structural fix -- drive context changes from explicit activation -- but the finding should name the right criterion.

References

  1. [1] W3C (2023). Understanding Success Criterion 3.2.2: On Input. W3C, Accessed 2026-04-07. https://www.w3.org/WAI/WCAG22/Understanding/on-input.html ↩ ↩ ↩