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.
To ensure that status messages on web pages are programmatically determined and announced to users by assistive technologies, keeping them informed about the results of their interactions without shifting keyboard focus, using WAI-ARIA properties.
This success criterion does not mandate the appearance of status messages but requires that, if present, they are programmatically determinable for assistive technologies.
Before applying WAI-ARIA properties, it's crucial to verify whether the message qualifies as a "status message".
Such messages should provide information on:
For instance, a live chatbox that sends messages to users must be marked with the WAI-ARIA role to ensure alerts are received by blind users. Using role="log" ensures assistive technologies can parse each status message effectively, leveraging default aria-live and aria-modal properties.
Another example is when a user submits a form. If the author includes a status message that isn't programmatically determined, users relying on assistive technologies won't understand if the form submission was successful. Adding role="status" to the message ensures assistive technologies parse and notify users about the action's outcome, utilizing built-in properties with aria-live set to polite and aria-atomic set to true to include all content under the container in the message.
Simultaneously, the message must not cause a "change of context," such as receiving focus, altering the viewport significantly, or adding new dynamic content that does not refer to a "message status."
Examples include a search box displaying results as text is typed or revealing text upon user activation of an accordion button. Alertdialog messages that shift user focus within a dialog should not be tested under success criterion 4.1.3 either.
Non-text content, such as icons, also falls under this success criterion. For example, if a "busy" icon indicates that the application is busy, provide alt-text for the icon and use necessary WAI-ARIA properties or roles for the associated status message.
Use ARIA Roles: Use roles such as role=”status”,role=”log”,role=”alert” or properties such as “aria-live” to make status messages programmatically determined.
Prioritize Important Updates: Only use live regions for important status messages to avoid overwhelming users with excessive announcements.
Avoid Focus Shift: Ensure that status messages do not shift focus, but still provide the necessary feedback.
Test with Assistive Technologies: Regularly test status messages with screen readers to ensure they are being announced properly.
Example: Including a Search Results Message
A web page updates search results without any announcement to screen reader users.
<p>5 results returned.</p>
Explanation:This implementation does not use any ARIA attributes to announce the status message, leaving screen reader users unaware of the update.
<div role="status">5 results returned.</div>
Explanation:By using role="status", the screen reader is notified of the update and announces the message "5 results returned" to the user. This ensures that all users, including those relying on screen readers, are informed about the search results.