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.

Examples

iOS

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.

Android

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.

An updated 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.

HTML

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.

Testing procedures

  1. Activate the app without a screen reader.
  2. Complete forms and trigger error messages within the app.
  3. Locate any cues used to signal error states or form completion.
  4. Verify that additional cues exist (text or visual, audio, or vibration) to provide the same information that was conveyed.
  5. Start the screen reader.
  6. Focus on an individual object, element, or control that can change state.
  7. 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.
  8. Verify that the state of the element is announced properly.
  9. If applicable, toggle the state of the item and verify that the screen reader announces the correct state change.

Testing results

The following checks are true:

  • The app provides both visible and audible cues for each alert or notification used to convey information or errors;
  • Object, elements, or controls including their labels, roles, values, states and state changes are correctly announced by a screen reader.

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:

  • Have traits that are understood by assistive technology such as screen readers,
  • Generally appear in a consistent location, and
  • Follow the user-defined options for font and colour.

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.

Examples

iOS

Use a UIAlertView to display a message box dialog that contains the error message.

Android

Use the AlertDialog to display error messages. As long as this is used, error messages and their associated functions will be accessible.

HTML

A JavaScript alert is one option for HTML to meet this standard.

Testing procedures

  1. Activate a screen reader.
  2. 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.
  3. Verify that the alerts or error notifications are announced by assistive technologies.

Testing results

The following checks are true:

  • The app uses operating system standard methods for providing app level or non-action triggered alerts and indicating errors to users which are announced by assistive technologies.

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.

Examples

iOS

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.

Android

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.

HTML

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.

Testing procedures

  1. Activate the app.
  2. Trigger an alert or error on an object, element, or control in the app.
  3. Verify that an alert or error indicates there is an error.
  4. Verify that the alert or error notification clearly indicates the fields needing correction.

Testing results

The following checks are all true:

  • The presence of an error or alert is indicated;
  • Alerts and error notifications provide sufficient information to allow users to identify which form controls contain errors.

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.

Examples

iOS

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.

Android

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.

HTML

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.

Testing procedures

  1. Start the screen reader.
  2. Activate the app or game.
  3. Locate or activate any feedback, hints or help.
  4. Verify that this assistance is both visual and available to the screen reader.
  5. Verify that this assistance is appropriate and not over-bearing.

Testing results

The following check is true:

  • Assistance provided is appropriate and inclusive.