What this criterion requires
Status messages - results counts, "added to cart", saving indicators, form success banners - must be programmatically determinable as status so assistive technology can announce them without receiving focus.
Who it helps
Screen reader users, who otherwise never learn that something happened elsewhere on the page.
Example: fails vs passes
<div role="status" class="visually-hidden" id="cart-status"></div>
<script>status.textContent = "3 items in cart";</script>role="status" (polite) or role="alert" (urgent) announces changes without stealing focus. Render the region up front, inject text into it.
How to meet and fix it
- Use role="status" (polite) or role="alert" (assertive) / aria-live regions for dynamic messages
- Render the live region container up front and inject text into it, so the announcement fires reliably
- Do not move focus to the message - that is what this criterion exists to avoid
Common failures auditors find
- "Item added to cart" toasts that are never announced
- Search result counts updating silently
- Loading spinners with no accessible status
Automated scanning catches a share of these instantly - run a free check - and a manual audit covers the judgement calls a tool cannot make.
- W3C, Understanding 4.1.3: Status Messages - w3.org/WAI
- W3C, How to Meet 4.1.3 (quick reference) - w3.org/WAI/quickref
Last updated . Reviewed by the EqualWeb accessibility team.
Does your site pass 4.1.3?
Run a free automated check now, or have certified IAAP/CPWA auditors test every criterion and document the result.