4.1.3: Status Messages [AA]
Description
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.
Sufficient Techniques
Sufficient Techniques for Success Criterion 4.1.3
Note: Other techniques may also be sufficient if they meet the success criterion. See Understanding 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:
- ARIA19: Using ARIA role=alert or Live Regions to Identify Errors
- G83: Providing text descriptions to identify required fields that were not completed
- G84: Providing a text description when the user provides information that is not in the list of allowed values
- G85: Providing a text description when user input falls outside the required format or values
- G177: Providing suggested correction text
- G194: Providing spell checking and suggestions for text input
Situation C: If a status message conveys information on the progress of a process:
- ARIA23: Using role=log to identify sequential information updates
- Using role="progressbar" (future link)
- ARIA22: Using role=status to present status messages AND G193: Providing help by an assistant in the Web page
Advisory Techniques
Advisory Techniques for Success Criterion 4.1.3
- Using aria-live regions with chat clients (future link)
- Using role="marquee" (future link)
- Using role="timer" (future link)
- ARIA18: Using aria-alertdialog to Identify Errors
- SCR14: Using scripts to make nonessential alerts optional
Failures
Failures for Success Criterion 4.1.3
- F103: Failure of Success Criterion 4.1.3 due to providing status messages that cannot be programmatically determined through role or properties
- Using role="alert" or aria-live="assertive" on content which is not important and time-sensitive (future link)