accessibility-guidelines

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

Back to the overview page

Error identification

When someone makes a mistake filling in a form:
→ Clearly identify where the error is, and describe it in text.

When a form validation error occurs, the user is informed of where the error is, and what caused it, using text.

---

On this page:

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

---

Requirements

• Each form validation error is described with text, and the form input that is in error is in error is clearly identified;
• The error messages clearly and accurately explain the errors that have occurred;
• Each form validation error is associated with the input field it relates to.

Common mistakes

• An error is only indicated by an icon near to the field;
• An error is described with text, but it is not associated in code with the field it relates to.

Why?

This ensures that the form validation error is available to people who cannot see, distinguish colours, or understand icons and other visual cues.

Clear error messages help everyone to input and interact with content correctly. It is important to provide inclusive error messages that users of assistive technology can perceive. Keep in mind that not everyone sees visual cues, such as colour or icons. And people with cognitive impairments may have difficulty in understanding how to correct errors.

Official wording in the Web Content Accessibility Guidelines

3.3.1 Error Identification: If an input error is automatically detected, the item that is in error is identified and the error is described to the user with text. (Level A)

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

---

Guidance for Design

For example, when a form is submitted:

1. a list of all fields needing correction could be added in above the form;

2. that list could be announced to screen reader users, either by:

   • moving the keyboard focus to that error summary box,
   • or by making that error summary box a ‘live’ region that announces when its content changes;

3. form inputs that are in error are identified both visually (using than colour alone) and in code (using aria-invalid for example).

More guidance for design

• Error Message component and guidance in the GDS Design System
• Error Summary component and guidance in the GDS Design System

---

Guidance for Web

Associating an error with a text input field using aria-describedby

<label for="national-insurance-number">
  National Insurance number
</label>

<span id="national-insurance-number-hint">
  It’s on your National Insurance card, benefit letter, payslip or P60. For
  example, ‘QQ 12 34 56 C’.
</span>

<input
  id="national-insurance-number"
  name="national-insurance-number"
  type="text"
  aria-describedby="national-insurance-number-hint national-insurance-number-error"
/>

<span id="national-insurance-number-error">
  <span class="visually-hidden">Error:</span> Enter a National Insurance number
  in the correct format
</span>

More guidance for Web

• Error Message component and guidance in the GDS Design System
• Error Summary component and guidance in the GDS Design System
• Validating user input tutorial by the W3C’s Web Accessibility Initiative.
• User Notifications in Forms tutorial by the W3C’s Web Accessibility Initiative.
• Basic form hints article on MDN.
• Using aria-describedby to provide form hints by Léonie Watson and The Paciello Group.
• Practical Support: aria-label, aria-labelledby and aria-describedby section in the W3C’s Using ARIA document.

---

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.