On Input
Tier 1 · The normative floor
Baseline compliance
What the normative text of WCAG 2.2 requires, and nothing more. Only a failure of this tier is a WCAG failure.
The bare minimum
Changing the setting of a component doesn't automatically cause a change of context, unless the user was told about this behavior before using the component.
Normative text
Verbatim from WCAG 2.2, W3C Recommendation 12 December 2024. Underlined terms are defined below.
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.
Not required by the normative text
Common claims that this criterion does not support. Don't log these as WCAG failures.
- A submit button on every form. A select that navigates on change is allowed if users are told beforehand.
Definitions used (2)
Glossary definitions are normative. Their notes are informative.
- user interface component
-
a part of the content that is perceived by users as a single control for a distinct function
Informative notes (3)
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.
User interface components include form elements and links as well as components generated by scripts.
What is meant by "component" or "user interface component" here is also sometimes called "user interface element".
- changes of context
-
major changes that, if made without user awareness, can disorient users who are not able to view the entire page simultaneously
Changes in context include changes of:
- user agent;
- viewport;
- focus;
- content that changes the meaning of the web page
Informative notes (1)
A change of content is not always a change of context. Changes in content, such as an expanding outline, dynamic menu, or a tab control do not necessarily change the context, unless they also change one of the above (e.g., focus).
Tier 2 · The gap
Usability & user impact
Where content can meet this criterion and still make things harder for people with disabilities. These are not failures of SC 3.2.2, so raise them as usability defects. Known failures, including failures of related criteria, are listed in Tier 1.
Advance notice that is technically present, such as a sentence above the form, is easily missed. Keyboard users browsing a select with arrow keys can trigger navigation by accident.
Tier 3 · The golden path
Recommended best practice
The pattern that meets the floor, closes the gap, and avoids audit disputes. A recommendation, not a requirement.
Pair selects and option groups with an explicit Apply or Go button.
W3C's Understanding document and techniques for SC 3.2.2 ↗ are informative: sufficient techniques show ways to pass, and documented failures show common ways to fail, but neither changes what the criterion requires.
How SC 3.2.2 maps to the WCAG 3 draft
From this site's reviewed map to the WCAG 3 editor's draft. It's an interpretation: W3C has not published a mapping.
No provision in the current draft forbids a change of context on input.
Related, not a successor
From WCAG 2.2, section 5.1: “The main content of WCAG 2.2 is normative and defines requirements that impact conformance claims. Introductory material, appendices, sections marked as "non-normative", diagrams, examples, and notes are informative (non-normative). Non-normative material provides advisory information to help interpret the guidelines but does not create requirements that impact a conformance claim.”