WCAG 4.1.3 requires that status messages, such as "12 results found", "Added to cart" or "Draft saved", reach screen reader users without keyboard focus being moved to them, which you do by placing the message in a live region with a role such as status, alert or log. Sighted users notice these updates at a glance; without a live region, a blind user hears nothing and has to go looking.
Quick facts
Level
AAAdded in
WCAG 2.1Principle
RobustCovers
Messages about success, results, waiting, progress or errors that appear without a change of contextMain tools
role status, role alert, role log, or aria-live on a containerNot covered
Messages that take focus, open a dialog or load a new page
Which updates count as status messages
WCAG defines a status message as a change in content that tells the user about the success or result of an action, a waiting state, the progress of a process, or an error, and that is not a change of context. Some everyday examples:
| Message | Status message? | Suitable role |
|---|---|---|
| "24 results" after filtering a product list | Yes | status |
| "Added to cart" next to the button | Yes | status |
| "Uploading, 60 percent" | Yes | status or progressbar |
| "Session expires in 2 minutes" | Yes | alert |
| New lines in a chat window | Yes | log |
| Error summary that receives focus after submit | No, focus moves to it | None needed |
| A modal dialog that opens | No, change of context | dialog |
What WCAG 4.1.3 actually asks
In content built with markup, status messages must be programmatically determinable through role or properties, so that assistive technology can present them to the user without the message receiving focus. In practice, that means the message lives in a live region: an element the browser watches and reports to the screen reader whenever its text changes.
The criterion does not force you to show a message. It applies when you already show one visually. It also does not apply if you move focus to the message; that is allowed, though jumping focus around is often more disruptive than a quiet announcement.
Who benefits
Blind screen reader users are the main group: they cannot see a counter change or a toast slide in. Screen magnifier users zoomed in on one part of the screen often miss updates that appear elsewhere. People with attention or memory difficulties gain from a clear spoken confirmation that an action worked.
Live region code that gets announced
The most reliable pattern is to have an empty live region in the page from the start, then change its text. Many screen readers ignore a live region that is created and filled at the same moment.
Fails: the message appears as plain text, so screen readers stay silent.
<p class="cart-note">Added to cart</p>Passes: the region is in the page on load, empty.
<p role="status" class="cart-note"></p>After the click, script puts the words into that same element, and the screen reader reads them out:
<p role="status" class="cart-note">Added to cart</p>role="status"is polite: it waits until the screen reader finishes speaking. Use it for most messages.role="alert"is assertive: it interrupts. Keep it for urgent problems, such as a timeout warning.role="log"suits a stream of new entries, such as chat.aria-live="polite"on a plain element works too, if no role fits.
Testing WCAG 4.1.3 with a screen reader
- Make a list of actions that show a message without a page load: filters, add to cart, save, copy, upload, form checks.
- Turn on a screen reader. The free one for Windows paired with Firefox, or the one built into a Mac with Safari, are good starting points.
- Perform each action using the keyboard. The message should be spoken without you pressing anything else.
- Check that focus is still on the control you used.
- Inspect the message in developer tools and confirm its role or aria-live value.
- Repeat in a second screen reader and browser pair, because live region support varies.
Our screen reader testing guide covers the keys you need.
Status message failures and fixes
| Failure | Effect | Fix |
|---|---|---|
| Search results count updates silently | User does not know the filter worked | Put the count in a role status element |
| Toast added to the page with its text already inside | Often not announced at all | Keep an empty live region on the page and fill it |
| Every keystroke triggers an announcement | Constant interruptions while typing | Wait until typing pauses, then update once |
| role alert used for routine confirmations | Interrupts whatever the user was hearing | Use role status for non-urgent news |
| Message removed after one second | Cut off before it is spoken, and sighted users miss it | Leave it long enough to read, or until the next action |
A live region only announces changes. Text that is already there when the page loads is not read out automatically, which is why an error summary shown on a fresh page load should usually receive focus instead.
Questions people ask
What is a status message in WCAG?
It is an update that tells the user about a result, success, waiting state, progress or error, without moving focus or changing context. Examples include a results count, a saved confirmation or an upload percentage.
Should I use role alert or role status?
Use role status for most messages, because it waits politely for the screen reader to finish. Use role alert only for urgent, time-sensitive problems, since it interrupts.
Does a toast notification need to meet 4.1.3?
Yes, if it reports a result or status without taking focus. Put its text into a live region that already exists on the page, and leave it visible long enough to read.
Do I need aria-live if focus moves to the message?
No. When focus moves to the message, the screen reader reads it anyway and 4.1.3 does not apply. Moving focus suits error summaries after a submit, but it is too disruptive for small confirmations.
Is 4.1.3 WCAG required for Level A?
No. It is a Level AA criterion added in WCAG 2.1, so it is in scope for any AA target from 2.1 onward, the usual target in law and contracts.