Unlike browsers where a sighted user can notice the changes when the page does not reload, screen readers read the DOM and the Accessibility Tree as it was generated when the document was loaded, so if later changes occur, such as messages, content updates, new blocks, etc... the user will not perceive them and will not be able to access them, losing the information they may offer.
ARIA is used to fill this gap. As we said in the previous post, one of the cases where it makes sense to use ARIA is "If the feature is available in HTML but it is not implemented, or it is implemented but accessibility support is not.".
In this case we have a functionality (updating the page) that is supported in browsers but is not accessible, so it is totally appropriate to use an auxiliary technology that helps assistive technologies.
To define an area of the page in which changes can occur, there are two options, using different ARIA attributes in the container of that area:
- With
aria-live=”polite/assertive”andaria-atomic=”true” - With
role="alert"
Both serve to warn the screen reader to be aware of changes that may occur inside and notify the user of them when they occur. Later we will explain the differences between them and in which cases to use each one.
EDITED: More on live regions in this article by the always interesting Scott O'Hara, who highlights this:
[...] ensuring an empty live region exists in your DOM, and injecting content into it when necessary, proves to be the most robust way to ensure a live region will be announced.
And a very helpful and well explained video by Sarah Higley on how to notify the user of content changes.
Top comments (2)
Great explanation
Thanks!