WCAG 3.2.2 On Input Explained (Level A)

WCAG 3.2.2 On Input is a Level A rule that says: changing the setting of a form control — checking a box, typing in a field, or selecting a dropdown option — must not automatically cause a change of context unless you’ve told the user that will happen before they use the control. Inputs should be predictable, never sprung as surprises.

What 3.2.2 On Input requires

The official wording from the W3C Understanding document is:

Changing the setting of any user interface component does not automatically cause a change of context unless the user has been advised of the behavior before using the component.

Two phrases carry the whole rule. “Changing the setting” means altering a control’s value: ticking a checkbox, entering text, or choosing a different option in a <select>. (Activating a link or button is not “changing a setting” — that’s a deliberate action the user took.) “Change of context” is a defined term in WCAG: a major change to the user agent, the viewport, focus, or content that changes the meaning of the page. Concretely that means opening a new window, navigating to a new URL, moving keyboard focus to a different component, or significantly re-arranging the page.

The key word is automatically. A dropdown that reveals three extra fields in place when you choose “Meeting” is fine — the page structure and your reading position are preserved. A dropdown that reloads the whole page the instant you choose an option is a violation, unless you warned the user first.

Who it affects

This criterion protects the people who can’t take in a page at a glance and re-orient after a sudden jump:

• Blind screen reader users (JAWS, NVDA, VoiceOver). When a <select> silently navigates to a new page on change, the screen reader’s cursor and the user’s mental model are both destroyed. They were reading option three of a list; now they’re somewhere else entirely with no explanation.
• Low-vision users using screen magnifiers (ZoomText). They see only a small slice of the screen at high zoom. If picking a radio button opens a new window, the change happens completely outside their viewport — they never see it.
• People with cognitive and learning disabilities. The W3C notes these users specifically benefit from additional cues to detect changes of context. An unannounced page reload is disorienting and can make a form impossible to complete.
• Keyboard-only users. When auto-advance logic moves focus on its own (see the auto-tabbing failure below), it fights the user’s own arrow and tab keys.

Concrete failures (and the fix)

Failure F36 — auto-submitting on change

The most common violation is a form that submits itself the moment a control’s value changes — a country, currency, or language selector with no submit button. W3C catalogs this as Failure F36.

<!-- FAILS 3.2.2: page navigates the instant the value changes -->
<select onchange="this.form.submit()">
  <option>United States</option>
  <option>Canada</option>
</select>

A screen reader user arrowing through the options triggers a submit on every option they pass — they may never reach “Canada.” The fix is an explicit action:

<!-- PASSES: the context change only happens when the user chooses to submit -->
<form action="/set-country">
  <select name="country">
    <option>United States</option>
    <option>Canada</option>
  </select>
  <button type="submit">Update country</button>
</form>

Failure F37 — launching a window or navigating on selection

Failure F37 covers launching a new window when a radio button, checkbox, or select value changes. W3C’s own failing example wires a radio group to window.open():

<!-- FAILS 3.2.2: selecting a mirror opens a new window with no warning -->
<input type="radio" name="mirror" value="belnet.be"
       onclick="window.open('https://download.belnet.be/');" />

Selecting an option is supposed to set a choice, not teleport you. Move the navigation behind a button, or — if the on-change behavior is genuinely required — keep it and add the warning that 3.2.2 allows.

The allowed exception: warn first (G13)

3.2.2 does permit on-input context changes if the user is advised beforehand. Technique G13 says to put the instruction earlier in the reading order than the control, so a screen reader announces it first:

<p id="lang-note">Choosing a language reloads the page in that language.</p>
<select aria-describedby="lang-note" onchange="this.form.submit()">
  <option>English</option>
  <option>Español</option>
</select>

That advance notice is exactly the kind of instruction covered by WCAG 3.3.2 Labels or Instructions — the two criteria reinforce each other on forms.

Aggressive auto-advance

A related trap: phone or verification-code inputs that auto-move focus to the next field after the expected character count. W3C’s Example 2 accepts this only when the behavior is described up front. Done silently, the focus jump fights screen reader and keyboard users and can drop characters. (See our keyboard navigation guide for why hijacking focus backfires.)

How to test for 3.2.2

You can’t catch most of these with an automated scanner alone — the failure is a behavior, not a static attribute. Test it like a user would:

1. Tab to every form control and change its value with the keyboard. Press arrow keys through each <select>, toggle every checkbox and radio. Watch for any page reload, new window, URL change, or focus jump that you didn’t ask for.
2. Listen with a screen reader. Turn on NVDA or VoiceOver and arrow through dropdowns. If the page navigates while you’re still browsing options, that’s the failure in action.
3. Look for missing submit buttons. A settings or filter form with no submit button is a red flag for an F36 auto-submit.
4. Grep your code for onchange handlers that call submit(), window.open(), or change location.href. Each one needs either a submit button or a documented G13 warning.
5. Check auto-advancing fields for an explicit, visible instruction before the first field.

Because the violation is interactive, thorough coverage means manual testing, not just a widget or a one-pass crawler. That is exactly what a hands-on accessibility audit is for — and it’s why we pair tooling with real keyboard and screen reader passes on every accessible forms review.

Why it matters legally

Predictable inputs are part of WCAG 2.1 — and 3.2.2 On Input is a Level A criterion, so it sits below even the AA bar. WCAG 2.1 AA is the standard U.S. accessibility law leans on: the Department of Justice’s April 2024 Title II rule formally adopted WCAG 2.1, Level AA as the technical standard for state and local government web content, per ADA.gov, which sharpens AA as the practical benchmark courts apply to private businesses under ADA Title III too. Digital accessibility litigation runs at scale: UsableNet tracked over 4,000 ADA-related digital lawsuits in 2024, roughly flat with 2023’s total (UsableNet 2024 Year-End Report). Forms are where money changes hands — checkout, booking, account creation — so form-behavior failures like a self-submitting country selector are exactly what a plaintiff’s tester documents.

A widget won’t save you here: the same report found more than 1,000 businesses were sued in 2024 despite already running an accessibility overlay. An overlay can’t rewrite your form’s onchange logic or reliably suppress an unexpected redirect. (See why overlays don’t work.) For the official requirement language, see the W3C Web Accessibility Initiative.

This is general information, not legal advice. For your specific exposure, consult a qualified attorney.

Fixing it the right way

3.2.2 problems are almost always small, surgical code changes — add a submit button, move a redirect behind an explicit click, or write the one-line G13 warning the standard allows. The wrong fix is bolting on an overlay and hoping. Curbcut does this as manual remediation: our team rebuilds the form behavior in your actual code so the default experience is predictable, then we can document it in a VPAT if you need proof of conformance.

3.2.2 is one Level A checkpoint among many in the WCAG standard — see the full success criteria index for the rest. If you’re not sure whether any of your forms spring a surprise on users, start with a free scan and we’ll show you exactly where, then fix it for you through hands-on remediation.