Accessibility Quick Wins: Multiple aria-live on single action, Caveat!
Quite posssibly, you are already aware that aria-live can be used to inform users of any dynamic changes that have happened on the application as a result of an external event or a user action, for example, form input validation errors. You might be then tempted to wrap all your dynamic error messages in aria-live, which might prove to be an anti pattern in some situations. Let’s look at an example.
We have a login form with 2 fields, username and password, neither of which can be empty. Let’s say the user tries to submit the form with empty values and you show relevant error messages beside each input field. If both of these messages have aria-live, you would expect both errors to be announced, but unfortunately that is not how aria-live works. ATs would (generally, but implementations might differ) only announce the first error message, which means the user would fill in the username, try to submit the form again, and then get to know about the password error. Not nice!
What to do instead:
- if the form is small, it might make sense to have a single error message which is created by concatenating all the error messages.
- If the form is large and it wouldn’t make sense to announce all the errors in aria-live in one single message, you could instead have a single error message saying some fields are in error and suggest users to focus on them for extra information. (This would need to be combined with a aria-describedby or aria-labelledby so that the help/error messages are announced when the user focuses on that field)
TL;DR
- don’t pepper your UI with aria-live for updates which are not necessary to be announced. For example, in a search application, it makes sense to announce that search results have changed, but it may or may not make sense to announce that the recommendations sidebar content has also changed.
- aria-live = “assertive” clears off the queue, which effectively means that multiple aria-live updates due to the same action will not be announced. This is not a strict implementation but according to the spec, ATs are allowed to clear the queue.
User agents or assistive technologies MAY choose to clear queued changes when an assertive change occurs.
- although you might expect it not to, but aria-live =“polite” also clears off the queue for same action.
- It is fine to use multiple aria-live (or multiple live regions in general) for error messages or updates which get triggered on different actions or stimuli. For example on the same screen it would be fine to have aria-live for search results update, as well as an aria-live for global alert messages which inform the user about impending session timeout.
You can find a codesandbox example below: