From W3C Wiki
< PF‎ | ARIA‎ | BestPractices
Jump to: navigation, search

Live Regions

Live regions are parts of a web page that the web page author expects to change. Examples of live regions include tables with dynamically updated content (sports stats, stock information), logs where new information is being added (chat transcript logs), notification areas (status, alerts), etc.

Live regions enable assistive technologies, such as screen readers, to be informed of updates without losing the users' place in the content. Live region settings provide hints to assistive technologies about how to process updates. Note that the assistive technology is responsible for handling these updates and enabling users to override these hints.

With the following process, rich Internet application (RIA) developers can set live region settings that will provide a good user experience for most assistive technology users with little configuration on their part.

Step 1: Identify the live regions

Live regions are any region on a page that receives dynamic updates. Note the regions of your page that will be live.

Step 2: Decide the priority of each live region

When a live region changes, should the user be notified of the change? Notifications could include a sound for a screen reader user. (For simplicity, we will use the case of an audio notification in this discussion.) The shorter the interval between changes and the less important the information, the less likely that the user needs hears every change. A simple example of changes that should not be heard are changes to time; a sound for every second would be very annoying.

If the user should hear the change, should the change be announced immediately, as soon as possible, or only when the user is idle. Announcing a change immediately can be disorienting for users, so that should be done sparingly. Most updates should probably only be announced when the user is idle.

After you have decided the priority for each live region, then decide the live property value:

  • Never spoken, then live="off"
  • Spoken when user is idle, then live="polite"
  • Spoken as soon as possible, then live="assertive"
  • Spoken immediately, then live="rude"

Step 3: Decide how much context is needed for each update

When part of a live region changes, how much context is needed to understand the change. Does the user need to hear the entire live region or just the change by itself?

If the user needs to hear the entire live region, then mark the entire live region with atomic="true".

Step 4: Decide what types of changes are relevant for each live region

Three possible types of changes are: additions, removals, and text. Additions are new nodes added to the DOM; removals are nodes removed from the DOM; and text are changes solely to the textual content. Should the user hear all types of changes or only certain types?

By default, the user will hear additions and text type changes. If you wish to explicitly define the types of changes, you need to set relevant="THE_TYPES_OF_CHANGES". If more than one type of change is relevant, the types are separated by a space. For example, to define additions and removals as relevant but not text, set relevant="additions removals".

Step 5: Decide if multiple output channels make sense

For most applications, a single output channel is sufficient. However, for complex applications with many updates happening simultaneously, multiple output channels may be adviseable.

If you need to use multiple channels, then you need to separate the live regions on your page and decide which ones should go into which channel. To specify a channel for a live region, you set channel="THE_CHANNEL". By default, channel="main"; you can specify a higher priority channel by using channel="notify".



One of the most important concepts behind live regions is politeness. Politeness indicates how much priority a live region has. The following politeness settings are possible: live="off", live="polite", live="assertive", and live="rude".


This is the default. Any updates made to this region should not be announced to the user. live="off" would be a sensible setting for things that update very frequently such as timers that change every second.


Any updates made to this region should only be announced if the user is not currently doing anything. live="polite" should be used in most situations involving live regions that present new information to users, such as updating news headlines.


Any updates made to this region are important enough to be announced to the user as soon as possible, but it is not necessary to immediately interrupt the user. live="assertive" should be used if there is information that a user should know about right away, for example, warning messages in a form that does validation on the fly.


Any updates made to this region are extremely important. In fact, the updates are so important that the user must be interrupted immediately. live="rude" should be used sparingly and only with great consideration as it can be very annoying to users.


When a live region is updated, the update can often be announced on its own and still make sense. For example, if a news headline is added, it would make sense to simply announce the headline. However, sometimes the entire live region must be read in order to give the user enough context to make sense of the update. For example, it would not make sense to only give the current value of a stock without saying the name of the stock. The atomic setting gives assistive technologies a hint about which of these cases an update falls into.


This is the default. It means that when there is a change in the region, that change can be presented on its own; the AT should not present the entire region. atomic="false" is generally a good idea as it presents users with only changes and does not cause them to hear repetitive information that has not changed. However, web developers should take care that the changed information, when presented by itself, can still be understood and contextualized by the user.


If atomic is set to "true", it means that the region must be presented as a whole; when there is a change, the AT should present the entire region, not just the change. atomic="true" can make it harder for users to understand changes as the changed areas are not presented independently. atomic="true" can also be annoying as it can force users to listen to repetitive information that has not changed. However, atomic="true" is necessary in cases where the change, when presented by itself, cannot be understood and contexualized by the user.


Not all updates to a live region are relevant. For example, if the oldest headline in a list of headlines is removed and a new headline is added, the removal of the oldest headline is probably not important enough to announce to the user. However, in a chat application, when a user leaves the chat and their username is removed from the list of users, that removal may be important enough to announce. The relevant setting gives a hint about what types of changes are relevant and should be announced. Any change which is not relevant will be treated as if the region had live="off" and will not be announced. Multiple types of changes can be listed as relevant; the types are separated by a space. The default is relevant="additions text".


relevant="additions" states that the insertion of nodes to the live region should be considered relevant.


relevant="removals" states that the removal of nodes to the live region should be considered relevant.


relevant="text" states that changes to the textual content of nodes that already exist in the live region should be considered relevant. Textual content includes text equivalents, such as the alt attribute of images.


Some notifications should be spoken before regular messages without causing the regular messages to be dropped. An example of such a notification is a chat message that is directed at the user. In such a case, that message should be spoken before the other chat messages, but the other chat messages should still be spoken and not just dropped. In addition, some AT users have both speech synthesis and Braille - they may prefer notifications to be delivered to the Braille display while regular messages are spoken by the synthesizer. channel={main/notify} gives web developers a way to provide a hint about which updates should be routed to which hardware channel, and in the case that only one channel is available, how the updates should be interleaved. The user agent defines the mapping between main/notify channels to the hardware channels available on the user's system.


This is the default. Messages in the main channel can only cancel out other messages in the main channel.


The notify channel is slightly higher priority than the main channel. If there are two messages of equal politeness waiting in both the notify and main channels and there is only one output channel, the message in the notify channel will be processed first. However, if the politeness values are different, then the message that is less polite will be processed first, regardless of which channel it is in. Messages in the notify channel can only cancel out other messages in the notify channel.

Example 1

The user is on an AT that supports only a single hardware channel.


Both live regions get updates that are "polite" simultaneously. liveRegionB should be spoken first since it is on the notify channel.

Example 2

The user is on an AT that supports only a single hardware channel.


Both live regions get updates simultaneously. liveRegionA should be spoken first, because its message has a higher priority than liveRegionB.

See Also

Explanation of Live Region Use