ARIA Live Regions

by Andrea de Souza published on

ARIA stands for Accessible Rich Internet Applications. It is a set of roles and attributes that makes web page elements accessible to users who require assistive technology, like screen readers, when native HTML alone is not enough. One of these sets of roles and attributes is aimed at defining live regions.

Live regions are areas that, when dynamically updated, trigger screen readers to announce their new content. They are commonly used for notifications that do not receive focus when the new content is added to the page. For example: form errors, loading spinners, search results that appear on dynamic search, and toasts.

Here is a practical example. On an e-commerce website, the notification “product added to cart” displays momentarily whenever the “add to cart” button is pressed. The new content is added to the page, but doesn't receive focus. While sighted users would be able to see it, screen-reader users would not know that somewhere on the page an updated happened. Adding a live region to the parent element that displays this type of notification allows it to be announced by screen readers.

Creating Live Regions

There are two ways widely used to implement a live region in an HTML element: adding the aria-live attribute or adding a role that has an implicit live region.

A third option for specific scenarios is to use the native HTML <output> element, which has the implicit role="status" property. However, there are accessibility issues associated with it, as described in detail by Scott O’Hara.

aria-live Attribute

The aria-live attribute on an HTML element creates the behaviour of a live region by defining a "politeness setting", which indicates when dynamic updates should be announced to users of assistive technology. This attribute needs to be declared using one of three possible values:

  • off: This is the default value. No changes will be announced, unless if the user is focused on the region where the update happens.
  • polite: The screen reader will announce the changes when it has a chance. For example, when the user is idle or once the task being performed at the moment of the notification ends. This option should be used for low priority updates that don’t require immediate attention from the user.
  • assertive: The screen reader will interrupt whatever it is reading to announce the content update. This option should only be used for time-sensitive, critical information.

Going back to the e-commerce website example, the “product added to cart” message may have an aria-live="polite" attribute.

<div aria-live="polite">
	<p>Product added to cart.</p>
<div>

However, if the user is on a news website and there's a weather alert or an emergency broadcast, then this notification has a high degree of priority and should have an aria-live="assertive".

Please note that those are generic examples. The aria-live attribute value will depend on different factors. A good way to determine the politeness setting required is to ask directly the users that will be the recipients of the message. One important aspect to keep in mind is that the assertive level is disruptive for screen-reader users and should only be used when absolutely required.

There are other ARIA attributes that, in theory, should provide greater control of how ARIA live regions should behave. But, in practice, they have only partial support and/or their behaviour varies between different screen reader/browser combinations.

  • aria-busy: When set to true, it indicates that the element is not yet ready to be announced because it’s still being modified. It also means that screen readers MAY want to wait before announcing the changes (W3C). The partial support for this attribute happens when it's set to true, according to a11ysupport.io. The default value is false. An example that may apply this attribute is to set area-busy="true" while a page is still loading and change it to false once all elements are loaded.
  • aria-relevant: Specifies the updates that are relevant to be announced, which can be either: the addition of new nodes (aria-relevant="additions"); text content, text alternative, or node removal (aria-relevant="removals"); or the addition of text content or text alternative (aria-relevant="text"). The shorthand all includes the three values. Multiple space-separated values can also be used. For example, additions text, which is the default value. Please note that the values removals and all should be used carefully, since only in specific scenarios it's relevant to announce the removal of content. One example would be when a user leaves a chat room. According to W3C, aria-relevant is an optional attribute and represents a suggestion to assitive technologies. The partial support for this attribute is documented by a11ysupport.io.
  • aria-atomic: Specifies if the whole live region should be announced (aria-atomic="true") or only the content that has changed (aria-atomic="false") based on the value of aria-relevant. For example, with default value false and the default aria-relevant="additions text", only the updated nodes and the addition of text content or text alternative will be announced. When set to true, the entire live region will be announced. In this case, screen readers MAY choose to combine multiple changes and present the whole region at once (WAI ARIA - aria-atomic). Depending on the application, this attribute may be important, but make sure to test the behaviour with different browser/screen reader combinations. Test results for this attribute can be found at a11ysupport.io and at Paul J. Adam's website.

Live Region Roles

