Alerts are banners that communicate a message with a severity attached to it. They grab the user’s attention to provide critical information needed in context.

Two Main Types

Your container has been created. You can customize your VM in the Settings Panel. This feature is still under development. Your license is about to expire.
Standard Alerts

Standard alerts are used in the context of an application either in the content area itself or within components.


There are four different sub-types of standard alerts success, info, warning, and error.

You can customize your VM in the Settings Panel. This feature is still under development. Your license is about to expire. Your container has been created.
App-Level Alerts

App-level alerts are used in the global context of an application. They are placed at the very top of all content and navigation.

There are three different sub-types of app-level alerts info, warning, and error.

Standard Alerts

Four different sub-types

There are four different sub-types of standard alerts: error, warning, info, and success.

Error
Error

Reserved for errors, malfunctions, as well as critical issues like license expiration.

Warning
Warning

Reserved for warnings: a message that needs the user attention and acknowledgment but might not cause errors.

Info

Provides info to users in context. Shouldn’t be overused to replace regular content.

Success
Success

Reserved to provide to a static persistent success message.

Order in context

Standard alerts convey different levels of severity and urgency. They’re ordered by the urgency in which the user needs to pay attention to: error, warning, info, then success.

In the case there are multiple of each sub-type, all of them are shown before another sub-type is reached. For example, multiple errors are shown before the first warning is.

Style

The consistency in the style of the standard alerts allows users to quickly identify them, pay attention to them, and acknowledge them.

Typography

Depending on the sub-type of a standard alert, make sure to communicate a clear, concise, and actionable message.

Size

There are two sizes of standard alerts: default and compact. Use the compact alert only in places where vertical space is scarce and information density is needed. Cards provide a good example here.

Info Compact Info

Placement

Standard alerts could be placed in multiple different contexts including inside of components.

Modals

Alerts could appear within modals. It is recommended that no more than one alert appear within a modal. Their function should not be to validate, validation should be done inline and closer to the error itself.

 

Cards

It is recommended to use concise language as you share an alert within a card. It is also recommended to use a compact-size alert. The focus of the alert should be on its content not on the alert appearing in it.

It is also recommended to have an alert at the very top of a card, on top of its title. An alert is meant to attract the attention of the user.

Using more than one alert within a card distracts the user and dilutes the importance of the alerts displayed.

Data might be outdated. Last update: 16 hours ago.
Memory
10.05 GB free
1.94 GB used | 11.99 GB total

App-Level Alerts

Three different subtypes

There are three sub-types of app-level alerts: error, warning, and info.

Why no success app-level alert?

App-level alerts are global in nature. Reporting a success of an operation should either be communicated within context or as a notification message.

Order in context

App-level alerts follow the same urgency order as standard alerts: error, warning, and info.

Placement

App-level alerts are placed at the very top of the global context. They should not be placed in any other configuration. Their purpose is to provide global alerts available and relating to the full context of the overall application.

App-level alerts appear at the very top of your application

Accessibility

Actionable controls inside dynamically genrated alerts are not accessible to screen reader users! For this reason Clarity does not recommend using dropdowns, buttons, links inside alerts that appear as dynamic notifications.

Accessibility problems related to using actionable controls inside dynamically generated alerts:

  • They are announced as part of the alert message, which is out of context and may be confusing. For example, the following alert will be announced as "success acknowledge":
    Success
  • There is no way for the user to directly interact with the announced action controls.

It is acceptable to use actions in static alerts. The following guidlines are recommended:

  • Controls can be dropdown, button or link elements.
  • Buttons should be used for actions, links for navigation.
  • The text for these controls should be as descriptive as possible.

Code & Examples

Several classes and elements are required to implement the Clarity alert layout. A table of these classes and elements with a brief description of each follows:

.alert This class is a wrapper around .alert-items and the .close button. Place the .close button before the alert items.
.alert-items This class is a wrapper around one or more .alert-item elements.
.alert-item This class is a wrapper around .alert-text, .alert-icon-wrapper, and .alert-actions.
.alert-icon-wrapper .alert-icon-wrapper contains a clr-icon with the classname .alert-icon applied to it. The icons used for the different alert types of success, danger, warning, and info are, respectively: check-circle, exclamation-circle, exclamation-triangle, and info-circle.
.alert-actions .alert-actions can consist of dropdowns or links. Each action should extend the .alert-action class.

Types

Clarity has error, warning, information, and success alerts denoted by the following classes:

  • .alert-danger
  • .alert-warning
  • .alert-info
  • .alert-success

Placement

Alerts in the Content Area
Alerts in Cards
Alerts in Modals

Size

Use the .alert-sm class with .alert for an alert 24 pixels in height. The default is 36 pixels.

App-Level Alerts

.alert-app-level

This class must be applied with .alert to render an app-level alert.

Angular Component

Summary of Options

Input Values Default Effect
[clrAlertClosable]
Type: Boolean
Default: true
true, false true If false, the alert will not be closable by clicking on the top-right "x".
[(clrAlertClosed)]
Type: Boolean
Default: false
true, false false Two-way binding on the state of the alert: opened or closed.
[clrAlertType]
Type: String
Default:
"info"
"info", "warning", "success" and "danger" "info" Sets the type of the alert.
[clrAlertSizeSmall]
Type: Boolean
Default: false
true, false false If true, renders a small alert.
[clrAlertIcon]
Type: String
Default: varies
icon name as string varies View supported icons.
[clrAlertAppLevel]
Type: Boolean
Default: false
true, false false If true, renders an app-level alert.
[clrPolite]
Type: Boolean
Default: true
true, false true aria-live will be set to "polite"
[clrAssertive]
Type: Boolean
Default: false
true, false false aria-live will be set to "assertive"
[clrOff]
Type: Boolean
Default: false
true, false false aria-live will be set to "off"
[clrCloseButtonAriaLabel]
Type: String
Default: Close alert
Close alert Close alert Overwrite default aria-label for close alert button
Deprecation: Since v4, we will no longer handle setting aria-live and announcing the message for you by default. Based on the application use case, you can use the new ClrAriaLiveService to make announcements when they make sense for a user to hear about updates or loading status changes. This will result in of removing few inputs provided by the component such as clrPolite, clrAssertive, clrOff
Examples
1. clrAlertClosable set to false. Default value is true.
2. clrAlertType set to alert-success. Default value is alert-info. Accepts values same as the static alert type classes.
3. clrAlertSizeSmall set to true. Default value is false.
4. Binding to the clrAlertClosedChange event.
5. clrAlertAppLevel set to true. Default is false.
6. Multiple app level alerts can be displayed with previous and next buttons.