WCAG 3.2.2 · Level A · EN 301 549 9.3.2.2

On Input

Requires that changing a control, such as a select list or check box, does not cause a change of context unless users were told in advance.

In brief

People change a drop-down, tick a box or type in a field without expecting the page to react. If choosing an option instantly loads another page or submits the form, users who navigate with the keyboard, or who are still scrolling through the options, are thrown off before they have finished.

This criterion requires that changing the setting of any user interface component does not automatically cause a change of context, unless the user has been advised of the behaviour before using the component.

What does it cover?

  • What is a change of context: A change of context is a major change that can disorient users who cannot see the whole page at once: a change of user agent, viewport, focus, or of content that changes the meaning of the page.
  • Changing a setting: Ticking a check box, choosing a radio button or a list item, or typing in a text field changes a setting. Activating a link or a button is not changing a setting.
  • Activation is different: A button that submits a form and navigates, or opens a dialog, is activation. A button that toggles a state, such as a pressed button, does change a setting.
  • Advice in advance: If a setting change will cause a change of context, tell users before they reach the control (G13), for example "Choosing a language reloads the page".
  • A submit button: The most reliable approach is to put the change behind a submit button (G80), or a button next to a select list (H84).
  • Content changes are fine: Updating a list in place, showing a field that depends on a choice or a live total is not a change of context if focus does not move and the meaning of the page does not change.
  • Out of scope: Changes on receiving focus are 3.2.1. Error handling is 3.3.1.

Who does it affect?

Keyboard users, who change the value of a list by moving through it with the arrow keys and trigger every change. Screen reader users, who cannot see the page change. People with low vision who see only part of the screen. People with cognitive disabilities who need predictable behaviour. People with motor disabilities who change a setting by accident.

In the EAA and EN 301 549

The European Accessibility Act (Directive (EU) 2019/882) applies to in-scope products and services placed on the market after 28 June 2025. Recital 47 names four principles for websites and mobile applications: perceivable, operable, understandable and robust. Predictable behaviour on input is part of "understandable".

The technical counterpart is the standard EN 301 549, which incorporates WCAG 3.2.2 by reference and turns it into separate clauses for each kind of ICT.

Where WCAG 3.2.2 appears in EN 301 549
ClauseType of ICTWhat it requires
9.3.2.2Web pagesWeb content must satisfy WCAG success criterion 3.2.2.
10.3.2.2Non-web documents (PDF, Office files)Documents must not change context when a control setting changes, where the standard applies the criterion to them.
11.3.2.2Non-web software (native mobile apps)Software must not change context automatically when the setting of a control changes.

Whether and how the criterion applies to non-web documents is stated in clause 10 of the standard. Clause numbers follow the "9. + WCAG number" pattern of EN 301 549. In V3.2.1 the software clause is divided into further subclauses for open and closed functionality. Check the exact numbers in the standard when you cite them.

Standard version: EN 301 549 V4.1.1 (September 2026) is based on WCAG 2.2 and is the first version prepared specifically for the EAA. It has not yet been cited in the Official Journal of the European Union, so for now it is best treated as a voluntary technical route to the EAA's requirements. Once cited, it will give a presumption of conformity. The text of criterion 3.2.2 is the same in WCAG 2.1 and 2.2.

A note on EAA scope: Article 2(4) of the Directive excludes certain content from the requirements, for example office file formats published before 28 June 2025 and archives that are not updated after that date. Content you publish or change after that date is not covered by these exclusions.

Directive (EU) 2019/882, EUR-Lex, opens in a new tab

Code examples for the web

1. A select that navigates on change

A keyboard user who arrows through the options is sent away at the first one. Add a button (H84).

Incorrect
<select onchange="location.href=this.value">
  <option value="/en">English</option>
  <option value="/tr">Türkçe</option>
</select>
Correct
<label for="lang">Language</label>
<select id="lang">
  <option value="/en">English</option>
  <option value="/tr">Türkçe</option>
</select>
<button type="button" onclick="location.href=lang.value">Go</button>

2. A form that submits when the last field is filled

Automatic submission without warning fails (F36). Let the user submit.

Incorrect
lastField.addEventListener("input", () => form.submit());
Correct
<form>
  …
  <button type="submit">Submit</button>