The ARIA specification lists five live region roles, according to the type of notification that they announce:

  • alert: Time-sensitive notifications that require immediate attention, like form errors.
  • status: Notifications that are not as important as an alert, nor time-sensitive.
  • log: The order in which the notifications are added have meaning, as in a log, and old information may disappear.
  • marquee: The information is non-essential, changes often, and the order is not meaningful.
  • timer: The notification is the amount of elapsed time from a starting point or the remaining time until an end point of a numerical counter.

Each live region role has an implicit aria-live attribute:

  • role="alert" has aria-live="assertive"
  • role="status" has aria-live="polite"
  • role="log" has aria-live="polite"
  • role="marquee" has aria-live="off"
  • role="timer" has aria-live="off"

MDN recommends adding a redundant aria-live attribute to the alert, status, and log roles to maximize compatibility.

Please keep in mind that role="status" and role="alert" are the only two live region roles that have good browser/screen reader support.

aria-live Attribute vs Live Region Role

So, what is the difference between using aria-live and a live region role? aria-live is an attribute that creates the behaviour of a live region by defining the “politeness” level of how the notification should be announced. A live region role not only creates the behaviour of a live region, but also provides semantic meaning to screen readers. It has an implicit aria-live property.

For example, an element with role="alert" has an implicit aria-live="assertive" property and should inform the screen reader that the notification in that area is really an alert. While the aria-live="assertive" attribute by itself will inform the screen reader that it should interrupt whatever it is reading to announce that notification.

Another difference is that live region roles allow to define an accessible name, which may be important when having more than one live region in the same page. For example:

<div role="status" aria-labelledby="[id-of-an-element]"><div>

While the definition with aria-live wouldn't allow the addition of an accessible name:

<div aria-live="polite"><div>

One last difference specific to live regions defined with role="alert" or role="status" is the implicit aria-atomic="true" property.

“Robust” live regions

Unfortunately, live regions don’t behave consistently in all browser/screen reader combinations, even if all roles and attributes are added according to the specification. However, there are a few recommendations that can be followed to make the implementation as robust as possible:

First: Insert the live region

The element that contains the aria-live attribute or live region role should be in the DOM, empty, before the update happens. Ideally, on page load or as close as possible to it. This is important because live regions need to be in the accessibility tree in order to be announced. The accessibility tree is a subset of the DOM tree. It provides information from the DOM in a way that can be understood by screen readers and other assistive technologies.

For example, the div below can be part of the initial HTML markup and, later on, used for a dynamic notification:

<div role="status"><div>

Having an element with a live region declared, as the example above, will not trigger any announcement by screen readers. It's only when an update in the content inside the live region happens that the it will trigger screen readers to announce the new content.

If the element with the live region role is dynamically injected in the DOM at the same time as the notification happens, it may not be correctly announced. For example, if an element with a live region is in the HTML, but has the CSS property display: none:

<div role="status" style="display:none;"><div>

Using the CSS properties display: none or visibility: hidden hides the content from users, but also removes it from the accessibility tree. And if the live region is not in the accessibility tree, then it cannot be tracked by screen readers. Although these properties can be dynamically changed with JavaScript to display: block or visibility: visible, it should not be done at the same time as the content update.

Second: Add dynamic content

The dynamic content should be added to descendants of the element that has the aria-live attribute or live role region. Adding to the previous example, the dynamic content can be added as:

<div role="status">
	<p>Product added to cart.</p>
<div>

When not to use a live region

Although a live region may seem like the ideal solution to announce a dynamic content update, it is not always the best approach. Here are a few examples when not to use it:

  • If there is an option to replace the live region with static instructions, then do it. It will probably be a better experience for screen-reader users to read additional content than to be interrupted with a notification. For example, a <select> element updates another area of the page according to the option value. Instead of using a live region for the area that will be updated, it's possible to have static text saying that the content will be updated according to the option selected.
  • Focus change and live regions firing at the same time are prone to conflicts. If there is a focus change to the element being updated, then a live region is not needed. Going back to the "add to cart" example, instead of having the "product added to cart" message, we can have a "cart flyout" (modal dialog) opening on the side of the screen. Focus may go the modal close button, an interactive element. In this example, there's no need for a live region, but the user should be informed of the new context.
  • Don’t use live regions to announce state changes that can be communicated through an ARIA state. For example, if using an accordion, use the attribute aria-expanded to indicate if it’s opened or closed. If using a toggle button, use aria-pressed.
  • Don’t use live regions for visual UIs that change constantly. Sarah Higley suggests to provide a separate interface in some scenarios. This will keep the live region concise by announcing only relevant information. A practical example would be a search box in which the results update every time the user types a character. Wrapping the element in an ARIA live region would be too verbose because every single change would be announced.

