TC Design
Page alerts 2
- Dan Larmour
- Allison Batoff
Use a page alert to notify users of important information or changes on a page.
How page alerts work
Page alerts occur after a change of context. For example, when a user clicks a link or submits a form, launching a new page or an updated view.
Success and error summary alerts are used following a form submission. When the new page or view is first loaded, ensure that focus is moved to the success or error summary alert. Screen readers will then announce the alert, letting the user know the status of their form submission and what to do next.
The HTML title element should also start with copy that indicates the status (for example, “Success:” or “Attention”) to ensure feedback is provided in the page’s name.
Best practices
Page alerts are typically at the top of the page between the level 1 heading (H1) and body content. In some cases, there might be an alert needed for a particular section of a page - in this case, place the alert next to impacted points of service or information.
If a 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. Any errors relating to a specific field must have a link to the field. For business rule validation that isn’t field-specific, a link can optionally be provided to an anchor for the relevant section of the page.
Types of page alerts
There are four main types of page alerts:
Information
Warning
Success
Error
Information
Use information alerts for time-sensitive information. For example, important dates, recent content updates, and new policies.
Informational alert messages should be dismissible using an ‘X' in the top right corner to close. Make sure the 'X’ is keyboard-focusable.
Warning
Warning alerts tell the user something urgent or help the user avoid a problem. For example, travel information, content trigger warnings, or location closures.
Warning alerts should not be dismissible.
Success
Default to using toasts for success messages, unless the feedback is delayed, persistent, has a call to action, and/or marks the end of a process (e.g. the form was submitted, here is your reference #).
Success alerts should be used to tell the user that the action was successful. Use them for confirmation messaging as a user completes sections in a web form. For example, when a payment has been successfully processed in a transaction.
Success message should be dismissible using an 'X' in the top right corner to close.
Success Toast messages
Use toast messages to confirm an action that doesn’t meet the criteria of the Success Alert message above. In general, toast messages should not go over 3 words and should not be used for error messages. Use the ‘noun + verb' pattern for writing toasts such as “Inspection data updated” or ‘File added’.
Do not include an action in a toast unless the same action is available somewhere else on the page.
Make sure toasts appear in the same spot across the entire application and in both portrait and landscape mode. For example, if a toast appears in the top-right corner in portrait mode and the user rotates their device to landscape, the toast should re-orient to the top-right corner.
Toast message accessibility requirements:
Use an ARIA live region using [aria-live=”polite”] so that screen readers announce the toast text after other more pressing announcements
Toast should persist for at least 10,000 milliseconds
For more information on toast message accessibility requirements, refer to the article “Designing Toast Messages for Accessibility”.
Example success toast message:
Error summary
Error alerts tell users that the action was unsuccessful or that there was a validation error upon submission of a form. For example, a user incorrectly completes a field and the system does not allow the user to complete the task upon submission unless the errors are fixed. Use a hyperlink for each field that needs to be corrected, listed in the order that they appear on the form. Upon clicking the hyperlink, the user is brought to that field.
Error messages must not be dismissible.
Error messages
Put the message in red between the field label and the input. If the input has a border such as a text input or calendar picker, give the input field a red border. Here are two examples:
To help screen reader users, the error message component includes a hidden ‘Error:’ before the error message. These users will hear, for example, “Error: Enter your first name”.
How to write error messages
Writing good error messages can be difficult. You want to describe what happened and tell the user how to fix it, but make sure you use plain English, use positive language and be concise.
There is also no ‘one size fits all’ approach for writing error messages and the way you write each message could vary depending on what you are asking the user to do and the type of validation error that occurred.
Whenever you are writing error messages, refer to the GOV.UK Error Message page for detailed explanations of what to do and what not to do, examples, and different use cases. The GOV.UK Recover from Validation Errors page is also a great resource for how to apply validation to your forms and help users recover from validation errors.
Extra technical specifications
A page alert consists of a shaded background with an emphasized left-hand border, an icon, a heading (title of the alert), descriptive text, and in some cases, an 'X' to dismiss the alert (refer to the examples above).
Use FontAwesome solid or regular icons (no light or duotone).
Ensure the colour contrast between the icon colour and the background colour is at least 3:1 (use this WebAIM contrast checker).
When the new page or view is first loaded, ensure that focus is moved to the alert so that screen readers will announce the alert right away.
References and resources
TC Design