Skip to main content
Accessibility.com, LLC
Category: WCAG Principles and Conformance

On Input

Also known as: WCAG 3.2.2, Success Criterion 3.2.2, SC 3.2.2
Simply put

On Input is a web accessibility guideline that says interacting with a form field or control, such as typing text or selecting an option, should not trigger unexpected changes to the page. For example, choosing an item from a dropdown should not automatically submit a form or jump the user to a new page unless they were warned in advance. This predictability helps people, including those using assistive technology, understand and control what happens as they fill out forms.

Formal definition

On Input is Success Criterion 3.2.2 in the Web Content Accessibility Guidelines (WCAG), set at conformance Level A. Per the W3C's Understanding document, its intent is to ensure that entering data into a component or changing the setting of a user interface control does not automatically cause a change of context unless the user has been advised of the behavior before using the component. A change of context in this sense includes changes such as launching a new window, moving focus, submitting a form, or otherwise substantially altering the page. Meeting this criterion generally requires that context-altering effects be initiated deliberately by the user or preceded by clear notice; note that WCAG conformance addresses predictability of input behavior and is distinct from broader usability and from legal compliance, and that manual testing is typically needed to evaluate it. This entry is informational and not legal advice.

Why it matters

Forms are one of the most common ways people interact with websites, whether they are checking out of a store, applying for services, or entering account details. When interacting with a control, such as selecting an option from a dropdown, unexpectedly triggers a change of context like submitting a form or navigating to a new page, users can lose track of where they are and what just happened. This is especially disruptive for people using assistive technology, who may not immediately perceive that focus has moved or that the page has substantially changed.

On Input (WCAG Success Criterion 3.2.2) addresses this by requiring that entering data or changing a setting does not automatically cause a change of context unless the user has been advised of the behavior beforehand. Predictability gives people control over their own interactions: they can complete a field, review their choice, and then deliberately proceed. Without this predictability, users may submit incomplete information, be taken to unintended destinations, or abandon a task entirely because the interface behaves in ways they cannot anticipate.

Because SC 3.2.2 is a Level A criterion, the most basic conformance level in WCAG, it is often treated as a foundational expectation rather than an advanced enhancement. That said, meeting this criterion addresses the predictability of input behavior specifically; it does not on its own guarantee an accessible experience across all interactions, nor does WCAG conformance in itself guarantee legal compliance. Organizations should treat it as one component of a broader accessibility effort.

Who it's relevant to

Front-End Developers
Developers implementing forms and interactive controls are directly responsible for ensuring that events tied to input, such as change or input handlers, do not trigger unexpected navigation or submission. They can meet SC 3.2.2 by requiring an explicit user action, like activating a submit button, before a change of context occurs, or by providing advance notice of the behavior.
UX and Interaction Designers
Designers shape how forms and controls are expected to behave. By designing predictable interaction patterns, for example, pairing a dropdown with a separate action button rather than auto-submitting on selection, they help ensure users remain in control of what happens as they enter data.
QA and Accessibility Testers
Because SC 3.2.2 typically requires manual evaluation, testers play a key role in interacting with controls to confirm that input does not cause unexpected changes of context and that any intended context changes are clearly communicated in advance. Automated checks alone are generally insufficient to verify this criterion.
Compliance and Accessibility Program Owners
Those responsible for accessibility conformance should recognize that On Input is a Level A criterion often treated as a baseline expectation. This entry is informational and not legal advice; conformance requirements evolve through regulation and case law, and qualified legal counsel should be consulted for questions about legal obligations.

Inside On Input

Success Criterion 3.2.2 (WCAG)
On Input is WCAG Success Criterion 3.2.2, a Level A criterion introduced in WCAG 2.0 and carried forward in WCAG 2.1 and 2.2. It addresses predictable behavior when users interact with form controls and other user interface components.
Change of context
The core concept: changing the setting of a user interface component (such as selecting a radio button, checking a checkbox, or choosing an option from a menu) should not automatically cause a change of context unless the user has been advised of the behavior beforehand.
Definition of 'change of context'
Per W3C, a change of context includes major changes such as opening a new window, moving focus to a different component, navigating to a new page, or significantly rearranging page content in a way that could disorient a user, especially those using assistive technology.
Setting the value of a component
Refers to entering or altering data in a control, such as typing into a text field or selecting from a dropdown. Simply providing input should not trigger unexpected navigation or context shifts.
Advance notice as the permitted alternative
The criterion is satisfied if users are informed of the behavior before using the component, allowing automatic changes of context when the user has been made aware they will occur.

