Single-page apps change the DOM without a page load, so a screen reader that only reads on navigation misses updates such as validation errors and status messages. A live region tells assistive technology to announce changes inside it, and the choice of polite or assertive sets how urgently.
Before you start
You should be comfortable with JSX, ARIA roles and keyboard access. This article covers announcements; it assumes you already label controls correctly.
Step-by-step walkthrough
Step 1: Create the region before the update
The live region element must already be in the DOM when its content changes. Rendering the region and the message together often fails to announce, because the region was not present to observe the change. Render an always-present container and update its text.
Step 2: Use polite by default, assertive sparingly
aria-live="polite" waits for a pause before announcing, which suits status updates, result counts and saved confirmations. aria-live="assertive" interrupts immediately and should be reserved for urgent errors, since it cuts off what the user is hearing.
Step 3: Use the right role and keep messages short
role="status" implies a polite live region, and role="alert" implies an assertive one, so you can use them in place of the attribute. Keep messages concise and human-readable; a screen reader reading a long JSON blob is worse than no announcement.
Worked scenario
The always-present status region announces the result of a search.
function SearchStatus({ count }) {
return (
<div role="status" aria-live="polite" className="visually-hidden">
{count} results found
</div>
);
}Walk through the example
The role="status" container stays mounted, and only its text changes, so the screen reader observes the update and announces “12 results found”. The visually hidden class keeps it off the visual layout while leaving it available to assistive technology. Because it is polite, the announcement waits until the user finishes the current phrase.
Common mistake
Mounting the live region and the message in the same render, so there is no change to announce. Another is marking every message assertive, which floods the user, or using display: none, which hides the region from assistive technology too.
Verify the behavior
Use a screen reader or the browser’s accessibility tree to confirm the region is present and that changing its text triggers an announcement. Assert that the region exists before the count changes. Check that hidden content uses a visually-hidden technique that does not remove it from the accessibility tree.
Interview exercise
Why can a live region fail to announce when you render the message and the region together?
Answer and reasoning
Because a live region announces changes that happen to content inside an element already in the accessibility tree. If the element and its content appear in the same commit, the region is new rather than changed, so there is no observed mutation to announce. Keeping the region mounted and updating its children fixes it.
Continue learning
Compare dialog accessibility in Accessible dialogs. Read the MDN ARIA live regions guide and try the React interview questions.