4.1.3 - Status messages

Make sure status messages are identified in code, so that assistive technologies can convey them to users.


Make sure status messages are identified in code, so that assistive technologies can convey them to users.


There are different situations where a status message need to be shown in a way that screen readers understand. For example:

  • error messages that appear while users fill in a form;
  • an alert message that is displayed when a session is about to expire;
  • some content that is changed/removed/added as a result of a user's action.

These messages need to be conveyed to users without disturbing the user's position on a page.

Screen reader announcements (using ARIA Live regions for the Web, for example) should be used to inform screen reader users of these events without disrupting their position on the page.


  • A sighted person can quickly see status messages on a page, and them go back to what they were doing or reading. Moving focus to a message can be disruptive for screen reader users, users of speech recognition software and keyboard only users.

    • Screen reader users navigate page with what is called a 'screen reader cursor'. They can move that screen reader cursor using their keyboard, braille display or gestures on a touch screen.
    • Status messages (like system error messages or form validation error messages) need to be communicated to users without moving their 'scren reader cursor' on the page. Otherwise users would need to figure out where they are on the page afterwards, and move back to where they wanted to be.
  • If focus is always moved to the message users with cognitive impairments may also be confused by unpredictable focus changes.

Official wording in the Web Content Accessibility Guidelines

4.1.3 Status Messages: 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. (Level AA)

See the W3C's detailed explanation of this guideline with techniques and examples.

Guidance for Design

This section needs some ❤️
Contribute via Github

Guidance for Web

The following are different situations you will need to cover:

When a status message tells the user something is successful

When a status message tells the user something is successful or is the results of an action. This can also be used for a state change when part of a page updates:

You can use these following techniques:

Use the ARIA role="status" to present status messages in combination with the technique Providing success feedback when data is submitted successfully.

If a status message conveys a suggestion, or a warning or error:

NOTE: There may be times when the best user experience is to move focus to a message, such as an error, as a part of form validation etc. See the GDS' Error Summary component and guidance for an example.

Use the following techniques:

Use ARIA role="alert" or Live Regions to Identify Errors in combination with any of the following:

If a status message conveys information on the progress of a process:

The ARIA role="progressbar" can be used but may not be enough on its own (depending on support by browsers and assistive technologies). For some examples of progressbar role see:

You can use the following techniques:

Common mistakes

  • Status messages are not to be shown in a way that the screen reader understands and without receive keyboard focus.
  • Using role="alert" or aria-live="assertive" on content which is not important.
  • On a page with ARIA live regions - if regions are hidden or not needed - always make sure to switch their active and inactive states accordingly.

More guidance for Web