This post originated from an ARIA-live question in the Accessibility Slack.¹ I was encouraged to write it up as a blog post, so here it is. For more of this kind of stuff, check out the accessibility section of my site.

ARIA-live overview

ARIA live regions are an extremely powerful tool, allowing you to make screen reader and other assistive technology users aware of important and timely information that they would otherwise find it difficult to access. The aria-live attribute and its related roles² is also a rare example of a commonly used ARIA feature that can’t be easily recreated³ using semantic HTML.

With great power, comes great responsibility. As with any ARIA role or attribute, there’s always a risk that inappropriate use will annoy, confuse or block assistive technology users. Explicit announcements are particularly risky, because – by design – they interrupt a screen reader’s normal output in order to announce something. Before including a new live region in your web site or web app, you should consider if a screen user needs to know the information you’re intending to announce to them. Screen reader users are, in general, competent IT users, and they generally prefer to encounter information organically by browsing a page at their own pace.

The aria-live attribute has two possible values: assertive and polite. Both behave similarly, but assertive (as its name implies) is more forceful when interrupting the current flow.

ARIA-live key questions

When deciding whether an ARIA live region is appropriate, ask yourself two questions:

• Would a screen reader user find out about a change/update organically?
  • e.g. they’re navigated to a new page with a different title)
  • If so, you probably don’t need to use aria-live at all.
• Assuming that the change/update does need to be announced, is this information urgent and/or does it require immediate action?
  • If so, aria-live="assertive" is probably suitable.
  • If not, aria-live="polite" is more appropriate.

If in doubt, use polite over assertive. Users will still get the announcement, but it won’t necessarily be the first thing they hear.

assertive use cases

Here is a non-exhaustive list of situations where aria-live="assertive" is appropriate:

• The user has submitted a form but there are errors preventing it from being sent to the backend.
• The user is about to be logged out unless they perform a specific action immediately.
• A timer is about to run out.
• The user must perform a specific action before they can progress further, and are otherwise blocked from performing other actions.

polite use cases

And here are some example use cases for polite :

• A notification about something else unrelated to the current task.
  • For example ‘You have 1 new notification’ or ‘[Background task] has completed’.
• A dismissible page banner that communicates important but non-urgent information.
  • In this context, ‘dismissible’ means that it won’t come back if you refresh the page or navigate elsewhere…
  • … unless the information being displayed in the banner has significantly changed.
• Making the user aware of an element’s position in a drag and drop interface when it has been focused, picked up, moved to a drop zone or dropped.
  • For a live demo of this use case, see this Multiple Droppables example from the dnd kit React library.

When to avoid aria-live entirely

Finally, here are some situations where aria-live should not be used at all:

• Triggering an announcement every time an auto-advancing carousel moves onto the next slide. If you really must have an auto-advancing carousel, let assistive technology users browse carousel content at their own pace, and make sure that your pause button has an accessible name and can be reached via keyboard controls.
• A promotional/marketing banner that appears on all pages and/or cannot be permanently dismissed.
  • e.g. a free shipping banner that appears in the <header> section of every page.
• Telling people information that is already communicated in the page title/H1 after they have been navigated to a new URL
  • e.g. ‘Thank you for downloading’
• Anything that the business wants to push but the user is unlikely to care about
  • e.g. fake countdown timers, ‘X people are viewing this product’, ‘sign up to our newsletter’

Never use ARIA live regions to tell users information you want them to know, unless they need to know it.

Other aria-live considerations

Hopefully the above scenarios give you a good overview of when aria-live is and isn’t appropriate, and how to decide between polite and assertive (if in doubt, default to polite!). There are a few more things you should be aware of though:

• ARIA live regions must be ‘registered’ before they are populated with content. This can be achieved by pre-rendering them (empty) on the page before they are needed, or by including a short delay (think milliseconds) between adding the element to the DOM and populating it with text. For more on this, check out Sarah Soueidan’s guidance and Tetralogical’s advice on debugging live regions.
• aria-live attributes are typically used on inert (non-interactive) elements such as div, span and p, but they can theoretically be applied to any HTML element, including interactive ones. Once again, think carefully before deciding if a piece of content really warrants an announcement.
• You can use aria-atomic alongside the aria-live attribute to tell screen readers to always read out the full announcement when it changes. There is also aria-busy and aria-relevant, but screen reader support is more patchy.⁴
• The alert and status roles (among others, see footnote 2) set the assertive and polite aria-live attributes for you, and also give the announcements semantic meaning.
• The alert role also has the benefit of not needing to be ‘pre-registered’ in the DOM before it is populated with content, but please don’t use it unless the announcement is genuinely an alert.

Further reading

• MDN – aria-live attribute
• Sarah Souiedan – Accessible notifications with ARIA Live Regions (and here’s part 2)
• Tetralogical/Patrick H Lauke – Why are my live regions not working?

1. If you’d like to score an invite to the A11y Slack, contact me via LinkedIn, Mastodon, email or carrier pigeon with the email address you would like to use for the Slack. ↩︎
2. MDN: alert, status, log, marquee and timer roles. ↩︎
3. Yes, I’m aware of the output element, but this is only one of many aria-live use cases and I’ve never knowingly come across this element in the wild. ↩︎
4. A11ySupport references: aria-live, aria-atomic, aria-busy and aria-relevant. ↩︎