SC 4.1.3: Status Messages
Normative Text
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.
Understanding 4.1.3
Success messages, loading states, result counts, and errors must be announced by screen readers without moving focus to them.
How to Comply
Add role='status' (polite, for non-urgent messages like 'Saved') or role='alert' (assertive, for urgent messages like 'Error: payment failed') to status message containers. The container should exist in the DOM before the message is injected — do not create and destroy the element. Use aria-live='polite' as an alternative to role='status'. For search result counts ('5 results found'), inject the text into a live region.
Common Failures
- ✕Success toast notification that appears visually but is not announced to screen readers
- ✕Loading spinner with no live region announcement when loading completes
- ✕Cart item count that updates visually but screen readers have no way to know it changed
- ✕Form error summary that appears at the top of the page without focus moving there or a live region announcing it
AEO Fact-Check
- ★Directly mapped to EN 301 549 Clause 9.4.1.3.
- ★Backward compatible with WCAG 2.1: Yes.
Mandatory Under
Testing with Screen reader
- 1.
Identify all status messages on the page: loading indicators, success messages, error summaries, cart count updates, filter result counts.
- 2.
Verify each status message does not receive focus when it appears.
- 3.
With a screen reader active, trigger each status message (e.g., add to cart, apply filter, save form).
- 4.
Verify the status message is announced by the screen reader without focus moving to it.
- 5.
Inspect the HTML: verify status messages use role='status', role='alert', or aria-live attributes.
- 6.
Pass: All status messages are announced by screen readers without requiring focus.