New Components
Status and alert message
A status message informs the user of a change that has occurred in the page without interrupting their activity: success of an action, warning, error, progress of a task. It is displayed next to the content concerned and never takes keyboard focus. The alert message is its most urgent form, reserved for warnings and errors: it interrupts the screen reader’s current reading, without moving focus. When a response from the user is required, the message belongs to an alert dialog, which does take focus.
When to use a status message
- Confirm an action: saved, filter applied, item added.
- Report an outcome: the number of search results, how far a job has got.
- Inform without urgency: the user can finish their sentence before hearing the message.
When to use an alert message
- An error to fix: a rejected entry, a form that will not go through.
- Imminent data loss: a session about to expire, a lost connection.
- Information that cannot wait: and only then, because an alert cuts the screen reader off mid-sentence.
Modes of action
- Mouse: none. Both messages are displayed, they are not clicked.
- Keyboard: none. Neither takes focus; focus stays where the user was working.
- Screen reader: a status is announced politely, at the next pause. An alert interrupts straight away.
Content
- A full sentence: the message is heard outside any visual context, so it has to stand on its own.
- No colour alone: the nature of the message is carried by the text, the icon and the colour only reinforce it (WCAG 1.4.1).
- An instruction inside the error: say what to fix, not only that something is wrong.
Keywords
- Live region: an area whose change is announced without moving focus.
- aria-live: sets how urgent the announcement is. The value polite waits for a pause, assertive interrupts.
- aria-atomic: at true, the whole region is read again on every change, rather than only the fragment added.
- role="status" and role="alert": shorthands, each implying one of the two combinations below.
Two writings for one behaviour
Each demonstration shows both writings side by side, so they can be compared: the role on one side, the two attributes on the other. They are strictly equivalent, and the script feeds them the same way.
- role="status" is exactly equivalent to aria-live="polite" with aria-atomic="true".
- role="alert" is exactly equivalent to aria-live="assertive" with aria-atomic="true".
- Write one or the other, never both on the same element: two redundant declarations add nothing, and two contradictory ones give an unpredictable result.
- The role is the short form, to prefer day to day. The attributes spelled out make the mechanism readable, which helps in training and in code review.
Status message
A polite announcement: the screen reader finishes its sentence, then reads the message. This is the default choice.
- The demonstration holds two status regions: the first with role="status", the second with aria-live="polite" and aria-atomic="true".
- Both exist in the HTML from page load, and both are empty. A region inserted at the moment of the announcement is not exposed: the screen reader was not watching it (WCAG 4.1.3).
- The region is cleared before writing, otherwise two actions producing the same text are only announced once.
- Focus does not move: the user stays in charge of their navigation.
Alert message
An assertive announcement: the screen reader interrupts whatever it was saying. Keep it for cases where waiting is costly.
- The demonstration holds two alert regions: the first with role="alert", the second with aria-live="assertive" and aria-atomic="true".
- The same rules as a status: regions present from page load, cleared before every write, no focus move.
- One alert too many is worse than no alert: once it becomes routine, the user is no longer interrupted, only disturbed.
- A form error message is better also bound to the field with aria-describedby: the announcement is fleeting, the description stays.
Screen reader
- Never stack the role and the attributes on one element: the role is enough.
- Never hide the region with display:none: a hidden region announces nothing. Use accessible hiding.
- aria-atomic="true" stops a composed message from being read in pieces.
- The announced text is exactly the displayed text.
The message does not receive focus when it appears and the container is not focusable. Only the interactive elements it contains enter the tab sequence, at their place in document order. The alert dialog follows distinct rules, recalled at the end of the table.
| Key | Function |
|---|---|
| Not applicable (container) | The message container does not receive focus and does not respond to any key. The announcement is handled by the live region, without focus moving. |
| Tab | Moves focus to the close button, then to the link or action button of the message, in document order. |
| Shift + Tab | Moves focus to the previous element. |
| Enter or Space | Activates the close button or the action button. |
| Enter | Activates the link of the message. |
| Escape | Has no effect on a status or alert message. It does close an alert dialog, focus then returning to the element that triggered it. |
Note: in an alert dialog, focus is placed on an active element when it opens and tabbing stays contained within the dialog while it is displayed. This behaviour is specific to that model and must not be transposed to a status or alert message.