Error, Alert and Status Messaging, Instructions and Help Text

Owned by Christina Lutz-Hatfield
Last updated: Sept 11, 2024
9 min read

 

Table of Contents

Overview

Help users avoid and and correct mistakes.

Make sure that error and alert messages are accessible to screen reader and keyboard only users. 

People who are blind or have low vision need non-visual instructions.

Ensure that instructions provided for understanding and operating content do not rely solely on sensory characteristics of components such as shape, color, size, visual location, orientation, or sound.

Provide users with adequate time to correct errors. For example form related errors.

Provide help to users on the function currently being performed.

Make users aware of important changes in content that are not given focus, and to do so in a way that doesn't unnecessarily interrupt their work.

Ensure that help text and custom tooltips that display on hover and focus are dismissible, hoverable and persistent.

Present instructions or labels that identify the controls in a form so that users know what input data is expected.

Help Users Avoid and Correct Mistakes

Identify Errors

Provide descriptive notification of errors.

Flagging errors helps people with reduced sight and cognitive disabilities resolve them.

Ensure that users are aware that an error has occurred and can determine what is wrong. In the case of an unsuccessful form submission, it is not sufficient to only re-display the form without providing any hint that the submission failed.

An "input error" is information provided by the user that is not accepted. This includes:

  • information that is required by the web page but omitted by the user, or

  • information that is provided by the user but that falls outside the required data format or allowed values.

For example:

  • the user fails to enter the proper abbreviation in a state, province, or region field;

  • the user enters a state abbreviation that is not a valid state;

  • the user enters a non existent zip or postal code;

  • the user enters a birth date 2 years in the future;

  • the user enters alphabetic characters or parentheses into their phone number field that only accepts numbers;

  • the user enters a bid that is below the previous bid or the minimum bid increment.

Please see more detailed information on how to comply with the guideline.

Prevent Errors

Provide ways for users to confirm, correct, or reverse important submissions.

People with disabilities may be more likely to make mistakes, or not notice them.

Help users with disabilities avoid serious consequences as the result of a mistake when performing an action that cannot be reversed.

Providing the ability to reverse actions allows users to correct a mistake that could result in serious consequences.

Providing the ability to review and correct information gives the user an opportunity to detect a mistake before taking an action that has serious consequences.

For web pages that cause legal commitments or financial transactions for the user to occur, that modify or delete user-controllable data in data storage systems, or that submit user test responses, at least one of the following should apply:

  • Submissions are reversible.

  • Data entered by the user is checked for input errors and the user is provided an opportunity to correct them.

  • A mechanism is available for reviewing, confirming, and correcting information before finalizing the submission.

Please see more detailed information on how to comply with this guideline.

Provide Error Suggestions

Provide appropriate suggestions on how to correct an input error.

Ensure that users receive appropriate suggestions for correction of an input error if it is possible.

The definition of "input error" is "information provided by the user that is not accepted" by the system.

Some examples of information that is not accepted include information that is required but omitted by the user and information that is provided by the user but that falls outside the required data format or allowed values.

People with cognitive limitations may find it difficult to understand how to correct the errors.

People with visual disabilities may not be able to figure out exactly how to correct the error. In the case of an unsuccessful form submission, users may abandon the form because they may be unsure of how to correct the error even though they are aware that it has occurred.

Please see more detailed information on how to comply with this guideline.

General Error Message Guidelines

Provide labels or instructions when content requires user input.

Ensure that data entered by the user is checked for input errors and the user is provided an opportunity to correct them.

Do not rely on color alone to convey the error or alert message when something is not completed correctly or missing. 

Provide a description and the nature of the error message and how to correct it. Example: “Please provide the correct date of birth. The primary applicant must be 18 years of age or older”. 

Declare form controls as invalid and display inline error messages once the form control has lost focus, or there has been an adequate delay in key presses (a few seconds).

Describe controls by name, not just by appearance or location.

Please see more details on how to comply with these guidelines.

Using ARIA to Create Accessible Inline Error Messages

Make inline error messages accessible to screen reader users by adding ARIA labels.

  • Most screen reader and browser combinations announce a form control as “required” when using the required attribute.

  • Prevent screen readers from announcing required form controls as invalid by default, by using aria-invalid="false".

  • Update the aria-invalid attribute to “true” if the current value (or lack of value) of a required control does not pass validation.

  • Wait to declare form controls as invalid and display inline error messages once the control has lost focus, or there has been an adequate delay in key presses (a few seconds)

  • Use aria-describedby on required form controls to point to an element that will contain any necessary inline error messaging.

  • Can’t always rely on browser’s client-side error validation to be accessible.

  • Create a custom client-side validation script and helpful messaging by suppressing the browser’s default validation message by adding the novalidate attribute to the  form element. 

CODE EXAMPLES:

Default Error Message Treatment

<form novalidate> <label for="name"> Name:</label> <input id="name" aria-required="true" required aria-invalid="false"> </form>

Invalid Error Message Treatment

<form novalidate> <label for="name">  Name:</label> <input id="name" aria-required="true" required aria-describedby="name_msg" aria-invalid="true"> <span id="name_msg">Please enter your name.</span> </form> <form novalidate> <label for="Email">  Email:</label> <input id="Email" aria-required="true" required aria-describedby="emal_msg" aria-invalid="true"> <span id="email_msg">The email address entered is invalid.</span> </form>

