Toast- und Snackbar-System

Was macht Toast- und Snackbar-System?

Zweck

Das Toast- und Snackbar-System bietet eine Methodik zur Gestaltung temporärer, nicht-störender Benachrichtigungsebenen. Diese bestehen aus kurzen, selbstschließenden oder manuell schließbaren UI-Komponenten, die in einer dedizierten Bildschirmebene über der primären Oberfläche liegen. Im Gegensatz zu modalen Overlays übernehmen sie nicht den Fokus oder unterbrechen den Benutzerfluss; stattdessen dienen sie als passive, gut sichtbare "Bestätigungsschleife", die bestätigt, dass eine Hintergrund- oder Sofortaufgabe erfolgreich war, fehlgeschlagen ist oder geringfügige Aufmerksamkeit erfordert. Dieses System stellt sicher, dass Toasts visuell einheitlich sind, positioniert sind, um wichtige Steuerelemente nicht zu blockieren, und für Maus-, Touch- und assistive Technologien voll zugänglich sind.

Anwendungsfälle

• Asynchrone Aktionen: Bestätigung, dass eine Datei hochgeladen wurde, ein Entwurf gespeichert wurde oder ein Datensatz im Hintergrund gelöscht wurde.
• Mikro-Verpflichtungsbestätigung: Bestätigung von Aktionen wie dem Hinzufügen eines Produkts zum Warenkorb, dem Kopieren eines Links in die Zwischenablage oder dem Umschalten einer lokalen Systemeinstellung.
• Umkehrbare destruktive Vorgänge: Benachrichtigung eines Benutzers, dass ein Element archiviert oder gelöscht wurde, gepaart mit einer sofortigen "Rückgängig"-Aktion innerhalb der Snackbar.
• Vorübergehende Statusaktualisierungen: Anzeige kurzer, automatisierter Systemwarnungen, z. B. beim Übergang in den Zustand "Offline" oder "Online".

Wann NICHT verwendet werden

• Hochkritische Systemblöcke: Wenn ein kritischer Fehler sofortiges Eingreifen erfordert oder den Benutzer am Fortfahren hindert (z. B. abgelaufene Sitzung, Zahlungsfehler); verwenden Sie das overlay-and-dialog-system (Modal).
• Dauerhafte Abschnittswarnungen: Wenn eine Warnung oder ein Fehler speziell einen gesamten Abschnitt, eine Seite oder einen Formularkontext betrifft und bis zur Lösung sichtbar bleiben muss; verwenden Sie das banner-and-alert-system (Inline-Alarm).
• Formularvalidierungsmeldungen: Wenn ein Benutzer innerhalb eines bestimmten Eingabefelds einen Fehler macht; verwenden Sie das form-design-system (Feld-Validierung).
• Primäre Inhaltserkennung: Verwenden Sie Toasts niemals, um primäre Inhalte, Marketingankündigungen oder Navigationsoptionen zu präsentieren.

Eingaben

1. Nachrichtenschwere / Typ: Erfolg (Bestätigung), Information (neutrale Updates), Warnung (nicht blockierendes Problem) oder Fehler (Vorgang fehlgeschlagen).
2. Aktionsanforderungen: Ist die Rückmeldung passiv (nur lesen) oder enthält sie eine einzelne Mikro-Aktion (z. B. "Rückgängig", "Anzeigen", "Wiederholen")?
3. Bildschirmfläche und Geräteklasse: Ziel-Viewports (Desktop, Tablet, Mobile) und vorherrschende Eingabemethoden (Maus-Hover vs. Daumenreichweite).
4. Z-Index und Schichtungsstrategie: Stacking-Context-Regeln, um Überlappungen mit Kopfzeilennavigation, klebrigen Fußzeilen oder aktiven Overlays zu verhindern.

Ausgaben

