On each web page, are status messages correctly rendered by assistive technologies?
A screen reader user fills out a contact form and clicks Send. The page displays "Your message has been sent successfully", focus remains on the button. Without ARIA markup, this message does not exist for the screen reader: it announces nothing, the user does not know if their action succeeded.
Criterion 7.5 applies to status messages, that is, messages that appear without a change of context. Without focus movement, without page reload. Four categories are concerned: success or result of an action, busy state of an application, progress of a process, existence of errors or suggestions.
Each category has its ARIA tool. For a success message or application state: role="status" or aria-live="polite" accompanied by aria-atomic="true". For an error or warning: role="alert" or aria-live="assertive" with aria-atomic="true". For the progress of a process: role="log", role="progressbar" or role="status" depending on the intention. The urgency level of the message determines the role to choose.
Without ARIA, the message exists visually. Not for the screen reader.
3 tests to ensure that status messages are correctly conveyed
ARIA marking of status messages
- Identify in the page all messages that appear without a change of context (no focus movement, no reload): confirmations, errors, progress indicators, application state messages.
- For each message identified, determine its category, then verify the markup of the element containing it:
- Success, action result or application state: the element must have
role="status"OR (aria-live="polite"+aria-atomic="true"). - Error or suggestion: the element must have
role="alert"OR (aria-live="assertive"+aria-atomic="true"). - Progress of a process: the element must have
role="log",role="progressbar"orrole="status"ORaria-live="polite"(for the equivalent of a log) OR (aria-live="polite"+aria-atomic="true"for the equivalent of a status).
- Success, action result or application state: the element must have
- The test is validated if at least one of the valid implementations is present. It fails if no appropriate role or ARIA attribute is detected.
ARIA marking of status messages (continued 1)
Methodology identical to test 7.5.1. Apply the same steps: identify status messages in the page, determine their category (success, error, progress), then verify the presence of the corresponding role or ARIA attributes on the container element.
ARIA marking of status messages (continued 2)
Methodology identical to test 7.5.1. Apply the same steps: identify status messages in the page, determine their category (success, error, progress), then verify the presence of the corresponding role or ARIA attributes on the container element.
Examples
❌ Non-compliant : Confirmation message injected without ARIA markup
<button type="submit">Send</button>
<!-- Injected dynamically after submission -->
<div id="confirmation">Your profile has been successfully updated.</div>The message appears in the DOM after submission, focus remains on the button. Without role="status" or aria-live, the screen reader detects no change. The user has no idea whether their action succeeded.
✅ Compliant : Confirmation message with role="status"
<!-- Present in the DOM on load, empty, filled by JS after submission -->
<div id="confirmation" role="status" aria-atomic="true"></div>
<button type="submit">Send</button>The role="status" container is in the DOM on load, but empty. When the script injects the message into it, the screen reader announces it automatically in polite mode, without interrupting navigation. aria-atomic="true" ensures that the entire message is read, not just the modified part.
❌ Non-compliant : Error messages injected after validation without ARIA
<!-- Injected dynamically after validation, focus not moved -->
<div id="errors">
<p>2 errors have been detected.</p>
<ul>
<li>The email address is invalid.</li>
<li>The phone field is required.</li>
</ul>
</div>Errors appear in the DOM without focus being moved. Without role="alert" or aria-live="assertive", the screen reader ignores these changes. The user may continue to believe the form was submitted correctly.
✅ Compliant : Error messages with role="alert"
<!-- Present in the DOM on load, empty, filled by JS after validation -->
<div id="errors" role="alert" aria-atomic="true"></div>role="alert" is semantically equivalent to implicit aria-live="assertive" + aria-atomic="true". The screen reader interrupts what it is reading to announce the errors immediately. This is the expected behavior: the user must be informed without delay that their input is problematic.
Tips and pitfalls
⚠️ Creating the ARIA container at the same time as the message
The container bearing role="status", role="alert" or aria-live must be present in the DOM before the message is injected. If you create the element and add text to it simultaneously via innerHTML or createElement, most screen readers miss the announcement. Best practice: an empty container in the base HTML, filled by JavaScript at the right time.
⚠️ Using role="alert" for all types of messages
role="alert" is intrusive: it immediately interrupts the current reading. Using it for a success message ("Profile saved") unnecessarily disrupts the user. Reserve it for urgent errors and warnings. For non-urgent confirmations, role="status" or aria-live="polite" are the right choices.
⚠️ Error message with focus movement: outside the scope of criterion 7.5
If, after validation, focus moves to the error area or to the first erroneous field, there is a change of context. Criterion 7.5 no longer applies: the screen reader will naturally read the content where the focus is. Adding role="alert" in this case is redundant and can cause a double announcement, a source of confusion.
💡 aria-atomic="true" is not optional with role="status"
The ARIA specification does not impose aria-atomic by default on role="status". In practice, some screen readers only announce the modified part of the container if aria-atomic="true" is absent. To ensure that the complete message is read, systematically add aria-atomic="true" on status-type live regions.
⚠️ Progress of a process: three possible roles depending on intention
For a typical progress bar: role="progressbar" with aria-valuenow, aria-valuemin and aria-valuemax. For an activity log where messages accumulate: role="log" or aria-live="polite". For a step indicator ("Step 2 of 4"): role="status" with aria-atomic="true". Each pattern corresponds to a different expected behavior of assistive technologies.
Frequently asked questions
How do you distinguish a status message from a message outside the scope of RGAA criterion 7.5?
The key is the change of context. If focus moves to the message or elsewhere on the page, there is a change of context and criterion 7.5 does not apply. If the message appears in the DOM without anything else changing (no reload, no focus movement), it is a status message within the meaning of criterion 7.5.
How do you choose between role="alert" and aria-live="assertive" for status messages under RGAA 7.5?
role="alert" is equivalent to implicit aria-live="assertive" + aria-atomic="true". In practice, role="alert" is more concise and its intention is clearer in the code. aria-live="assertive" with aria-atomic="true" gives the same result but requires two attributes. Both are valid under criterion 7.5.
How do you implement role="alert" on an inline error message according to RGAA 7.5?
This depends on the announcement mechanism. If the message is linked to the field via aria-describedby or aria-errormessage, the screen reader will read it when the user navigates to that field. In this case, role="alert" is not necessary. However, if the message appears dynamically after submission without focus returning to the field, role="alert" or aria-live="assertive" is essential for an immediate announcement.
How do you effectively audit RGAA criterion 7.5 on status messages?
Use DevTools to inspect elements that receive dynamic content (confirmations, errors, loaders). Look for role, aria-live and aria-atomic in the generated HTML. Then test with a screen reader (NVDA under Firefox, VoiceOver under Safari) by triggering corresponding actions: form submission, search, loading. If the message is not vocalized automatically, the criterion fails.
How do you distinguish RGAA tests 7.5.1, 7.5.2 and 7.5.3 despite their common methodology?
In the RGAA, multiple tests under the same criterion often correspond to different types of content technologies or application contexts covered by the standard. The methodology is identical for all three. In practice, apply the same procedure for each and document the results separately in your audit report.