TC Design
How do I ensure that my status feedback messages are accessible?
- Allison Batoff
We use various types of status messages within most of our applications in MAACE: System/page unavailable messaging (like 404 messages), system-level messaging, page level status messages, in-line validation, and confirmation messages. I have linked to some great articles on how to use each message type and how to write clear, effective content in the Resources section.
Telerik provides UI components for in-line validation, form-level validation, and notifications. There are some accessibility challenges with these notifications and some workarounds described below.
In-line Validation
The current Telerik input components, including drop downs, date inputs and text inputs offer the ability to change the border colour, focus state colour and label colour to $error to indicate a validation error on the field, as well as displaying an error message below the field.
Validation Summary
The Telerik Form component offers the ability to display a contextual validation summary of errors found within the form. The WET toolkit provides a good, working example of how to structure this kind of validation summary (Form validation - Working examples - Web Experience Toolkit (wet-boew.github.io)).
Known Issues
The Telerik Form component validation summary does not include the functionality to link from the individual summary items to their respective form fields. It also does not include a dynamic count of the number of errors and does not use aria-live attribute to announce the validation errors to the user when they appear on the page (ARIA19: Using ARIA role=alert or Live Regions to Identify Errors (w3.org)). These improvements have been captured in our backlog.
Notification
The Telerik Notification component provides status messages styled for success, warning, information, and error. They can be used with an optional icon to indicate the message type and optional close icon. In order to ensure that we do not rely entirely on the use of colour alone to communicate the message type, it is recommended to use the versions provided with the icon (Understanding Success Criterion 1.4.1: Use of Color (w3.org)). Â
Toast messages that disappear on their own can be problematic from an accessibility perspective as they may get missed if they are not in the user’s field of view or they do not have sufficient time to read them before they disappear. We recommended to use notification messages that stay visible on the page until the user has either (a) performed another action or (b) dismisses the message themselves.
However, we understand that there may be specific use cases for these types of toast messages in your applications. The Polaris Design System provides good guidance on how to use these notifications in a way that allows for the most accessible and usable experience, while still acknowledging the limitations of this pattern (Toast — Shopify Polaris).
Known Issues
It is difficult to use toast messages that dismiss on their own in a way that still allows us to comply with WCAG 2.2.1 Timing Adjustable. We are looking at potentially making this a configurable option that the user may set as a preference. However, in the meantime, please use a duration of at least 10,000 milliseconds.
Resources
Page alerts | Design System (ontario.ca)
Error message – GOV.UK Design System (design-system.service.gov.uk)
Error summary – GOV.UK Design System (design-system.service.gov.uk)
Indicators, Validations, and Notifications: Pick the Correct Communication Option (nngroup.com)
TC Design