1. Anatomie-Spezifikation: Rasterbasiertes Blueprint des Containers, Symbolplatzes, Nachrichtenstrings, Aktions-CTA und manuellen Schalters.
2. Räumliche Ausrichtungs- und Platzierungsregeln: Adaptive Koordinaten für Desktop (z. B. rechts oben oder rechts unten stapeln) und Mobile (z. B. unten ganzer Bildschirmbreite Slide-Up).
3. Warteschlangen- und Stapellogik: Systemregeln für die Verarbeitung gleichzeitiger Benachrichtigungen, maximale sichtbare Grenzen und Ablaufsequenzierung.
4. Interaktive Zeitleiste und Ablaufspezifikation: Regeln für Selbstausblendungs-Timeouts, Hover-to-Pause-Verhalten und Wischgesten.
5. Barrierefreiheit / ARIA-Blueprint: Semantische Abbildung von Live-Regionen, Fokusbehandlung für interaktive Toasts und Bildschirmleser-Ansagen.

Arbeitsablauf

1. Strukturieren Sie die Komponentenanatomie

Definieren Sie ein präzises Abstands- und Layoutraster für den Toast-Container unter Verwendung standardmäßiger räumlicher Token:

• Symbol-Slot: Feste Breite (z. B. 20px oder 24px), positioniert ganz links. Verwenden Sie semantische, kontrastreiche Statussymbole (Häkchen für Erfolg, Ausrufezeichen-Dreieck für Warnung/Fehler, Info-Kreis für Info).
• Textbereich: Linksbündige, umbrechende Typografie, bestehend aus einem kurzen Titel (fett, optional) und einer Beschreibung. Lassen Sie Text niemals mit Auslassungspunkten abschneiden; umbrechen Sie ihn bis maximal 3 Zeilen.
• Aktions-Slot (Optional): Ein einzelner, gut sichtbarer Textbutton (z. B. "Rückgängig"), rechts neben der Nachricht platziert. Bei langem Text auf Mobilgeräten die Aktion in eine neue Zeile umbrechen, rechtsbündig ausgerichtet.
• Schließen-Trigger: Ein deutlicher 'X'-Schließen-Button, ganz rechts platziert. Muss eine Mindest-Hit-Fläche von 24x24px haben (44x44px bevorzugt für Touch-Ziele).

2. Bestimmen Sie die räumliche Platzierung nach Viewport

• Desktop-Platzierung: Positionieren Sie den Toast-Container-Stapel entweder in der oberen rechten oder unteren rechten Ecke des Bildschirms. Halten Sie einen konsistenten Abstand von 24px zu den Viewport-Rändern ein.
  • Stapel oben rechts: Am besten, wenn der primäre Aktionsstrom in den unteren Teilen der Seite stattfindet.
  • Stapel unten rechts: Am besten, wenn oben montierte Navigations- oder Dienstleistungsleisten den oberen Rand belegen und so eine Überlappung verhindern.
• Mobile Platzierung: Wandeln Sie den Desktop-Stapel in eine unten verankerte, vollbreite Snackbar um (Ränder von 12px bis 16px von links, rechts und unten). Dies hält die Interaktion innerhalb der optimalen "Daumenreichweitenzone".
• Z-Index-Regel: Weisen Sie immer einen dedizierten Z-Index-Token zu (z. B. z-index: 5000 oder höher), der Toasts über standardmäßigen klebrigen Kopfzeilen (z-index: 1000) platziert, aber unter aktiven Vollbild-Overlays (z-index: 10000).

3. Etablieren Sie die Stapel- und Warteschlangenlogik

Verwalten Sie Umgebungen mit hohem Triggeraufkommen, ohne Layout-Thrashing oder kognitive Überforderung zu verursachen:

• Maximale sichtbare Grenze: Begrenzen Sie die aktive Warteschlange auf maximal 3 sichtbare Toasts, die vertikal gestapelt sind.
• Stapelrichtung:
  • Bei Platzierung oben am Bildschirm rutschen neue Toasts von oben herein und schieben ältere Toasts nach unten.
  • Bei Platzierung unten am Bildschirm rutschen neue Toasts von unten herauf und schieben ältere Toasts nach oben.
• Warteschlangenpuffer: Wenn ein 4. Toast ausgelöst wird, während 3 aktiv sind, puffern Sie den neuen Toast im Speicher. Rendern Sie ihn sofort, wenn der älteste sichtbare Toast auf natürliche Weise abläuft und ausblendet.

