Last updated on October 11, 2025
I’ve been encountering a pattern lately of developers trying to do things right when it comes to live regions, but not understanding how they essentially work. This tip is to provide a super high level on how they function.
Live Regions Purpose
We use live regions to help screen reader users know when something has changed on the page or when a user takes an action what the result is. The change can be something they triggered, like adding a product to a shopping cart and hearing, “Hershey’s bar added to cart.” It could be a Cookie banner that loads and needs the user’s attention. Receiving a message in chat application would use one to alert the user that they got a response.
How they function
In an ideal situation, live regions are loaded to a page and empty before they can be used. The best practice it to have one live region in the initially loaded HTML and that’s it. Then as messages are needed, they are added into this element and queued for announcement.
Depending on message type, the screen reader will announce it at the next opportunity. In the vast majority of cases, we should use them in a “polite” mode. Here, the assistive technology will wait until the user is paused in what they are doing to be announced.
There is also the “assertive” mode. I urge caution here in using it. Recall the message queue of things to be said to the user? If you add a message in as assertive, the queue is immediately dumped. The assertive message is announced, and there may be some important information the user missed.
When to use assertive
When something catastrophic is about to happen, it makes sense to change our live region to assertive with JavaScript and add the message. Critical things would include:
- Credit Card Declines
- System crash
- Making legal or financial decisions
One area it is often used is in inline form validation errors. Here the hope is that the interruption will trigger the user to go back in and correct the field before submitting. I think this is just an OK use. It is not a violation, but I’m not a fan. I’m not a fan because of the dumping of the queue when a user is in the middle of a process. I accept it as a valid pattern because the queue would be filled with messages related to the field. Once the field is determined to be in error, those messages don’t matter.
When Live Regions don’t work
This also opens up another point. Live regions only fire when something is removed or added to the DOM.
The pattern that I mentioned at the top of the post looks like this when they are inserted into the page:
<code><button type="button" aria-live="polite">My Button</button> <div role="alert" class="error"><img alt="" class="icon">Error message</div></code>
They come preloaded with content and often applied to the specific element. This results in dozens, some times hundreds, of live regions on a page. Remember I said to use one? With multiple live regions on a page they each are adding or interrupting the queue. If every time I interact with a button it announced “BUTTON” it would become gibberish as there is no reason for it to announce it’s name. But if the button changes the page, then you would send the message to page’s live region.
For the error, these are often loaded then hidden with aria-hidden="true" and display: none. If you put an error message under your form field with an assertive or alert setting and use display: none, at load, then show them on error they will work. This is because the it is newly added to the DOM. However, this will not work for polite or status.
That’s it for now.