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

When developers first built rich internet applications using a combination of HTML, CSS, and JavaScript, people with disabilities were left behind because those applications failed to provide the semantics required to be understood by assistive technologies. Sadly, not much has changed over the years, but that doesn't need to be the case. WAI-ARIA is capable of providing sufficient semantics to ensure rich internet applications can be understood, and is now relatively well supported.

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

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

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 assertive should 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.

Using aria-live="polite"
<ul aria-live="polite">
  <li>Item 1</li>
  <li>Item 2</li>
  <li>item 3</li>

The aria-atomic property

The aria-atomic property is an optional property that can have the values true or 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.

Announcing the region as a whole
<div aria-live="polite" 
  <h3>Currently playing</h3>
  <p>Jake Bugg - Lightening Bolt</p>

The aria-relevant property

The aria-relevant property is an optional property used to indicate the type of update that should be announced within a region. 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
Announcements are made when elements are removed from the DOM within the region
Announcements are made when text is added or removed from the DOM
All of the above (additions, removals, 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.

Announce additions to the region
<ul aria-live="polite" 
  <li>Item 1</li>
  <li>Item 2</li>
  <li>item 3</li>

The aria-busy property

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.

Temporarily stop updates being announced while busy
<ol aria-live="polite" 

Roles with live regions

WAI-ARIA also defines some roles that have live regions.

The alert role

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.

Role of alert
<div role="alert">
  Maximum amount reached.

The status role

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.

Role of status
<div role="status">
  3 new messages in inbox.

The timer role

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 off.

Role of timer
<div role="timer">

The marquee role

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.

Role of marquee
<div role="marquee">
  Marquee text.

The log role

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.

Role of log
<div role="log" id="chatarea">
  <span class="name">Dave: </span> What time will you be finished?
  <label for="chat">Chat: </label>
  <input aria-controls="chatarea"

For further information about using WAI-ARIA's live regions, see the authoring practices guide for WAI-ARIA on managing dynamic changes.

Category: Accessibility.


  1. [wai-aria_live-regions_updated.php#comment1]

    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

    Posted by Sam on

  2. [wai-aria_live-regions_updated.php#comment3]

    Hi Andy,

    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

Comments are closed for this entry.