</form>

3. A radio button that opens a window

Opening a new window when a selection changes fails without prior warning (F37).

Incorrect
<input type="radio" name="mirror" onchange="window.open(this.value)">
Correct
<input type="radio" name="mirror" id="m1" value="/dl/1"> <label for="m1">Mirror 1</label>
<button type="button">Download from selected mirror</button>

4. Warn before the change (G13)

If the setting must trigger a change, say so before the control.

Incorrect
<select onchange="reloadInLanguage(this.value)">…</select>
Correct
<p id="note">Choosing a language reloads the page.</p>
<label for="lang">Language</label>
<select id="lang" aria-describedby="note" onchange="reloadInLanguage(this.value)">…</select>

5. A change that is not a change of context

Filtering a list in place, without moving focus, is a content change that is allowed.

Incorrect
<select onchange="location.href='/results?color='+this.value">…</select>
Correct
<label for="color">Colour</label>
<select id="color">…</select>
<ul id="results" aria-live="polite">…</ul>
<script>
color.addEventListener("change", () => updateResultsInPlace(color.value));
</script>

6. A check box that moves focus

Moving focus to another place when a box is ticked disorients users.

Incorrect
agree.addEventListener("change", () => submitBtn.focus());
Correct
<input type="checkbox" id="agree"> <label for="agree">I agree</label>
<button type="submit">Continue</button>

Code examples for mobile

On mobile, pickers, toggles and segmented controls often navigate right away. Either wait for an explicit action, or tell the user in advance.

iOS (SwiftUI)

import SwiftUI

struct LanguageSettings: View {
    @State private var language = "en"

    var body: some View {
        VStack {
            Picker("Language", selection: $language) {
                Text("English").tag("en")
                Text("Türkçe").tag("tr")
            }
            // The change is applied by an explicit action, not by choosing an option
            Button("Apply") { applyLanguage(language) }
        }
    }
}

Android (Jetpack Compose)

import androidx.compose.foundation.layout.Row
import androidx.compose.material3.*
import androidx.compose.runtime.*

@Composable
fun NotificationsSetting(onApplied: (Boolean) -> Unit) {
    var enabled by remember { mutableStateOf(false) }
    Row {
        Text("Email notifications")
        // The switch changes the setting only; it does not navigate
        Switch(checked = enabled, onCheckedChange = { enabled = it })
    }
    Button(onClick = { onApplied(enabled) }) { Text("Save") }

    // Avoid: onCheckedChange = { startActivity(...) }
}

How to test

  • Change every control: Change the value of each select list, radio button, check box and field. Does anything open, navigate or submit on its own?
  • Use the keyboard: Move through a select list with the arrow keys. Does the page react before you press a button?
  • Look for the warning: If a change does cause a context change, is the user told before they reach the control?
  • Search the code: Look for onchange, change and input handlers that call submit(), window.open(), location or focus().
  • Check the exceptions: Is the content updated in place with focus staying where it is?
  • Check forms: Does every form that changes context have a submit button?
  • Use a checker as a starting point: Automated tools cannot tell what a change handler does. A person must use the controls.

Common mistakes

  • Navigating on select change: The classic failure, and a keyboard trap for arrow key users.
  • Automatic form submission: The form submits as soon as the last field is filled (F36).
  • New windows on change: A radio button or check box that opens a window (F37).
  • Language pickers that reload: No button and no warning.
  • Warnings that come too late: The advice must be available before the control is used.
  • Moving focus on change: Jumping to another control when a value changes.
  • Confusing a setting with activation: A button is activation, a toggle is a setting.
  • Forgetting custom controls: Custom dropdowns and sliders often react on every change.

Sources

Standard version: EN 301 549 V4.1.1 (2026-09), WCAG 2.2. This page is for informational purposes only and is not legal advice. For binding requirements, refer to the official texts of the European Accessibility Act (Directive (EU) 2019/882) and EN 301 549.

Corpowid is recognized by Gartner

Corpowid has been recognized by Gartner, a leading global research and advisory firm, for our innovation and performance in digital accessibility. These badges reflect our commitment to creating inclusive, AI-powered web experiences.

Have questions about Corpowid?

Let’s connect.

We will get back to you as soon as possible.