Status Messages
When a page tells you something without moving focus to it, that message has to reach assistive technology too. Added to cart. 3 results found. Saving. Visually those land as a toast or a changed number. For a screen reader user they are silence, unless the text sits in a live region that announces itself. Status message is a defined term with two halves, and the second half keeps this rule from swallowing every update on the page. It has to tell the user about the success or result of an action, a waiting state, progress, or the existence of errors. And it must not be a change of context, so an error inside a dialog that takes focus is outside this rule entirely. A list of search results is not a status message either. The count above the list is.
Why it matters
Feedback tells a user whether the thing they did worked. Without it, people do it again to check. That is where duplicate cart items come from, and double submissions, and the second payment. The rule is not asking you to invent announcements. A page with no status messages passes it without doing anything at all. What it asks is that the messages you already show reach everyone you are already showing them to.
Who this rule protects
Screen reader users add something to the cart, apply a filter, or submit a form, and hear nothing back, so they have no way to know whether anything happened. Blind and low-vision users of assistive technology are the audience the criterion names. There is a second benefit further out. Software that can identify a status message can also hold it back, delay it, or push it forward for a user who wants that. None of it is possible until the message is marked.
How to check it yourself
- With a screen reader running, add a product to the cart, apply a search filter, and submit a form that confirms inline.
- Check each visual message is announced without you moving focus to find it. If you had to go looking, it did not announce.
- Inspect the container in the accessibility tree. Five things carry a status message in the markup W3C documents, and a tester who knows only three files false findings. The HTML output element, role="status", role="alert", role="log", and aria-live set to polite or assertive. Newer routes exist and are not yet dependable on their own, so treat anything outside the five as a claim to test rather than dismiss.
- Change a number rather than adding a message, then listen again. A counter going from 0 items to 3 items is a new status message, and if only the digit is marked as the changing part, the announcement is the word three and nothing else.
- Watch what happens when a status disappears. A Saving message vanishing is information a sighted user gets and a screen reader user does not, so something has to say Saved.
- Count how often it speaks. A page that announces every keystroke is its own kind of failure, and an assertive announcement that interrupts for something not urgent does real harm.
Failures we see most often
- A toast appears and fades and is never announced, so the only people who learn the action worked are the people who saw it.
- A results counter drops from 12 results to 3 results in silence when a filter changes.
- An Added to cart confirmation is an animation on the cart icon and nothing else, with no text anywhere for a screen reader to read.
- A cart counter announces only the new number, because the marked-up region holds the digit rather than the whole sentence, so the user hears three with no idea three of what.
- A live region is created and filled in the same instant, and nothing is announced, because assistive technology tends to watch regions that were already there.
- Everything on the page is marked assertive, so a routine confirmation cuts across whatever the user was in the middle of hearing.
Who this one is for
Read from this rule's own note above, so the grouping and the note cannot disagree.
- Blind and screen reader userspeople who cannot see the screen
- Low visionpeople who can see the screen but not easily
How to fix it
- Put the message into a container carrying role="status" for routine news or role="alert" for something urgent. Status is polite and waits its turn. Alert interrupts, so give it to anything the reader has to act on now and withhold it from everything else. Urgency decides that, not the word error, so a routine validation message can be polite and a session about to expire can be assertive.
- Have that container already sitting on the page before the message needs it, because assistive technology tends not to announce a region that appears and fills at the same moment. That is a support consideration rather than something the standard states, and it is the difference between a fix that works and one that tests clean and stays silent.
- Set aria-atomic="true" where the whole container has to be read for the message to mean anything. A counter updating one number announces 60 rather than 60 of 340 shown without it. Leave it off a log, where the point is to hear the new line rather than the whole history again.
- Write the announcement as a whole sentence and add the words a sighted user gets from the layout. Added Gold twist ring to cart tells somebody what happened. Ring does not.
- Say when something ends as well as when it starts. If a Saving indicator disappears on success and the visible text cannot change to Saved, put Saved into a hidden status region instead.
- Leave focus where it is for routine confirmations. Live regions exist precisely so an announcement can happen without moving anybody.
- Pick one route for errors rather than both. A form that moves focus to an error summary has already changed context, which takes the summary outside this rule, so it needs no alert role. Add one anyway and some screen readers will read the summary twice while others read it once, which is a good reason to choose and test rather than belt and braces.
Step-by-step fix guides (15)
- ARIA22: Announce status messages with role=status
- ARIA18: Raise blocking errors in an alert dialog
- ARIA19: Announce form errors with role=alert
- ARIA23: Announce chat and feed updates with role=log
- ARIA25: Announce progress bar updates with a live region
- ARIA27: Announce progress with the ariaNotify API
- SCR14: Let users switch nonessential alerts off
- G83: Tell users which required fields they missed
- G84: Explain when input is not an allowed value
- G85: Explain format errors and show the fix
- G177: Suggest corrections when input fails validation
- G193: Provide an accessible help assistant on the page
- G194: Spell-check text input and offer fixes
- G199: Confirm success when a submission works
Passes vs. fails
Passes
A visually hidden <div role="status"> that was already on the page receives the text "Added Gold twist ring to cart", the screen reader reads it out once, and focus never moves.
Fails
Clicking Add to cart animates the cart icon and does nothing else, so a screen reader user hears nothing, assumes the click missed, and clicks again. Two rings in the cart, and nobody chose the second one.
In audits and lawsuits
Our hands-on sessions show this one in the first five minutes. The auditor adds an item to the cart, hears nothing, and adds it again to check. Single-page apps are where we raise it most, not because the architecture fails the rule but because it shows so much without reloading, and nothing announces itself unless a developer built the announcement. A page that shows no status messages at all has nothing to announce and passes. This is also the cleanest example we have of a criterion no tool can clear for you. W3C publishes no test rule for it, and the part that matters could not be settled by one anyway, because a live region cannot be judged from static markup. You have to make the thing happen and listen. The other half of the job is not over-reporting it. An accordion that fails to say expanded is a 4.1.2 finding rather than this one. An error inside a dialog that takes focus is outside the rule entirely, because taking focus makes it a change of context.