Announce status messages with role=status
A status message is a change in content telling the user how something went, what an application is waiting for, how far a process has got, or that there are errors. It does all of that without moving focus. Those four categories and that last condition are the normative definition, and both halves decide whether the rule reaches you at all. Moving focus is a change of context, which puts the message outside the definition, so a page that announces in a live region and moves focus to the same message announces it twice. W3C lists ARIA22 as sufficient for 4.1.3 Status Messages at Level AA when a more specific technique carries it. The timing rule is the one that catches everybody, and it is a test step rather than an opinion. The container has to carry role="status" before the message arrives in it. Inject the container and its text together in one render and it usually announces nothing at all, because there was no region for the browser to watch. Add aria-atomic="true" while you are in there. The role is meant to imply it, and W3C says outright that some environments do not treat it as atomic, so make it explicit.
How we find it in an audit
With a screen reader running, we trigger every toast, counter and inline confirmation on an audited page and log what gets announced. Silence after add to cart is the finding, and the screenshot sequence tells the story without a caption. Click, nothing, click again, two in the cart. We check the container is in the page before the message rather than after, because that is W3C's own test step. Then we check the opposite case, where the page announces and moves focus, so the listener hears the same sentence twice.
How affected users experience it
A sighted customer gets a small confirmation in the corner of the screen and reads it without breaking stride. With no live region, a screen reader user gets nothing whatever, so as far as they can tell the button did not work. People then do the reasonable thing and press it again. They find out at the checkout, where the cart holds two of everything. Feedback is not decoration on an interaction. It is how anybody knows the interface heard them.
Passes vs. fails
Passes
<div id="cart-status" role="status" aria-atomic="true" class="sr-only"></div>
<script>
function addToCart() {
document.getElementById("cart-status").textContent = "Added to cart";
}
</script>Fails
function addToCart() {
const toast = document.createElement("div");
toast.setAttribute("role", "status");
toast.textContent = "Added to cart";
document.body.append(toast);
}Other ways to satisfy this rule
15 guides on this site are filed under 4.1.3 Status Messages. W3C lists this one as sufficient for that rule when it is implemented through a more specific technique, so the condition is part of the test rather than a footnote to it.
- ARIA19sufficientAnnounce form errors with role=alert
- ARIA23sufficientAnnounce chat and feed updates with role=log
- ARIA25sufficientAnnounce progress bar updates with a live region
- ARIA27sufficientAnnounce progress with the ariaNotify API
- G83sufficientTell users which required fields they missed
- G84sufficientExplain when input is not an allowed value
This guide is our interpretation of W3C technique ARIA22: Using role=status to present status messages. W3C publishes its techniques as guidance rather than as the standard, and says so on every one of them. The success criterion is what conformance is measured against, and a technique is one documented way to meet it.