Page alerts

When to use this component 

• Use page alerts to bring the user’s attention to important page information or system status 

• Use page alerts to communicate the result of a user action (for example, error or success) 

When not to use this component 

• Do not use page alerts just for styling regular content (for emphasis or highlighting) 

• Do not use page alerts to provide information about a normal step in a process or task 

• Do not use page alerts to tell the user about a problem that’s affecting the service as a whole – Use product alerts instead 

Best practices 

Do 

• Display page alerts after a change in context, for example, when a user clicks a link or submits a form, launching a new page or an updated view 

• Write concise headings and copy - Provide further details in the appropriate section or page 

• Place page alerts underneath the page or subsection heading, as applicable 

• Ensure that page alerts include headings that clearly convey the purpose of the alert (for example, “Warning”) 

• Use an appropriate status – Please see the Guidelines for Alerts article 

Don’t 

• Display alerts that are not related to the user’s current goal 

Tips 

• Try to limit to one alert per page 

Accessibility 

The WCAG criteria outlined in this section were chosen because they represent some of the most common failures when designing and implementing these components. For a comprehensive list, please see Web Content Accessibility Guidelines (WCAG) 2.1 (w3.org). 

1.4.3 Contrast (Minimum) 

The intent of this success criterion is to provide enough contrast between text and its background so that it can be read by people with moderately low vision (who do not use contrast-enhancing assistive technology). Text that is larger and has wider character strokes is easier to read at lower contrast. The contrast requirement for larger text is therefore lower. 

It is recommended to check colour contrast between the text and background using a contrast checking tool like the one provided by WebAIM WebAIM: Contrast Checker. 

Understanding Success Criterion 1.4.3: Contrast (Minimum) | WAI | W3C 

1.4.11 Non-text Contrast 

The intent of this success criterion is to ensure that active user interface components (i.e., controls) and meaningful graphics are distinguishable by people with moderately low vision. Low contrast controls are more difficult to perceive, and may be completely missed by people with a visual impairment. 

It is recommended to check that UI components have a contrast ratio of at least 3:1 against adjacent colours using a contrast checking tool like the one provided by WebAIM WebAIM: Contrast Checker.  

Understanding Success Criterion 1.4.11: Non-text Contrast | WAI | W3C 

4.1.3 Status Messages 

This criterion requires that, in content implemented using markup languages, status messages can be programmatically determined through role or properties such that they can be presented to the user by assistive technologies without receiving focus. 

The intent of this success criterion is to make users aware of important changes in content that are not given focus, and to do so in a way that doesn't unnecessarily interrupt their work. 

The intended beneficiaries are blind and low vision users of assistive technologies with screen reader capabilities. 

Understanding Success Criterion 4.1.3: Status Messages | WAI | W3C 

Key component features 

Telerik provides four built-in notification types suitable for use as page alerts: error, warning, info and success. They also offer the option to define your own type by customizing the template and setting options for size, colour and position. 

Blazor Notification Demos - Overview | Telerik UI for Blazor 

Open

Figure 1 - Telerik Notification component showing informational, success, warning and error alerts 

Examples 

Open

Figure 2 – Telerik Notification component used as a page alert 

Responsive design

In order to be inclusive to all users, we need to consider how our applications behave on smaller viewports. (For more information on viewports, see The viewport is the window to your site – Digital.gov.) While designing and building using responsive design principles will allow you to create an optimized layout for users accessing your application on smaller viewports, this is not the only benefit. This will also ensure you are supporting users with low vision who need to enlarge text by using the browser’s zoom function. 

To help ensure the responsiveness of your application, consider the following points when designing alerts:

• Preservation of content - Content shouldn’t be removed or changed to view an application on a smaller screen size. Don’t change or reduce the amount of text or functionality of an alert to fit a smaller screen size.

• Concise text - Keep text concise to avoid taking up larger amounts of space then necessary on smaller screen sizes.

• Consistency and visibility - The location of a page alert on the page shouldn’t change or be hidden when viewing on a smaller screen size. The entire alert should be visible without needing to scroll horizontally.

Resources 

Government of Canada resources 

Contextual alerts - Canada.ca design pattern - Canada.ca 

Alert fatigue during COVID-19 | Canada.ca blog 

External resources 

Page alerts | Ontario Design System