WCAG 2.1 got some new success criteria and one of them is 4.1.3: Status Messages (opens in new window). It’s really important for screen-reader users and I’ll try to explain why with this post.
Let’s think of a simple example – adding an item to shopping cart on a e-commerce website. For users that can see the interface it may happen with an animation or maybe they just need to scroll to top or bottom to check that item is really there if user flow does not forward them to a new site.
But what about screen-reader users? How can they know the item was added to cart? Some solutions moved focus to the cart part of page but that would potentially cause user to use a lot of time to get back to the product list or maybe even get them confused. That’s why it’s way easier to use a technology that informs the assistive technology about changes without moving focus. And here we come to the status message possibilities.
Why do we even need status messages
In the “old days” status messages were practically not needed. When user submitted the form page navigated to a status page where assistive technology got new context. When we started to use Asynchronous JavaScript And XML (AJAX) to improve user experience we introduced a big problem for users of assistive technologies. When parts of page update visually the assistive technology was not able to update statuses automatically.
Maybe some tried, but imagine having a lot of dynamic ads changing and all being announced to the user. It would be too much. So letting developers decide what parts will be announced was the best option. Accessible Rich Internet Applications ( ARIA ) was updated to allow developer define different roles on elements that get updated.
There are two possibilities that can be used to notify assistive technology about changes and doing it with ARIA it allows us to define politeness (for important messages we can decide to use “assertive” and for less important messages “polite”, more on that later);
- adding a role (for example “alert”, “log”, “progressbar”, “status”) to an HTML element (ideally not having an implicit role from before, so maybe div and span work best here),
- adding ARIA attribute “aria-live” with correct value (“polite” or “assertive”)
Using roles means that politeness is predefined and “baked” into role, like for example role=”alert” (opens in new window) automatically means that politeness will be “assertive” and so called aria-atomic is set to true – that means assistive technology will present all content inside of the element, so all ancestors will be a part of the announcement.
I invite you to learn more about specifics in the official documentation about aria-atomic (opens in new window).
So developer do have some possibilities on how to present these live announcements and statuses to users of assistive technology and they should be studied by everybody involved in production of modern web technologies, especially those using a lot of dynamic updates, like for example single page applications.
Status messages in practice
Sometimes we need more guidance that are presented by the WCAG. When should we use assertive versus where should we use polite announcements, for example. I’ve studied the matter and the rule of thumb should be to use polite most often and only use assertive for statuses that need immediate attention.
For example form validation errors, fatal system errors, and very important announcements that are critical to the user – they should be assertive and with that they would have bigger priority for assistive technology and be announced at once.
Some other status messages, like for example “added to cart” should in my opinion not deserve to be assertive but should be polite. Polite would then mean that user will get the announcement only after all other tasks of assistive technologies are done and will not interrupt them.
As with many things in the field of accessibility – sometimes it really do depend what to use, but personally I try to first think about user experience I wanted to achieve and then also about browser and assistive technology support. Not every aria attribute is supported for all combinations of screen-readers and browsers, so I really try to investigate and test before releasing to end users.
