TC Design

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

When to use this Component  

  • Use product alerts to tell the user about something they need to know about, but that’s not directly related to the page content, for example: 

  • A significant situation, such as a site-wide service disruption, or other critical information that will impact most users 

  • Important recent or upcoming changes to a process or service 

When not to use this Component 

  • Do not use product alerts to tell the user about validation errors – Use in-line alerts instead 

  • Do not use product alerts for information that is directly relevant to the thing the user is doing on that page – Use page alerts instead 

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

Best Practices  

Do  

  • Write concise headings and copy 

  • Place product alerts at the top of the page above the main heading or global header bar, as applicable 

  • Remove alert text once the issue is resolved or enough time has passed that the information provided is no longer new 

  • Describe the impact on the user 

  • Use product alerts sparingly to avoid alert fatigue 

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

Don’t  

  • Stack product alert banners 

Tips 

  • Consider how tall the product alert banner will appear on mobile screens 

  • Since product alerts can impact the visibility of other content, use a link or call to action to direct users to further information, as needed 

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.  

Tip: There are contrast checking features built into some automated accessibility testing tools. However, these tools are not always capable of checking the contrast of different UI component states. For instance, if your page alert uses a dismiss button, it is recommended to manually test the contrast of its hover and focused states. 

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 that can be modified for use as product 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 

Telerik Notification component showing a blue informational alert with an i icon, a green success alert with a checkmark icon, a yellow warning alert with an exclamation mark icon and a red error alert with an x icon.

Examples 

Note: The following example is a visual illustration of how this component could be used in a MAACE application. Live examples of the Telerik UI component implemented in MAACE applications will be added when available. 

Telerik Notification component used as an error product alert in the MITRACK application telling users that there is a scheduled maintenance period.

Resources

Government of Canada Resources 

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

Alert fatigue during COVID-19 | Canada.ca blog 

External Resources 

Critical alerts | Ontario Design System 

Notification banner – GOV.UK Design System (design-system.service.gov.uk) 

  • No labels