WCAG 3.2.2: On Input

What This Rule Means

WCAG 3.2.2 On Input is part of the Understandable principle and falls under Guideline 3.2 Predictable. It states that changing the setting of any user interface component must not automatically cause a change of context, unless the user has been informed in advance that such a behavior will occur.

A change of context is a major change in the content of a web page that can disorient users who cannot see the entire page at once. According to the WCAG specification, changes of context include: changes of user agent (browser), changes of viewport, changes of focus, and changes of content that significantly alter the meaning of the page. Submitting a form, opening a new window, or navigating to another page all qualify as changes of context. Simply revealing additional content, such as an expanding accordion, does not.

The criterion applies specifically to changing the setting of a UI component — for example, selecting a radio button, checking a checkbox, or choosing an option in a <select> dropdown — as opposed to activating a control (like clicking a button). If an action requires an explicit activation step (pressing Enter, clicking Submit), it generally does not fall under this criterion. The problematic pattern is when the mere act of selecting a value instantly triggers navigation or a significant page reload without any warning.

What counts as a pass: A form that uses a submit button to process user selections, even if those selections include dropdowns or checkboxes, passes this criterion. A dropdown that filters results on the same page without reloading or shifting focus significantly passes. A page that advises users upfront — for example, with a visible note like "Selecting a language will reload the page" — that a particular input will trigger a context change also passes.

What counts as a fail: A country or language selector that automatically redirects the user to a new URL the moment an option is chosen fails. A form that automatically submits and navigates away when a radio button is selected, without any submit button, fails. An autocomplete widget that shifts keyboard focus to a new region of the page without warning upon selection also fails.

Official exceptions: The WCAG specification notes that if the user is advised of the behavior before using the component, the automatic context change is acceptable. This advisory must be present before the interaction occurs, not after.

Why It Matters

Unexpected changes of context are one of the most disorienting experiences on the web, and the impact is amplified dramatically for users with disabilities. When a page suddenly navigates, reloads, or shifts focus without warning, users who cannot see the full visual layout of the page lose their orientation entirely.

Screen reader users are especially vulnerable. When a blind user operating NVDA or JAWS selects an option in a dropdown and the page immediately reloads or navigates, the screen reader announces the new page context from scratch. The user loses track of where they were, what they were doing, and must re-navigate the entire page to find their bearings. This is not a minor inconvenience — it can make the task completely impossible to complete independently.

Keyboard-only users, including people with motor impairments who cannot use a mouse, face a similar problem. They may be navigating a form using Tab and arrow keys and accidentally trigger a context change they did not intend. Without fine motor control, recovering from an unintended page navigation can require significant effort.

Cognitive disabilities further compound the issue. Users with attention-deficit conditions, learning disabilities, or memory impairments rely on predictable, stable interfaces to understand what is happening. Sudden context changes break the mental model they have built up during the session, often forcing them to start over or abandon the task.

Users with vestibular disorders may experience physical discomfort or disorientation when pages change unexpectedly, particularly if the change involves animation or scroll position shifts.

A concrete real-world scenario: consider an e-commerce checkout page in Turkey where a user selects their province from a dropdown. If that selection instantly reloads the page to update shipping options, a screen reader user might suddenly find themselves at the top of the page with no indication of what happened. They would have to navigate back through all the form fields to find where they were, not knowing whether their previous inputs were preserved. This kind of friction can cause users to abandon the purchase entirely.

From a usability and SEO perspective, pages that behave predictably have lower bounce rates. Users are less likely to leave in frustration, and search engine crawlers can more reliably index the content without unexpected redirects interfering with crawl paths.

Related Axe-core Rules

WCAG 3.2.2 On Input requires manual testing. Automated tools like axe-core cannot reliably detect violations of this criterion because the problematic behavior is contextual and depends on the intent behind an interaction, not simply the presence or absence of a specific HTML attribute or structure. A tool can identify that a <select> element has an onchange event handler, but it cannot determine whether that handler triggers a change of context, whether the user has been warned about this, or whether the resulting behavior is disorienting in practice.

