Eine Toast Notification ist eine kurze, nicht-modale Statusmeldung, die temporär am Rand der Benutzeroberfläche erscheint, den Nutzer über den Ausgang einer Aktion informiert und nach wenigen Sekunden automatisch verschwindet.
Rubrik: Mediendesign & Digitale Medien · Unterrubrik: UI-Komponenten · Niveau: Einsteiger Synonyme / Auch bekannt als: Snackbar (Material Design), In-App-Benachrichtigung, Flash Message, Alert Banner, Status Toast
Was ist eine Toast Notification?
Der Name „Toast" stammt von der Analogie zu einem aufspringenden Toaster – die Benachrichtigung „poppt" kurz hoch und verschwindet wieder. Toasts geben dem Nutzer unmittelbares Feedback auf seine Aktionen, ohne den aktuellen Arbeitsfluss zu unterbrechen oder eine manuelle Reaktion zu erfordern. Sie sind die leichteste Form des System-Feedbacks und erscheinen nach erfolgreichen Aktionen (Speichern, Senden), Fehlern (Verbindungsprobleme) oder allgemeinen Statusinfos.
Erklärung
Varianten nach Nachrichtentyp
Success Toast: Grüner Hintergrund oder grünes Icon. Bestätigt eine erfolgreich abgeschlossene Aktion. Beispiel: „Datei erfolgreich gespeichert ✓". Kürzeste Anzeigedauer (3–5 Sekunden).
Error Toast: Roter Hintergrund oder rotes Icon. Informiert über einen Fehler, den der Nutzer beachten muss. Sollte nicht automatisch verschwinden, wenn die Fehlermeldung eine Handlung erfordert. Beispiel: „Upload fehlgeschlagen. Bitte erneut versuchen."
Warning Toast: Gelb/orange. Warnung, die keine sofortige Handlung erfordert, aber beachtet werden sollte. Beispiel: „Niedrige Speicherkapazität."
Info Toast: Blau/neutral. Allgemeine Information ohne Dringlichkeit. Beispiel: „Neues Feature verfügbar."
Action Toast (Snackbar): Toast mit einem Aktions-Button innerhalb der Benachrichtigung. Material Design nennt diese Variante „Snackbar". Klassisches Beispiel: „E-Mail gelöscht [Rückgängig]" – der Undo-Button ermöglicht Korrektur ohne Modal.
Positionierung
| Position | Verwendung |
|---|---|
| Unten mittig | Material Design Standard, Mobile |
| Unten rechts | Desktop Web-Apps (Notion, Figma) |
| Oben rechts | Dashboard-UIs, Enterprise Software |
| Oben mittig | Kritische Systemwarnungen |
Auf Mobile: unten und daumen-erreichbar. Desktop: üblicherweise oben rechts oder unten rechts, außerhalb des Hauptarbeitsbereichs.
Timing und Stacking
- Auto-dismiss: 3–5 Sek. für einfache Erfolgs-Meldungen, 5–7 Sek. für Fehlermeldungen mit Infos
- Kein Auto-dismiss: Bei kritischen Fehlermeldungen, die Handlung erfordern
- Stacking: Mehrere Toasts gleichzeitig erscheinen in einem Stack übereinander. Maximale Anzahl: 3–5 gleichzeitig.
- FIFO: Älteste Toasts werden zuerst entfernt bei Overflow.
Anatomie
- Container: Abgerundeter Balken, farblich nach Typ codiert
- Icon: Optionales Status-Icon (✓, ✗, ⚠, ℹ)
- Message Text: Kurze, klare Statusmeldung (max. 1–2 Zeilen)
- Action Button: Optionaler Text-Button (Rückgängig, Anzeigen, Schließen)
- Close/Dismiss Icon: Optionales X zum manuellen Schließen
Accessibility (WCAG 2.1)
role="status"für nicht-kritische Benachrichtigungen (Success, Info, Warning) –aria-live="polite"role="alert"für kritische Fehlermeldungen –aria-live="assertive"– Screenreader unterbricht sofort- Toast-Container immer im DOM vorhanden (leerer Div), damit
aria-livefunktioniert – Text dynamisch einfügen - Auto-dismiss: Mindestanzeigedauer gemäß WCAG 2.2.1 (Timing Adjustable) – Nutzer mit Leseschwäche benötigen mehr Zeit
- Wenn Aktionen im Toast verfügbar sind: per Tastatur erreichbar, Fokus kann (sollte aber nicht immer) zum Toast wandern
- Farbe allein nicht als einziges Signal – immer Icon oder Text für den Typ verwenden
Beispiele
- Notion – Speicher-Feedback: Nach jedem Auto-Save erscheint kurz ein grüner Toast unten rechts mit „Änderungen gespeichert". Sehr kurze Anzeigedauer (ca. 2 Sek.), da es sich um eine häufige Routine-Aktion handelt. Kein X zum Schließen nötig.
- Gmail – E-Mail-Aktionen: Klassischer Action-Toast nach Archivieren oder Löschen: „Konversation archiviert. [Rückgängig]". Der Rückgängig-Button bleibt 10 Sekunden sichtbar – genug Zeit für eine Korrektur, kein Modal nötig.
- Mobile vs. Desktop: Android-Snackbar erscheint immer unten mittig (über der Bottom Navigation), nimmt die volle Breite minus Margins ein. iOS nutzt eigene Banner-Patterns eher oben. Web-Apps variieren je nach Design-System.
- Accessibility Best Practice: Die Implementierung mit
role="status"und dynamisch eingefügtem Text ermöglicht, dass VoiceOver (iOS) und NVDA (Windows) die Meldung ankündigt, ohne den aktuellen Fokus zu unterbrechen – perfektes Polite-Notification-Pattern. - Häufiger Fehler: Fehlermeldungen als Auto-dismiss-Toast anzeigen, die eine Nutzeraktion erfordern. Fehler wie „Formular konnte nicht gespeichert werden" dürfen nicht verschwinden, bevor der Nutzer sie gelesen und reagiert hat. Zweiter Fehler: Toast-Texte ohne Bezugskontext – „Fehler" ohne Angabe welcher Fehler und was zu tun ist.
In der Praxis
Figma: Toast-Komponente mit Type-Variant (Success/Error/Warning/Info), Size-Variant und Boolean-Properties für Icon, Action-Button und Close-Icon. Toast-Stack-Frame als separater Overlay-Frame. Für Prototypen: Overlay-Animationen (Move In von unten oder rechts mit Dissolve).
HTML/CSS-Grundstruktur: ```html <!-- Toast-Container (immer im DOM!) --> <div id="toast-container" class="toast-container" aria-live="polite" aria-atomic="true" ></div>
<!-- JavaScript: Toast dynamisch einfügen --> <script> function showToast(message, type = 'success', duration = 4000) { const container = document.getElementById('toast-container'); const toast = document.createElement('div'); toast.className = toast toast-${type}; toast.setAttribute('role', type === 'error' ? 'alert' : 'status'); toast.innerHTML = <span class="toast-icon" aria-hidden="true">${type === 'success' ? '✓' : '✗'}</span> <span class="toast-message">${message}</span> <button class="toast-close" aria-label="Meldung schließen">×</button> ; container.appendChild(toast); if (duration) setTimeout(() => toast.remove(), duration); }
showToast('Datei erfolgreich gespeichert', 'success'); showToast('Verbindungsfehler – bitte prüfen', 'error', 0); // kein Auto-dismiss </script> ```
Vergleich & Abgrenzung
| Komponente | Unterbrechung | Aktion nötig | Dauer |
|---|---|---|---|
| Toast | Nein | Nein | Temporär (auto) |
| Modal Alert | Ja | Ja | Bis Bestätigung |
| Banner | Nein | Optional | Persistent |
| Tooltip | Nein | Nein | Hover-gebunden |
| Progress Bar | Nein | Nein | Prozessdauer |
Häufige Fragen (FAQ)
Wie lange soll ein Toast sichtbar sein? WCAG 2.2.1 empfiehlt, dass Nutzer genug Zeit haben sollen, den Text zu lesen. Faustregel: 1 Wort = 1 Sek., mindestens 3 Sek. für sehr kurze Texte. Erfolgsbestätigungen: 3–5 Sek. Fehlermeldungen mit Handlungsanweisung: 7 Sek. oder kein Auto-dismiss. Wenn eine Aktion im Toast enthalten ist (Undo), sollte die Anzeigedauer mindestens 8–10 Sek. betragen.
Kann ich mehrere Toasts gleichzeitig anzeigen? Ja, aber mit Limit. Ein gutes Toast-System stapelt Nachrichten und begrenzt die Anzahl gleichzeitig sichtbarer Toasts auf 3–5. Ältere Toasts werden automatisch entfernt, wenn neue hinzukommen. Bei vielen gleichzeitigen Benachrichtigungen (z. B. Batch-Aktionen) besser zusammenfassen: „5 Dateien hochgeladen" statt 5 einzelne Toasts.
Verwandte Einträge
Weiterführend
- Nielsen Norman Group – „Notification Pattern": nngroup.com
- Material Design 3 – Snackbar: m3.material.io/components/snackbar
- Apple Human Interface Guidelines – Notifications: developer.apple.com/design/human-interface-guidelines/notifications
- WCAG 2.1 – SC 4.1.3 Status Messages: w3.org/WAI/WCAG21/Understanding/status-messages
