In this article, we will look at ARIA live regions and how they can be used to expose information to assistive technologies.
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.
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.
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:
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>
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>
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>
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.
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:
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>
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>
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>
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>
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
<div aria-live="polite" aria-relevant="additions text"> // live region content. </div>
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-relevantvalues 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.
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.
The following is an example using
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>
This element has an
aria-atomic value of
false by default. If we try to update the score from
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>
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. If we wanted to be more explicit in this example we know that only text changes within an existing node occur so we could add
<p aria-live="polite" aria-atomic="true" aria-relevant="text"> The Quiz leader is Gary Byrne with a score of <span id="score">70</span> points. </p>
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 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|
Thank you for reading.