WCAG 4.1.3 — Status Messages, explained with examples

Why this criterion exists

Toast notifications, "Saved" confirmations, and inline error summaries are invisible to screen readers if they are not in a live region.

If you only remember one thing: status messages (success, error, loading) must be announced by assistive tech without moving keyboard focus. Everything else on this page is detail.

Who feels it when this fails

Accessibility criteria sometimes feel abstract until you see who pays the cost when a site ignores them. Status Messages affects:

• Screen reader users

How sites typically fail it

These are the patterns we see week after week. None are intentional — they are accidents of how teams build interfaces under deadline. Knowing the failure modes is the fastest path to writing them out of your component library.

• Toast appears but is never announced

• Form-saved confirmation only visible

How to test for it

• Trigger a status; a screen reader should announce it without you tabbing.

A code fix you can copy

role="status" with aria-live="polite" announces non-critical changes; role="alert" interrupts for critical errors.

<div class="toast">Saved</div>

<div role="status" aria-live="polite">Saved</div>
<!-- For errors: -->
<div role="alert">Could not save. Try again.</div>

Other Robust criteria