Inclusive Notifications Must
Notifications must be both visible and audible.
All users benefit when notifications are communicated clearly and can be perceived in multiple ways. Some users may only perceive in one way, while others will benefit from a combination.
Make notifications visible using standard operating system alerts, inline messages or icons. Make notifications audible using sound bites or ensuring they can be read by assistive technology. And, where possible, make notifications felt by using haptic feedback when appropriate to do so.
Notifications inform and guide users. They can be error messages, alerts, instructions, changes of state, responding to an interaction or a range of other cues.
Content elements change state when their meaning changes during interaction, for example, 'selected/not selected', 'add/added', or 'delete/deleted'. Populating an autosuggest, or similar dynamic area, would also be a change of state. Hover and focus states indicate an element is interactive. Icons and avatars are visual cues, and should have supporting audio cues (or "earcons") when appropriate.
To provide notifications in an inclusive way, combine a displayed message or image with an accessibility label, vibration, an audio tone and perhaps a screen flash.
Where available a trait should be used to indicate state. If a custom state is desired it should be added to the accessibility label. Standard objects will set state automatically for states that are known, however if a state is unknown to the control or used in a non-standard way an accessibility trait must be explicitly set, for example a checkbox could have the trait of 'selected' assigned to it.
To provide notifications in an inclusive way, combine a displayed message or image with an accessibility label, vibration, and audio tone and perhaps flash the screen.
contentDescription should be used to provide state information for custom elements. States are provided for standard platform elements but must be set for custom or compound elements.
To provide notifications in an inclusive way, combine a visual cue with audio and haptic cues. For example, if the user types too many characters in a form field, display an error in the label of the form field in addition to a sound and/or vibration.
For standard controls such as radio buttons or checkboxes created with the input element these state changes are automatically provided by the browser. However, for images and other custom controls these changes must be provided visually, textually, and could also be provided through ARIA. With a change of state there should be a new text alternative for an image. ARIA can also be used but not solely relied upon. Non-ARIA fallback options must be available.
- Activate the app without a screen reader.
- Complete forms and trigger error messages within the app.
- Locate any cues used to signal error states or form completion.
- Verify that additional cues exist (text or visual, audio, or vibration) to provide the same information that was conveyed.
- Start the screen reader.
- Focus on an individual object, element, or control that can change state.
- Verify that the announced item label matches the on-screen text or contains additional supplementary information to assist with non-visual access of the item.
- Verify that the state of the element is announced properly.
- If applicable, toggle the state of the item and verify that the screen reader announces the correct state change.
The following checks are true:
Standard Operating System Notifications Should
Standard operating system notifications should be used where available and appropriate.
Standard operating system (OS) methods for alerts and messages can often be more accessible than something custom made, in particular for users of assistive technology. This is because standard controls:
App level and browser level errors and alerts should use operating system methods of notification. However, page/screen or content level errors and alerts may use either OS or custom notifications. Custom notifications must be perceivable.
UIAlertView to display a message box dialog that contains the error message.
AlertDialog to display error messages. As long as this is used, error messages and their associated functions will be accessible.
- Activate a screen reader.
- Trigger an alert or error on at the app level e.g.
- Time out,
- Update notice,
- Error contacting the server,
- Other app level errors or alerts.
- Verify that the alerts or error notifications are announced by assistive technologies.
The following checks are true:
Error messages and correction Must
Clear error messages must be provided
Clear error messages help everyone to input and interact with content correctly. It is important to provide inclusive error messages that users of assistive technology can perceive. Keep in mind that not everyone sees visual cues, such as colour or icons. And people with cognitive impairments may have difficulty in understanding how to correct errors.
When errors can be detected programmatically, provide clear informative messages that succinctly tell the user where the error is and suggestions, tips or instructions on how to correct it. Ensure it is easy for the user to return to the input/control that needs correcting, and other content.
For example, on a form submission, a list of all fields needing correction could be added to an
aria-live area above the form, with
aria-invalid and inline visual cues to provide guidance. Be careful to avoid
a keyboard trap and use ARIA or standard operating system notifications for users of assistive technology, such
as screen readers.
Display an error message at the top of a form with indication of fields in error. Move focus to the error message on form submit or display an alert pop-up. Make the error label a first responder and display the errors below.
After the form is submitted focus the error label:
Display an error message at the top of a form with indication of fields in error. Move focus to the error message on form submit or display an alert pop-up.
contentDescription display errors:
setError only to display error:
Display an error message at the top of the form, with an appropriate level heading and indication of the fields in error. Move focus to the error message after a failed submission.
- Activate the app.
- Trigger an alert or error on an object, element, or control in the app.
- Verify that an alert or error indicates there is an error.
- Verify that the alert or error notification clearly indicates the fields needing correction.
The following checks are all true:
Feedback and assistance Should
Non-critical feedback or assistance should be provided when appropriate.
Occasional feedback and assistance can help people learn how to use something unfamiliar. It can be especially helpful for young children and people with cognitive impairments.
When someone is not completing an objective correctly and/or does not progress multiple times, support and encouragement can motivate them to continue or keep trying. For example, in a game or other interactive content this could include hints, tips or the option to pass and move on to other content.
Don't rely on a single form of feedback, use visual cues, sounds and haptics, and avoid overwhelming the user with too much feedback. There are many ways this could be done, but try not to use an alert as the user must acknowledge it. Refer to Human Interface Guidelines - Feedback.
Add a label to the bottom toolbar:
Don't rely on a single form of feedback, use visual cues, sounds and haptics, and avoid overwhelming the user with too much feedback. Refer to Material Design - Help & Feedback.
For simple feedback you could use a Toast or a Snackbar:
Don't rely on a single form of feedback, use visual cues supported by text that assistive technology can perceive, and avoid overwhelming the user with too much feedback.
- Start the screen reader.
- Activate the app or game.
- Locate or activate any feedback, hints or help.
- Verify that this assistance is both visual and available to the screen reader.
- Verify that this assistance is appropriate and not over-bearing.
The following check is true: