WCAG 3.2.2 — On Input

What this requires

Changing the setting of any user interface component must not automatically cause a change of context, unless the user has been advised of the behaviour before using the component. The criterion governs select menus that submit on change, checkboxes that redirect, and any input that does more than register a value.

How AI coding tools fail this

When asked to "make this filter apply immediately" or "save settings on change", AI tools wire up onChange handlers that submit forms, navigate routes, or refresh server state. For a keyboard user arrowing through a <select>, every option change is a page navigation.

The second pattern: language switchers and locale dropdowns that redirect on change with no warning. The user picks "German" to read the option and lands on a German page they didn't want.

The third: search inputs that fire route changes on every keystroke ("debounced search") that change the URL. Each character triggers history entries; the back button is now broken.

Failing examples

A language switcher that redirects on change:

<select
  onChange={(e) => window.location.assign(`/${e.target.value}`)}
  defaultValue={currentLocale}
>
  {locales.map((l) => <option key={l} value={l}>{l}</option>)}
</select>

A sort dropdown that navigates on each option focus:

<select
  onChange={(e) => router.push(`?sort=${e.target.value}`)}
>
  {/* options */}
</select>

Passing examples

Make the navigation explicit with a button:

<form action="/locale" method="get">
  <label htmlFor="locale">Language</label>
  <select id="locale" name="locale" defaultValue={currentLocale}>
    {locales.map((l) => <option key={l} value={l}>{l}</option>)}
  </select>
  <button type="submit">Change language</button>
</form>

If the change must apply immediately, warn the user up front and keep the change non-destructive (the user can change back without loss):

<>
  <p id="sort-help">Changes apply immediately.</p>
  <select
    aria-describedby="sort-help"
    onChange={(e) => updateUrlPreservingHistory(e.target.value)}
  >
    {/* options */}
  </select>
</>

Edge cases

In-page content updates (filtering a list, sorting a table) are generally fine — the criterion targets "change of context", which means navigation, focus shift, or major content replacement.
Search-as-you-type with results updating in place is fine. URL changes per keystroke are not.
Form submission on change is a fail. Use an explicit submit button.
Warning the user up front lets you have automatic behaviour and still pass — the criterion permits it with notice.
replaceState instead of pushState for URL updates that reflect filter state avoids polluting browser history.

How Jeikin handles this

The scanner flags onChange handlers on form controls that perform navigation or form submission. The dashboard records each finding and tracks whether the user has been warned or whether the behaviour has moved behind an explicit button.

References

W3C — Understanding 3.2.2 On Input (opens in new tab)