WCAG 2.2 success criterion, Level AA

WCAG 4.1.3 Status Messages

When the page tells people something has happened, such as "Added to basket", "3 results found" or "Saving", a screen reader must be told too, without moving the person’s focus to the message.

Number: 4.1.3
Level: AA
Added in: WCAG 2.2
Guideline: 4.1 Compatible
Principle: Robust

What it asks

A status message is a piece of text that tells the person about the result of an action or the state of the page, without being a control and without taking focus. A toast saying "Changes saved". A count that reads "12 results" after a filter is applied. "Loading" while a list fetches. An error summary that appears at the top of a form. Sighted people see these appear. A screen reader user, whose focus is still on the button they pressed, hears nothing unless the message is marked up so that assistive software announces it.

The marking is a role or a live region. role="status" on the container tells assistive software to announce new text politely, when the current speech finishes. role="alert" interrupts, and is for errors and urgent messages. aria-live="polite" does the same job as role="status". The container should be on the page before the message is added to it, because a live region injected at the same time as its content is usually not announced.

The criterion applies only to messages that do not receive focus. A dialog that takes focus, or an error message that focus moves to, is handled by other rules. It is Level AA, new in WCAG 2.1, and in most audits it comes out as partly met, because sites announce some messages and not others.

Its official name is success criterion 4.1.3 Status Messages, at Level AA. It was added in WCAG 2.2, under guideline 4.1 Compatible and the principle Robust. The W3C’s normative text says, in part:

“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.”

From WCAG 2.2, W3C. Full explanation: Understanding 4.1.3 Status Messages.

Who it helps

Screen reader users, who otherwise press a button and hear nothing, and are left to guess whether it worked. People with low vision using magnification, who may not see a message that appears in a corner of the screen outside their view, and whose software can announce it.

People with cognitive disabilities, who are helped by being told clearly that something happened, as long as the message is not so intrusive that it breaks their concentration.

What passes and what fails

These pass

A "Added to basket" toast rendered inside a container with role="status" that was on the page from the start.
A results count "12 results" in a <p aria-live="polite"> that is updated when the filters change.
A form error summary with role="alert" added when the submission fails.
A "Loading" message in a role="status" region while a list fetches, replaced by the result when it arrives.
A progress bar with role="progressbar" and its value updated as the upload proceeds.

These fail

A toast that appears and fades with no live region, so nobody using a screen reader hears it.
A live region created at the same moment as its message, which assistive software does not announce.
"3 results found" updated in a plain <span> with no role.
A loading spinner that is only an animated image, with no status role and no text.
aria-live="assertive" on a message that is not urgent, which interrupts whatever the person was doing.

How to test it by hand

List the actions on the page that produce a message without moving focus: adding to a basket, saving, filtering, searching, submitting a form that fails, loading more content.
Perform each action with a screen reader running and listen. A message you can see but did not hear is a candidate failure.
In the developer tools, inspect the message container. Look for role="status", role="alert", role="log", role="progressbar" or an aria-live attribute.
Check that the container exists before the message is added to it, by inspecting the page before the action.
Check that urgent messages use alert and everything else uses status or polite, so that routine updates do not interrupt.

What automated testing can decide

What a machine can decide

Automated testing can find the containers that receive status content and check whether they carry a live-region role or attribute. If it performs an action, it can also see whether the message was added to a region that already existed, or whether the region arrived with the message, which is the common way announcements are lost.

What it cannot

Whether a piece of text is a status message at all is a judgement. A tool can see that text appeared after a click; it cannot always tell a status message from a new section of content, a chat reply or an advert. It also only reaches the actions it can safely perform, and a message that appears only after a real submission may be out of its reach. And whether an announcement is too intrusive is a question of taste as well as markup.

How Dreven handles it

Dreven finds the status messages on your pages, such as validation summaries, toasts, result counts and loading or saving states, and shows you each one with the page and a picture of what was seen.

A reviewer decides whether assistive software would announce each one, and the report names the specific messages, because that is what a developer can fix the same afternoon.

No automated check makes a site conform. In Dreven, a person reviews the results and signs the report.

4.1.2 Name, Role, Value (Level A). Controls expose their name, role and state; status messages are the content that is not a control.
3.3.1 Error Identification (Level A). Error messages are a common status message, and they also have to describe the error.
2.4.3 Focus Order (Level A). A status message must not take focus; content that does is governed by focus order.
1.3.1 Info and Relationships (Level A). The meaning of the message should be in the code as well as on screen.

Questions people ask

What counts as a status message under WCAG 4.1.3?

Text that tells the person about the result of an action or the state of the page, without being a control and without taking focus. Examples are "Added to basket", "3 results found", "Saving" and a form error summary that appears at the top of the page.

Should I use role="status" or role="alert"?

Use role="status", or aria-live="polite", for routine updates such as a basket count or a save confirmation. Use role="alert" only for urgent messages such as errors, because it interrupts whatever the person is hearing.

Why is my live region not announced?

The most common cause is that the region was added to the page at the same time as its content. Assistive software watches existing live regions for changes, so put the empty container in the page first and add the message to it afterwards.

Does an error message that receives focus count?

No. 4.1.3 is only about messages that do not receive focus. If your form moves focus to the error summary, the person is taken to it and it is read, and this criterion does not apply to it. The message still has to identify and describe the error under 3.3.1.

All WCAG 2.2 criteria, in plain words