You are currently viewing Success Criterion 3.2.2 – On Input

Success Criterion 3.2.2 – On Input

This success criterion improves accessibility by preventing unexpected context changes and giving users control of their web experiences.

WCAG Principle: Understandable

Guideline 3.2: Predictable (Make Web pages appear and operate in predictable ways)

Conformance Level: A (Minimal Requirement)

What is Success Criterion 3.2.2?

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.

This guideline ensures that when users interact with form controls—like typing in a text field, checking a box, or selecting an option—it does not automatically trigger unexpected changes in context. A “change in context” is anything that disrupts the user’s experience, like navigating to a new page, opening a new window, or major content change.

For instance, selecting an option from a dropdown menu should not reload the page or redirect the user without warning. Instead, changes should only happen when users clearly signal their intent, such as by clicking a submit button.

It’s important to understand how this differs from Success Criterion 3.2.1 (On Focus). “On Focus” is about what happens when an element receives focus—like when you tab to a dropdown or a text input field. Nothing disruptive should happen simply because focus lands on the element. “On Input,” however, refers to what happens when a user changes the actual value of that element—for example, when they type in a text box or select an option.

These two criteria complement each other to prevent disorienting or unexpected actions. This ensures that users, especially those who rely on keyboard and assistive tools, experience predictable and controlled interactions.

How to Meet Success Criterion 3.2.2

Common mistakes on websites:

  • Selecting an option in a dropdown menu immediately reloads the page or navigates to a new location.
  • Forms automatically submit when users type in a text field or check a box without explicit user confirmation.
  • Changing a setting, like selecting a radio button, causes a new window or popup to open unexpectedly.
  • Adjusting a form control dynamically updates large portions of the page, confusing users who aren’t expecting it.
  • Developers tie navigation or major actions to ‘onchange’ events without requiring additional confirmation, like a submit button.

How to fix mistakes:

  • Trigger actions only on confirmation using a submit button or an explicit user action, like a click or key press.
  • Replace ‘onchange’ events with a submit button. This allows users to confirm their selection before any changes happen.
  • If opening a new window is necessary, warn users in advance using visible text like “opens in a new window.”
  • If dynamic updates are essential, inform users beforehand and ensure only small, relevant parts of the page update.
  • Navigate through forms and dropdowns using only the keyboard and verify no unexpected actions occur until users confirm their input

Helpful tips for developers:

  • Do not tie significant actions, like navigation or form submissions, directly to ‘onchange’ or ‘oninput’ events. Instead, require a clear user confirmation, such as pressing a button.
  • If an input must trigger a change, provide a clear notification. Notify users in advance about actions like reloading a page or updating content.
  • Ensure focus behavior is predictable after input. Focus should remain in place, and automatic shifts should happen only when absolutely necessary.
  • Test all form controls—text fields, radio buttons, checkboxes, and dropdown menus—to ensure they behave predictably. Confirm that no action occurs without explicit user input.

How to test if your site meets conformance

  • Go through your website and list all form controls that allow users to input or select information.
  • Change the value of each control, such as typing in a text box, selecting an option in a dropdown, or checking a box. Watch for any unexpected actions, like page reloads, form submissions, or new windows opening automatically.
  • Ensure that significant actions, like submitting a form or navigating to a new page, only happen after explicit user input, such as pressing a button or clicking a link.
  • When a control updates part of the page, ensure focus remains logical and doesn’t shift unexpectedly to a new location.
  • If an action must occur immediately when input changes—such as updating part of the page—verify there’s a clear message informing users beforehand.
  • Use screen readers or keyboard navigation to interact with the inputs. Confirm that behavior remains predictable and no changes occur without user intent.
  • Interact with form controls on desktop, tablet, and mobile devices to ensure the behavior remains consistent and accessible.

Bad and Good Examples of On Input (Code Snippets)

Code example that fails success criterion 3.2.2

Code Snippet

<label for="language">Choose your language:</label>  
<select id="language" onchange="window.location.href=this.value;">  
  <option value="#">Select Language</option>  
  <option value="/en">English</option>  
  <option value="/es">Español</option>  
</select>

Consider the example above. When the user selects a language from the dropdown, the page immediately redirects to the chosen language’s page. This can be disorienting because the user doesn’t have time to confirm their choice. 

Next, see a more conformant example below. 

<label for="language">Choose your language:</label>  
<select id="language">  
  <option value="#">Select Language</option>  
  <option value="/en">English</option>  
  <option value="/es">Español</option>  
</select>  
<button onclick="changeLanguage()">Confirm</button>  

<script>  
  function changeLanguage() {  
    const language = document.getElementById('language').value;  
    if (language !== "#") {  
      window.location.href = language;  
    } else {  
      alert("Please select a language before proceeding.");  
    }  
  }  
</script>

In this revised version, the user selects a language but nothing happens until they click the “Confirm” button. This approach ensures the user has time to review their choice and prevents accidental redirection while exploring the dropdown. It’s especially helpful for keyboard and assistive technology users who need predictable navigation.

Frequently Asked Questions

How is “On Input” different from "On Focus"?

“On Focus” applies when an element receives focus while “On Input” applies when a user actively changes the value of that element. In other words, the former ensures changes are intentional and the latter prevents disruptions from simply landing on an element.

What qualifies as a change in context?

A change in context includes significant actions like navigating to a new page, opening a new window, or reloading large portions of the page. Minor content updates, like showing or hiding additional fields in a form, are not considered context changes as long as they are predictable.

Can I still dynamically update content based on user input?

Yes, but the updates should not disrupt the user experience. For example, dynamically filtering search results is fine as long as users can navigate easily and are informed about the update (e.g., using ARIA live regions for screen readers).

Does this criterion apply to mobile devices as well?

Yes. On mobile devices, ensure that changes triggered by user input behave predictably and give users enough time to confirm actions. Test dropdowns, text fields, and other controls for consistent behavior across all devices.

Ready To Meet
WCAG Compliance?

Leave a Reply