Common questions

Answers to the questions practitioners most commonly ask about On Input.

Does the On Input success criterion prohibit forms from doing anything automatically when a user enters data?
No. On Input (WCAG 2.0 Success Criterion 3.2.2, Level A) does not ban automatic behavior triggered by input. It addresses changes of context, which include things like automatically submitting a form, opening a new window, moving focus, or substantially changing the page, when they occur solely because a user changed a setting of a UI component. Such changes are permitted if the user is advised of the behavior before using the component. Ordinary responses such as showing a validation message or updating content without shifting context are generally not restricted by this criterion.
Is On Input the same as On Focus, since both deal with user interaction?
No, they are distinct criteria. On Focus (Success Criterion 3.2.1) addresses changes of context triggered simply by a component receiving focus, and it does not permit those changes at all. On Input (Success Criterion 3.2.2) addresses changes of context triggered when a user changes a component's setting, such as selecting a value, and it permits those changes if the user is warned beforehand. Both are Level A criteria under WCAG, but they cover different triggering events and have different allowances.
How can a select menu that navigates to a new page satisfy On Input?
One common approach is to avoid triggering the change of context on selection and instead require an explicit action, such as a separate submit or 'Go' button, so the navigation happens on the user's deliberate command rather than on the input event itself. Alternatively, if the component is designed to act on change, informing the user before they interact with it, such as through visible instructions describing the behavior, can help meet the criterion. Whether a given implementation conforms should be verified through testing.
What counts as advising the user before they use the component?
The criterion is generally understood to require that the user be informed of the automatic behavior before they operate the control, not after the change of context has already occurred. This is commonly done with instructions presented ahead of the component in a way that is available to assistive technology users. Notification given only after the context change has taken place would typically not satisfy the intent, since the user has no opportunity to anticipate the outcome.
How should On Input conformance be tested?
Testing generally involves interacting with each form control and setting, such as selecting options in menus, toggling checkboxes and radio buttons, and entering values, then observing whether any change of context occurs. Where a change of context does occur, the tester checks whether the user was advised of that behavior in advance. Because automated tools detect only a portion of accessibility issues and cannot reliably judge whether a warning is adequate or a context change is unexpected, manual review and testing with assistive technology are typically needed.
Does displaying an error message or updating field hints when someone types violate On Input?
Generally not, provided those updates do not constitute a change of context. Showing inline validation feedback, revealing help text, or updating related content on the same page without moving focus, launching a new window, or substantially reorganizing the page is typically outside the scope of what On Input restricts. The criterion is concerned specifically with changes of context that occur because the user changed a component's setting, so distinguishing an in-place content update from a context change is central to evaluating conformance.

Common misconceptions

On Input prohibits all automatic actions triggered by form controls.
The criterion does not ban automatic behavior outright. It requires that a change of context not occur unexpectedly. If users are advised of the behavior in advance, automatically changing context can conform to the criterion.
On Input and On Focus (3.2.1) cover the same situation.
They are distinct criteria. On Focus (3.2.1) addresses context changes caused simply by a component receiving focus, while On Input (3.2.2) addresses context changes caused by changing a component's setting or value. Both are Level A, but they apply to different user interactions.
Passing automated tests confirms compliance with On Input.
Automated tools detect only a portion of potential issues and generally cannot reliably determine whether a context change is unexpected or whether users were adequately advised. Manual evaluation and assistive technology testing are commonly needed to assess conformance.

Best practices

Avoid triggering navigation, new windows, or focus changes automatically when a user selects an option, checks a box, or enters data in a form control.
Where an automatic change of context is intended, inform users in advance, for example, through clearly associated instructions near the control, so the behavior is predictable.
Prefer an explicit submit or confirmation action (such as a button) to initiate context changes rather than triggering them from a component's value change.
Test forms and interactive components manually with keyboard navigation and assistive technologies, since automated checks alone may not detect unexpected context changes.
Distinguish On Input (3.2.2) from On Focus (3.2.1) during review, verifying both that focusing a control and that changing its value behave predictably.
Treat conformance with this Level A criterion as one part of broader accessibility and usability work, and consult qualified legal counsel for questions about legal obligations in your jurisdiction.