Why do some users not receive website status messages as standard? 

Users of assistive technologies (AT) that include screen reader functionality hear the content of your website spoken aloud. However, if a website delivers a status update without changing the context — in other words, without taking focus — that message could be overlooked by the AT. For example, a sighted user might see a snackbar pop up confirming that an action has been executed, but an unsighted or visually impaired person would hear the status message only if the appropriate roles or properties had been assigned by the developer. 

The W3C’s Web Content Accessibility Guidelines (WCAG) address this issue in guideline 4.1.3: Status Messages. To achieve Level AA conformance, the role or properties of your status messages should be programmatically determined so they can be presented by AT without receiving focus. 

Why is it important to conform with WCAG 4.1.3?

Sighted users often receive small visual cues and status messages on websites that keep them informed without stealing focus. These can enrich the user experience and give confidence that the website is performing as expected. 

For people with visual disabilities who rely on screen reader functionality, these status messages may not always be read out by AT, leaving the user unaware of potentially important information. Users with cognitive disabilities could also be impacted if the roles or properties of status messages are not correctly determined. This is because they may want to be able to set a preference to have their system delay or suppress certain types of message that would otherwise be distracting.  

Failure to take the appropriate action on status messages isn’t just frustrating for disabled users. It could also put your organization at risk of a digital accessibility lawsuit under the Americans with Disabilities Act (ADA). 

What can I do to fix the issue? 

The first step is to be clear about what counts as a status message. This is a message that is not delivered via a change in context and that provides information to the user regarding the success/failure of an action, the progress of a process, or the presence of errors.  

To ensure that status messages are spoken aloud by screen readers, you need to assign the appropriate roles or properties to each one — the W3C provides a number of techniques for accomplishing this. 

You may also need to consider creating additional content to pass to screen readers, in order to provide added context to the user. For example, if an item is added to a shopping cart, the screen reader might only be given the updated number of items in the cart. This would potentially be confusing without additional context saying, “the shopping cart contains this many items.” 

Naturally, you need to avoid going too far in the other direction: the W3C warns against making a website or app too “chatty” for a screen reader. Here, you need expertise and plenty of user testing. 

AudioEye combines automated scanning and remediation technology with human-led testing and custom remediation, providing a unique hybrid service that resolves accessibility issues on an ongoing basis. By subscribing to the AudioEye service, you get the benefit of rapid identification and remediation of accessibility issues around status messages. You also gain access to a team of human experts who can support your web designers in adopting universal design practices for the longer term. 

Don’t delay — subscribe today and solve your digital accessibility issues with AudioEye.