Description
In this modern web, it is very common to have dynamic updates/changes on the web. If you are wondering what the dynamic changes on the web is then here is the explanation. Dynamic changes are nothing, but the parts or portion of the web page gets updated without reloading the entire page and it is as simple as that. The examples could be chat log, stock ticker, cricket score board, ticket’s price list, search result on the fly, and so on. That said, When the dynamic changes/updates take place on the web then it is visually apparent that something is going on. However, same may or may not be communicated to the screen reader users as screen reader users can interact with only one part of the page at a time and they may not aware of the changes that are taking place at the other part of the page. If the update about the changes is not communicated/notified to the assistive technology users, then it is going to be nightmare for the users. It is important that authors need to communicate/notify these changes to screen reader users to make sure that users of screen reader are not lost on the web page.
ARIA introduces aria-live attribute or live roles to communicate/notify these dynamic changes to the screen reader users without moving their focus. Let us discuss more about aria-live in this post. Aria-live Indicates that an element will be updated, and describes the types of updates the user agents, assistive technologies, and user can expect from the live region. To put it simpler, as soon as we set aria-live on any HTML container, the HTML container becomes live region. whatever the changes that are taking place in this container, assistive technologies will notify those changes to the users based on the value of the aria-live that we have set. The value of aria-live attribute is token and it accepts 3 values. The accepted values of aria-live are assertive, polite, and off, and will discuss in-details of purpose of all these values in the author notes section of this post.
Author notes
- Aria-live can be used on any base markup and it is the global attribute
- The default value of aria-live is off for all elements
- Authors need to set the value of aria-live as assertive(aria-live=”assertive”) only if the updates are critical(like user name and password are incorrect). The reason is that assertive value interrupts the user’s current task and notify the updates immediately
- Authors need to set the value of aria-live as polite(aria-live=”polite”) only if the updates need to be notified by assistive technology at the next graceful opportunity. The reason is that polite value does not interrupts the user’s current task and notify the updates at the next graceful opportunity, such as at the end of speaking the current sentence or when the user pauses typing.
- Authors need to set the value of aria-live as off(aria-live=”off”) when the updates need not to be notified to the assistive technology users
- Authors sometimes use hidden live regions to notify the important updates to the screen reader users. It is important to remember that these hidden live regions must be removed from the DOM as soon as the purpose is accomplished. Failing to do so results the screen readers to read the same live region content in the browse mode/reading mode without any context and this creates confusion to the users like why that text is present and so on.
- if multiple changes to a live region should be spoken as a single unit of speech then follow the below steps
- For robust support, it is advised to include aria-live always in the initial markup itself but do not add the aria-live container dynamically with the script. Even author wants to add aria-live container dynamically to the DOM with the script(better to avoid this approach as much as possible), it is important to maintain some time delay to insert the dynamic message in the dynamic container for screen readers to pick this dynamic message.
Do not do this:
<div class=”will-change”>
<!—both live container and content within the live container will be updated with Javascript –>
</div>
<script>
document.querySelector(“.will-change”).setAttribute(“aria-live”, “polite”);
document.querySelector(“.will-change”).textContent = “New content!”;
</script>
Instead, Do this:
<div aria-live=”polite” class=”will-change”>
<!– content will be updated with Javascript –>
</div>
<script>
document.querySelector(“.will-change”).textContent = “New content!”;
</script>
Sample code snippet
Here are sample code snippets for all the 3 different values
<h1>Polite</h1>
<button onclick=”updateContent(‘msg’)”>To view the updates, click this button!</button>
<br/> <br/>
<div id=”msg” role=”region” aria-live=”polite” id=”msg”></div>
<h1>Assertive</h1>
<button onclick=”updateContent(‘msg2’)”>To view the updates immediately, click this button!</button>
<br/> <br/>
<div id=”msg2″ role=”region” aria-live=”assertive” id=”msg”></div>
<h1>Off</h1>
<button onclick=”updateContent(‘msg3’)”>No updates will be announced, so don’t click this button 😂!</button>
<br/> <br/>
<div id=”msg3″ role=”region” aria-live=”off” id=”msg”></div>
Complementary info on aria-live
authors sometimes use CSS attributes(from display:none to display:block and vice-versa) to show and hide the dynamic message in the live container in order to notify the message to the screen reader users. However, this may not work as expected in some of the screen readers. It is better to use script to inject the dynamic message in the aria-live container in order to get robust support in most of the screen readers.