WCAG 3.2.2 On Input — Testing Guide for Mobile & Web Apps

WCAG 3.2.2, "On Input," is a crucial accessibility guideline. It mandates that a change of context should not occur simply because a user provides input to a form control. This means that actions like

Ensuring WCAG 3.2.2 (On Input) Compliance for Accessible Applications

WCAG 3.2.2, "On Input," is a crucial accessibility guideline. It mandates that a change of context should not occur simply because a user provides input to a form control. This means that actions like typing into a field or selecting an option should not automatically trigger a new page load, a significant content change, or a focus shift without the user explicitly confirming the action.

What WCAG 3.2.2 Requires (In Plain English)

Essentially, this criterion states: Don't surprise users with unexpected changes.

When a user interacts with a form element (like a text box, dropdown, or checkbox), the application should not automatically perform a significant action just because the user entered data or made a selection. The user should be in control of when a change of context happens.

A "change of context" includes:

• Opening a new window or tab.
• Moving the focus to a different component.
• Programmatically invoking a change of state (e.g., submitting a form, expanding a section).

The only exceptions are when the user is explicitly warned about the impending change and has a way to prevent it, or when the change is essential to the functionality of the component (e.g., a search input that instantly shows results as you type, but the user can still see the original page).

Why It Matters: Real User Impact

This guideline directly impacts users who rely on assistive technologies or have cognitive disabilities.

• Screen Reader Users: An unexpected context change can disorient screen reader users. They might lose their place, miss important information, or struggle to navigate back to where they were. Imagine a user filling out a form, and suddenly the screen reader announces a new page loaded, making it difficult to complete the original task.
• Users with Cognitive Disabilities: Unpredictable changes can be confusing and overwhelming. Users might become frustrated, abandon the task, or make errors if the interface behaves in ways they don't anticipate.
• Users with Motor Impairments: If a change of context occurs unintentionally, users who have difficulty with precise control might accidentally trigger it, leading to a frustrating experience.
• All Users: Even users without disabilities can be annoyed by unexpected behavior. It disrupts their workflow and can lead to errors.

Adhering to 3.2.2 is not just about compliance; it's about creating a predictable and user-friendly experience for everyone. This is a core expectation for applications seeking to meet EU EAA (European Accessibility Act) and ADA (Americans with Disabilities Act) requirements.

Common Violations with Examples

Here are typical scenarios where WCAG 3.2.2 is violated:

#### Mobile App Examples:

1. Auto-Submitting Search Forms:

• Violation: A user types a search query into a text field. As soon as the user stops typing (or after a short delay), the app automatically navigates to the search results page without the user pressing a "Search" button or hitting "Enter."
• Impact: The user might not have finished their query or might have made a typo. They are forced to see results for an incomplete or incorrect search, and then must navigate back to correct it.

1. Dropdowns Triggering Navigation:

• Violation: A user selects an option from a <select> element (a dropdown menu) in a form. The act of selecting the option immediately loads a new page or updates a large section of the current page without a confirmation step.
• Impact: The user might have intended to select the option but not yet finalize the form submission. The unexpected navigation can lead to confusion and lost progress.

1. Interactive Elements Opening New Views Unprompted:

• Violation: On a product listing screen, tapping an image or a product title automatically opens the product detail page. While this might seem intuitive, it violates 3.2.2 if the user intended to simply view or interact with the listing further.
• Impact: The user might have wanted to compare multiple products, add items to a wishlist, or perform another action on the listing page. The immediate navigation forces them to go back and forth.

#### Web App Examples:

1. Form Field Focus Changes Triggering Actions:

• Violation: A web form has a field. When the user clicks into this field, it automatically triggers a JavaScript event that changes the state of another element on the page or navigates away.
• Impact: The user might be trying to enter data, not initiate an action. This can be particularly disorienting for users relying on keyboard navigation.

1. Automatic Form Submission on Input Change:

• Violation: A user is filling out a multi-step registration form. When they enter their email address and move to the next field, the application automatically submits the current step without the user clicking a "Next" or "Continue" button.
• Impact: The user might have intended to review their input or make changes before submitting. The unsolicited submission can lead to errors if the email is incomplete or incorrect.

How to Test for Compliance

#### Manual Testing Steps:

1. Identify Form Controls: Locate all input fields, select elements, checkboxes, radio buttons, and any other interactive elements designed for user input.
2. Interact with Controls: For each identified control, perform common input actions:

