ARIA live regions are a feature of the Accessible Rich Internet Applications (ARIA) specification. The ARIA spec is a set of attributes that can be added to HTML elements to make web pages more accessible for users with disabilities.

ARIA live regions are used to provide real-time updates for dynamic content such as live sports scores, chat messaging, stock prices, notifications, etc.

Relevant HTML attributes

When it comes to live regions there are a few relevant HTML attributes.

aria-live

The aria-live attribute is used to specify that an element is a live region. It can be added to any HTML element, but it is typically added to a container element that contains the dynamic content that needs to be updated.

The aria-live attribute accepts one of three values:

• off: Indicates that updates to the live region will not be announced to the user (this is the default value).
• polite: Indicates that updates to the live region will be announced to the user at the next available opportunity, without interrupting the user's current task. This is the most common value to use.
• assertive: Indicates that updates to the live region will be announced to the user immediately, interrupting whatever the user is currently doing. This value should be used sparingly as it can be disruptive.

aria-relevant

The aria-relevant attribute is used in conjunction with the aria-live attribute to indicate which updates to a live region should be announced to the user. In other words, the aria-relevant value dictates which types of changes to the DOM trigger an announcement.

The aria-relevant attribute is used to specify a space-separated list of one or more of the following values:

• all: Indicates that all updates to the live region should be announced. Shorthand for additions removals text.
• additions: Indicates that updates that involve the addition of content to the live region should be announced.
• removals: Indicates that updates that involve the removal of content from the live region should be announced.
• text: Indicates that updates that involve changes to the text content of the live region should be announced.

The default value for aria-relevant is additions text. Changes are announced when element nodes are added to the accessibility tree within the live region and text content or a text alternative is added to any descendant in the accessibility tree of the live region.

<div aria-live="polite" aria-relevant="additions">
  <ul id="live-updates">
    <li>Initial content</li>
  </ul>
</div>

In the example above, updates to the content inside the <ul> element that involve the addition of content will be announced to the user at the next available opportunity, without interrupting the user's current task.

aria-atomic

The aria-atomic attribute is used in conjunction with the aria-live attribute to indicate how updates to a live region should be announced to the user.

By default, the aria-atomic attribute is set to false and only the changed parts of the live region are announced. This can be useful when the live region contains a large amount of content that is frequently updated, and it's not necessary for the user to be aware of all the updates at once.

When the aria-atomic attribute is set to true, the entire live region will be announced every time it is updated. This can be useful when the live region contains a small amount of content that is frequently updated, and it's important for the user to be aware of all the updates at once.

<!-- 
If there is a new notification, "Static content" will be announced along with the notification. 
-->
<div aria-live="polite" aria-atomic="true">
  <p>Static content</p>
  <div id="notification"></div>
</div>

<!-- 
If there is a new notification, only the new notification will be announced. 
-->
<div aria-live="polite">
  <p>Static content</p>
  <div id="notification"></div>
</div>

Even though the default value is false we should still include aria-atomic="false" rather than omitting it.

<!-- Good -->
<div aria-live="polite" aria-atomic="false">
  <p>Static content</p>
  <div id="notification"></div>
</div>

<!-- Slightly less good -->
<div aria-live="polite">
  <p>Static content</p>
  <div id="notification"></div>
</div>

Including the attribute gives the user performance benefits. From the MDN documentation on aria-atomic:

When the content of a live region changes, the DOM is traversed from the changed element through its ancestors to find the first element with aria-atomic set. This determines the content that the user should be presented with.

If no ancestor has explicitly set aria-atomic, only the node or nodes of live region content that have been updated are read. The difference between omitting aria-atomic altogether and explicitly setting an ARIA live region's ancestor node with aria-atomic="false" is that explicitly setting aria-atomic="false" will stop the screen reader from going up the ancestor chain. Both lead to only the updated node being read. When set to aria-atomic="true", the entire changed region as a whole will be presented.

aria-busy

The aria-busy attribute is used to indicate an element is being modified and that assistive technologies may want to wait until the changes are complete before informing the user about the update.

When multiple parts of a live region need to be loaded before changes are announced to the user, set aria-busy="true" until loading is complete. Then set to aria-busy="false". This prevents assistive technologies from announcing changes before updates are done.

Practical examples

It's important to note that while the aria-live attribute is used to indicate that an element is a live region, it alone is not enough to make the dynamic content accessible. The updates to the content must also be properly structured and labeled in order for assistive technology to be able to announce them to the user.

Let's take a look at some contrived but practical examples.

Notifications

