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)

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.

Why is it important?

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.

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.

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.

Design Guide

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

Error Identification Example 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.

Error Identification Example 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>

References

1. Error Message component and guidance in the GDS Design System
2. Error Summary component and guidance in the GDS Design System
3. Validating user input tutorial by the W3C’s Web Accessibility Initiative.
4. User Notifications in Forms tutorial by the W3C’s Web Accessibility Initiative.
5. Basic form hints article on MDN.
6. Using aria-describedby to provide form hints
7. Practical Support: aria-label, aria-labelledby and aria-describedby section in the W3C’s Using ARIA document.
8. Accessibility Guidelines- Github.io