• Type characters into text fields.
• Select options from dropdowns.
• Check/uncheck checkboxes.
• Select radio buttons.
• Click buttons that are part of a form.

1. Observe for Unexpected Changes: After each interaction, carefully observe:

• Does the page reload?
• Does a new window or tab open?
• Does the focus automatically shift to a different element without user initiation?
• Does a significant portion of the content change without explicit user confirmation (e.g., pressing a submit button)?

1. Check for Warnings/Confirmation: If a change of context *does* occur, ensure there was a clear warning or an explicit confirmation step that the user could interact with.
2. Test with Different User Personas:

• Novice/Elderly: Can they easily understand what is happening? Are they likely to be surprised?
• Impatient/Power User: Do they expect immediate feedback? Does the current behavior hinder their efficiency?
• Adversarial: Can they intentionally trigger unexpected changes to break the flow?

#### Automated Tools for Checking:

While manual testing is crucial for understanding user intent, automated tools can flag potential issues:

• Browser Developer Tools: Inspect network requests and DOM changes after input. Look for unexpected page loads or significant DOM manipulations.
• Accessibility Checkers (Browser Extensions): Tools like axe DevTools, WAVE, and Lighthouse can sometimes flag dynamic content changes or focus management issues that might relate to 3.2.2, although they might not always catch the nuanced "change of context" aspect directly.
• Static Code Analysis: Linters and security scanners can sometimes identify patterns that might lead to unsolicited context changes, especially if they rely on certain JavaScript event handlers.

#### Mobile-Specific Considerations (Android/iOS):

• Focus Management: On mobile, ensure that tapping an input field doesn't immediately dismiss the keyboard and change focus in a way that disrupts the user's input flow.
• Screen Transitions: Be mindful of how selecting an item in a list or a dropdown navigates the user. Ensure there's a clear "back" action or a confirmation if the transition is significant.
• Native UI Components: Developers often use native UI components. Test how these behave. For example, a native Picker in iOS or Spinner in Android should not trigger a new screen upon selection of an item.

How to Fix Violations

The primary fix is to defer actions until the user explicitly confirms them.

#### Web App Fixes:

• Use Explicit Buttons: Instead of submitting a form or changing context when an input changes, add clear buttons like "Search," "Submit," "Apply Filters," or "Next."
• JavaScript Event Handling: Ensure that event listeners for input changes do not trigger navigation or major state changes directly. Instead, they should update UI elements or store data temporarily. Use event.preventDefault() where necessary to stop default browser actions.
• Debouncing/Throttling for Live Search: If you want live search suggestions, implement debouncing or throttling on the input event. This means the search API is only called after the user has stopped typing for a brief period, and the results are displayed *below* the search bar, not by navigating away.
• Confirmation Dialogs: For critical actions triggered by input (e.g., deleting an item), use a confirmation dialog.

Example (Web - preventing auto-submit):

// Instead of this (bad):
const searchInput = document.getElementById('search');
searchInput.addEventListener('input', () => {
  window.location.href = `/search?q=${searchInput.value}`; // Auto-navigates
});

// Use this (good):
const searchInput = document.getElementById('search');
const searchButton = document.getElementById('search-button');

searchButton.addEventListener('click', () => {
  window.location.href = `/search?q=${searchInput.value}`; // Navigates only on button click
});

// Or for live search suggestions without navigation:
let searchTimeout;
searchInput.addEventListener('input', () => {
  clearTimeout(searchTimeout);
  searchTimeout = setTimeout(() => {
    // Fetch and display suggestions below the input field
    displaySuggestions(searchInput.value);
  }, 300); // Wait 300ms after user stops typing
});

#### Mobile App Fixes:

• Button-Triggered Actions: For form submissions or navigation initiated by user input, ensure a dedicated button is pressed.
• Clear Navigation Flow: When selecting an item from a list or dropdown that *should* navigate, ensure there's a clear visual cue and an accessible "back" button to return.
• Avoid Ambiguous Gestures: Be cautious with gestures that might be misinterpreted as navigation commands.

How SUSA Checks This Criterion

SUSA's autonomous QA platform inherently tests WCAG 3.2.2 through its exploration and persona-based testing.

• Autonomous Exploration: SUSA uploads your APK or web URL and begins exploring your application as a user would. It interacts with all visible form controls and input elements.
• Persona-Based Dynamic Testing: SUSA employs 10 distinct user personas, including "Novice," "Elderly," and "Impatient" users. These personas simulate different interaction styles and expectations.
• When SUSA, acting as a "Novice" or "Elderly" persona, types into a field and the app