https://codepen.io/TPG/pen/3b68c22db120c0960503fe892bb2c068

Declaring Form Controls as Invalid

Wait to declare form controls as invalid until the form control has lost focus, or there has been an adequate delay in key presses (maybe a few seconds).

Example of Default State:

<form novalidate>

<label for="name"> Name:</label>

<input id="name" required aria-invalid="false">

</form>

Example of Invalid Error Message State:

<form novalidate>

<label for="name">  Name:</label>

<input id="name" required aria-describedby="name_msg" aria-invalid="true">

Accessibility Guidelines

<span id="name_msg">Please enter your name.</span>

</form>

Code Example: Required attr Testing with basic client side validation


References

Please see our forms guide for additional information on error message acceptance criteria.

Error Messaging

Instructions and Sensory Characteristics

Instructions provided for understanding and operating content should not rely solely on sensory characteristics of components such as shape, color, size, visual location, orientation, or sound.

People who are blind and people who have low vision may not be able to understand instructions if they rely only on a description of the shape and/or location of content. Providing additional information in any instructions other than shape and/or location will allow users to understand the instructions even if they cannot perceive shape and/or location.

Please more detailed information on how to comply with this guideline.

Provide Users with Adequate Time to Correct Errors

People with disabilities may need more time to complete activities.

Users should have adequate time to correct errors. For example when completing and submitting a form.

Allow users to turn off, adjust, or extend any time limits.

For each time limit that is set by the content, at least one of the following should apply:

Turn off

The user is allowed to turn off the time limit before encountering it; or

Adjust

The user is allowed to adjust the time limit before encountering it over a wide range that is at least ten times the length of the default setting; or

Extend

The user is warned before time expires and given at least 20 seconds to extend the time limit with a simple action (for example, "press the space bar"), and the user is allowed to extend the time limit at least ten times; or

Real-time Exception

The time limit is a required part of a real-time event (for example, an auction), and no alternative to the time limit is possible; or

Essential Exception

The time limit is essential and extending it would invalidate the activity; or

20 Hour Exception

The time limit is longer than 20 hours.

Please see more detailed information on how to comply with this standard.

Provide Status Messages and Make Users Aware of Important Changes in Content.

Let assistive technology notify users about status changes that don't take focus.

People who do not see messages need to be informed about them.

Make users aware of important changes in content that are not given focus, and to do so in a way that doesn't unnecessarily interrupt their work.

This is especially useful to blind and low vision users of assistive technologies with screen reader capabilities.

A status message is a defined term in WCAG. There are two main criteria that determine whether something meets the definition of a status message:

  • the message provides information to the user on the success or results of an action, on the waiting state of an application, on the progress of a process, or on the existence of errors;

  • the message is not delivered via a change in context.

Please see more detailed information on how to comply with this guideline.

Help Text and Custom Tooltips Displayed on Hover and Focus

Ensure that help text and custom tooltips that display on hover and focus are dismissible, hoverable and persistent and are accessible to keyboard and screen reader users.

Dismissible

A mechanism is available to dismiss the additional content without moving pointer hover or keyboard focus, unless the additional content communicates an input error or does not obscure or replace other content;

Hoverable

If pointer hover can trigger the additional content, then the pointer can be moved over the additional content without the additional content disappearing;

Persistent

The additional content remains visible until the hover or focus trigger is removed, the user dismisses it, or its information is no longer valid.

Please see more detailed information on how to comply with this guideline.

Provide Labels or Instructions When Content Requires User Input

Present instructions or labels that identify the controls in a form so that users know what input data is expected.

In the case of radio buttons, checkboxes, comboboxes, or similar controls that provide users with options, each option must have an appropriate label so that users know what they are actually selecting.

Instructions or labels may also specify data formats for data entry fields, especially if they are out of the customary formats or if there are specific rules for correct input.

Content authors may also choose to make such instructions available to users only when the individual control has focus especially if the instructions are long.

Avoid cluttering the page with unnecessary information, while providing important cues and instructions that will benefit people with disabilities. Too much information or instruction can be just as harmful as too little. T

The goal is to make certain that enough information is provided for the user to accomplish the task without undue confusion or navigation.

How This Helps Users

  • Providing clear and unambiguous labels and instructions (including examples of expected data formats) helps all users - but particularly those with cognitive, language, and learning disabilities - to enter information correctly.

  • Providing clear and unambiguous labels and instructions (including clear identification of required fields) can prevent users from making incomplete or incorrect form submissions, which prevents users from having to navigate once more through a page/form in order to fix submission errors.

Please see more detailed information on how to comply with this guideline.

WCAG Related Guidelines

1.3.3 Sensory Characteristics (Level A)

1.4.13 Content on Hover or Focus (Level AA)

2.2..1 Timing Adjustable (Level A)

3.3.1 Error Identification (Level A)

3.3.2 Labels and Instructions (Level A)

3.3.3 Error Suggestion (Level AA)

3.3.4 Error Prevention - Legal, Financial, Data (Level AA)

4.1.3 Status Messages (Level AA)