Elements do not change when they receive input.

Introduction

As we saw with On Focus, all users need predictability when navigating a website. If elements don’t act as they expect, they may become disorientated. 

This is also true when elements receive input, they shouldn’t automatically change. For example, forms shouldn’t skip to another field or auto-submit without confirmation from the user.

A change on input is especially troublesome for users who navigate by keyboard, as well as those with visual disabilities or cognitive limitations. 

How to Pass

Ensure no elements change on input.

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

Exceptions

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 if it’s clear from the text before the element what will happen when you input.

Tips

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

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 “On Input (3.2.2 – 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?

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

      Reply

Leave Comment