Rethinking Toast Snackbars
Toast snackbars might seem like an easy way to provide feedback, but they’re often not the best fit for accessible and user-friendly design. Here’s why:
- Accessibility Limitations: Because snackbars are custom HTML elements, they lack semantic meaning and can be challenging for assistive technologies like screen readers.
- Missed Messages: If a user doesn’t catch a snackbar in time, it’s difficult to go back and review the information.
- Auditory Clutter: For screen readers, snackbars can create unnecessary noise, especially if they appear frequently or unexpectedly.
- Unclear Rules: Like tooltips, snackbars are tricky to define and test consistently in design criteria.
Instead use an inline element to indicate a change
- Inline Feedback: Inject a success message in proximity to the updated control
- Accessible Undo/Redo Options: Place these buttons in clear, easy-to-navigate locations.
- Thoughtful Confirmations: Use a confirmation screen for critical actions or when users are exiting an important flow.
When Toast Snackbars Don’t Work:
There are certain scenarios where snackbars simply aren’t the right tool:
- Critical or Irreversible Actions: For example, “Unsend this message” or “Confirm payment.” These require deliberate, visible feedback
- Blocking Error Messages: Important errors should grab attention and provide clear guidance—not rely on a fleeting message.
- Page-Load Alerts: Automatically showing messages on page load can confuse users, particularly those using screen readers.
Timing
If you find a situation where a toast snackbar is truly necessary:
- Avoid auto-dismiss wherever possible.
- If dismissal must be automatic, make sure the [timing is adjustable to meet WCAG 2.2.1 standards] (https://www.w3.org/WAI/WCAG21/Understanding/timing-adjustable.html).
Only use toast snackbars to reinforce updates
- If using a snackbar is unavoidable, it must only be used for non-critical messaging.
- The status injected must also be discernable on the page without the snackbar.
Practical example
Given that I am on a dynamic single page app
- WHEN the customer changes the state of a toggle to OFF or ON
- THEN the toast appears to reinforce that the change has been saved
- AND the customer can confirm this is true from the toggle itself