Live region

Most of what a screen reader says is a response to where the user went. A live region covers the other case: something changed somewhere else on the page, and the user needs to hear about it without being dragged there. Added to cart, five results found, saving, saved. The point is that focus does not move, so whoever was halfway through a form stays halfway through that form.

There are two politeness levels and picking between them is most of the work. aria-live="polite" queues the message until the user pauses, and it is what almost everything should use; role="status" is the shorthand for it. aria-live="assertive" interrupts whatever is being spoken right now, and it is for errors that stop the task; role="alert" is the shorthand. An assertive region used for routine feedback talks over the user constantly, which is why the polite one is the default answer.

The mechanics are unforgiving in one specific way: the region has to exist in the DOM, empty, before the message is put into it. Screen readers watch a live region for changes, and an element that arrives already carrying its text often arrives as part of nothing anyone was watching. Render the empty container on load, then write text into it. Keep it in the layout too, or size it deliberately, so the message appearing does not shove the page around.

Not every message needs one. If the change is next to what the user just activated and focus is about to land on it anyway, a live region only duplicates what they will hear. WCAG 2.2’s Status Messages criterion asks for the case where the message is not where the user is, which is exactly the case the region is for.