4. Codieren Sie die Ablauf- und Hover-to-Pause-Zeitleiste

Toasts müssen lange genug existieren, um gelesen zu werden, aber sich prompt auflösen, um den Bildschirm zu räumen:

• Dynamische Time-to-Live (TTL): Berechnen Sie den Ablauf basierend auf der Inhaltslänge:
  • Kurze passive Toasts (< 40 Zeichen): Schließen nach 5 Sekunden.
  • Längere oder aktionsbehaftete Toasts: Schließen nach 7 bis 10 Sekunden, um sicherzustellen, dass Screenreader sie vollständig ansagen können und Benutzer Zeit zum Lesen und Handeln haben.
  • Fehler-/Fehlschlag-Toasts: Nicht automatisch schließen. Lassen Sie sie sichtbar, bis der Benutzer manuell auf den 'X'-Button klickt, um sicherzustellen, dass kritisches Feedback nicht verloren geht.
• Die "Hover-to-Pause"-Interaktion:
  • Wenn ein Mausbenutzer über einen Teil des Toast-Stapels fährt, frieren Sie alle aktiven TTL-Countdowns ein. Setzen Sie die Timer erst zurück und setzen Sie sie fort, nachdem die Maus die Toast-Grenzen verlassen hat.
  • Wenn ein Tastaturbenutzer einen Fokus auf ein Element innerhalb eines Toasts legt, frieren Sie den Timer auf unbestimmte Zeit ein. Setzen Sie die Countdowns erst fort, wenn der Fokus zurück auf das Hauptdokument wechselt.

5. Definieren Sie Schließ- und Gestenverhalten

• Touch-Swipe: Erlauben Sie Benutzern auf Mobilgeräten, einzelne Snackbars sofort zu schließen, indem Sie sie horizontal (links oder rechts) aus dem Bildschirm wischen. Halten Sie die Ziehschwelle bei 30% der Viewport-Breite.
• Animation: Verwenden Sie flüssige, hardwarebeschleunigte Übergänge (z. B. transform und opacity) mit einer Dauer von 200ms bis 300ms und cubic-bezier(0.16, 1, 0.3, 1) (Ease-Out-Expo) für das Erscheinen und einfaches opacity-Ausblenden für das Verschwinden.

---

Entscheidungsregeln

Stapelausrichtungsmatrix

Viewport	Primäres Navigationslayout	Empfohlene Toast-Platzierung	Animationsrichtung
Desktop	Linke Seitenleiste / Dashboard	Unten rechts (hält Hauptarbeit frei)	Von links außerhalb des Bildschirms einblenden
Desktop	Klebrige Kopfzeile oben	Unten rechts (verhindert Navigationsverdeckung)	Von links oder oben einblenden
Desktop	Minimalistisch / Fußzeilenlastig	Oben rechts	Von links oder unten einblenden
Mobile	Beliebig	Unten zentriert / Volle Breite	Von unten nach oben einblenden

Ablauflogik-Matrix

Toast-Schwere / Typ	Enthält Aktionsbutton?	Empfohlener Ablauf	Schließtyp
Erfolg / Info	Nein	5 Sekunden (fest)	Automatisch schließen + Manuell schließen
Erfolg / Info	Ja ("Rückgängig" / "Anzeigen")	8 - 10 Sekunden	Automatisch schließen + Manuell schließen
Warnung	Nein	7 Sekunden	Automatisch schließen + Manuell schließen
Fehler / Fehlschlag	Ja oder Nein	Unendlich (bleibt bestehen)	NUR manuell schließen

---

Einschränkungen

