ARIA-live: The Harbinger of Dynamic Content
(If you don’t already know what ARIA live regions are, you might want to first check out MDN’s article about aria-live regions, as the following article is specificly about when to use aria-live.)
It is a common misconception that aria-live should be used directly on all container elements that contain dynamic content, i.e. content that may change without a page reload. At first glance, it might sound like aria-live is a brilliant way of telling a screen reader to automatically start reading even huge blocks of text that dynamically appear on the webpage. Except… no. Let me explain what happens.
The screen reader starts reading the new text. From start … to end. The user may interrupt the reading, but that’s about it. The user is offered no methods for skimming, rewinding, repeating, reading words letter by letter, or any other way of navigating the content. All the keystrokes that the screen reader offers for these things will apply for text at the current position of the virtual cursor, which is usually not even where the live region is located.
This is not a design flaw with ARIA live regions. It’s just not the best use of the feature. As long as the user is made aware of what and where something is changing on the page, then the user is capable of navigating to that location and start reading the new content on their own, in the way that they prefer.
You can think of it this way. Screen readers queue up text that should be read to the user, just like a pile of post-it notes on your desk. Except screen readers can’t selectively choose entries from the queue. The only way of discarding a message is by emptying the entire queue. Imagine if that was the case with your pile of post-it notes, and then somebody drops today’s newspaper on top of it. At that point you have two options. Either you can spend an indeterminate amount of time reading everything, or you can discard it all and hope that no important notifications were also in the queue at the time. As an experienced user of screen readers, I can assure you that this yields a sense of frustration.
Live regions are good for announcing important changes, relaying notifications, or reading incoming messages in a chat window. They should not be used on large blocks of content that will likely require non-linear navigation or interaction, such as a result list on a search page after the user clicks the Next button in a paginator. If the latter had been desirable, then we could have just added aria-live=polite” and aria-atomic=”false” to the body element itself and be done with it.
Bottom line: Please try to be mindful of what you code your applications to automatically inject into the queues of screen readers. You could ask yourself:
- Is it likely that the user would want this region of dynamic content to be automatically injected into the read queue?
- Is it likely that the user would be happy about reading new content linearly in this region?
- If it’s not just a notification area, is it easy for the user to infer the location of new content based on context?
Unless you can say yes to these questions, aria-live is probably not the right choice for that region of dynamic content. Instead, you might want to consider a technique where a separate live region is used to simply announce the arrival (or removal) of content, assuming the event is relevant for the user.
