01 — Purpose

Say what changed and why it matters

Dynamic interfaces need meaningful announcements — not a running commentary of every render.

Screen reader users experience your app through speech and navigation, not layout. When content updates, filters apply, or steps complete, they need to understand what happened without hunting focus around the page.

Announcements overlap with live regions — this guide focuses on message quality and timing, not only the markup hook.

02 — Principles

Only announce meaningful change

Users should understand what changed and whether they need to respond.

  • concise — one clear sentence beats a paragraph read aloud
  • relevant — tied to user action or system state they care about
  • understandable — plain language, not internal status codes or jargon
  • timely — after the update is visible or logically complete

03 — Practice

Good announcement patterns

Name the outcome, not the mechanism.

  • “3 results found” after search — not “DOM updated”
  • “Item removed from basket” — not “click handled”
  • step progress: “Step 2 of 4, Payment details” — not “tab index changed”
  • errors linked to fields: “Email address is required” — after focus or submit policy is clear
  • use visible text in the announcement when possible — avoid divergent visual vs spoken messages

04 — Avoid

Announcement anti-patterns

Spam trains users to ignore you.

  • announcing every filter chip toggle in a long list
  • vague messages: “Success”, “Updated”, “Done” with no subject
  • decorative counts, marketing copy, or animation narration
  • repeating the same announcement because a component re-rendered

05 — Close

Test with real assistive tech

If you would not understand the spoken update, neither will your users.

Walk critical flows with VoiceOver, NVDA, or TalkBack. Trigger saves, errors, empty results, and async completion. Note what gets read twice, what never gets read, and what arrives too early.

Related: toast notifications, confirmation, and the accessibility QA checklist.