Toast snackbar

How to test a toast snackbar

Gherkin Condensed

Given that I am on a page with a toast snackbar

1 Keyboard for mobile & desktop

WHEN I use use features that trigger the toast I SEE the toast (BUT focus DOES NOT transfer automatically when the alert appears)

2 Desktop screenreader

WHEN I use a desktop screenreader (NVDA, JAWS, VoiceOver) AND I use use features that trigger the toast
- I HEAR The toast is read when it appears (BUT focus DOES NOT transfer automatically when the toast appears)
- I HEAR It identifies itself as an alert or status when it appears
- I HEAR If it is possible to close the toast, focus then returns to a logical place in the page
- I HEAR It remains open until closed by user

3 Mobile screenreader

WHEN I use a mobile screenreader (Talkback, VoiceOver) AND I use features that trigger the toast snackbar
- I HEAR The toast is read when it appears (BUT focus DOES NOT transfer automatically when the toast appears)
- I HEAR It identifies itself as an alert or status when it appears
- I HEAR If it is possible to close the toast, focus then returns to a logical place in the page
- I HEAR It remains open until closed by user

1 Keyboard & screen reader actions

When I use	I see/hear
Tab	Focus visibly moves in logical order to buttons or links inside the toast
Space	Any buttons inside are activated
Enter	Any links or buttons inside are activated

2 Mobile screenreader gestures

When I use	I hear
Swipe	Focus moves in logical order to the toast
Doubletap	This typically activates most elements in the toast

3 Screenreader output for all devices

Reads	I hear
Name	The toast is read when it appears (BUT focus DOES NOT transfer automatically when the toast appears)
Role	It identifies itself as an alert or status when it appears
Group	If it is possible to close the toast, focus then returns to a logical place in the page
State	It remains open until closed by user

Don’t use toast snackbars

It’s exceedingly rare this is a good design choice.

Snackbars are a custom HTML construct and have no semantic meaning.
They add auditory noise to the screen reader experience and are difficult to browse if the message was missed.
As such, like tooltips, it is difficult to define precise acceptance criteria.

Instead use an inline element to indicate a change

Inject a success message in proximity to the updated control
Place undo/edit buttons in easy to find locations for keyboard users
Utilize a confirmation screen on exit

Marketing preferences Send me constant spam

Never use toast snackbars for:

Critical or irrevocable functionality like:
- Time sensitive actions (ex: Unsend this message)
- Confirmation of choices (ex: Are you sure you want to send payment?)
- Blocking error messages
On page load messaging/alerts
- Performing unexpected actions or alerts on page load is confusing to people using a screenreader

Timing

It is preferable to not let a toast snackbar time out.
If the snackbar must dismiss automatically, it is preferred that timing be adjustable (WCAG 2.2.1).

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

Code example

<div id="toast">
  <span id="toast-message" role="status">
    <!-- Inject snackbar message here -->
  </span>
  <button type="button">
    Dismiss
  </button>
</div>