Notifications and Toasts: When to Interrupt and When Not To
A toast is a brief message that disappears on its own. When to use one to confirm an action, when not to, and how to keep it from being missed or annoying.
What is a toast notification?
It is the floating message that appears in a corner when you save a file, when a submission succeeds, or when an item is deleted and undo is offered. The name comes from its resemblance to toast popping up: it appears, stays for a moment, and goes away.
Design systems describe it the same way. For example, the Singapore Government Design System defines it as a component for quick notifications, with a default delay of 5 seconds for short, routine messages (Singapore Government Design System, “Toast”).
Why should a designer care?
Because it is one of the cheapest ways to give feedback. A confirmation stops someone from wondering whether the click worked. But the same pattern, used badly, is a source of noise: messages that show up when nobody needs them, or that cover the button the person was about to press.
Adrian Roselli, who has reviewed notification patterns for years, starts from an uncomfortable premise: people will miss toasts. That is why he suggests asking first whether the message adds value. If it doesn’t, it shouldn’t appear (Adrian Roselli, “Defining Toast Messages”).
When is it the right choice?
A toast fits three cases:
- Confirming an action with no serious consequences. “Draft saved” or “Sent to Ana”.
- Offering undo after a deletion. This is the most useful case of the pattern. See the safeguards for destructive actions to decide when to confirm before and when to undo after.
- Reporting a background process that finished. “Export ready” or an upload that completed.
A simple rule: if the person can keep working without reading the message, and loses nothing if they miss it, the toast works.
When should you not use it?
- For errors that block the task. If a payment failed, the person needs to read it and act. That is a message that stays on screen, not a toast.
- For instructions. Text explaining how to complete a step must not disappear.
- As the only signal for something critical. The Singapore guidance is blunt: don’t use a toast as the only place for a critical instruction, or for content that must stay visible until it is read.
- For content that needs to be read calmly. Long text reads badly in a message that goes away by itself.
- In a series. If one action fires three toasts, the user stops reading after the first.
How do you make it accessible?
This is where most toasts fail. These are the points the sources of this article make:
- Timing and pausing. According to Roselli, a message that disappears by itself after a few seconds fails WCAG 2.2.1 (Timing Adjustable) unless users can adjust the time. At a minimum, pause the timer while the cursor or focus is on the message. The MiHCM design system does this, with a 5-second default.
- Announcing to screen readers. The message should be announced through a live region. For non-urgent messages,
status(polite) orlog(useful when message order matters) are the usual options. Reservealertfor urgent information that needs immediate attention. Roselli stresses that the region must exist on the page before the message appears: if it is created at the moment it is needed, it likely won’t be announced. - Not stealing focus. A toast should not move focus automatically for routine updates. Whoever is typing should keep typing.
- A real close button. If there is a close button, make it a named button, reachable by keyboard, and large enough to hit. In MiHCM, for example, the Esc key closes the focused message.
Roselli goes further: he states that none of the toast patterns he had found would pass a WCAG audit. His alternative is a fixed message region at the top of the screen, where messages stay until the person dismisses them. His article dates from 2020, so before adopting that position, test with real screen readers. That test is part of the accessibility review for any change like this.
Example
Illustrative example: a notes app has a “Delete” button that removes a note instantly and shows a five-second toast: “Note deleted”. A user who deletes by mistake has no way to get it back. The team changes the pattern: deleting shows “Note deleted. Undo”, the toast pauses while the cursor or focus is on it, has a close button, and the deleted note stays recoverable from the trash even after the toast is gone. The change isn’t cosmetic. It changes what the person can recover.
Common mistakes
- Showing a toast for every action, even the obvious ones.
- Putting something that belongs on screen into a toast, such as a form error.
- Using
alertfor every message and cluttering the screen reader’s output. - Letting the toast cover a button the person needs to press.
- Assuming the toast gets read just because it appears.
How to start tomorrow
List every toast in your product. For each one, write down what happens if the person doesn’t read it. If the answer is “nothing”, leave it. If the answer is “they lose something”, replace it with a persistent message or an undo. Then walk through the flow with a screen reader and the keyboard. If the toast isn’t announced or can’t be closed, you already have your first accessibility ticket.
If you’re interested in how the interface shows its current state, look at status awareness. And if the message appears because something is slow, the page on loading states gives you the context.