Here is an example of how a live region could be used to provide notifications:

<div aria-live="polite" id="notification-container">
  <div id="notification"></div>
</div>

<script>
  const showNotification = message => {
    const notification = document.getElementById('notification');

    notification.innerHTML = message;

    setTimeout(() => {
      notification.innerHTML = '';
    }, 5000);
  };
</script>

The time that the message is displayed should be enough for the user to read and understand it but not too long that it becomes annoying or irrelevant.

Let's see this concept in action with a more practical example.

Form submission

Here is an example of how a live region can be used to improve accessibility for a form.

<form>
  <div aria-live="polite" id="form-notification"></div>

  <label for="name">Name:</label>
  <input type="text" id="name" name="name" />

  <br />

  <label for="email">Email:</label>
  <input type="email" id="email" name="email" />

  <br />

  <button type="submit">Submit</button>
</form>

<script>
  const showNotification = message => {
    const notification = document.getElementById('form-notification');

    notification.innerHTML = message;

    setTimeout(() => {
      notification.innerHTML = '';
    }, 5000);
  };

  const submitForm = event => {
    event.preventDefault();

    const name = document.getElementById('name').value;
    const email = document.getElementById('email').value;

    if (!name) {
      showNotification('Please enter your name.');
    } else if (!email) {
      showNotification('Please enter your email.');
    } else {
      showNotification('Thank you for submitting the form!');
    }
  };

  const form = document.querySelector('form');

  form.addEventListener('submit', submitForm);
</script>

Now we have an idea of how this works in response to user input. But how should we handle a situation where we need to notify the user otherwise?

Real-time updates on a news website

Here is an example where we fetch breaking news updates from a news API:

<div aria-live="polite" id="breaking-news-updates">
  <h2>Breaking News</h2>
  <ul id="breaking-news-list">
    <li>No breaking news at this time.</li>
  </ul>
</div>

<script>
  setInterval(() => {
    fetch('https://newsapi.org/v2/top-headlines?country=us&apiKey=your_api_key')
      .then(response => response.json())
      .then(data => {
        const breakingNewsList = document.getElementById('breaking-news-list');

        breakingNewsList.innerHTML = '';

        data.articles.forEach(article => {
          const li = document.createElement('li');

          li.innerHTML = article.title;

          breakingNewsList.appendChild(li);
        });
      });
  }, 10000);
</script>

It's best practice to provide a default, or "initial" value that will be announced when the page loads. That way, users of assistive technology will have an understanding of the context of the live region.

Best practices

Here are some best practices to consider when implementing ARIA live regions:

1. Use the appropriate aria-live value. Use polite unless you have a specific reason to use assertive. Only use off if you don't want the live region to be announced to the user.
2. Update the live regions only when it's necessary. You should try to avoid updating the live regions unless it's necessary. This will prevent users of assistive technology from being overwhelmed with too many updates. Use aria-atomic and aria-relevant to support the appropriate experience.
3. Provide default or "initial" values. As mentioned earlier, it's best practice to provide a default or "initial" value that will be announced when the page loads so users of assistive technology will have an understanding of the context of the live region.
4. Limit the number of live regions. It is best practice to limit the number of live regions on a page. Having too many live regions can be overwhelming for users of assistive technology.
5. Use clear and concise updates. The updates that are announced to the user should be clear and concise. Avoid using jargon or technical terms that might be confusing to users of assistive technology.
6. Leverage the aria-busy attribute when multiple parts of a live region need to be asynchronously loaded before changes are announced.
7. Test your live regions. It's important to test your live regions with assistive technology and with users who have disabilities to ensure that they are accessible and easy to use.

By following these best practices you can ensure that your ARIA live regions are accessible and easy to use for all users, including those who rely on assistive technology.

Next steps for developers

As a developer, implementing ARIA live regions in your web development projects is an important step in making your application accessible to all users, including those who rely on assistive technology.

Here are a few tips for getting started with ARIA live regions:

1. Start by familiarizing yourself with the ARIA live regions specifications and best practices.
2. Identify areas in your application where real-time updates, notifications, or dynamic content is present, and consider how you can use live regions to improve accessibility.
3. Use the aria-live, aria-atomic and aria-relevant attributes to indicate how updates to a live region should be announced to the user.
4. Test your application with assistive technology and make sure that updates to live regions are being announced correctly.
5. Remember to always provide an initial value or context for the live region so that users of assistive technology have an understanding of the context of the live region.

By following these tips and incorporating ARIA live regions into your web development projects, you can help make your application more accessible to all users.