Status messages communicate important updates to users without moving focus.
If these messages are only visible on screen and not exposed programmatically, screen reader users may never know the update occurred. This rule ensures that when status messages appear, they are marked up so assistive technologies can automatically announce them.
WCAG Success Criterion
4.1.3 — Status Messages (Level AA)
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.
Common doubts
What Does “Programmatically Determinable” Mean?
Programmatically determinable means: The browser exposes the message in a way that software (like screen readers) can detect and announce it automatically, without the user navigating to it.
Visually seeing text on a screen is not enough.
Assistive technologies rely on information exposed by the browser, not pixels.
What Is the Accessibility Tree?
Browsers do not give screen readers the raw DOM.
Instead, they build an accessibility tree, a structured representation of:
- Roles (what something is)
- Names (what it’s called)
- States and properties (expanded, busy, invalid, etc.)
Only content that appears in this tree can be announced automatically.
Why Plain DOM Updates Are Silent
If you change text like this:
message.textContent = "Saved successfully";Nothing is announced unless:
- The element is marked as a live region, or
- The change moves focus
Without that, the update exists visually but is invisible to assistive technologies.
What Is a Status Message?
A status message is brief text that informs the user about:
- The result of an action
- The progress or waiting state of a process
- The presence of errors
- A confirmation or system update
Examples:
- “Item added to cart”
- “Saving…”
- “Upload complete”
- “Invalid postal code”
- “5 results returned”
What Makes a Status Message Special?
A status message:
- Appears without taking focus
- Does not change the user’s context
- Is visible to sighted users
- Must be announced automatically to screen reader users
If focus moves (for example, a modal dialog opens), it is not a status message under this criterion.
How Screen Readers Detect Status Messages
Status messages are announced through live regions.
A live region is an area of the page that tells screen readers:
“If the text here changes, announce it.”
Live regions are created using:
- r
ole="status" role="alert"- or
aria-live
role="status" vs role="alert"
role="status"- Polite announcement
- Does not interrupt current speech
- Used for confirmations, updates, and background information
- Implies
aria-live="polite"
role="alert"- Assertive announcement
- Interrupts current speech
- Used for errors or urgent information
- Implies
aria-live="assertive"
Choosing the wrong one can either silence important errors or make the interface overly disruptive.
What This Rule Checks
This rule verifies that:
- Status messages are exposed via live regions
- Appropriate roles or ARIA properties are used
- Announcements occur without focus movement
- Updates are available to assistive technologies when content changes
The rule does not require creating status messages, only exposing them correctly when they exist.
Correct Markup Examples
Confirmation message (polite)
<div role="status">
Item added to cart
</div>✔ Announced after the current speech
✔ Focus remains unchanged
Search result count
<div role="status">
5 results returned
</div>✔ Screen reader announces update automatically
Error message requiring attention
<div role="alert">
Invalid postal code
</div>✔ Announced immediately
✔ Does not require focus change
Background process feedback
<div role="status" aria-atomic="true">
Uploading… 40% complete
</div>✔ Entire message announced when updated
✔ Prevents partial announcements like “forty”
Progress Indicators
<div role="progressbar"
aria-valuemin="0"
aria-valuemax="100"
aria-valuenow="40">
</div>A progress bar does not automatically announce updates.
- Screen readers announce progress when focused
- Background changes may be silent
For non-focused progress updates, pair with a status message:
<div role="status">
Upload 40% complete
</div>Indeterminate progress must also include text like “Uploading…” or “Processing…”.
Incorrect Markup Examples (Failing)
Visual-only message
<div>
Saved successfully
</div>✖ Visible
✖ Not announced
DOM update without live region
<p id="message"></p>
<script>
message.textContent = "Form submitted";
</script>✖ Change is silent to screen readers
Focus-moving dialog used unnecessarily
<div role="dialog">
Saved successfully
</div>✖ Changes context
✖ Not a status message under SC 4.1.3
What Is Not a Status Message
Changes that move focus
- Modal dialogs
- Alert dialogs
- Page navigation
Focus change already notifies assistive technologies.
UI state changes
- Expanding menus
- Accordions
- Tabs
- Tree items
These are covered under 4.1.2 Name, Role, Value, not status messages.
New content that is not feedback
- Additional survey questions
- Conditional form sections
These do not meet the definition of status messages.
Special Considerations
Updating Existing Status Text
When updating messages like:
“0 items” → “3 items”
Ensure the entire phrase is treated as the update.
<div role="status" aria-atomic="true">
3 items in cart
</div>
Removing Status Text
If removal conveys meaning (e.g., “busy” disappears), provide a replacement:
<div role="status">
System available
</div>Avoid Overuse
Excessive live regions can:
- Interrupt users constantly
- Cause screen readers to queue announcements
- Make applications frustrating or unusable
Status messages should be meaningful, brief, and intentional.
Why This Matters
Sighted users notice messages added to the screen without effort. Screen reader users do not know unless the message is exposed programmatically.
Without proper markup:
- A form may fail silently
- A cart update may go unnoticed
- A process may appear stuck
Users lose confidence and control.
How This Is Tested
- Automated tools can detect missing live region roles
- They cannot determine whether a message should be a status message
- Manual testing with a screen reader is required
Verify that:
- Focus does not move
- The message is announced
- Polite vs assertive behaviour matches importance
How to Fix the Problem
- Identify messages that appear without focus movement
- Mark them as live regions using appropriate roles
- Choose status vs alert intentionally
- Ensure updates occur after the region exists in the DOM
- Avoid unnecessary announcements
Wrapping Up
Status messages provide essential feedback without interrupting the user. When they are not programmatically exposed, screen reader users are left unaware of changes that sighted users can see instantly. If a message communicates status and does not take focus, it must be programmatically determinable.
