Understanding WCAG SC 3.2.2 On Input
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)
On Input Transcript
Today, we’re exploring the topic of context change on input, its importance, the benefits it offers, examples of good and bad practices, and how to address these issues effectively.When users interact with form fields—such as entering data, selecting a dropdown value, or choosing options in a group of radio buttons—these inputs should not trigger a context change unless users are explicitly informed beforehand. Context change occurs when an unexpected action, such as a page refresh, form submission, or focus shift, is initiated without user confirmation. For instance, on an online registration page, users entering the first three characters of their address may see a list of matching options. Ideally, users should navigate this list using arrow keys to select their desired address. However, if the system automatically selects the first suggestion and advances the form, this causes an unintended context change, disrupting the user experience.
Predictable interactions are vital for many users. Screen reader users, for example, rely on form controls that behave consistently to navigate effectively. Similarly, users with cognitive disabilities depend on intuitive and predictable web interactions. For individuals with limited dexterity who use keyboards or alternative input mechanisms, such disruptions can make completing forms difficult or even impossible.
To mitigate such challenges, providing clear instructions is essential when a context change is unavoidable. For example, on a checkout page, users selecting a saved delivery address should be warned beforehand that doing so will move them to the next step. On an e-commerce website with search filters, users should apply changes by selecting an “Apply Filters” button rather than having changes trigger automatically.
Conversely, poor practices, such as automatically moving focus to the next field when users type the first few digits of a credit card number, can create confusion and hinder usability. These issues can be avoided by requiring explicit user actions to apply changes or submit forms. For instance, grouping related form fields, such as for credit card information, and ensuring focus remains consistent until the user actively confirms their input helps prevent unnecessary context changes. Providing instructions and warnings for any inevitable context changes ensures users are prepared and able to proceed confidently.
In conclusion, designing form inputs to prevent unexpected context changes is crucial to creating an accessible and inclusive experience for all users. By implementing these practices, we can ensure that people with disabilities can interact seamlessly with web pages. Thank you for joining us in today’s discussion.
If you found this video helpful, please like and subscribe for more accessibility insights.
This success criterion conveys that change of context should not occur while user is trying to input data. For example, if the user is filling a form & if the page refreshes while selecting an option in <select> element or if the form submits after the user fills in the last form field, it fails this checkpoint. User should be provided with an option to submit the form by providing a submit button or hint/instruction should be provided for all users informing that form will submit once the form fields are filled
Exceptions
There are some exceptions to this success criterion. Change of content is not change of context. For example if a radio button is selected & if it triggers more form controls it is not change of context. Here content is updating. Activating links, buttons or tab controls doesn’t fall into on input category. Here is user is taking deliberate action to trigger these form controls…
In the documentation for understanding this guideline, focus is listed under “change of context” in the Key Terms section.
https://www.w3.org/TR/UNDERSTANDING-WCAG20/consistent-behavior-unpredictable-change.html
Does this mean that if you submit a form to filter results, if the page refreshes and the user has lost focus, that this would classify as a change in context?
Thanks so much!
Hello Monique,
There is a lot of difference between change of context & change of content. Change of content is not failure of this SC, if you submitted a form using the submit button & page refreshes then it’s not a failure. But if you selected a checkbox or a radio button option & page refreshed then its failure of this SC. Hope this is helpful.
Hi Raghav,
If I Describing what will happen before I make a selection for the radio button/ Checkbox, would that be considered as success criteria?
E.g. Selecting a radio button/ checkbox will move over to the next question something like that. (No submit buttons)
Hi Jahnvi,
Yes, if you can provide the instruction visually & let all the user groups know that a change of context will trigger when an option is selected then it passes this checkpoint.
Good Work friends.