Aria-live: announce DOM changes
When an action changes your page contents, sometimes it's hard to see where. Even harder if you're not watching it change!
Aria live
JS allows us to add, modify and remove all kinds of stuff from the page: in a more technical way, we can say that “JS lets us modify the page DOM”. This is a great feature, but mainly if you can see changes happen. If you use an SR and something changes before (but also in other places of the page) the part the screen reader's cursor is in, you will never know.
Aria-live attribute lets the browser (and so the user) be aware that something, somewhere on the page, has changed. This attribute can be applied to any HTML element and we have three values and behaviours it can have:
aria-live=”off” : SR only announces the change if the focus is currently inside the aria-live. It's the default value for all the elements, but it could be useful to know if you want to "deactivate" an aria-live.
aria-live=”polite”: announces the change when possible, for example at the end of the current reading line.
aria-live=”assertive”: announce is immediate. Useful for example, to announce errors or time critic messages.
Be aware: this attribute should be present BEFORE the change occurs!
Other attributes of aria-live
aria-atomic=true (or false): if true SR reads the whole area, if false (default) only the part that has changed.
aria-relevant=”value”: you can add one or more values, separated by a space, to specify which changes should trigger the reading. Values can be “additions”, “removals”, “text” and “all” (default is “additions text”).
Argh, my aria-live is not working!
Calm down, you're not alone, we've all been there. Try the following to troubleshoot possible problems: I've listed the most common ones:
First and foremost, different screen readers behave differently, sometimes even between different versions of the same SR! When testing, use different screen readers: it could be a software bug, not your fault. But try to address the bug to the software house and try thinking of another way to obtain the expected result.
Toggling the visibility of an element inside the aria-live doesn't automatically trigger the aria-live. You'll find around the web that playing with "display: none", "visibility: none", "hidden" or "opacity" triggers the aria-live behaviour. Unfortunately, this is not reliable at all, and I've spent a lot finding that.
Aria-live attribute should be present at the initial page load ('cause SR usually scan the whole document): try not to add aria-live with js, it may not work.
Announcements stack in line and are announced one after the other. Firing an “assertive” message could possibly clear the other “polite” messages: consider this carefully if you plan to have lots of aria-live announcements
Specific aria-live roles
some elements can have a specific role that addresses them as “elements used for display notifications and messages to the user”.
role=”alert”: has implicitly aria-live=”assertive”. This means that if you're attributing the role “alert” to an element you don't need to specify aria-live too.
role=”log”: has implicitly aria-live=”polite” and aria-atomic="false". This piece of information is added in a meaningful order, added only to the end of the list, and suggests that old logs may disappear. Logs must have a visible label. You shouldn't give them focus to not interrupt the user actions or flow.
role=”status”: has implicitly aria-live=”polite” and aria-atomic="true". Status contains useful status infos that are not so critic to become alerts. You shouldn't give them focus to not interrupt the user actions or flow.
role=”progressbar”: has implicitly aria-live=”polite”. Gives feedback on a requested action. Its detailed description is out of scope here, but mind that has various properties to define to make it work.
role=”marquee”: has implicitly aria-live=”off”. Contains info that changes frequently and that are not important, usually, to be announced.
role=”timer”: has implicitly aria-live=”off”. The only content should be a value that is updated at regular intervals, and contain an aria-label to specify what that number means! Be particularly cautious when implementing time-critic actions when dealing with users that don't see the page...