• Manual Testing Required — onchange Navigation Patterns: Automated scanners can flag <select>, <input type='radio'>, and <input type='checkbox'> elements that have JavaScript event handlers (particularly onchange), but they cannot determine whether those handlers cause a change of context. A human tester must interact with each such control and observe whether the page navigates, reloads, shifts focus to a dramatically different region, or opens a new window without an explicit activation step from the user.
• Manual Testing Required — Presence and Adequacy of Advance Warning: Even if a context change is detected, an automated tool cannot determine whether the user was adequately warned about it before interacting with the control. A human must verify that any advance notice is visible before the component is encountered, clearly worded, and actually describes the behavior that will occur.
• Manual Testing Required — Focus Management After Input: Some violations manifest as focus being moved to an unexpected location upon input change rather than outright navigation. Automated tools cannot reliably trace focus destinations triggered by onchange events and confirm whether the resulting focus placement constitutes a disorienting context change.

How to Test

1. Automated scan baseline: Run axe DevTools or Lighthouse against the page to identify any flagged issues under WCAG 3.2. While 3.2.2 itself requires manual testing, axe may surface related issues (such as missing labels or focus management problems) that provide a starting point. Note all form controls — especially <select> dropdowns, radio groups, and checkboxes — for manual follow-up.
2. Identify all input controls with change handlers: In browser DevTools, inspect the page's JavaScript or use the Event Listeners panel to identify any <select>, <input type='radio'>, <input type='checkbox'>, or custom widget that has an onchange, oninput, or equivalent event listener attached.
3. Manual keyboard interaction test: Using only a keyboard (Tab to navigate, arrow keys for radio/select options), interact with each identified control. Observe whether selecting an option causes the page to navigate, reload, open a new window, or move focus to a significantly different part of the page. If yes, confirm whether a visible warning was displayed before the control was encountered.
4. NVDA + Firefox test: Launch Firefox with NVDA active. Navigate to each form control using NVDA's virtual cursor (arrow keys) and then interact using the forms mode (Enter or Space). Select options in dropdowns and radio groups and listen for any unexpected announcements indicating a page load, navigation, or major context shift. Note whether NVDA reads out a new page title or a dramatically different region.
5. VoiceOver + Safari test (macOS/iOS): Enable VoiceOver and navigate to each control using VO+Right arrow. Interact with dropdowns and checkboxes. If a context change occurs, VoiceOver will typically announce the new page or shift focus. Determine whether the user was forewarned.
6. JAWS + Chrome test: Use JAWS in virtual cursor mode to navigate the page. Interact with form controls and monitor whether JAWS announces a change in context (page title change, new URL, shifted reading position) immediately upon input — without a submit button being activated.
7. Visual observation test: For sighted users without assistive technology, select options in each dropdown and radio group and observe whether the page navigates or reloads unexpectedly. If it does, check whether any instructional text visible before the control warned about this behavior.

How to Fix

Auto-submitting select dropdown — Incorrect

<!-- BAD: Selecting a country immediately redirects the page -->
<label for='country'>Select Country</label>
<select id='country' name='country' onchange='window.location.href="/region/" + this.value'>
  <option value='tr'>Turkey</option>
  <option value='de'>Germany</option>
  <option value='us'>United States</option>
</select>

Auto-submitting select dropdown — Correct

<!-- GOOD: Selection is confirmed via a submit button; no automatic navigation -->
<form action='/region/' method='get'>
  <label for='country'>Select Country</label>
  <select id='country' name='country'>
    <option value='tr'>Turkey</option>
    <option value='de'>Germany</option>
    <option value='us'>United States</option>
  </select>
  <!-- Explicit submit button gives the user control over when navigation occurs -->
  <button type='submit'>Go</button>
</form>

Radio button auto-submit pattern — Incorrect

<!-- BAD: Selecting a payment method immediately submits the form -->
<fieldset>
  <legend>Payment Method</legend>
  <label>
    <input type='radio' name='payment' value='card' onchange='this.form.submit()'>
    Credit Card
  </label>
  <label>
    <input type='radio' name='payment' value='bank' onchange='this.form.submit()'>
    Bank Transfer
  </label>
</fieldset>

Radio button auto-submit pattern — Correct

<!-- GOOD: onchange can update UI state without navigating; submit requires user action -->
<fieldset>
  <legend>Payment Method</legend>
  <label>
    <input type='radio' name='payment' value='card' onchange='showPaymentDetails(this.value)'>
    Credit Card
  </label>
  <label>
    <input type='radio' name='payment' value='bank' onchange='showPaymentDetails(this.value)'>
    Bank Transfer
  </label>
