Alert

Alerts keep users informed of important and sometimes time-sensitive changes.

Examples

Informational alert

info

Alert header

Alert text goes here

header

info

Secondary alert

Alert text goes here

Success alert

check_circle

Alert heading

Alert text goes here

Danger alert

error

Alert heading

Alert text goes here

Default (Warning) alert

warning

Alert heading

This is also the default site level alert style

Informational alert

info

Alert heading

Alert text goes here

Light alert

info

Alert heading

Alert text goes here

Dark alert

info

Alert heading

Alert text goes here

Usage

  • User feedback. Use an alert for feedback messages that respond to an action a user has taken and to draw their attention to something that they need to correct or to confirm successful completion of a task. These messages use success and error variations.
  • In-application system status. An exception to the above is providing information to the user, unprompted, about a problem with a particular application. These system status messages typically use an error or warning variation and do not require user action.
  • Engagement messages that nudge the user to enter or update data. Engagement messages typically use the informational variation and ask the user to take an action.
  • Access messages when a user tries to access an item that is not available to them. Access messages typically warn the user that something they tried to access is not working correctly or is temporarily unavailable. These often use the error or warning variations.

Reasons to consider something else

  • Destructive actions. If an action will result in destroying a user’s work (for example, deleting an application) use a more intrusive pattern, such as a confirmation modal dialogue, to allow the user to confirm that this is what they want.
  • System maintenance. Most system messages related to maintenance are handled by the Site Alert component.

How to use alerts

When the user is required to do something in response to an alert, let them know what they need to do and make that task as easy as possible. Think about how much context to provide with your message. A notification of a system change may require more contextual information than a validation message. The message should be concise, in plain language, and adhere to the DOL Voice and Tone Guide.

  • Allow a user to dismiss a notification wherever appropriate.
  • Don’t include notifications that aren’t related to the user’s current goal.
  • Don’t stack alerts one after the other.
  • If the alert appears within the page body content, it should be co-located with relevant content.
  • Alerts should not contain other expandable components such as the accordion component.
  • Messaging should be direct, concise, and in plain language.
  • Standard alerts must contain headings.

Placement

  • In most cases, the standard alert (in all of its variations) should be placed directly below the summary text, near the top of the page.
  • When a standard alert is applicable to a specific section of content on a page, it should be placed directly below the header of that section.
Was this information helpful?