accessibility-guidelines

This document is in beta. Help us by reporting issues via Github or email.

Back to the overview page

Changes on input

Just changing the state of a form input (like a checkbox) must not cause anything surprising to happen (like submitting a form, significantly changing the content on the page, or moving the keyboard focus).

---

On this page:

• Requirements
• Guidance for Design
• Guidance for Web
• More info

---

Requirements

Changing the state of any user interface component (like a dropdown or a checkbox) must not automatically cause unexpected changes of context such as the following – unless the user has been advised of what was going to happen beforehand:

• automatically loading a new page;
• submitting a form;
• moving the keyboard focus somewhere else;
• significantly changing the content of the page.

Such changes only occur when initiated by the user (e.g. upon activation of a button or link).

Common mistakes

• As soon as a user has entered a certain number of characters in a text input field, automatically moving the keyboard focus to the next text input field. (This often happens for things like bank sort codes, National Insurance or phone numbers, when the numbers need to be entered across several text input fields).

• Moving the user to a new page as soon as they’ve selected an option in a select element (which is the native dropdown component in HTML).

Why?

It can be disorienting and hinder users from verifying information or correcting mistakes if the focus automatically changes when the user is not expecting it

• For example, moving to the next control or to a validation error message during input.
• Screen reader users in particular do not want the keyboard focus to be moved when they don’t expect it, as it is confusing and disorientating.

It’s disorientating and confusing if the content of the page changes when users don’t expect it

• Screen reader users and people with low sight might not notice that something in the page has changed, if they don’t expect it.

Keyboard-only users and screen reader users navigate through radio buttons and options of dropdown menus one by one

With some Operating Systems and some implementations of radio buttons and dropdowns, this can cause each option to become selected in turn.

Official wording in the Web Content Accessibility Guidelines

3.2.2 On Input: 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. (Level A)

See the W3C’s detailed explanation of this guideline with techniques and examples.

---

Guidance for Design

For input fields

• Don’t design interactions where entering a certain number of characters in a text field automatically moves the keyboard focus to another text field, unless users have been told beforehand.

  If you want users to input things like phone numbers, National Insurance numbers or bank sort codes across several input fields, set a limit to the number of characters that each field can receive and let the users move the keyboard focus manually to each input field.

For forms with radio buttons

• Don’t design interactions where just ticking a radio button triggers any of the following:
  • navigation to another page;
  • users to be taken to the next step of a process;
  • disorientating changes on the page, like the radio buttons group to disappearing.

For navigation

• Use links for navigation menus, rather than the Operating System / web browser’s pre-built dropdown elements, unless there is another confirmation step.

---

Guidance for Web

• See the Guidance for Design section as well.

Do not use select elements as navigation menus

• Do not use HTML select elements as a navigation menu, unless changing the value of the select element doesn’t automatically trigger navigation.

Do not move keyboard focus to the next control or to a validation error message during input

• Do not automatically move the keyboard focus when users have entered a certain number of characters in an input field.
• If you’re validating form fields before users trigger a submit event (for example if you’re validing on an input field’s blur event), make sure that the validation script does not move the keyboard focus.

Doing better

• It’s better to validate forms on submit events. Submitting on blur events leads to confusing announcements for screen reader users.

More guidance for Web

• Failure due to automatically submitting a form and presenting new content without prior warning when the last field in the form is given a value in the W3C Web Content Accessibility Guidelines
• Failure due to launching a new window without prior warning when the selection of a radio button, check box or select list is changed in the W3C Web Content Accessibility Guidelines

---

More info

Sources

• W3C Web Content Accessibility Guidelines 2.1
• Government Digital Service WCAG 2.1 Primer
• Barclays’ Accessibility Design Standards
• The BBC’s Mobile Accessibility Guidelines

Contribute

This document is in beta. Help us by reporting issues via Github or email.

This site is open source. Improve this page.