Notifications communicate relevant and timely information to users in response to user action or through system-generated messages.

Message Types

Notifications can be organized by type based on a combination of two factors: whether the message is system-generated or user-generated, and whether the notification is passive or actionable. These message types influence the notification’s level of prominence.

System-generated or User-generated

  • System-generated notifications are messages sent by the application that are independent of user action.
  • User-generated notifications appear in direct response to user action. They provide immediate feedback in context of the page the user is working on.

Passive or Actionable

  • Passive notifications provide information to the user but don’t require the user to take action.
  • Actionable notifications can require immediate action to move forward in a process (such as Error Banners), or present a user with the option to see further details or perform another action (such as Toasts with a link to “View more details”).
Generated ByPassive or ActionableExample
SystemPassiveNotification about a system update or system outage.
SystemActionableSession Timeout Modal: User’s session has timed out. Prompts the user to log back in before the user can proceed with other tasks.
UserPassiveSuccess Toast: “Your expense was submitted.”
UserActionableError Banner: “Enter an end date that is in the future.”
New Features Dialog: A Dialog component alerts the user of a new feature or enhancement. The user does not have to take immediate action on the Dialog as the page is not obstructed by an overlay.

Notification States

Notifications often use an icon as a supplementary visual indicator for different message states. Color can also evoke certain states, like using red for error messages and green for success messages. However, never use color alone to differentiate between these states. Refer to the guidelines in the Canvas Accessible Practices section of the site for more information.

StateIconAssociated ColorPurpose
Success Success icon in Green Apple 500 Green Apple 500Positive confirmation of status, such as an action or task completed successfully.
Error Error icon in Cinnamon 500 Cinnamon 500Indicates immediate attention is required. Prevents advancement until action is taken to resolve the issue.
Alert Alert icon in Cantaloupe 400 Cantaloupe 400 Please note that this color does not meet a 3:1 contrast ratio to adjacent colors according to WCAG 1.4.11 success criterion. The corresponding message must clearly communicate that this is an alert.Prompts user attention but doesn’t require action. Alert messages may help the user avoid errors.
Info Info icon in Blueberry 400 Blueberry 400Used for general informational messages with neutral status.

Transient, Dismissible, and Persistent Behavior


Low-fidelity illustration of a Toast notification composed of an image and two lines of text.

Transient notifications provide supplemental status updates. They automatically dismiss after a short period of time. They don’t receive keyboard focus, and don’t contain anything actionable.


Low-fidelity illustration of a Toast notification composed of an image, two lines of text, and a close button.

Dismissable Toasts have an “X” in the upper right corner that allows the user to dismiss the notification.

When a dismissable notification is loaded it should receive keyboard focus. Dismissible notifications can be dismissed by an X icon or an explicit button if the solution calls for it. However, not all notifications can be explicitly dismissed by the user, such as error messages, which require users to resolve the issue before proceeding.

Explicit Dismiss

Low-fidelity illustration of a Dialog component notification composed of a title, two lines of text, a checkbox, two action buttons, and a close button.

Sometimes notifications will have a more explicit dismiss, such as in Dialog components, where a checkbox serves as a double-confirmation in the content area, allowing the user to configure their notification cadence. An example of this double-confirmation is the “Do not show again” checkbox that prevents the Dialog from showing again in future sessions.

Not Dismissible

Low-fidelity illustration of an Error Banner.

Error Banners persist until all errors on a page have been resolved.

Accessibility Considerations

  • Transient (automatically disappearing) toasts may be very easy for low vision users to miss with magnification software. This pattern must not be used for higher emphasis messages.
  • Avoid stacking multiple dismissible toasts. Manually dismissing notifications requires cognitive and physical effort.
  • After a notification has been manually dismissed, set keyboard focus to a logical element in the page. This practice helps guide users and maintain their context.
  • Color must never be used as the only way to communicate notification error and warning states. Use color to support icons and text within a notification to convey its state.

Screen Reader Notifications

Supplemental Information is sometimes necessary to help screen reader users understand live changes to page content in real time. On the web, this type of notification is known as a “Live Region”. When a live region is created, screen readers will watch the area for any content changes and announce them to users in real time according to one of two possible rules:

  • polite will “politely” wait for users to finish what they are doing before announcing a live region change
  • assertive will interrupt what users are doing by immediately announcing a live region change

Live regions take control of the user experience away from users, placing it squarely into the hands of developers. Therefore, live regions should be used with thoughtful intent due to the risk of causing harm to users who depend on screen reading technology.

  • Live regions can be completely hidden from a visual design, or they can also be created around visible dynamic text in the design for both sighted and non-visual users.
  • A live region change will only be announced once. Users are unable to repeat them or re-examine them if the announcement was not understood.
  • Users may be able to pause a live region announcement, but they cannot prevent a live region announcement from occurring. Sending frequent and repetitive updates to a live region can be very disruptive to users.
  • Users cannot act on, or navigate to, a live region. Live regions must only contain plain text. (No images, links, buttons, or other input.)
  • Support for live regions is limited across platforms, browsers, and screen reader software. Real time announcements may not be perfectly reliable.

Can't Find What You Need?

Check out our FAQ section which may help you find the information you're looking for.

FAQ Section