Skip to main contentCarbon Design System

Notification

Accessibility testing status

For every latest release, Carbon runs tests on all components to meet the accessibility requirements. These different statuses report the work that Carbon has done in the back end. These tests appear only when the components are stable.

Latest version: ^1.51.0 | Framework: React (@carbon/react)

ComponentAccessibility testStatusLink to source code
NotificationTest(s) that ensure the initial render state of a component is accessible.
Passes all automated tests with no reported accessibility violations.
GitHub link
Tests that ensure additional states of the component are accessible. This could be interactive states of a component or its multiple variants.
Passes all automated tests with no reported accessibility violations.
Tests that ensure focus is properly managed, and all interactive functions of a component have a proper keyboard-accessible equivalent.
Test data is either not available or not applicable for this component state.
This manual testing ensures that the visual information on the screen is properly conveyed and read correctly by screen readers such as JAWS, VoiceOver, and NVDA.
A human has manually tested this component, e.g. screen reader testing.

How it works

Notification Carbon components are messages that communicate information to a user. The WAI-ARIA role="status" and role="log" are equivalent to aria-live="polite". It is used to display a message to the user in a way that does not interrupt the user’s current task and queues the notification until whatever task the user is currently working on is complete. If the notification contains an urgent message, a role="alert" can be used, it is equivalent to aria-live="assertive". It is used to display a message to the user that interrupts the user’s current task. These are considerably more disruptive to users than therole="status"orrole="log". In either case, these notifications attract the user’s attention without receiving focus to communicate the message.

Details pertaining to these roles include specifics around containing interactive elements, focus behavior, close behavior, and semantic contents. The role of status, log, and alert can not contain interactive elements, should not be given focus, and can optionally be closed by pressing the Escape key. The close button is given aria-hidden="true" so it is ignored by assistive technologies. Generally, plain text is preferred to be used within these notifications. When read by screenreaders, any semantic meaning surrounding the contents is not reflected to the user. For instace - Bold or italic emphasis, and/or semantic elements such as <li> etc. are not read to the user. If semantics are included, it should be non-essential to the understanding or meaning of the contents.

Notification components are allowed interactive children (actions) though, and when an interactive element is provided, a role="alertdialog" is used. These notifications should immediately be given focus so the user can navigate through the interactive elements. The close button is given an ARIA label of aria-label="close", and the icon has aria-hidden="true" so it is ignored by assistive technologies. The Tab key is used to move focus to the action and close button within the notification and the Space key or Enter key activate the appropriate button within the notification. It can also be optionally closed via pressing the Escape key.

Accessibility considerations

  1. Avoid using a toast notification for critical alerts or long messages because they are timed and will disappear automatically making it difficult for people with various disabilities to get the entire message. An alert that disappears too quickly can lead to failure of the optional WCAG 2.0 success criterion 2.2.3 (AAA).

  2. Provide a means to turn off nonessential alerts to enhance usability for people with visual and cognitive disabilities. Additional information is available in WCAG 2.0 success criterion 2.2.4 (AAA). Note: Providing this functionality is optional.

  3. Ensure the use of color and hidden icons are not used as the only means of conveying the importance of the notification.

Resources

Helpful resources for creating customized accessible implementations

Accessibility testing

Accessibility issues are tracked in the Carbon Component GitHub repository.

Automated test

Automated test environmentResults
- macOS Mojave version 10.14.6 with VoiceOver
- Chrome version 77.0.3865.90
- Dynamic Assessment Plugin version 1.8.0.0 - IBM Accessibility WCAG 2.1 Sept. 2019 Ruleset
- Carbon React version 7.7.1
DAP Test
- Violations

macOS screen reader tests

Environment Results
- macOS Mojave version 10.14.6 with VoiceOver
- Chrome version 77.0.3865.90
- Carbon React version 7.7.1
VoiceOver(VO) test:
  1. Press Control-Option-Shift keys to enter the Web content.
  2. Press the Tab key. VO announces the notification text and the close button.
  3. Press the Space key or Enter key to close the notification.
- macOS Mojave version 10.14.6 with VoiceOver
- Safari version 13.0.2
- Carbon React version 7.7.1
VoiceOver(VO) test:
  1. Press Control-Option-Shift keys to enter the Web content.
  2. Press the Tab key. VO announces the notification text and the close button.
  3. Press the Space key or Enter key to close the notification.

Windows screen reader tests

EnvironmentResults
- Microsoft Windows 10
- Firefox version 68
- JAWS version 18
- Carbon React version 7.7.1
JAWS test:
  1. Press H, JAWS announce the notification title.
  2. Press Alt-Down Arrow, JAWS announces each line of the notification text.
  3. Press the Tab, JAWS announces the close button.
  4. Press the Space key or Enter key to close the notification.

iOS screen reader tests

Environment Results
- iOS version 13.1.3 with VoiceOver
- Safari version 13.1.3
- Carbon React version 7.7.1
VoiceOver test:
  1. Swipe right to the notification and to read the notification text.
  2. Swipe right to the X icon. VO announces the close button.
  3. Double tap to close the notification.