I wrote about the W3C's Web Accessibility Initiative - Accessible Rich Internet Applications (WAI-ARIA)'s live region properties 6 years ago, but the WAI-ARIA specification has changed significantly in that time, and the details in that article are now outdated. The examples in the original article used XHTML namespaces, which are irrelevant now that WAI-ARIA is supported in HTML5.
The original out-of-date article now redirects to this entry, which provides more information on live regions and how to use them, along with roles that have implied live regions.
Author: Gez Lemon
Rich Internet Applications
A significant issue that the WAI-ARIA specification addresses is where parts of the page are updated without informing assistive technology users, using live regions.
Live regions inform assistive technology users of updates in the document without the user losing focus from their current activity. For example, announcing changes in a table that is dynamically updated with stock information. Live regions can also be used to aid the understanding of complex widgets. For example, Hans Hillen uses a hidden live region to announce how many items are returned in his example of an auto-complete widget, along with instructions to use the cursor keys to navigate through the list, as support for autocomplete isn't that good without this context at the moment. The following properties are used to define a live region.
The aria-live property indicates a section within the content that is live and the verbosity in which changes shall be announced. The following values may be used to determine the verbosity.
- The default value that indicates that a region is not live, and changes will not be announced.
- The update should be announced at the next graceful interval, such as when the user stops typing.
The update is announced to the user immediately. As this is obtrusive, a value of
assertiveshould only be used when the update is important and the user should be informed immediately.
In the following example, text changes or additions to the unordered list, they will be announced to the user.
The aria-atomic property is an optional property that can have the values
false (default). When the region is updated, the atomic property is used to indicate if assistive technologies should present all or part of the changed region to the user, and is influenced by the aria-relevant property. If the
aria-atomic property is set to
true, assistive technologies should present the entire region as a whole depending on the
aria-relevant property; otherwise, the part of the region that changed might be announced on its own.
Sometimes, updates make sense on their own, such as a new line arriving in a chat application. Other times, changes in the content may not make sense without the context of other parts of the region. In these cases,
aria-atomic="true" should be set on the relevant container so the region is presented as a whole. In the following example, if a change is made anywhere in the
div element, the whole content is announced to the user.
The aria-relevant property is an optional property used to indicate the type of update that should be announced within a region: see changes to document content or node visibility for technical details. The
aria-relevant property accepts a space separated list of the following property values:
- Announcements are made when elements are added to the DOM within the region or the CSS display state reveals hidden text in the region.
- Announcements are made when elements are removed from the DOM within the region or the CSS display state hides text in the region.
- Announcements are made when text is added or removed from the DOM or the CSS display state changes.
- All of the above (
text) apply to this region.
In the absence of an explicit
aria-relevant property, the default is to assume there are text changes and additions (
aria-relevant="text additions"). In the following example, only additions to the unordered list will be announced to the user.
The aria-busy property should be used when the region is busily being updated, and stops updates being announced before they are complete. Setting
aria-busy="true" on the region suppresses announcements until the attribute is removed, or the value changed to
false. Assistive technologies collate the changes, and announce them when the region is no longer busy. In the following example, nothing is announced while the list items for the unordered list are being gathered. When the developer set
aria-busy="false" or removes the
aria-busy attribute, the unordered list will be announced.
Roles with live regions
WAI-ARIA also defines some roles that have live regions.
The alert role is used to provide important information immediately to the user. A role of
alert is an assertive live region, meaning the message will be delivered to the user immediately.
The status role is used to provide advisory information to the user that isn't important enough for an alert. A role of
status has an implicit
aria-live value of
polite, but this doesn't necessarily mean it will be announced to the user. Authors can use the
aria-live property on the region to override how it's usually handled by assistive technologies.
The timer role marks a region that contains a counter that represents either elapsed or remaining time that are updated as time changes until the timer is paused or completes the time count. A role of
timer is a live region with an implied
aria-live value of
The marquee role is used when non-essential information changes regularly. A role of
marquee is a live region with an implied
aria-live value of
off. If you use marquees, ensure you provide a simple provision to stop it scrolling and updating, as they can be distracting and annoying.
The log role is used for regions where new messages are added at the end of the log, and older messages may disappear from the log, such as a chat log or messages in an error console. A role of
log has an implicit
aria-live value of
polite. If a text area is used to send updates to the region with a role of
log, the aria-controls attribute should be used to define the relationship.
For further information about using WAI-ARIA's live regions, see the authoring practices guide for WAI-ARIA on managing dynamic changes.
Explicit labels should also be provided for live regions, and long descriptions should also be provided for complex live regions. If a page contains multiple live regions, users of assistive technology will need to know which live region is furnishing the update, as they will be unable to review the announcement in the content of its surrounding content on the page. For further information see https://www.webaccessibility.com/best_practices.php?technology_platform_id=121
Posted by Sam on
Do you know of any good information on support in assistive tech for these properties, and ARIA in general? Specifically JAWS and Mac VoiceOver.
There's a good (but old) support table for roles here: http://www.html5accessibility.com/tests/landmarks.html - but do you know of anything more up to date, or more detailed?
Posted by Andy Hume on
I'm not aware of any good information for AT support on ARIA, other than html5accessibility, but I'll ask around. I'll mention your request to Steve, as he may have plans to update it.
Posted by Gez on
Hi Andy, Gez, I plan to update when i get time, there is not a lot of support tables out there. The JAWS doc http://www.paciellogroup.com/blog/2010/10/jaws-support-for-aria/ on ARIA support is useful and Accessible Cutlure http://www.accessibleculture.org/tag/wai-aria/ has some useful info.
Posted by steve faulkner on