Carbon Design System

How it works
Accessibility considerations
Resources
Accessibility 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 the

role="status"

role="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

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

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).
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.
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

W3C W3C WAI-ARIA Authoring Practices Alert Design Pattern covers the usage of ARIA names, state and roles.
W3C W3C Web Accessibility Tutorial - User Notifications provides a tutorial on notification accessibility.
IBM Accessibility Requirements:
- 3.3.1 Error Identification (WCAG Success Criteria 3.3.1)
- 3.3.2 Labels and Instructions (WCAG Success Criteria 3.3.2)
- 3.3.3 Error Suggestion (WCAG Success Criteria 3.3.3)

Accessibility testing

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: | Framework: React (@carbon/react)

Component	Accessibility test	Status	Link to source code
Notification	Test(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.	Passes all automated tests with no reported accessibility violations.
	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.