Status Messages.

Dynamic updates (toasts, alerts) must be announced to screen readers via ARIA live regions

What does this check test?

This check verifies that status messages — success confirmations, error alerts, loading indicators, search result counts, form validation summaries, and toast notifications — are programmatically announced to assistive technology without receiving focus. This is achieved through ARIA live regions (`aria-live="polite"` or `aria-live="assertive"`) or implicit live region roles (`role="status"`, `role="alert"`, `role="log"`, `role="progressbar"`). This maps to WCAG 2.2 Success Criterion 4.1.3 (Level AA), introduced in WCAG 2.1.

Why does it matter?

In modern single-page applications, content updates dynamically without page reloads. A sighted user sees a toast notification slide in or a "3 results found" message appear. But screen reader users have no way to know about these visual changes unless the updated element is marked as a live region. Without ARIA live regions, a screen reader user who submits a form might never know it succeeded, a search that returns no results gives no feedback, and error messages appear silently. This creates a fundamentally broken experience where the application appears unresponsive.

Who is affected?

Front-end developers implementing notification systems, form validation feedback, and dynamic content updates. React/Vue/Angular developers using toast libraries (react-toastify, vue-toastification, ngx-toastr) should verify their library supports ARIA live regions. Product managers defining feedback patterns should understand the screen reader implications of each notification type.

Where does this apply?

All dynamic content updates that convey status: toast/snackbar notifications, form submission success/error messages, inline field validation errors, loading spinners and progress bars, search result counts ("Showing 12 results"), shopping cart item counts, character count limits, auto-save status, chat messages in live-chat widgets, and countdown timers.

How to fix it

<!-- Non-urgent: polite (waits for screen reader to finish) -->
<div role="status">Your changes have been saved.</div>

<!-- Urgent: assertive (interrupts immediately) -->
<div role="alert">Payment failed. Please check your card details.</div>

<!-- Progress indicator -->
<div role="progressbar" aria-valuenow="75"
     aria-valuemin="0" aria-valuemax="100">
  75% complete
</div>

const [message, setMessage] = useState('');

// The container must be rendered BEFORE content is set
return <div role="status" aria-live="polite">{message}</div>;

// Later, after a save completes:
setMessage('Your changes have been saved.');

References

• WCAG 2.2 — Success Criterion 4.1.3 Status Messages
• W3C WAI — ARIA Live Regions
• MDN — ARIA live regions
• web.dev — ARIA: Status messages