</fieldset>
<!-- showPaymentDetails() reveals additional fields inline — no context change -->
<div id='payment-details' aria-live='polite'></div>
<button type='submit'>Confirm Payment</button>

Language switcher with advance warning — Correct

<!-- ACCEPTABLE: User is warned before interacting that selecting will reload the page -->
<p id='lang-notice'>Selecting a language will immediately reload the page.</p>
<label for='lang-select'>Language</label>
<select
  id='lang-select'
  name='lang'
  aria-describedby='lang-notice'
  onchange='window.location.href="/" + this.value + "/"'
>
  <option value='en'>English</option>
  <option value='tr'>Türkçe</option>
  <option value='de'>Deutsch</option>
</select>
<!-- The aria-describedby links the warning to the control for screen reader users -->

Common Mistakes

• Attaching window.location.href assignments directly to a <select> element's onchange attribute without a submit button, causing immediate page navigation the moment the user picks an option.
• Using this.form.submit() inside a radio button's onchange handler, which submits the entire form and navigates away the instant a radio option is selected — before the user can review their choices.
• Placing the advance warning after the control in the DOM so that screen reader users and keyboard navigators encounter the control before hearing or reading the warning about the behavior it triggers.
• Displaying the advance warning only as a tooltip or placeholder text that is not reliably exposed to assistive technologies, leaving screen reader users without any indication that a context change will follow their input.
• Building custom dropdown widgets using <div> and <ul> elements that fire navigation on selection via JavaScript but lack the semantic structure that would allow testers or accessibility overlays to identify them as interactive controls requiring scrutiny under 3.2.2.
• Triggering an automatic form submission on the last field in a form (for example, a PIN or OTP input) when the required number of characters is reached, without notifying the user this will happen.
• Opening a modal dialog or new browser window in response to a checkbox being ticked, without any prior advisory — this constitutes a change of context because it shifts the user's viewport and focus significantly.
• Confusing predictable in-page content updates with context changes and adding unnecessary submit buttons around interactions that are already acceptable (like a live search filter), which can clutter the UI — teams should understand that inline, non-disorienting updates do not require a submit step.
• Relying solely on automated accessibility scans and marking 3.2.2 as passed because no automated rule flagged it, without conducting the mandatory manual keyboard and screen reader testing that this criterion requires.
• Applying a context-changing onchange handler to a <select> used for sorting or filtering in a results list, causing a full page reload rather than an AJAX update, and failing to warn users that this reload will occur upon selection.

Relation to Turkey's Accessibility Regulations

Turkey's Presidential Circular 2025/10, published in the Official Gazette No. 32933 on June 21, 2025, establishes mandatory web accessibility requirements based on WCAG 2.2. WCAG 3.2.2 On Input is a Level A criterion, which represents the minimum baseline of conformance under the circular — meaning compliance is not optional but legally required for all covered entities.

The circular defines a two-tier implementation timeline. Public institutions — including ministries, municipalities, state universities, and government agencies — must achieve full Level A conformance within one year of the circular's publication. Private sector entities covered by the regulation have a two-year window to comply.

The following entity types are explicitly covered under the circular and must therefore ensure their digital services comply with WCAG 3.2.2: e-commerce platforms, public institutions at all levels of government, banks and financial institutions, hospitals and healthcare providers, telecommunications companies with 200,000 or more subscribers, licensed travel agencies, private transportation companies, and private schools authorized by the Ministry of National Education (MoNE).

For these entities, a violation of WCAG 3.2.2 — such as a language selector on a banking portal that auto-redirects upon selection, or a hospital appointment form that submits automatically when a department radio button is chosen — constitutes a direct regulatory non-compliance. Given that Turkey has a substantial population of users with disabilities, and that government digital services are increasingly the primary channel for citizens to access public services, the practical stakes of ignoring this criterion are significant.

Organizations subject to the circular should treat WCAG 3.2.2 testing as a mandatory audit step during QA. Because automated tools cannot catch violations of this criterion, manual testing by trained accessibility specialists — covering keyboard interaction, screen reader behavior with NVDA and JAWS, and explicit review of all onchange-driven interactions — must be built into the compliance process. Documenting test results and any accepted exceptions (with advance warnings in place) is advisable for demonstrating due diligence to regulatory bodies.