Status notifications

Status notifications inform users that something on the page has changed. These responses help users understand page processes, actions they have competed, additional options available, or actions still needing attention. Common examples include success and warning messages.

Transient status notificationsPersistent status notifications
PriorityLow, minimally disruptive Prominent, medium priority
ExpectancyUnexpectedUnexpected
BlockingNon-blocking, temporary, usually auto dismissesNon-blocking
RequiredNot requiredNot required
InformationAdvisory supplementary informationAdvisory supplementary information
LocationOverlay, typically in the top right of pageInline on page, generally located in associated section of effected content
ComponentsToastBanner

Transient status notifications are temporary messages that come and go without user input. They indicate the completion of a task or process initiated by the user or the application itself.

Their purpose is to provide:

  • Confirmation when updating and removing items 
  • Simple messages when saving user preferences 
  • Contextual information on the page processes 

They also allow the following options:

  • May be dismissible 
  • May be clicked on to see what’s previously happened

When to use

  • Confirming that a task or process initiated by the user was completed successfully
  • Providing contextual information on the page processes

When not to use

Transient status anatomy

Diagram for transient status notifications, annotating the required layout of the elements listed below

  1. Status notifications as an overlay
  2. Automatic dismissal
  3. Interactive controls

1. Status notifications as an overlay

Best practices

  • Return user focus to a logical location
  • If moving focus to the notification, provide the notification with at least one focusable UI element (i.e. close button, primary button)
  • If moving focus to the notification, make the notification content container dismissible
  • If moving focus to the notification, on dismiss the notification return focus to the next logical location in the page flow
  • Meet the standard color ratio requirements for both text (4.5:1) and activatable components (3.0:1)
  • Use for short messages to confirm an action
  • If notification is displayed as an overlay, interactive controls should be contained

What to avoid

  • Allowing the notification to block page content
  • Placing the notification near or on top of navigation area
  • Opening the notification as a blocking overlay window

Options:

Transient status notifications may appear as a timed display.

2. Automatic dismissal

Status notifications may be displayed for a set amount of time rather than become a lasting feature of a page. In these cases, if a user ignores a timed notification, it will still mean the action is completed successfully.

For example, an item would still be added to a cart regardless of a user's engagement with the notification informing them of the successfully added item.

3. Interactive controls

Interactive controls within notifications produce several hurdles for users of assistive technology. Specifically, the Aria-live region will not preserve the semantics of elements being read aloud. As an example, consider a virtual outfitting notification previously seen on the product page. A user will not know what the title, copy, or link are in the following text:

"Need help deciding? Schedule a free 1-on-1 virtual appointment with one of our experts. Book now."

Users may infer the "book now" text is a link—or just as likely search for a button or guess the entire text would be active.

Consider the following:

  • When triggered, live regions only read out their content to assisted technologies. They will not distinguish text from actionable elements present within a notification
  • Users may infer that actionable element is present, however a user will need to guess what element to search for. This is especially problematic for notifications that are automatically dismissed, as users will have limited time to correctly guess and act on this choice

If the notification must include an actionable element, you are responsible for the following:

  • Return focus to next logical location in the page flow
  • Ensure contained action is also readily available on the page
  • If the action is not available on page, the action should be added to a notification history page (see ARIA’s log role)

Persistent status notifications are “in page messages” informing the user that something on the page has changed. This feedback is a response to user actions, like making a product selection or settings change.

Their purpose is to:

  • Expose a status change to a product caused by user selection 
  • Provide non-validation errors, warnings, or updates on the status of items in the user’s curated item list 
  • Provide confirmation when updating and removing items which provide navigation or other actions 

They also allow the following options:

  • May include detailed information 
  • May include additional actions 
  • May be dismissible 

When to use

  • Exposing a status change to a product caused by user selection
  • Providing confirmation when updating and removing items that provides navigation or other actions
  • Increasing visibility of existing errors
  • Valid form options cause invalid selections

When not to use

Persistent status anatomy

Diagram for persistent status notifications, annotating the required layout of the elements listed below

  1. Container
  2. Optional dismiss action
  3. Message

1. Container

Best practices

  • Add role=”status” to the markup on activation, announcing the notification without interrupting the page flow of the user
  • Add ID to be referenced via aria-controls on the element which is causing the notification
  • Ensure the notification container can receive focus
  • Ensure the notification content is dismissible if moving focus to the notification
  • Ensure an element with role status does not receive focus because of change in status
  • Make the relationship between page controls and the notification explicit with the aria-controls attribute if another part of the page controls what appears in the status

What to avoid

  • Opening as a blocking overlay window
  • Moving focus automatically to the notification
  • Directing the user to a new page or window
  • Overusing notifications as they may interrupt the user experience
  • Reusing bespoke UI intended for other message or navigation types

Options:

  • Persistent status notifications may:
  • Display notifications in unique UI to create distinction around themselves and the page content
  • Open or update content in locations unrelated to the action which caused the notification to appear
  • Update a live region of the page
  • Use the HTML <aside> tag, denoting the section that, though related to the main element, doesn't belong to the main flow

2. Optional dismiss action

Best practices

  • Ensure the notification will not be removed if keyboard focus or mouse hover is within or over the notification
  • Return user focus to a logical location
  • Provide at least one focusable UI element (i.e. close button, primary button)

What to avoid

  • Creating notifications that disappear automatically.

3. Message

Best practices

  • Clearly communicate what is happening to the user.

For further reading on status notification accessibility, check out these references: