accessibility-guidelines

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

Back to the overview page

Error identification

On this page:

• Summary
• Requirements
• Guidance for Design
• Guidance for iOS
• Guidance for Android
• Guidance for Flutter
• Guidance for Web
• More info

---

Summary

When someone makes an error while filling in a form, describe the error with text and clearly identify where the error is.

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

---

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

This section needs more content. Contribute via Github or email.

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 iOS

This section needs more content. Contribute via Github or email.

---

Guidance for Android

You can use a live region in order to send a new AccessibilityEvent to the current enabled Accessibility Service on view updates. This means that any service like TalkBack will pay attention to any changes in that View and will automatically announce them.

To do so, you can easily mark any View as a live region in your XML file by adding the accessibilityLiveRegion attribute:

<View
  ...
  android:accessibilityLiveRegion="polite"
  .../>

Options for this attribute are the following:

• none: Accessibility services should not announce changes to this view.
• polite: Accessibility services should announce changes to this view.
• assertive: Accessibility services should interrupt ongoing speech to immediately announce changes to this view.

Carefully consider when to use live regions, as announcements for frequently changing views can be disruptive and annoying. Live regions can easily be overused, especially when you’re just starting out with accessibility. Live regions are the exception, not the rule.

---

Guidance for Flutter

This section needs more content. Contribute via Github or email.

---

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.