This website is being built in public and is very much under construction

Accessibility Specialist

Deep dive: understanding live regions, part 3

Posted:

In part 2, we explored how to create and configure live regions.

In this final part, we'll look at some of the common mistakes and questions that often crop up when working with them.

Common mistakes

Inserting a prepopulated live region into the DOM

With the exception of role="alert", adding a prepopulated live region to the DOM will not trigger a screen reader announcement. Have the live region present in the DOM before populating it with text.

Hiding the live region from assistive technology

A live region hidden from the accessibility tree through the use of the following will not announce updates:

  • display: none
  • visibility: hidden
  • aria-hidden="true"
  • inert
  • hidden

There are cases where a visually hidden, but screen reader accessible, live region can be useful. In these cases, hide it using the CSS clip method.

Overusing live regions

Not everything needs to be announced. Only informative, helpful, or critical, dynamic information that might otherwise be missed. You shouldn’t use a live region to announce:

  • Adverts and sales offers.
  • Information already conveyed by static elements on the page, like a <h1>.
  • Element state properties, e.g., a disclosure button that expands a section, should use aria-expanded, not a live region.

Too many live regions

Having too many live regions firing on the page can be overwhelming and defeat the purpose. When multiple live regions are needed, it’s a good idea to limit their number and use JavaScript to queue and update them as needed.

Overusing assertive regions

Assertive live regions, those that use aria-live="assertive" and role="alert", will interrupt the user and could be disorienting if they are midway through a task. Use sparingly and only for critical information.

Announcing too much

Don’t insert large amounts of text into a live region; this can be hard to follow and annoying for users. Use live regions to convey short informative messages that screen reader users may otherwise miss.

Inserting duplicate text without clearing

Inserting the same text repeatedly into a live region will not cause it to be announced. If you need the same text announced again, empty the live region first, then reinsert the text after a slight delay. I’ve found 150ms seems to be the shortest delay that consistently works well.

Inserting non-text content and interactive elements

Screen readers only announce text content changes inside live regions. The semantics of inserted non-text elements will not be announced. For example:

  • Image alt text is announced, but the presence of the image isn’t
  • Input label text is announced, but the presence of the input isn’t
  • Link/button text is announced, but the presence of the link/button isn’t

I’d advise against adding rich elements to a live region for this reason. In a small number of situations, it can be useful to inform screen reader users that non-text elements have been added, for example, in a web chat where an advisor sends a response that includes a button or link. In these cases, you could append a visually hidden notification about the elements, for example:

<div role="log">
  Advisor: What can I help you with today? 
  <span class="sr-only">Advisor sent 2 buttons</span>
  <button>Recent order</button>
  <button>Returns</button>
</div>

Which would sound something like: "Advisor: What can I help you with today? Advisor sent 2 buttons. Recent order. Returns."

Placing live regions inside buttons

Live regions placed within interactive elements, such as buttons, may not function as expected across different screen reader and browser combinations. Some announce updates correctly, some don't announce updates at all, and some announce updates multiple times.

To avoid these issues, use a separate live region outside the button to communicate microinteractions, such as changing button text from "Save" to "Saving", "Still saving", and "Saved".

Depending on the situation, you may want to visually hide the live region while still updating the visible button text.

Inserting text in pieces

Don’t use multiple DOM insertions to update a single live region message. If you do, screen readers may make multiple announcements, one part at a time. Build the complete message, then insert.

Common questions

Can live regions be visually hidden?

Yes, by using a screen reader friendly hide method, such as the CSS clip method.

Do live regions need to gain keyboard focus?

No. Live regions are used to announce changes when the new content does not receive keyboard focus (since setting keyboard focus to an element typically causes it to be announced).

Is role="region" a live region?

No, role="region" is an ARIA landmark role, which should be used sparingly to designate a generic page landmark of significance to aid in screen reader navigation. It does not relate to dynamic content, nor will a screen reader announce content changes to it, like a live region.

Should I use role="timer" with aria-live="polite" to announce a countdown?

No, this would announce every timer update, which, if the timer changes every second, would quickly become overwhelming for screen reader users. Generally, it’s better to use a separate live region to announce key intervals as the timer gets closer to expiring, such as 2 minutes, 1 minute, 30 seconds, and 10 seconds.

I have a visible "callout" message, displayed on page load, should this use role="alert"?

Websites often display important messages at the top of the page that aren't triggered by user action, such as delivery delay notices or holiday opening times.

Some design systems refer to these callouts as "alerts", which can cause confusion. Although they may look like alerts visually, they do not usually need to be coded as live regions. If they are marked up properly with headings, as landmarks (potentially, depending on the use case), and a clear content structure, screen reader users can discover them as normal.

Using role="alert" in these cases can be unnecessarily disruptive, as the message will be announced immediately when the page loads.

Why are my live region updates being announced twice?

While it depends on the scenario and browser/screen reader combination, some common causes include:

  • Using role="alert" and aria-live="assertive" on the same element
  • Browser/screen-reader combination quirks: for example, VoiceOver/Safari will announce live region updates twice when the live region is within an iframe.

Should I use a live region to announce route changes in a Single Page Application (SPA)?

Many frameworks, like Next.js, include a dedicated live region for route change announcements. If you are rolling your own, make sure the announcement is aligned with the page’s document.title and <h1>.

Conclusion

Live regions are a powerful way to make screen reader users aware of dynamic content changes. They can also be tricky and don’t always behave as expected.

When implementing them:

  • Ask yourself if a live region is needed at all.
  • Use them only for short, informative messages that screen reader users may otherwise miss.
  • Remember that live regions need to exist in the DOM before being populated with text, with the exception of role="alert".
  • Test across different browser and screen readers combinations, and ideally with native screen reader users.

Further reading