• Barrierefreiheit (WCAG 2.2 Konformität):
  • ARIA Live Regions: Ordnen Sie passive Toasts role="status" zu (standardmäßig aria-live="polite" und aria-atomic="true"). Vermeiden Sie die Verwendung von role="alert" (assertiv), es sei denn, es wird ein Systemfehler kommuniziert (z. B. "Internetverbindung verloren"), da assertive Alarme Screenreader sofort mitten im Satz unterbrechen.
  • Tastaturnavigation (WCAG 2.2 SC 2.1.1): Wenn ein Toast eine interaktive Aktion enthält (z. B. "Rückgängig" oder "Anzeigen"), muss er per Tastatur zugänglich sein. Da Tastatur-Tab-Schleifen langsam sein können, stellen Sie einen globalen Bypass-Shortcut bereit (z. B. Escape schließt den aktiven Toast, oder F6 verschiebt den Fokus direkt zum Toast-Queue-Container) oder platzieren Sie den Toast-Container im DOM-Tab-Reihenfolge dicht nach dem aktiven Trigger.
  • Keine Fokusfallen: Sperren Sie niemals den Tastaturfokus innerhalb einer Toast-Warteschlange. Der Benutzer muss in der Lage sein, frei aus dem Toast zurück zum Seiteninhalt zu tabben.
• Kontrast (WCAG 2.2 SC 1.4.3):
  • Alle Texte, Statussymbole und Buttons müssen die Kontrastminima gegenüber dem Toast-Hintergrund erfüllen:
    • Normaler Text: 4.5:1 Mindestkontrast.
    • Symbole und aktive Steuerelementrahmen: 3:1 Mindestkontrast.
• Responsivität:
  • Bei Viewports < 600px muss der Toast-Container volle Breite (width: calc(100% - 32px)) mit zentrierter horizontaler Ausrichtung haben, um unbequeme Randspalten zu vermeiden.

---

Häufige Fehlermuster

• Die "Verdeckte Aktion"-Falle: Platzieren der Desktop-Toast-Queue direkt über hochfrequenten interaktiven Elementen wie dem Warenkorb-Kopfzeilen-Button oder einem Tabellenfilter-Dropdown, was zu Fehlklicks führt.
• Das "Jetzt siehst du es, jetzt nicht mehr"-Aufblitzen: Automatisches Schließen einer komplexen, mehrwortigen Fehler- oder Warnmeldung innerhalb von 2-3 Sekunden. Dies verletzt grundlegende Barrierefreiheits-Leseschwellen und verunsichert Benutzer, die den Kontext verpasst haben.
• Screenreader-Stille: Dynamisches Hinzufügen von Toasts zum DOM ohne einen ARIA-Live-Region-Wrapper, wodurch sie für sehbehinderte Benutzer vollständig unsichtbar werden.
• Layout-Verschiebungs-Thrashing: Animieren der Höhe der Toast-Queue abrupt beim Eintreten, was dazu führt, dass der Hauptseiteninhalt auf und ab springt.
• Hover/Fokus-Ablauf-Ignoranz: Zulassen, dass sich ein Toast selbst schließt, während ein Benutzer über einen dichten Text schwebt oder über einem "Rückgängig"-CTA schwebt, was dazu führt, dass er auf "tote Luft" klickt und unerwünschte Aktionen auslöst.

---

Validierungskriterien

• Toasts sind mit deutlichen, kontrastreichen semantischen Indikatoren (Farbe + eindeutiges Symbol) gestaltet.
• Auf dem Desktop überlappen Toasts nicht primäre Navigationselemente oder globale Aktionszonen.
• Auf Mobilgeräten verwandeln sich Toasts in unten verankerte, vollbreite Komponenten, die leicht mit dem Daumen erreichbar sind.
• Aktive Timer pausieren sofort, wenn sie mit der Maus überfahren oder per Tastatur fokussiert werden.
• Aktionsbehaftete Toasts bleiben mindestens 8–10 Sekunden sichtbar; Fehlertoasts schließen niemals automatisch.
• Semantisches Screenreader-Markup (role="status" oder role="alert") ist korrekt angegeben.
• Tastaturbenutzer können zu Toast-Aktionsbuttons navigieren und diese auslösen, ohne Fokusfallen-Barrieren.
• Alle interaktiven Elemente (Schließen-Button, CTAs) erfüllen das WCAG 2.2 Mindest-Touch-Ziel von 24x24px (44x44px bevorzugt).