Loading content...
Loading content...
Changing a setting (like a checkbox) shouldn't unexpectedly change the page context.
Why it matters: Users need to be in control of context changes.
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.
What This Means: This success criterion requires that changing the setting of a user interface component (like selecting an option from a dropdown, checking a checkbox, or changing a radio button) does not automatically cause a change of context (like navigation or form submission) unless users have been clearly warned about this behavior before they interact with the component.
Why It's Important: Unexpected context changes when users interact with form controls can be disorienting and cause users to lose their place or accidentally trigger actions they didn't intend. Users should be in control of when navigation or other major changes occur. If a control will cause a context change, users must be clearly informed beforehand.
Remove automatic navigation or form submission when users change form control settings. If automatic context changes are necessary, provide clear, visible warnings before users interact with the control. For example, a language selector dropdown should not automatically navigate to a new page unless users are clearly warned. Instead, provide a 'Go' button or clearly indicate that selection will navigate.
This criterion ensures that users with cognitive disabilities can access and understand the content, improving their overall experience and ability to use the website effectively.
This criterion ensures that screen reader users can access and understand the content, improving their overall experience and ability to use the website effectively.
Impact: When this criterion is properly implemented, it removes barriers for these user groups and creates a more inclusive web experience for everyone.
Changing a select dropdown automatically navigates to a new page without warning.
<select onchange="window.location = this.value"><option value="/page1">Page 1</option></select>Select dropdown has clear label indicating it will navigate, and navigation occurs on change.
<label>Select page to navigate: <select onchange="window.location = this.value"><option value="/page1">Page 1</option></select></label>This success criterion benefits the following user groups:
Tip: Use this checklist during development and testing to ensure all requirements for 3.2.2 On Input are met. Check off items as you complete them.
To meet this success criterion, ensure the following requirements are met:
While meeting the minimum requirements ensures compliance, consider these enhancements for a better user experience:
If I add a label saying 'this will navigate', that's enough warning.
While warnings help, it's better practice to avoid automatic navigation entirely. Require explicit user action (like a 'Go' button) for navigation.
Auto-submitting forms on select change is convenient.
Auto-submission can cause data loss and confusion. Always require explicit form submission via a submit button.
Select dropdowns that automatically navigate on change.
Remove automatic navigation. Add a 'Go' or 'Submit' button that users must click to navigate. Or clearly warn users that selection will navigate.
Checkboxes or radio buttons that auto-submit forms.
Remove auto-submission. Require users to click a submit button to submit forms. Auto-submission can cause accidental submissions.
Form controls that trigger context changes without warning.
Either remove automatic context changes, or provide clear, visible warnings before users interact with the control.
Note: These are official W3C resources for 3.2.2. For the most up-to-date information and detailed technical guidance, always refer to the official W3C documentation.
Implementing 3.2.2 On Input correctly requires understanding your specific context. Code solutions vary significantly based on multiple factors:
HTML, React, Vue, Angular, PHP, Python, and other frameworks each have different patterns and best practices.
Server-side rendering, client-side rendering, static generation, and hybrid approaches require different solutions.
Your existing components, styling approach, and UI library influence how accessibility must be implemented.
Your specific user base, content type, and interaction patterns determine the most appropriate implementation.
We provide tailored implementation guidance by analyzing your specific technology stack, coding patterns, design system, and project requirements. Our team reviews your codebase and provides custom solutions that integrate seamlessly with your existing architecture.
Get Custom Implementation HelpPart of
Understandable PrincipleGuideline
3.2 Predictable