Elements do not change when they receive input

If you want your users to return to your website, make sure it acts as users expect it to.

When a form receives input from users (for example, typing in an address or selecting a date of birth), it must not automatically skip to another field or auto-submit – known as ‘changing on input’. This can disorientate users.

Only submit form data when a user chooses to click a submit button. It’s common sense behaviour, but if you get it wrong, your users will be frustrated and leave.

What to do

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).


The easiest way to pass Guideline 3.2.2 is to use submit buttons and avoid jumping your users between fields. It’s all about leaving the control in your users’ hands, where it belongs.


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.

See also

Free Developer Resources

Join over 3,700 subscribers on my weekly web accessibility email and get free developer resources like WCAG Checklists and special offers.

Powered by ConvertKit

Over 600 developers like you have learned more about the Web Content Accessibility Guidelines with my guidebook.

Learn more >

About Author

I'm Luke, I started Wuhcag in 2012 to help people like you get to grips with web accessibility. Check out my book, 'How to Meet the WCAG 2.0'.

2 comments on “3.2.2 – On Input (Level A)

    Priya K says:

    Hi Luke,

    In most application forms, new block of content appears or an existing block of content disappears when user selects/deselects a checkbox.

    Displaying the entire form fields upfront might be heavy to user (even if we divide them into sections). And based on user input if some fields are not required we have to disable them midway of form entry.

    What is the alternate for this?

      Luke McGrath says:

      Hey Priya,

      Best way is to break the form up as much as you can. However, forms expanding as required doesn’t necessarily need to fall foul of this guideline as what you’re describing doesn’t mean the form is submitting or skipping to the next field.


Leave Comment