A11y 101 – 3.2.2 On Input

Last updated on June 22, 2026

You’re filling out your taxes. Your cursor lands in the first field. You start typing. And halfway through entering your email address—whoosh!—the form submits automatically.

Now you’re looking at an error page because you didn’t finish. Or worse, you submitted incomplete data and lost what you had typed. Your screen reader says something confusing. You have to start over.

Here’s the spec in plain language:

When any component causes a change in the user interface context, there must be a way for the user to control when that change happens.

If a user makes an input change (typing into a field, selecting from a dropdown), the system shouldn’t act immediately unless:

1. The user explicitly confirms the action, OR
2. The user has been warned that input will trigger an action, AND given clear instructions on how to avoid triggering it, AND a mechanism to undo or correct after submission.

In practice, that means autocomplete suggestions, live search results, or dynamic filtering can happen—but the actual change of context (page reload, navigation, data submission) should wait for user confirmation.

This even extends to the use of arrows without opening a select. Placing an onChange event means with every arrow down or up, the interface changes.

This isn’t edge case territory. This is core accessibility.

The “Auto-Submit” Trap

This one trips up teams regularly. It’s subtle. It feels “smart.” It’s not.

Some patterns that fail this criterion:

• Search-as-you-type: Every keystroke triggers a full page refresh with filtered results. The user never gets to finish typing their query.
• Dynamic form validation: As soon as focus leaves a field, the form attempts to validate or submit, regardless of whether other fields are complete.
• Autocomplete selection: Choosing from a suggestion list submits the form instead of just populating the field.
• Multi-step workflows: Entering one piece of data advances to the next step without letting the user review or confirm.

Agency

I’ll be blunt: this is about giving users agency.

People using assistive technologies often navigate slowly. Screen reader users hear content sequentially. Keyboard-only users tab through forms methodically. Someone with motor impairments might take extra time to type each character.

When the page assumes speed and completes actions on their behalf, you’ve created a race they can’t win.

For cognitive disabilities, this is especially critical. If the interface changes while someone is still processing what they see, working memory breaks down. Instructions become irrelevant. Tasks become impossible.

This isn’t edge case territory. This is core accessibility.

The Fix Is Simple (Mostly)

The solutions are straightforward, though implementation varies by use case:

• Wait for Enter/Return: Don’t submit until the user presses Enter or clicks a visible submit button.
• Defer Validation: Validate individual fields when appropriate, but don’t trigger form submission until the user confirms.
• Use Debouncing: For live search/filtering, wait for a pause in typing before querying.
• Add Confirmation Steps: For destructive or irreversible actions, require explicit confirmation before proceeding.

<!-- Bad: Submits on every keystroke -->
<input type="text" onchange="form.submit()">

<!-- Good: Submits only on explicit button click -->
<input type="text" id="search">
<button type="submit">Search</button>

Sometimes all it takes is waiting for the event handler to fire.

Be People-First

When we design interfaces that act automatically on input, we’re making a choice. We’re deciding that efficiency matters more than control. We’re saying “We know better than the user when they’re ready to proceed.”

That’s arrogance disguised as convenience.

The user knows when they’re done. Our job is to wait for them to say so.

3.2.2 is about respect. It’s about recognizing that everyone works at different speeds. Different rhythms. Different needs.

Don’t let your interface guess when someone is finished. Give them the button. Give them the command. Give them the choice.

They’ll hit it when they’re ready. Not before.

Want to discuss this? Find me on LinkedIn and BlueSky!