Components - Alert

Contents

What is an Alert?

An Alert is something you show to your users to send them a message. This can include important feedback on what they're doing within the product, and help them understanding exactly what their actions will affect across the entire system, page or form. Alerts can be contextual too, indicating a positive or negative message, a warning, or just a piece of important information.

When, and why?

Alerts can be used to draw a user's attention to information you want them to know, such as status changes or updates. An Alert should contain information that is important to the user and should always be relevant. They can be generated in response to user actions (for example while they are performing a task within the software), or automatically generated by your application (such as notifying the user when a process that was running in the background has been completed). The main difference between these two methods is one provides immediate feedback, while the other provides updates on system activities.

Alerts can require an action, or simply contain information. When it requires an action, Alerts should actively interrupt the user's journey. However, Alerts that do not need an action can be less intrusive and subtler.

Note: Alerts must not be confused with or used as form validation. Form validation is tied to individual form fields and use an input's help text.

Alert types

The following Alert types are available:

Type	Description	Behaviour
Default	An Alert that contains an icon, a title, and a line of text	Persists. Cannot be dismissed or actioned
Compact	An Alert that contains an icon and a title	Persists. Cannot be dismissed or actioned
Coloured	An Alert that contains an icon, a title, and a line of text, with a coloured background	Persists. Cannot be dismissed or actioned
Solid	An Alert that contains an icon, a title, and a line of text, with a solid white background	Persists. Cannot be dismissed or actioned
Dismissible	An Alert that can be dismissed	Persists, but can be dismissed
Actionable	An Alert that contains an action	Persists, but can be actioned

Alert contexts

Context helps convey the information being communicated. Alert contexts correspond to a colour and an icon to provide a consistent experience for users. For more information, please refer to Colour.

Context	Description	Behaviour	Example
Success	Indicates actions were completed successfully. The Success colour is green.	Does not require user interaction, as disappears automatically after a short time	A new record saved or preferences have been updated
Danger	Indicates errors and, optionally, prevents users from proceeding until the issue has been resolved. The Danger colour is red.	Always persists until the user dismisses or resolves the issue	Credentials cannot be found or access is denied
Warning	Indicates that actions are not desirable or might have unexpected results. The Warning colour is yellow.	Persists until the user dismisses or continues regardless	A file is too big or a file already exists
Info	Indicates neutral or advisory information that may not be related to the current action. The info colour is teal.	Does not require user interaction, but persists until user dismisses	Scheduled system maintenance or a new report is ready

Using an Alert

Alert actions

Actions are a good idea for an Alert if they are telling the user to do something. Even if the action on the Alert isn't what they need to do, a link to place they need to go to achieve that action is a great idea.

If you do include an action, then there should only ever be one. If you require two actions on an Alert, the user should instead be signposted to where they can complete the requested task.

Alert dismissal

Alerts should only ever use a dismissible type when they are non-critical messages. A user is not guaranteed to be looking at the screen when the Alert is generated, and a user's disability may prevent them from reading or interacting with the Alert quick enough to action the warning.

Alert frequency

Although Alerts are great for communicating, we recommend that they are used sparingly. If users are continually being interrupted by Alerts, then this can become frustrating and impact their productivity.

Overusing Alerts may quickly see their importance fade and users may decide to ignore them, which would defeat the point! Alerts should be an exception to the user's normal workflow, to ensure their attention is captured.

Alert length

Alerts should always communicate a single, succinct message, which provide clear instructions and optionally offer actions a user can take. Ideally, they should take up no more than two lines.

Alert placement

Alerts should never stack vertically, nor should more than one Alert be visible at once. Each Alert type has its own distinct region in which it should be displayed. For consistency, these locations should not be ignored. The locations can be found in the System messaging guidelines.

Alerts should never cover another piece of content on the page - covering up a piece of content with an Alert may prove disruptive to users and inhibit their usage of the product.

Component accessibility

This component has been built to meet the current WCAG AA 2.1 guidelines. We also test these components against the guidelines before release.

Aria tags

Every component in Mosaic requires an appropriate Aria tag to ensure that screen readers can effectively parse the page. Aria tags are provided as part of Mosaic. Please do not override these without good reason.

Ensure that Aria tags are used as appropriate signposts throughout the product.

Colour Combinations

When designing with an Alert, you should be mindful of the colour combinations you are using. The components have been designed with this in mind, but if you are using colours that are not part of the default component, please ensure that there is a clear colour contrast within the parts of the component and between the Alert and the background it is on. To check the contrast, please use WebAIM's contrast checker.

Focus state

An Alert needs to have a focus state - a focus state is when you tab into an element to interact with it. Ensure that users can use their keyboard to focus on Alert.

Icons

An icon needs to have underlying code that describes what action the icon takes. the labels should be specific - for example, 'bin' icon for delete should be labelled 'delete'. not 'bin'.

Key Binding

An Alert needs to be able to be interacted with via a keyboard. Where possible we will provide key-binds within our Mosaic component or there will be default HTML ones. If this isn't the case then please implement logical key-binds for all intractable components.

Movement/Animation

Please refer to the WCAG guidelines for the time-based considerations for animations.

Alert