DEV Community

Cover image for Introduction to ARIA Live Regions
Gary Byrne
Gary Byrne

Posted on • Updated on

Introduction to ARIA Live Regions

In this article, we will look at ARIA live regions and how they can be used to expose information to assistive technologies.

What are ARIA live regions?

According to the W3C:

Live regions are perceivable regions of a web page that are typically updated as a result of an external event when user focus may be elsewhere.

In applications where content can update dynamically, users of assistive technologies may need to be updated about changes in those live regions. When we think of POUR we want our content to be perceivable. It is important that we ensure our webpage content can be identified even when it changes.

These changes in content can come from various sources. It could be the result of an API call to a third party that returned some data, a chat message appearing on screen, some user interaction, some AJAX update and much more.

The MDN docs state that:

Dynamic content which updates without a page reload is generally either a region or a widget. Simple content changes which are not interactive should be marked as live regions. WAI-ARIA provides us with a list of live region roles and attributes that allows us as authors to mark content as live regions.

Live region attributes

ARIA live region attributes provide a way for us as authors to mark any element as a live region. By doing so, assistive technologies such as screen readers will announce dynamic changes to their content even when we no longer have focus on them.

aria-live

This is an extremely important aria attribute.
By using the aria-live attribute on an element, we are marking it as a live region.

This attribute takes a priority setting as its value which tells the screen reader how it should announce changes to updated content. The value it takes for its priority setting can be one of the following:

off (default)

This is the default value for every element and is the same as if the attribute was omitted entirely. Users will not be notified of changes to any elements content and the element will not be marked as a live region. The only reason you should set this value is if you want to overwrite the aria-live value provided by an ARIA role.

<div aria-live="off">
//not a live region
</div>
// is the same as 
<div></div>

Enter fullscreen mode Exit fullscreen mode

polite

The polite value will mark the element as a live region and will ask the screen reader to announce changes to its content. However, it will not immediately announce it as it will wait until the screen reader is idle and no more announcements are taking place before doing so.

<div aria-live="polite">
//live region content
</div>

Enter fullscreen mode Exit fullscreen mode

assertive

The assertive value will mark the element as a live region and will announce the updated changes immediately as they happen and force the screen reader to stop its current operation. This will disrupt the current announcement of the screen reader and may very annoying for some users.

<div aria-live="assertive">
//live region content
</div>

Enter fullscreen mode Exit fullscreen mode

It is noted on the MDN docs that

the assertive value should only be used for time-sensitive/critical notifications that absolutely require the user's immediate attention.

aria-relevant

We can tell assistive technologies that only certain content is relevant to be announced on updates. We can do this by using the aria-relevant attribute. This attribute can take any number of the following four values:

  • additions

The addition of nodes within the live region is relevant.

<div aria-live="polite" aria-relevant="additions">
    // live region content.
   // only node additions are relevant
</div>

Enter fullscreen mode Exit fullscreen mode
  • removals

The removal of nodes within the live region is relevant.

<div aria-live="polite" aria-relevant="removals">
    // live region content.
   // only node removals are relevant
</div>

Enter fullscreen mode Exit fullscreen mode
  • text

Changes to the text content of existing nodes within the live region are relevant.

<div aria-live="assertive" aria-relevant="text">
    // live region content.
   // only text changes are relevant
</div>
Enter fullscreen mode Exit fullscreen mode
  • all

This is the same as using additions removals text

<div aria-live="polite" aria-relevant="all">
    // live region content.
    // all changes are relevant
</div>
// is the same as 
<div aria-live="polite" aria-relevant="additions removals text">
    // live region content.
    // all changes are relevant
</div>
Enter fullscreen mode Exit fullscreen mode

Note: When content is irrelevant, then it will not be announced by the screen reader which is the same as if we applied aria-live directly on that element.

The default value for this attribute is additions text.

<div aria-live="polite" aria-relevant="additions text">
    // live region content.
</div>

Enter fullscreen mode Exit fullscreen mode

The W3C have stated:

when the aria-relevant attribute is not provided, the default value, additions text, indicates that text modifications and node additions are relevant, but those node removals are irrelevant. aria-relevant values of removals or all are to be used sparingly. Assistive technologies only need to be informed of content removal when its removal represents an important change, such as a buddy leaving a chat room.

aria-atomic

When we have a live region and we know what content is relevant, the screen reader will announce what content has been updated. In some cases we want it to announce the entire live region even if it only has a small section of content that actually changed. This attribute takes a boolean (true or false). The default value for the aria-atomic attribute is false which means the screen reader only announces the updated content and not the content of the entire live region. In a lot of cases, this is perfectly fine but sometimes we may need aria-atomic to be set to true in order for us to get more context about the updated content.

Example

The following is an example using aria-live, aria-relevant and aria-atomic. See the MDN docs for more examples.

<p aria-live="polite">
    The Quiz leader is Gary Byrne with a score of <span id="score">70</span> points.
</p>
Enter fullscreen mode Exit fullscreen mode

This element has an aria-atomic value of false by default. If we try to update the score from 70 to 80 points then the screen reader only announces the change to a score of 80. The screen reader user may be confused as the announcement will not include the person's name.

<p aria-live="polite" aria-atomic="true">
    The Quiz leader is Gary Byrne with a score of <span id="score">70</span> points.
</p>
Enter fullscreen mode Exit fullscreen mode

Now that aria-atomic is set to true it will announce The Quiz leader is Gary Byrne with a score of 80 points whenever the score updates

aria-busy

The last attribute I want to talk about is aria-busy. If an element has a tonne of updates/modifications, we can use this attribute to tell the screen reader to pause live region announcements until these updates are completed. By default, the value for aria-busy is false which means it will try to announce every single update.

When aria-busy is true for an element, assistive technologies MAY ignore changes to content owned by that element and then process all changes made during the busy period as a single, atomic update when aria-busy becomes false - Digital A11Y

Live region roles

Live region roles are essentially ARIA roles that create live regions and can be changes by the above live region attributes. You can read more about these roles on the W3 docs.

Role Implicit aria-live Implicit aria-atomic
alert assertive true
status polite true
marquee off
log polite
timer off

Wrapping Up

If you enjoyed this blog and would like to see similar content in the future, or would like to get in touch then please follow me on Dev.to, Twitter and Hashnode.

Thank you for reading.

Top comments (0)