Would you like a live region?
Hello, and welcome to my travelling ARIA medicine show. I've got a little of everything here -- some combobox roles, maybe you want some selection, or even a tooltip! Have you ever experienced any of the following symptoms: hating your users, wishing you could take someone by the shoulders and yell at them, enjoying listening to a podcast while reading, talking during movies — you might like… LIVE REGIONS!
Ingredients
The Pitch
Practical Examples
Testing
(just apply debouncing based on typing!)
sometimes live regions can make users bounce out of their chair, which is why you sometimes need to debounce.
note: you could also just do this with a live region, depending on your specific needs. Sometimes live regions are NOT the answer. Don't worry, Dr. ARIA has a range of products available for purchase.
Do you:
Like using all caps?
Sometimes wish you could yell specifically at people using a screen reader?
Try Dr. Aria's Live Regions
Hello, and welcome to my travelling ARIA medicine show. Have you ever experienced any of the following symptoms: hating your users, wishing you could take someone by the shoulders and yell at them, enjoying listening to a podcast while reading, talking during movies — you might like… LIVE REGIONS!
Side effects may include:
side effects may include: users swearing at their computers, abandoning your app, spontaneous combustion, and developing a deep personal hatred of you, specifically.
Not intended for:
young children, the elderly, anyone with a heart condition, or who is experiencing stress, anxiety, or anyone who enjoys peace and quiet.
< pause for tomato throwing >
ok, okay, OK! Fine, I've just been made aware that I'm not allowed to use this platform to sell things to you.
(But, you know, if you're interested, see me afterwards.)
What is a notification?
It has come to my attention that "some" of you want to be "responsible" and "do the right thing"
So, under great duress, let's go over some definitions
What is a live region?
Is it a notification?
Yes! A live region is a notification, but more specifically for screen reader users (or rather: a bit more complicated, braille too. Sort of.)
aria-live="assertive"aria-live="polite"role="alert"role="status"
The other stuff doesn't matter. No, really. Don't sweat it. It's not _relevant_ (pun pun)
Practicum
role="alert" insertion
This is the experience of having elements with role alert dynamically inserted into the DOM as you move focus. Maybe not ideal, but it works.
Slowed down the speed of updates to make this clearer.
Find notification terms
REMEMBER: Type into the actual slide, not the notes.
Just to hammer this home a little more, what if we go for a visual metaphor. This is a filter/results pair, another good potential use for a live region
Because I can see, this works really well. As I type, I can immediately see feedback on what results are returned, and catch any typos.
Find notification terms
WARNING: there will be flying cats across this screen.
Now I've added a small visual aid to show what it's like when you have an overly verbose, too frequent live region on the page. It interrupts everything, is extremely distracting, and can prevent you from perceiving what is going on with the UI control you want to interact with.
But how do I apply live regions here? Help!
Don't worry, I have the answer to everything, just as a responsible vendor of reputable products should.
No but actually -- you can't just batch updates, since that can still conflict with typing
Don't worry!
Dr. ARIA's patented live regions can fix every ailment!
(just apply debouncing based on typing!)
sometimes live regions can make users bounce out of their chair, which is why you sometimes need to debounce.
note: you could also just do this with a live region, depending on your specific needs. Sometimes live regions are NOT the answer. Don't worry, Dr. ARIA has a range of products available for purchase.
function onInput(event) {
// cancel the timeout any time a user types
clearTimeout(id);
// start a new timeout to announce a message
// if the user stops typing
id = setTimeout(() => {
announce('10 results found');
}, 500);
}
Find notification terms
There is a 500ms delay after the last user input before the live region -- er, cat -- fires. This is somewhat arbitrary, but did fine in a user study.
It also works here!
This is another common use case where you want to debounce error messages based on typing.
Based on a user study I did a while ago, I would recommend firing a live region when the user approaches the limite (e.g. at 10-20 characters remaining, depending on length), and when the user has surpassed the limit. Only after the 500ms typing throttle, of course.
WARNING:Please consult a doctor for any of the following:
More than one simultaneous loading region
Using a live region to communicate what a focus change already did.
screen readers can only say one thing at a time, so live regions at the same time as a focus change will war with eachother.
You can't control when the user moves focus, but you should always avoid firing a live region together with a programmatic focus change.
Example: in a SPA, you should set focus to some part of the new content (maybe the top heading) when you navigate to a new route. Do not do this with live regions.
Wrapping any type of input in a live region
this actually happened, because the input changed an invalid value on blur, and someone had the bright idea to let people know by wrapping the input in a live region. Any guesses about what that does?
YES. It double-keyboard-echos, yay.
Wrapping any major section of changing content in a live region
This really happened, several times.
Side effects include:
Headaches, nausea, dizzyness...
No control over timing and frequency of updates
No control over visual vs. announced verbosity
No ability to filter out repetitive & supplementary content
Too many announcements that are too verbose
Let's actually dive into this a bit more using a chat pane, because it's the perfect example of multiple complex
Chatbots: a shallow dive
Chat bots are great because they have a little of everything: asynchronous updates, loading/loaded states, multiple possible sources for announcements (e.g. a new chat at the same time as uploading a file), and the need for the live region text to differ from the visual text content.
Also this is a place where you absolutely need to have
Field testing snake oil live regions
TWO Examles: first: what is a cat, then why is a cat, with different lengths of loading.
There may be semi-frequent visual updates to loading text on the screen, but that is less disruptive than having a live region fire. Also be careful of too much constant visual change.
Loading updates should be every 5 seconds, not based on visual changes. Re-announce the same text if needed, if there are no visual changes.
positive feedback to this cadence in user research. could potentially consider a setting to customize it, but that is low priority.
Be intentional about message text
CatBot said: The earliest known indication for the taming of an African wildcat was excavated close by a human Neolithic grave in Shillourokambos, southern Cyprus, dating to about 7500-7200 BC.
When a message is loaded and fully inserted, include the full message text, but also only the message text with a "Person said:" prefix.
Do NOT include action buttons, etc.
Do NOT wrap streaming content in a live region
I've seen this in the wild (the streaming content thing, not the baby heroin pictured ono screen). JAWS got stuck in a loop constantly re-reading increasingly long snippets of the message text.
Also don't give heroin to babies, I guess
It can be good!
“That’s really what you’d like it to do, right, is just read it automatically so I don’t have to look around.” - Jennifer
“I really liked whenever I pressed enter, you know, I liked how it said “generating reply, generating reply, still generating reply, that part was actually pretty cool. And I also liked how it actually read out the response — the entire response.” - Miguel
One of the most consistent pieces of feedback on the chat user studies I've run is that screen reader users really like the ability to hear loading updates / confirmation that something happened, and listen to the entire message text without moving focus from the input.
BUT. Live regions everywhere ≠ good
Do not generalize this advice! This is a very considered application of live regions in a very specific scenario.
Do NOT NOT NOT use live regions to read everything that is happening in your page or app
Do NOT use live regions to build a custom in-page screen reader
if I had a dollar for every time this has been suggested to me... I'd have maybe 10 dollars. Which is not a lot, but it's worrying that it's happened that many times.
Any sufficiently complex application should have central live region handling
Handle batching back-to-back loading/loaded announcements
Only need one live region node in the page
Allows components to fire a live region on insertion
Better testing and debugging
Genuinely one of the most painful parts of live regions is debugging them when something goes wrong. Doing this lets you abstract the DOM implementation and assert against a single stable function.
Testing
Speaking of having better testing and debugging, let's examine that a bit more.
With accessibility in general, the best laid plans often go astray, which is trebly so for live regions.
First: authoring error?
Check the following:
The live region exists on the page before text is added
Is there a simultaneous conflicting event, e.g. a focus change?
Is the live region outside an open dialog?
Is the live region actually updating its inner text?
Second: browser or screen reader error?
Check the screen reader speech log for immediately overridden text
Advanced: check the API events
Live debugging: MutationObserver
function observeElement(element) {
const config = {
attributes: true,
childList: true,
subtree: true
};
const callback = function(mutationsList, observer) {
for(let mutation of mutationsList) {
if (mutation.type === 'childList') {
const additions = mutation.addedNodes;
const removals = mutation.removedNodes;
// etc.
code: MutationObserver gist
Closing thoughts
Notification center
If you're buliding something with notifications that are persistently relevant (if you have toasts, this is a good indication that you are), strongly consider building a notification center.
This is a heavy lift, but people WILL miss toasts. Screen reader users will miss live regions sometimes even if you do everything right, and magnification users especially will miss toasts.
Let people review things, and take the stress away.
Also you can potentially add settings here, for example around the frequency and verbosity of loading updates in chat.
ariaNotify
ariaNotify('Help my web page is yelling at me');
This is still being spec'd out, but there is an ARIA proposal for non-DOM-based screen reader notifications.
It would also potentially help resolve or at least standardize conflicts between notifications and user-initiated information. This depends on screen reader vendors implementing it, since they control the speech queue.
Also has the potential (emphasis on potential) for greater user customizability in screen reader behavior, e.g. between braille displays and speech output, or at a stretch, ear cons. This bit is still very much up in the air though.
If anyone has a complex or unique use case where you'd want to use this, I'd be interested to hear about it after.
Remember:
ariaNotify('do not SCREAM at your users');
Only scream at developers
(who abuse live regions)
