WCAGAA
How to test criterion 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.”
- WCAG references
- 4.1.3 Status Messages (AA)
What this criterion says
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.
Official methodology to test criterion 4.1.3
Official W3C techniques
The W3C does not publish a test procedure for this criterion. It publishes techniques instead: documented ways to meet it, and the failures that do not.
Sufficient techniques
Situation A: If a status message advises on the success or results of an action, or the state of an application:
Situation B: If a status message conveys a suggestion, or a warning on the existence of an error:
Situation C: If a status message conveys information on the progress of a process:
Advisory techniques
- Using aria-live regions to support <a href="https://www.w3.org/WAI/WCAG22/Understanding/content-on-hover-or-focus">1.4.13 Content on Hover or Focus</a> (future link)
- Using <code>role="timer"</code> (future link)
- ARIA18 Using aria-alertdialog to Identify Errors
- SCR14 Using scripts to make nonessential alerts optional
Common failures
- F103 Failure of Success Criterion 4.1.3 due to providing status messages that cannot be programmatically determined through role or properties
- Using <code>role="alert"</code> or <code>aria-live="assertive"</code> on content which is not important and time-sensitive (future link)