The in-line alert pattern is comprised of two elements: In-line validation messages and an error summary. The in-line validation messages appear near the input where the error occurred and explain what went wrong and how to fix it. The error summary element appears underneath the page or subsection heading, as applicable, and contains a list with links of the in-line validation messages appearing on the page.
The error summary and in-line validation message elements should be used together in most cases. However, in situations where there is only one field on the page that requires validation, for example, a search field, an in-line validation message could be used on its own.
When to use this component
Use in-line alerts to inform the user of problems on a form and provide direction on how to fix them
When not to use this component
Do not use in-line alerts to inform the user of a problem they cannot fix, such as if the service is unavailable – Use a product alert instead
Best practices
Do
Display in-line 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
Ensure that error messages are clear, concise and easy to understand - Please see the Guidelines for Error and Validation Messaging article
Ensure that the error summary includes a heading that clearly conveys the purpose of the alert (for example, “Error”)
Use an appropriate status – Please see the Guidelines for Alerts article
When using the error summary, include in-page anchor links to the corresponding form controls to make it easier for users to get to the error they need to fix
Don’t
Avoid prematurely displaying errors
Disable submit or save buttons – Allow the user to submit their values and then provide validation messages as needed
Use input masks – Instead use simple interactions and explain the expected format in the input label
Rely on colour alone to indicate an error
Never cover user’s input – Users should be able to edit the input field while also reviewing the error messages provided to them
Avoid the use of toast messages - Users often do not get a chance to fully read or understand the error message before it has disappeared
Tips
Use clear questions in forms to avoid errors in the first place
Forgive trivial mistakes, for example, adding a space before or after a value
The worst error messages are those that do not exist - When users make a mistake and receive no feedback, it can lead to misunderstanding, wasted effort, and frustration
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
Pending: The Telerik Form Validation component does not currently meet all of our requirements. This item is in the MOLE team’s backlog for future development.
Telerik’s Form Validation component allows for multiple validation message display types, including none, tooltip and in-line. It is recommended to use the in-line display type.
Blazor Form Demos - Validation | Telerik UI for Blazor
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.
Resources
Government of Canada resources
Form validation - Working examples - Web Experience Toolkit (wet-boew.github.io)
External resources
Error message – GOV.UK Design System (design-system.service.gov.uk)
Error summary – GOV.UK Design System (design-system.service.gov.uk)