Changing the setting of any user interface component does not automatically cause a change of context unless the user has been advised of the behaviour before using the component.
Accessibility Requirements for 3.2.2 On Input (A)
- Users can predict what a control such as a button or drop-down menu will do
Common mistakes for 3.2.2 On Input (A)
- Form controls are used to trigger navigation without an explicit submit step, and without warning
The following are common mistakes that are considered failures of Success Criterion 3.2.2 by the WCAG Working Group.
- F36: Failure of Success Criterion 3.2.2 due to automatically submitting a form and presenting new content without prior warning when the last field in the form is given a value
- F37: Failure of Success Criterion 3.2.2 due to launching a new window without prior warning when the selection of a radio button, check box or select list is changed
FAQs for On Input (A)
What to do to ensure website Input are user accessible?
Here are some examples of the kinds of things to look out for:
Forms must not auto-submit when all fields are filled – this prevents your users from checking and editing what they have written.
Focus (the field where the user will input next) must not automatically jump to the next field in a form once a field is complete.
Using a control (like selecting yes or no) must not automatically perform the action (for example, selecting to subscribe to a newsletter in a check box must not automatically subscribe your user, they should be able to click a submit button to confirm their decision).
What is the purpose of On Input?
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
What are the exceptions of this guideline?
Elements can change on input if you inform the user of the change before they have the chance to input their data or make their selection. For example, you may have seen websites with options in the header to choose a text size. Once you click on the size you want, the website changes without giving you the chance to confirm your choice.
Controls like that don’t need to have a submit button, as long as it’s clear from the text before the element what will happen when you input.
Tips for this guideline.
Make sure that forms don’t submit on input of data.
Make sure that focus doesn’t move to next form control once a form field is populated with data.
Provide a submit button for all forms.
Make sure that control of how data is populated is in the hands of your users.
If there is a change of context, then provide an instruction that is available for all user groups.