Tips to improve the user experience

There are a few tips that can improve the user experience:

  • Live region notifications should be concise. Remember that screen-reader users have no control over it. And since the notification is only announced once, there’s no possibility to go back and review it, according to Sarah Higley - The Many Lives of a Notification.

  • Notifications should be easy to understand. Screen readers will read everything as plain text. Even if the text has headings, bold content, or any interative content (links or buttons, for example), everything will be read as one block of text. Try reading out loud your notifications and ask yourself if they make sense.

  • Don’t use special characters (anything other than letters and numbers). For example, always use "and" instead of ampersand (&). Use correct grammar. For punctuation, use only commas and periods.

  • If the live region contains a notification specific for screen-reader users that does not appear visually, it is recommended to remove it shortly after it shows up. This is important to avoid screen readers announcing old updates that are not relevant anymore. According to Sarah Higley, a notification doesn’t need to stay long in the DOM. Even half a second is enough because the screen reader is watching the live regions for updates, so it will announce any new content, even if it’s removed right after. Please note that this recommendation does not apply to notifications that communicate user-facing state and status that other ARIA cannot. It is only for content that can become obsolete.

  • Don’t add too many live regions to the same page. It may cause conflicts if more than one fires at the same time. For example, a "polite" notification may not be announced if an "assertive" notification also happens around the same time. According to W3C, the politeness level is an ordering mechanism and "user agents or assistive technologies MAY choose to clear queued changes when an assertive change occurs".

Keep in mind that if a live region can be avoided, take that route. If possible and if it makes sense for your application, move focus and don’t add a live region. However, focus should only move if it’s because of a user action. Also, depending on the scenario, adding clear instructions may be enough, instead of using a live region.

Taking Control

Screen readers allow users to control how they navigate a web page. For example, they can go first through all the headings of a page before deciding to read a full section. They can also go back and read a specific content again.

But when an element has a live region, the control is taken away from the screen-reader user. They will be forced to hear the notification, either in a polite or assertive way, and that announcement only happens once.

Therefore, developers should use caution when implementing live regions. They can negatively impact a screen-reader user experience if poorly implemented or if there are too many of them, providing non-stop notifications.

If the element requires a live region, then make sure to test the implementation with screen readers to ensure that it works as intended.

Testing

It is crucial to test live regions with different browser/screen reader combinations. And, whenever possible, get your page tested by a real screen-reader user.

If you need help to get started with screen readers, Sara Soueidan has an article with detailed instructions on setting up a screen reader testing environment on your computer. The article also suggests the following pairings for testing based on usage and compatibility:

  • JAWS on Chrome
  • NVDA on Firefox
  • Narrator on Edge
  • VoiceOver on Safari for macOS,

You will probably notice that the same implementation will not behave the same way across the board. This is because support for live regions vary between how browsers and screen readers are paired together. Since this can result in a poor experience for some users, it's essential to test thoroughly to uncover potential issues and fix them.

Wrapping up

Live regions provide a solution for announcing dynamically added content that would otherwise be missed by screen readers, but their behaviour is not consitent across different browser/screen reader combinations. If adding a live region to your page, follow the specification to implement it in the most robust way possible. Don’t add too many live regions to the same page and only make them assertive if it’s absolutely necessary. Remember to test your live regions thoroughly and re-test often to confirm that they still work as intended. Even better, have your page tested by a real screen-reader user.

About Andrea de Souza

Andrea de Souza is a front-end developer passionate about web accessibility. She works in Canada for an e-commerce agency specialized in Shopify.

website: andreadesouza.com