Skip to Content (Press Enter)

This document is a draft, and is designed to show changes from a previous version. It is presently showing added text,changed text,deleted text,[start]/[end] markers,and Issue Numbers.

Hide All Edits   |   Toggle Deletions  |   Toggle Issue Numbers   |   Toggle [start]/[end] Markers   |   Show All Edits

Changes are displayed as follows:


On Input:
Understanding SC 3.2.2

3.2.2 On Input: 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. (Level A)

Intent of this Success Criterion

The intent of this success criterion is to ensure that entering data or selecting from a control has predictable effects. Changes in context[begin delete], such as changing the input fields based on the value of a radio button, [2010] [end delete] can confuse users who do not easily perceive the change or are easily distracted by changes. Changes of context are appropriate only when it is clear that such a change will happen when a field is selected or a button is pressed.

Specific Benefits of Success Criterion 3.2.2:

  • This success criterion helps users with disabilities by making interactive content more predictable. Unexpected changes of context can be so disorienting for users with visual disabilities or cognitive limitations that they are unable to use the content.

  • Individuals who are unable to detect changes of context are less likely to become disoriented while navigating a site. For example:

    • Individuals who are blind or have low vision may have difficulty knowing when a visual context change has occurred, such as a new window popping up. In this case, warning users of context changes in advance minimizes confusion when the user discovers that the back button no longer behaves as expected.

  • Some individuals with low vision, with reading and intellectual disabilities, and others who have difficulty interpreting visual cues may benefit from additional cues in order to detect changes of context.

Examples of Success Criterion 3.2.2

Techniques and Failures for Success Criterion 3.2.2 [On Input]

Each numbered item in this section represents a technique or combination of techniques that the WCAG Working Group deems sufficient for meeting this success criterion. The techniques listed only satisfy the success criterion if all of the WCAG 2.0 conformance requirements have been met.

Sufficient Techniques

  1. G80: Providing a submit button to initiate a change of context using a technology-specific technique listed below

  2. G13: Describing what will happen before a change to a form control is made

    • H32: Providing submit buttons (HTML)

    • Using a button with a select element to perform an action (future link)

    • Hiding and showing content based on a select element change (future link)

    • Hiding and showing content based on a radio element change (future link)

Additional Techniques (Advisory)

Although not required for conformance, the following additional techniques should be considered in order to make content more accessible. Not all techniques can be used or would be effective in all situations.

(none currently documented)


The following are common mistakes that are considered failures of Success Criterion 3.2.2 by the WCAG Working Group.

Key Terms

changes of context

change of:

  1. user agent;

  2. viewport;

  3. focus;

  4. content that changes the meaning of the Web page.

Note: A change of content is not always a change of context. Small changes in content, such as an expanding outline or dynamic menu, do not change the context.

[begin add]

Example: Submitting a form, opening a new window, or moving focus to a different component are examples of changes of context. [1129]

[end add]
user interface component

a part of the content that is perceived by users as a single control for a distinct function

Note: Multiple user interface components may be implemented as a single programmatic element. Components here is not tied to programming techniques but rather to what the user perceives as separate controls.

Example: An applet has a "control" that can be used to move through content by line or page or random access. Since each of these would need to have a name and be setable independently, they would each be a "user interface component."