Live region.
A live region is an area of a page whose changes a screen reader has to announce to the user.
When content changes without the page reloading — a form is submitted, search results update, a notification appears — a sighted user notices at once. A screen reader user does not, because their focus is still elsewhere and they have no idea anything on screen has changed.
The live region marker closes that gap: it tells the browser and the assistive technology “if the content here changes, tell the user”. Once the marker is in place, every piece of text written into that region is announced without moving the focus.
There are two levels of urgency, and choosing correctly matters. The polite level does not interrupt what the user is doing; the reader waits its turn and announces at a suitable moment. The assertive level cuts off the current reading and says the message immediately. In almost every case polite is right; assertive should be kept for warnings that genuinely deserve an interruption.
The most common mistake in practice is a matter of timing, and it looks like a footnote in the documentation: the live region has to be present on the page BEFORE its content changes. A live region created together with the message goes unannounced in most screen readers — because the technology waits for the region to exist before it starts watching.
- The right pattern: keep an empty live region on the page from the start and write the message into it.
- The wrong pattern: create the live region along with the message when it arrives. It stays silent.
- Use the assertive level sparingly — not every message deserves an interruption; an interface that keeps interrupting becomes unusable.
- Do not use a live region for constantly changing content — an area updating on every keystroke leaves the reader unable to stop talking.
Typical places for a live region are form result messages, search result counts, cart updates and session timeout warnings. What they have in common is that they are pieces of information that appear without the user’s focus moving and must be known.
There is an alternative to a live region, and sometimes it is the better one: moving the focus directly to the message. If the user has already taken an action — submitting a form, for instance — being taken to the result can be smoother than waiting to hear it. The two approaches are not mutually exclusive; in critical flows they are used together.
The question that decides which is right is this: is the user expecting this change? For an expected result, moving the focus is appropriate; for an unexpected notification a live region is right — moving the focus without warning makes the user lose their place.