Potential dangers of status messages

Number of words: 1318.

(Loaded 687 times)

WCAG 4.1.3 is dedicated to status messages and we encourage their use, but we need to be aware of some potential dangers that are often beyond strict technical conformance.

When we learn about Web Content Accessibility Guidelines and, specifically, the success criterion 4.1.3 Status Messages, level AA (opens in new window), we can quickly start overusing the live updates on our web pages or in our mobile applications.

Our good intentions may lead to poor usability or sometimes we can even flood the screen reader users with too much information and with that actually make our solutions technically conforming and totally unusable at the same time.

And there are also users that rely solely on the braille refreshing displays. For them, status messages can even render the site or app useless (that’s why some braille refreshing displays didn’t even implement support for status messages and others have them disabled by default and users need to enable them deliberately).

In my accessibility and usability audits, I often stumble upon solutions that are totally ignorant of status messages. Which is often an indication of organization that is very early on their accessibility journey. When I provide feedback on how to remediate parts that need status messages – with the help of so called live regions (opens in new window), I really try to emphasize some points that can make the user experience worse.

And this post will kind of build upon them, and hopefully help to improve the usability, not only tick the conformance checkboxes.

Typical problems with status messages and what to do about them

There are a lot of potential problems, but I will limit myself to the typical ones that I encounter more often. Welcome to come with your suggestions, I am sure there are lots of different scenarios that I still haven’t met.

Not testing them with different screen-reader and browser combinations

Live regions come in multiple variants, we have some HTML roles like alert and status that include implicit ARIA live region properties (like assertive and polite and different values for atomic and so on). And then we can also use ARIA attributes directly, like aria-live and try to modify the rest with other ARIA attributes.

But, once again, the support for live regions may differ between different screen readers and browser combinations (opens in new window). That’s why we should try to use the more robust code patterns and always test them with multiple combinations.

Too much text in status message

The status message can technically be quite long. Accessible Rich Internet Applications (ARIA) did not define the maximum characters, but this is not an open invitation to have long status messages, please.

Any status message longer than 100 characters can be overwhelming in my experience and with testing with screen reader users. If we need to inform the user with a longer text, then we should really re-think our user interface.

Forgetting that status messages can’t announce semantics

Status messages will flatten their content. This means that if I have a HTML list inside the wrapper for status messages the list semantics will be lost (or any other semantics).

If this semantics is important for understanding, then we risk that some people will not be able to understand the meaning. We need to rethink the user interface and make sure status message will not rely on the implicit semantics that may be there and may help other groups of users.

Status messages often can’t be repeated

Not all screen-readers can repeat status messages, so if user is distracted or focused on other things it may be a huge problem if they miss a triggered status message that is perhaps only triggered once (some may even claim this borders to a WCAG 2.2.1 Timing Adjustable, level A (opens in new window) fail, but as it is the platform and not the author that controls this, this is not the case).

When we test status messages, we are often focused and expect them. Call it testing bias if you like. Imagine if we do not know that status message can even appear there and we are doing other things in the page or in the app.

We may argue that we did our job. But did we really? Surely, nobody can claim that we are missing status messages and that we are (perhaps) conforming to WCAG 4.1.3, but that does not help our users a lot.

That’s why it’s best to keep the messages short (and to the point). But even that is sometimes not enough. When status messages appear unexpected (not as a side effect of our interactions) we have the most risk of people not perceiving them, so perhaps we need to inform users about such statuses in a different way (perhaps a modal window can be a better solution, but I am really saying that it depends on your context).

Too many status messages at the same time

Imagine situations with multiple components where each of them have their own status messages. Again, probably conforming to the WCAG but can soon be very unusable, again depending on the situation.

After testing with some limited combinations of screen-readers and browsers, I’ve quickly noted a huge problem – some alerts were silent and only last some were announced.

This means that in some scenarios status messages will be suppressed, I am quite sure that this is so by design – to not flood users when developers . So, we need to design for such cases if we allow multiple components that use status messages and perhaps even require a message bus solution that would be centralize status messages (with throttling) in a central live region. Again – it depends on the scenario and we really need to make sure that we do not spam screen readers with too many messages.

Some users will disable status messages (or will not be able to enable them at all)

Yes, indeed, some users will disable status messages and some users will not be able to enable them at all. Some screen readers allow users to disable some or all status messages. And some screen readers will not transport status messages to refreshing braille displays (intentionally).

This is kind of out of our hands, but it doesn’t mean we have to ignore it. A very simple alternative can be to have a feature toggle somewhere (again it depends a lot on the context, the type of the medium (is it just a website or an web application or is it a mobile application and do we have any other user settings etc.)). A feature toggle to show a modal dialog instead of using a status message. And when I think about it – perhaps that can be the answer for many other issues here – user preference for status messages – some may keep the live regions and some may choose modal dialogs instead (again not suitable for absolutely all status messages to be fair).

To conclude – it’s not so simple after all

WCAG conformance to 4.1.3 is kind of simple at first sight, but what is conformance without usability? Not much, as we can actually introduce new issues to our users, even when we actually meant to help them.

Status messages and live regions can often be like that – quite simple to conform to WCAG and very simple to make different kind of issues, and if we are not careful – if we do not design the “invisible” – we can actually prevent some groups of users to use our products.

Hope this post will help you to think a bit more about how to apply them to your products (or perhaps avoid when not suitable) and I am certain that some people can also extend on other bad practices and how to fix or bypass them.

Author: Bogdan Cerovac

I am IAAP certified Web Accessibility Specialist (from 2020) and was Google certified Mobile Web Specialist.

Work as digital agency co-owner web developer and accessibility lead.

Sole entrepreneur behind IDEA-lab Cerovac (Inclusion, Diversity, Equity and Accessibility lab) after work. Check out my Accessibility Services if you want me to help your with digital accessibility.

Also head of the expert council at Institute for Digital Accessibility A11Y.si (in Slovenian).

Living and working in Norway (🇳🇴), originally from Slovenia (🇸🇮), loves exploring the globe (🌐).

Nurturing the web from 1999, this blog from 2019.

More about me and how to contact me:

Leave a Reply

Your email address will not be published. Required fields are marked *