Understanding SC 4.1.3 Status messages

Success Criterion 4.1.3 Status Messages (Level AA): In content implemented using markup languages, status messages can be programmatically determined through role or properties such that they can be presented to the user by assistive technologies without receiving focus. The modern web pages are so dynamic that many a times the results of user interactions are […]

Success Criterion 4.1.3 Status Messages (Level AA): In content implemented using markup languages, status messages can be programmatically determined through role or properties such that they can be presented to the user by assistive technologies without receiving focus.

The modern web pages are so dynamic that many a times the results of user interactions are more visual. Error messages, success messages that do not receive keyboard focus very often go unnoticed by the assistive technology (screen reader) users. More often than not, users are left wondering what is happening on the pages or whether they successfully performed tasks. This success criterion intends to bridge that gap by asking the authors that such status messages be programmatically determined so that screen readers or other assistive technologies detect such messages automatically and provide feedback either by announcing the messages or by any other means that the users prefer.

What are status messages?

Success toasts, form errors, cart updates, interstitial loading indicators, dynamically updating number of search results are some examples of status messages. Note that the focus does not shift to such messages but visual users are aware of them. Also, any modification of status messages, off-screen messages like delete confirmation can be considered as status messages.

How do we meet this criterion?

With the evolution of ARIA, automatic announcement of status messages in web pages are now possible. We can use either aria-live regions or role=”alert” to announce the status updates. However, we need to practise caution. Too much of aria-live regions would kill accessibility. For example, a page contains a carousel that updates automatically. Now, do we announce the slide change through aria-live? First, such a dynamic update is a status message? The answer is ‘a double no.’ This is a content update and not a status message. Besides, such live region usage will interfere with screen readers preventing the users from performing the primary tasks. Note that mobile apps also must announce status messages with appropriate roles and properties applicable within the mobile programming languages.

Points to ponder

  • Ensure all success toasts and error messages are announced by screen reader
  • Do not fill the pages with live regions. Decide which is an important update and qualifies a status message intelligently
  • Ensure focusable messages are not considered as status messages.

References

Understanding Success Criterion 4.1.3: Status Messages


Print Share Comment Cite Upload Translate
CITATION GOES HERE CITATION GOES HERE
Select a language: