Overview
The success criterion states that 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.
Key messages
- Let assistive technology notify users about status changes that don't take focus.
- Form validation (one example) with impact on form development across the work we do.
- ARIA live regions: aria-live=assertive/role="alert" (read now) and aria-live=polite (read at a pause).
- Often better to have one messaging element, rather than multiple live regions.
How to implement
If a status message advises on the success or results of an action, or the state of an application:
- Use role=status to present status messages in combination with any of the following:
- Providing success feedback when data is submitted successfully.
If a status message conveys a suggestion, or a warning on the existence of an error:
- Use ARIA role=alert or Live Regions to Identify Errors in combination with any of the following:
- Providing text descriptions to identify required fields that were not completed.
- Providing a text description when the user provides information that is not in the list of allowed values.
- Providing a text description when user input falls outside the required format or values.
- Providing suggested correction text.
- Providing spell checking and suggestions for text input.
Not all examples in the preceding general techniques use status messages to convey warnings or errors to users. A role of "alert" is only necessary where a change of context does not take place.
If a status message conveys information on the progress of a process:
- Use role=log to identify sequential information updates.
- Use role=status to present status messages in combination with providing help by an assistant in the web page.
Barriers
- Just because some aspects of this are available doesn't mean they should be used.
- Business Analysis should identify appropriate use and call it out.
- Access to testing add-ons or testing tools.
How to test
Form success:
- Fill in form fields with no errors.
- Submit the form.
- Check that a feedback message on the screen confirms that the submission was successful.
For each status message:
- Check that the container destined to hold the status message has a role attribute with a value of status before the status message occurs.
- Check that when the status message is triggered, it is inside the container.
- Check that elements or attributes that provide information equivalent to the visual experience for the status message (such as a shopping cart image with proper ALT text) also reside in the container.
ARIA role=alert:
- Determine that an empty error container role=alert or aria-live=assertive attribute is present in the DOM at page load.
- Trigger the error that causes the content in the live region to appear or update.
- Determine that the error message was injected into the already present error container.
Form text descriptions:
- Fill out a form, deliberately leaving one or more required (mandatory) fields blank, and submit it.
- Check that a text description is provided identifying the mandatory field(s) that was not completed.
- Check that other data previously entered by the user is re-displayed, unless the data is in a security related field where it would be inappropriate to retain the data for re-display (e.g. password).
Form text description when user provides information that is not in the list of allowed values:
- Enter invalid data in a form field.
- Check that information is provided in text about the problem.
Form text description when user input falls outside the required format or values:
- Fill out a form, deliberately enter user input that falls outside the required format or values.
- Check that a text description is provided that identifies the field in error and provides some information about the nature of the invalid entry and how to fix it.
- Check that other data previously entered by the user is re-displayed, unless the data is in a security related field where it would be inappropriate to retain the data for re-display (e.g. password).
Providing suggested correction text:
- Identify form fields where correct text could be inferred from incorrect text.
- Fill out the form, deliberately filling in the identified form fields with incorrect text.
- Check that the user is presented with suggestions for the correct text.
- Check that the suggestions are provided close to the form field.
Providing spell checking and suggestions for text input:
- Check that there is a form field on the page.
- Enter a misspelled word.
- Check that a suggested spelling is presented.
- Check that a mechanism is available to enter the suggested word into the form.
Using role=log to identify sequential information updates:
- On a page that contains sequentially updating information, check that the container for the information is given a role of log.
Testing Tools
- None identified. You will need to test manually as noted above.
Training
