Toast
Also called snackbar, notification, flash message, growl
A brief message that appears over the interface, usually near an edge, and dismisses itself after a few seconds.
Example
The first one is fine to miss. The second carries an action, so it stays up longer — and in a real product the same action would also exist somewhere permanent.
That third one is the anti-pattern in this element's list: an error the user has to act on should not be the kind of message that removes itself.
When to use it
- Confirming something the user just did, when the result is not visible on screen — saved, copied, sent, archived.
- Reporting that a background job finished while the user carried on with something else.
- Offering a short-lived undo. This is the one case where a toast may carry an action, and the timeout should be generous.
- The information is useful but losing it costs nothing.
When not to
- Errors the user has to act on. A toast that vanishes takes the error message with it and leaves someone stuck.
- Form validation. The message belongs next to the field it is about, not floating in a corner.
- Anything longer than a sentence. Nobody finishes reading a paragraph before it fades.
- Critical or irreversible information. If it matters, it must stay on screen.
- Several at once. Stacked toasts turn into a wall nobody reads, and each one steals attention from the last.
Trade-offs
- Never blocks the interface — the user keeps working.
- Cheap to add and instantly familiar.
- Good fit for undo, because it appears exactly when regret would.
- Easy to miss entirely, especially on a large screen where it sits far from where the user is looking.
- Hostile to slow readers, translated text and anyone using a screen magnifier.
- Hard to reach with a keyboard before it disappears, which makes toast actions a usability trap.
Accessibility
What this pattern needs in order to work for everyone.
- Keyboard
- If a toast carries an action, it must be reachable — either keep it up until dismissed, or provide the same action somewhere permanent.
- Never move focus to a toast. It arrives unannounced, and yanking focus mid-task is worse than the toast being missed.
- Escape should dismiss the visible toast when your implementation supports it.
- Roles and state
- Use `role="status"` with `aria-live="polite"` for ordinary confirmations — it waits for a pause instead of cutting in.
- Reserve `role="alert"` (assertive) for genuine problems; it interrupts whatever the screen reader is saying.
- Render the toast into a live region that already exists in the DOM. A region added at the same moment as its content is often not announced at all.
- Focus
- Focus stays where it was. The trade-off is that keyboard and screen reader users may never reach the toast's action — which is exactly why an action-carrying toast needs a permanent counterpart elsewhere.
In the wild
- Gmail — The archive toast with Undo is the pattern's best case: brief, reversible, and offered exactly when it is wanted.
- Slack — Uses toasts for transient confirmations and keeps banners for anything about connection state.
Compared with
Side-by-side breakdowns of patterns that solve a similar problem.