WCAG 3.2.2 On Input: Avoiding Unexpected Changes When People Complete Forms

What WCAG 3.2.2 On Input requires

WCAG 3.2.2 On Input says that when a user interface component receives input it must not automatically cause a change of context unless the user has been advised of that behavior. This applies to form fields, controls, and any input that could navigate, submit, open a dialog, or otherwise move the user away from their current task.

Why this matters for forms

Unexpected changes break people who use keyboards, screen readers, switch devices, or dwell on a mobile screen. For example, auto-submitting a form when a field loses focus can stop a screen reader user mid-scan. Users may lose typed text, lose focus, or be surprised by navigation they did not intend.

What counts as a change of context

• Navigation to a new page or anchor
• Automatic form submission that replaces page content
• Opening or closing modal dialogs or overlays
• Launching file downloads or print dialogs
• Replacing the whole content area so keyboard focus jumps unexpectedly

Common ways forms fail this criterion

• Auto-submit on blur or on select without a clear notice
• Dropdowns that immediately navigate when an option is clicked
• Instant search results that replace focus and page content as you type
• Checkboxes or radio buttons that open dialogs or change pages on change
• Autosave that causes a page refresh or redirects

How to meet WCAG 3.2.2 On Input

Follow these design and engineering patterns to avoid unexpected context changes.

Prefer explicit user action

• Require a visible, keyboard-focusable submit or confirm control for actions that change context.
• Label the control clearly, for example “Apply filter” or “Search now”.

When automatic changes are necessary, warn first

• Provide a persistent, visible message describing the automatic behavior before it occurs.
• Use inline text that is associated with the control so screen reader users hear the notice when they focus the field.

Offer an undo or confirmation

• If a change cannot be avoided, allow users to undo it with a single action, like “Undo” or “Back”.
• Keep the undo control visible and reachable by keyboard focus after the change.

Manage focus and announcements

• When a context change does happen, set focus to a predictable element in the new context and not to an arbitrary part of the page.
• Use aria-live politely to inform screen reader users of non-critical updates. Do not use live regions as a substitute for avoiding unexpected navigation.

Preserve user data and history

• Do not discard typed input when a change occurs. Save input or prefill fields when users return via the back button.
• For multi-step flows, preserve state on server or client so accidental changes do not require retyping.

When a change of context is allowed

Some inputs legitimately change context without prior warning. That is acceptable if the change is expected or the user initiated it explicitly. Examples include clicking a clearly labeled link, pressing a submit button, or choosing a link-style control that is presented as navigation. Make the behavior obvious through labels and UI affordances.

Real-world examples and fixes

Problem	Why it fails	Fix
Search auto-submit on blur	Page reloads when user tabs out. Keyboard or screen reader users lose place.	Replace with an explicit “Search” button. Keep autosuggest for suggestions only, not navigation.
Filter dropdown immediately applies and navigates	User choices trigger a page update without confirmation.	Show an “Apply filters” button or a toast that offers “Undo” and keeps focus on the filter control.
Checkbox opens modal on change	Modal appears unexpectedly and shifts focus.	Change the checkbox to a labeled button or add a separate control that opens the modal after confirmation.

Testing checklist

Use this order when you test a form for 3.2.2 compliance.

1. Keyboard only: Tab through inputs and controls. Verify no input causes navigation or page refresh unless a submit or clearly labeled navigation control is activated.
2. Screen reader: With a screen reader like NVDA or VoiceOver, focus each input and listen for announcements. Confirm any warning text is read before an automatic change.
3. Mobile: Test touch focus and change events. Ensure auto-complete or clear buttons do not trigger navigation.
4. Undo and state: Trigger a permitted automatic change and confirm an undo is available and that form state is preserved if the user navigates back.

Common developer mistakes and how to avoid them

• Relying on blur events to save or submit. Instead, use an explicit save action or confirm before submitting.
• Using visual cues only. Always expose the warning to assistive tech using visible text that is in the DOM and reachable by focus.
• Assuming autosave is harmless. Autosave that causes a redirect or major UI swap violates the criterion unless warned.

Quick implementation checklist for engineers

• Add explicit, labelled controls for actions that change pages or replace main content.
• Provide clear inline notices for any automatic behavior and ensure they are programmatically associated with the input.
• Keep focus predictable after any change and avoid moving focus without user intent.
• Provide undo where changes cannot be avoided and keep the undo control keyboard accessible.
• Test with keyboard and screen reader as part of QA and accessibility reviews.

Summary

WCAG 3.2.2 On Input focuses on preventing surprises when users interact with form controls. Use explicit actions, warnings, and undo options. Test with keyboard and assistive technology to confirm the experience is predictable and recoverable.