4.1.3 - Status messages
Benefits users with:
- blindness/low vision who use screen reader
- cognitive disabilities
Intent
The intent of this success criterion is to 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.
The intended beneficiaries are blind and low vision users of assistive technologies with screen reader capabilities. An additional benefit is that assistive technologies for users with cognitive disabilities may achieve an alternative means of indicating (or even delaying or supressing) status messages, as preferred by the user.
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.
Examples that do not meet the definition of this criterion
The list of results obtained from a search are not considered a status update and thus are not covered by this success criterion.
However, brief text messages displayed about the completion or status of the search, such as "Searching...", "18 results returned" or "No results returned" would be status updates if they do not take focus.
Ways to meet the criterion
In content implemented using markup languages, status messages can be programmatically determined through role or properties such that they can be presented to the user by assistive technologies without receiving focus.
Examples
Alert message
An alert message appears when users do not act on a form page for a while.
Success
- Screen reader reads an alert message when it appears.
- These ARIA below support screen readers to read the status message.
- If it is time-sensitive/critical notifications that absolutely require the user’s immediate attention, such as an error message, remaining time warning, content change, use one of these below so a screen reader will announce it immediately.
- role=“alert”
- aria-live=“assertive”
- aria-atomic="true"
- If it is not time-sensitive/critical notifications such as search results or success message, use one of these below so a screen reader waits until the user is idle before presenting updates to the user:
- aria-live="polite"
- more stable
- role="status"
- It may not work with some older versions of screen readers & browsers.
- aria-live="polite"
- If it is time-sensitive/critical notifications that absolutely require the user’s immediate attention, such as an error message, remaining time warning, content change, use one of these below so a screen reader will announce it immediately.
Failure
Screen reader does not read an alert message when it appears. So the user cannot receive the information.
Not applicable
The keyboard focus moves to the alert message when it shows up so screen reader users can receive the information.
Search results
After a user presses a search button, the page content is updated to include the results of the search, which are displayed in a section below the Search button. The change to content also includes the message near the top of this new content.
Success
The element has an appropriate role for a status message. Screen readers announce “Search results for dogs 3140 results”.
Failure
The element does not have an appropriate role for a status message. Screen readers do not announce the message.
Other possible status message examples
Form success/error messages after clicking submit button.
Numbers of items added to shopping cart after a user presses an add to shopping cart button.
Loading icon when a user activates a process.
Avoid adding satus message roles on content which is not important and time-sensitive
Adding role=“alert” or aria-live=“assertive” on content which is not important and time-sensitive distract screen reader users.
Failure
Status message roles are added for the advertisements in a slider function that automatically changes the content.
Screen readers read every time the slider’s content changes.
Testing principles
For content that is dynamically added to the page:
- Check that the element containing the updated content does not take focus.
- Check that the new content provides information to the user on one of the following:
- the success or result of an action
- the waiting state of an application
- the progress of a process
- the existence of errors
- Check that the element containing the new content does not have a pre-existing aria role of status, alert, log, or progressbar, or an aria-live attribute.
- Check that the status message is not surfaced (i.e., announced) by assistive technology.
If #1 through #4 are all true, then content fails the success criterion.