Toast Benachrichtigung gestalten: So funktionieren UI Feedback Meldungen

Jemand sendet ein Formular ab, legt ein Produkt in den Warenkorb oder speichert eine Einstellung. Dann gleitet in einer Ecke des Bildschirms ein kleiner Kasten herein und verschwindet nach einigen Sekunden wieder. Diesen Kasten nennen wir Toast Benachrichtigung. Er wirkt zunächst unscheinbar. Allerdings wissen Nutzer bei einer schlecht gebauten Variante nicht, ob ihre Aktion geklappt hat. Wer zudem einen Screenreader nutzt, hört womöglich gar nichts.

In diesem Leitfaden zeigen Talha Aslan und Team, wie wir Rückmeldungen in Oberflächen gestalten. Wir trennen Erfolgs, Fehler und Infomeldungen, besprechen Anzeigedauer und Position und erklären Ansagen für Screenreader auf konzeptioneller Ebene. Zum Schluss finden Sie eine Checkliste, die Sie sofort anwenden können.

Der Name stammt vom Toastbrot, das aus dem Toaster springt. Der Kasten kommt von unten oder von der Seite und zieht sich dann zurück. Allerdings gehört nicht jede Rückmeldung in einen Toast. Muss jemand etwas korrigieren, bestätigen oder genau lesen, brauchen Sie eine dauerhaftere Komponente.

Die Nielsen Norman Group zieht diese Grenze in ihrem Artikel über Indikatoren, Validierungen und Benachrichtigungen sehr klar. Zunächst beziehen sich Validierungen auf die eigene Eingabe und verlangen eine Handlung. Benachrichtigungen melden dagegen Systemereignisse; es gibt solche, die eine Aktion verlangen, und passive. Der Toast ist das typische Beispiel für eine passive Benachrichtigung. Deshalb übersehen Nutzer ihn leicht, und er sollte nie allein eine kritische Information tragen.

Wie unterscheidet sich eine Toast Benachrichtigung von Banner und Modal?

Wer Komponenten für Rückmeldungen beliebig austauscht, produziert einen der häufigsten Fehler in Oberflächen. Zum Beispiel überspringen Nutzer eine Löschbestätigung im Toast, ohne die Entscheidung je zu sehen. Die Tabelle fasst zusammen, worauf unser Team bei der Wahl der Komponente achtet.

Kurz gesagt: Der Toast sagt "nur zur Info". Das Modal sagt "halten Sie an und entscheiden Sie". Verwechseln Sie beide, unterbrechen Sie Menschen entweder grundlos, oder eine wichtige Entscheidung rutscht unbemerkt durch.

Welche Arten von Rückmeldungen gibt es in einer Oberfläche?

Zunächst lohnt es sich, die Meldungstypen zu benennen, bevor Sie etwas gestalten. Jeder Typ hat nämlich eigenen Ton, eigene Farbe, eigenes Symbol und eigene Dauer. Unser Team definiert im Designsystem meist vier Typen:

• Erfolg: Die Aktion ist abgeschlossen, zum Beispiel "Adresse gespeichert".
• Fehler: Die Aktion hat nicht geklappt, und der Nutzer muss etwas tun.
• Warnung: Die Aktion lief durch, aber etwas verlangt Aufmerksamkeit.
• Info: Eine neutrale Nachricht ohne direkten Bezug zur Aktion, etwa eine neue verfügbare Version.

Manche Teams führen zudem einen eigenen Lade oder Fortschrittszustand. Auch die WCAG zählt Warte und Fortschrittsmeldungen zu den Statusmeldungen. Außerdem verhindert ein festes Textmuster pro Typ, dass verschiedene Teams auf derselben Website unterschiedlich sprechen. Für die Textseite ist unser Leitfaden zu UX Writing und Mikrotexten ein guter Einstieg.

Welchen Ton sollte der Text einer Benachrichtigung haben?

Der Benachrichtigungstext ist ein winziger Teil Ihrer Markenstimme. Trotzdem erscheint er genau dann, wenn Menschen aufmerksam lesen: nach einer Zahlung, während eines Uploads oder wenn etwas schiefgeht. Deshalb verdient der Ton eine bewusste Entscheidung.

Bei Erfolgsmeldungen genügt also eine ruhige, knappe Sprache. Bei Fehlern vermeiden Sie dagegen jede Schuldzuweisung. Statt "Sie haben das falsch eingegeben" schreiben Sie "Dieses Feld braucht eine Nummer mit elf Ziffern". So beschreibt der Satz die Bedingung, nicht die Person. Technische Fehlercodes zeigen Sie zudem nicht direkt an; braucht der Support einen, ergänzen Sie eine kurze Referenznummer.

• Sprechen Sie Nutzer überall gleich an, also durchgehend mit Sie.
• Verzichten Sie in Fehlermomenten auf Witze.
• Wählen Sie Wörter, die Ihre Nutzer kennen, statt interner Fachbegriffe.

Somit trägt die Benachrichtigung dieselbe Persönlichkeit wie der Rest der Website und stärkt das Vertrauen.

Wie melden Sie Ladezustand und Fortschritt?

Manche Aktionen brauchen allerdings Zeit. Ein großer Upload, ein Berichtsexport oder eine Zahlungsprüfung kann einige Sekunden dauern. Sehen Nutzer in dieser Zeit keine Veränderung, klicken sie erneut oder verlassen die Seite. Daher behandeln Sie den Wartezustand als eigene Art der Rückmeldung.

Bei kurzen Wartezeiten genügt ein kleiner Ladekreis im Button. Bei langen Vorgängen sagt dagegen ein Fortschrittsbalken mit kurzer Statuszeile mehr aus. Auch das WCAG Dokument zu Statusmeldungen nennt Ladeanzeigen und Fortschrittsmeldungen ausdrücklich als Beispiele.

Auf der Seite des Screenreaders ist allerdings Vorsicht geboten. Kündigen Sie jeden Prozentwert an, hören Nutzer einen endlosen Zahlenstrom. Stattdessen sagen Sie Beginn, wichtige Zwischenstände und Ergebnis an. Ist der Vorgang beendet, bestätigt eine kurze Toast Benachrichtigung das Ergebnis.

Wie schreiben Sie eine gute Erfolgsmeldung?

Eine Erfolgsmeldung sagt in einem Satz, was passiert ist. Allgemeine Formeln wie "Vorgang erfolgreich" sagen Nutzern nichts. "Rechnungsadresse aktualisiert" zeigt dagegen genau, was sich geändert hat. Also nennen Sie Objekt und Ergebnis zusammen.

Außerdem zählt Kürze. Ein Toast bleibt nur wenige Sekunden sichtbar, deshalb ist die Lesezeit knapp. Konkret funktionieren einzeilige Sätze am besten. Ausrufezeichen, überschwängliche Formeln wie "Super!" und unnötige Danksagungen machen die Meldung nur länger.

• Nennen Sie das Objekt: "Artikel im Warenkorb", "Link kopiert".
• Bieten Sie bei Bedarf den nächsten Schritt an, etwa einen Link zum Warenkorb.
• Bieten Sie bei umkehrbaren Aktionen "Rückgängig" an.
• Verwenden Sie für dieselbe Aktion überall dieselbe Formulierung.

Andererseits braucht nicht jede erfolgreiche Aktion eine Meldung. Zeigt der Bildschirm das Ergebnis schon, etwa ein angehaktes Kontrollkästchen, erzeugt ein zusätzlicher Toast nur Lärm. Setzen Sie Benachrichtigungen dort ein, wo die sichtbare Änderung allein nicht reicht.

Sollten Sie Fehler in einer Toast Benachrichtigung anzeigen?

In den meisten Fällen nicht, denn der Kasten verschwindet. Ein Fehler verlangt eine Handlung, und ein Kasten, der nach wenigen Sekunden verschwindet, kann diese Aufforderung nicht tragen. Verschwindet die Meldung, während der Nutzer woanders hinschaut, erfährt er nie, warum die Aktion gescheitert ist.

Bei Formularfehlern platzieren Sie deshalb eine dauerhafte Meldung direkt neben dem betroffenen Feld. Dort bleibt sie, bis das Problem behoben ist. Bei seitenweiten Problemen wie einem Server oder Verbindungsfehler passt ein dauerhaftes Banner besser. Die allgemeinen Prinzipien behandeln wir in unserem Beitrag zum Formulardesign.

Es gibt allerdings eine schmale Ausnahme. Angenommen, eine automatische Speicherung im Hintergrund schlägt fehl und das System versucht es erneut. Dann kann eine kurze Benachrichtigung das melden. Sie darf sich jedoch nicht selbst schließen, sondern bleibt, bis der Nutzer sie schließt oder das Problem verschwindet.

Eine gute Fehlermeldung beantwortet drei Fragen: Was ist passiert, warum, und was ist jetzt zu tun? Statt "Etwas ist schiefgelaufen" schreiben Sie "Verbindung unterbrochen; Ihre Änderungen sind nicht gespeichert. Bitte erneut versuchen."

Wie unterscheiden Sie Info und Warnmeldungen?

Eine Infomeldung ist neutral und erwartet nichts. Eine Warnung weist dagegen auf ein Risiko oder eine Grenze hin. Zum Beispiel ist "Neuer Kommentar eingegangen" eine Info, "Ihr Speicherplatz ist fast voll" eine Warnung. Teilen beide denselben Stil, halten Nutzer auch Warnungen bald für belanglos.

Verlassen Sie sich bei dieser Unterscheidung nicht allein auf Farbe. Menschen mit Farbsehschwäche können Gelb und Blau unter Umständen nicht trennen. Deshalb bekommt jeder Typ ein eigenes Symbol und bei Bedarf ein sichtbares Textlabel. Ein kurzes Präfix wie "Warnung:" nennt die Art der Meldung zusätzlich in Worten.

Außerdem sollte sich die Dauer unterscheiden. Eine Info darf schnell verblassen, eine Warnung bleibt dagegen, bis der Nutzer sie gelesen und geschlossen hat. Betrifft die Warnung die aktuelle Aufgabe, ist ein dauerhaftes Banner oben auf der Seite oft die bessere Wahl.

Anders gesagt: Jede Meldung, die eine Handlung erwartet, gehört in eine Komponente, die nicht von selbst verschwindet.

Wie lange sollte eine Toast Benachrichtigung sichtbar bleiben?

Eine einzige richtige Dauer gibt es nicht; Länge und Bedeutung der Meldung entscheiden. Der häufigste Fehler ist allerdings eine viel zu kurze Anzeige. Langsame Leser, abgelenkte Nutzer und Menschen mit vergrößerter Ansicht verpassen den Kasten oft, bevor sie fertig gelesen haben.

Das WCAG 2.2 Kriterium Zeitbegrenzungen anpassbar (2.2.1) wertet Änderungen, die nach einer festen Zeit automatisch eintreten, als Zeitbegrenzung. Laut Dokument kann eine vorübergehende Benachrichtigung ausgenommen sein, wenn Nutzer dieselbe Information auf anderem Weg finden. Gibt es keinen anderen Weg, müssen Sie Nutzern erlauben, die Zeit abzuschalten, zu verlängern oder anzupassen.

In der Praxis geht unser Team so vor:

• Lassen Sie die Information nie nur im Toast; zeigen Sie das Ergebnis auch auf der Seite.
• Halten Sie den Timer an, sobald der Mauszeiger oder der Tastaturfokus auf dem Kasten liegt.
• Schließen Sie Benachrichtigungen mit Button oder Link nie automatisch.
• Lassen Sie Fehler und Warnungen stehen, bis der Nutzer sie schließt.

Folglich liegt die Entscheidung über die Dauer beim Nutzer.

Wo auf dem Bildschirm sollten Benachrichtigungen erscheinen?

Die Position hängt davon ab, wo die Aufmerksamkeit des Nutzers liegt. Auf dem Desktop sind die Ecken oben rechts und unten rechts verbreitet, weil sie den Inhalt freilassen. Auf einem breiten Bildschirm bleibt das Auge allerdings dort, wo die Aktion stattfand. Ein Kasten in der Ecke kann also weit entfernt liegen.

Daher lohnt es sich, die Rückmeldung nah an der Aktion zu platzieren. Drückt jemand zum Beispiel in einer Karte auf "Kopieren", bestätigt ein kurzes Label direkt neben dem Button die Aktion. Für seitenweite Aktionen wählen Sie dagegen eine feste Ecke und nutzen sie überall gleich.

Vor allem gilt: Eine Benachrichtigung darf nie wichtige Inhalte oder Bedienelemente verdecken. Ein Kasten über dem Warenkorbbutton, der Chatblase oder dem Cookiebanner blockiert den Nutzer. Teilen sich außerdem mehrere fixierte Komponenten dieselbe Ecke, legen Sie die Stapelreihenfolge schon im Design fest.

Halten Sie die Regel einmal im Designsystem fest, dann muss niemand sie bei neuen Seiten erneut diskutieren.

Wie hören Screenreader eine Benachrichtigung?

Ein sichtbar erscheinender Kasten bedeutet für einen Screenreader zunächst nichts. Stattdessen muss der Code den Inhalt als Statusmeldung kennzeichnen. Das WCAG 2.2 Kriterium Statusmeldungen (4.1.3) verlangt genau das: Hilfstechnologien müssen Statusmeldungen ausgeben können, ohne dass der Fokus wandert. Das Kriterium gehört zur Stufe AA.

Dahinter steht das Konzept der Live Region. Sie definieren einen Bereich, den der Screenreader vorliest, sobald sich sein Inhalt ändert. Die MDN Dokumentation zu Live Regionen nennt drei Werte: off, polite und assertive. Polite wartet, bis der Screenreader seinen aktuellen Satz beendet hat, und passt zu den meisten Benachrichtigungen. Assertive unterbricht dagegen sofort.

In der Praxis übersehen Teams oft ein Detail. Die Live Region sollte beim Laden der Seite bereits leer vorhanden sein. Erzeugen Sie den Container erst im Moment der Meldung, bemerken manche Screenreader die Änderung womöglich nicht. Deshalb platzieren Sie vorab einen festen, leeren Container und aktualisieren nur seinen Inhalt.

Den größeren Rahmen der Barrierefreiheit beschreibt unser Leitfaden zu WCAG und barrierefreien Websites.

Wann wählen Sie die Rolle status und wann alert?

ARIA bietet zwei fertige Rollen, und beide wirken wie eine Live Region. Laut MDN entspricht die Rolle status einer Live Region mit polite, die Rolle alert dagegen einer mit assertive. Beide lesen den Inhalt als Ganzes vor, und keine verschiebt den Fokus.

Konkret ist die Faustregel einfach. Für Erfolg, Fortschritt und Info nutzen Sie status. Die Rolle alert reservieren Sie für Fälle, in denen der Nutzer sofort Bescheid wissen muss, etwa bei einer ablaufenden Sitzung oder einem gescheiterten Speichervorgang. MDN schreibt ausdrücklich, dass alert wegen seiner störenden Wirkung sparsam einzusetzen ist. Mehrere Alerts gleichzeitig führen laut MDN zu einer schlechten Erfahrung.

1. Muss die Meldung die Arbeit des Nutzers unterbrechen? Wenn nicht, dann status.
2. Schadet eine Verzögerung? Wenn ja, dann alert.
3. Muss der Nutzer entscheiden? Dann brauchen Sie einen Dialog mit Fokus, keine Live Region.

Auch das WCAG Dokument rät von alert oder assertive für Inhalte ab, die weder wichtig noch zeitkritisch sind. Somit sollte status Ihr Standard sein.

Gehört eine Schaltfläche Rückgängig in die Benachrichtigung?

Bei umkehrbaren Aktionen ja. Statt eines Bestätigungsdialogs für das Archivieren einer E-Mail oder das Entfernen eines Listeneintrags führen Sie die Aktion sofort aus und bieten im Toast "Rückgängig" an. So unterbrechen Sie Menschen nicht jedes Mal und lassen trotzdem einen Ausweg offen.

Dieses Muster hat allerdings seinen Preis. Ein Toast mit Button ist nämlich eine interaktive Komponente, also gelten strengere Regeln. Nutzer mit Tastatur und Screenreader müssen ihn erreichen, und er darf nicht vorher verschwinden. Eine Schaltfläche, die nach wenigen Sekunden weg ist, existiert für langsam agierende Menschen schlicht nicht.

Deshalb gilt bei uns eine Regel: Gibt es Rückgängig, muss es auch einen zweiten Weg zur Umkehr geben. Ein gelöschtes Element liegt dann etwa in einem Bereich für zuletzt gelöschte Einträge, oder Nutzer holen es über einen Verlauf zurück.

Bei nicht umkehrbaren Aktionen versprechen Sie dagegen kein Rückgängig. Endgültiges Löschen oder Zahlungsschritte brauchen einen klaren Bestätigungsdialog.

Worauf achten Sie bei Tastatur und Fokusmanagement?

Die Grundregel für Statusmeldungen lautet: Lassen Sie den Fokus in Ruhe. Zieht eine Benachrichtigung den Fokus an sich, während jemand ein Formular ausfüllt, verliert die Person ihre Position. Auch MDN schreibt, dass der Fokus bei einer Aktualisierung nicht auf den Statusbereich springen soll.

Andererseits müssen Tastaturnutzer einen Button in der Benachrichtigung erreichen können. Dafür braucht der Kasten einen sinnvollen Platz in der Tabreihenfolge und darf nicht von selbst verschwinden. Manche Teams bieten zudem ein Tastenkürzel, um zu Benachrichtigungen zu springen. Nutzen Sie das, nennen Sie das Kürzel deutlich.

• Geben Sie der Schaltfläche zum Schließen einen zugänglichen Namen; ein Kreuzsymbol allein reicht nicht.
• Die Taste Escape sollte eine offene Benachrichtigung schließen.
• Nach dem Schließen bleibt der Fokus dort, wo der Nutzer war.
• Der Fokusring bleibt auch im Benachrichtigungskasten klar sichtbar.

Viele dieser Punkte decken sich mit allgemeinen Prinzipien, die wir in unserem Beitrag zu nutzerzentriertem UI Design ausführlicher behandeln.

Wie setzen Sie Farbe, Symbole und Kontrast in Benachrichtigungen ein?

Grün für Erfolg, Rot für Fehler, Gelb oder Orange für Warnungen ist ein vertrautes Muster. Allerdings sollte Farbe nie allein Bedeutung tragen. Die WCAG verlangt, dass Farbe nicht das einzige visuelle Mittel zur Vermittlung einer Information ist. Deshalb bekommt jeder Typ ein eigenes Symbol, und der Text nennt den Typ zusätzlich selbst.

Auch der Kontrast rutscht oft durch. Weiße Schrift auf hellem Grün wirkt am Monitor in Ordnung, ist aber am Handy bei Tageslicht schwer lesbar. Messen Sie daher den Kontrast zwischen Text und Hintergrund, und sorgen Sie dafür, dass sich das Symbol von seiner Umgebung abhebt. Bei Websites mit dunklem Design prüfen Sie jedes Farbpaar gesondert.

Dekorative Symbole verbergen Sie zudem vor dem Screenreader. Trägt ein Symbol Bedeutung, braucht es eine Textentsprechung. Sonst liest der Screenreader etwas Bedeutungsloses vor oder übergeht den Typ ganz.

Die allgemeine Logik erklären wir in unserem Beitrag zum Kontrast im Webdesign. Für Benachrichtigungen gilt eine Zusatzregel: Der Kasten hebt sich mit Schatten oder Rahmen von der Seite ab, ohne grell zu wirken.

Wie beeinflussen Animation und Bewegung eine Benachrichtigung?

Ein leichtes Einschieben oder Einblenden zeigt, woher die Meldung kommt, und lenkt die Aufmerksamkeit sanft. Abrupte Sprünge, wackelnde Kästen oder lange Animationen lenken dagegen ab. Für manche Menschen mit Bewegungsempfindlichkeit sind sie außerdem unangenehm.

Respektieren Sie deshalb die Einstellung für reduzierte Bewegung im Betriebssystem. Ist sie aktiv, schalten Sie die Animation ab oder reduzieren sie auf ein schlichtes Einblenden. Browser stellen diese Einstellung über eine CSS Media Query bereit. So passt sich dieselbe Komponente den Vorlieben jedes Nutzers an.

Vor allem halten Sie Animationen kurz. Dauert der Auftritt zu lange, warten Nutzer, bevor sie lesen können. Dauert der Abgang zu lange, kollidiert er mit der nächsten Meldung. Zudem zählt die Zeit der Ausblendung nicht als Lesezeit.

Für Mikrointeraktionen im Allgemeinen finden Sie Beispiele in unserem Beitrag zu Mikroanimationen. Bei Benachrichtigungen gilt: Bewegung unterstützt die Botschaft, sie ersetzt sie nicht.

Wie vermeiden Sie eine Flut an Benachrichtigungen?

Eine Oberfläche, die bei jedem Klick einen Kasten zeigt, bringt Menschen bald bei, Benachrichtigungen zu ignorieren. Kommt dann eine wichtige Warnung, liest sie niemand. Benachrichtigungen wirken also nur, solange sie selten und bedeutsam bleiben.

Konkret nutzt unser Team diese Regeln:

• Keine Meldung für Aktionen, deren Ergebnis schon sichtbar ist.
• Nie mehrere Toasts gleichzeitig; bei Bedarf in eine Warteschlange stellen.
• Wiederholte Meldungen bündeln, zum Beispiel "3 Dateien hochgeladen".
• Werbebotschaften nicht in derselben Komponente wie Rückmeldungen zu Aktionen zeigen.
• Keine Meldung direkt beim Öffnen der Seite; der Nutzer hat noch nichts getan.

Für Screenreader ist ein Übermaß noch anstrengender. Liest er jede kleine Änderung vor, kann der Nutzer dem eigentlichen Inhalt nicht folgen. Daher schreiben Sie nur in die Live Region, was Menschen wirklich wissen müssen. Aktualisieren sich etwa Suchergebnisse bei jedem Tastendruck, sagen Sie die Trefferzahl stattdessen einmal nach kurzer Verzögerung an.

Wie verändert sich das Toast Design auf dem Smartphone?

Auf dem Smartphone ist der Bildschirm schmal, und der Daumen bewegt sich im unteren Bereich. Deshalb erscheinen Benachrichtigungen dort meist unten als fast bildschirmbreiter Streifen. Gibt es allerdings eine untere Navigationsleiste oder einen fixierten Kaufbutton, darf die Meldung sie nicht verdecken.

Außerdem zählen Touchziele. Schließen und Rückgängig brauchen genug Größe für einen Finger und genug Abstand zueinander. Unterstützen Sie Wischen zum Schließen, ergänzen Sie einen sichtbaren Button mit derselben Funktion, denn nicht jeder kennt die Geste.

Zudem verdeckt die Bildschirmtastatur die untere Hälfte des Displays. Eine Meldung, die von unten kommt, bleibt in dieser Zeit womöglich unsichtbar. Testen Sie das auf Formularseiten, und verschieben Sie die Meldung bei Bedarf nach oben.

Querformat, vergrößerte Schrift und systemweite Textgröße sind weitere eigene Szenarien. Wächst der Text, sollte der Kasten mitwachsen, ohne die Meldung abzuschneiden.

Beispielszenario: Warenkorbmeldungen in einem Onlineshop

Der folgende Ablauf ist ein Beispielszenario, kein echter Kundenfall. In einem Modeshop wählt eine Nutzerin auf der Produktseite eine Größe und drückt "In den Warenkorb".

1. Der Button wechselt kurz in einen Ladezustand, und eine Region mit der Rolle status kündigt das an.
2. Ist die Aktion abgeschlossen, erscheint eine Toast Benachrichtigung: "Schwarzes Shirt, Größe M, im Warenkorb." Dazu kommt ein Link zum Warenkorb.
3. Gleichzeitig aktualisiert sich der Zähler im Kopfbereich, sodass die Information nicht nur im Toast steht.
4. Drückt die Nutzerin den Button ohne Größe, erscheint kein Toast. Stattdessen steht eine dauerhafte Fehlermeldung neben dem Größenfeld.
5. Ist der Artikel in diesem Moment ausverkauft, erscheint im Produktbereich eine dauerhafte Warnung mit Vorschlägen für andere Größen.

In diesem Ablauf meldet der Toast nur Erfolg. Fehler und Warnungen bleiben am jeweiligen Bereich. Der Toast mit Link bleibt stehen, solange Mauszeiger oder Fokus darauf liegen. Wer einen Screenreader nutzt, erfährt dasselbe Ergebnis über eine Ansage mit polite.

Wie testen Sie ein Benachrichtigungssystem?

Auf den ersten Blick wirken Benachrichtigungen meist einwandfrei. Probleme zeigen sich allerdings erst bei unterschiedlichen Nutzungsweisen. Deshalb testen Sie in drei Ebenen.

Zunächst testen Sie mit der Tastatur. Erledigen Sie die Aktion ohne Maus, versuchen Sie den Button in der Benachrichtigung zu erreichen, und schließen Sie sie mit Escape. Danach hören Sie denselben Ablauf mit einem Screenreader an. Mindestens ein Screenreader am Desktop und einer am Smartphone sind der verlässlichste Weg, um zu prüfen, ob Ansagen wirklich ertönen.

Anschließend probieren Sie Belastungsfälle:

• Fünf Aktionen schnell hintereinander: Stapeln sich die Meldungen?
• Browser auf 200 Prozent zoomen: Wird Text abgeschnitten?
• Reduzierte Bewegung aktivieren: Vereinfacht sich die Animation?
• Langsame Verbindung: Erscheint während der Aktion ein Ladezustand?

Machen Sie diese Prüfungen zum Teil einer regelmäßigen Usabilityprüfung. Die Schritte beschreiben wir in unserer Anleitung zum UX Audit.

Checkliste für das Design einer Toast Benachrichtigung

Nutzen Sie die Liste, wenn Sie eine neue Komponente für Benachrichtigungen bauen oder eine bestehende prüfen. Jeder Punkt fasst einen der Abschnitte oben zusammen.

1. Ist der Typ klar: Erfolg, Fehler, Warnung oder Info?
2. Passt ein Toast, oder brauchen Sie eine Meldung am Feld, ein Banner oder ein Modal?
3. Nennt der Text Objekt und Ergebnis in einem Satz?
4. Bleiben Fehler und Warnungen stehen, bis der Nutzer sie schließt?
5. Steht die Information auch auf der Seite und nicht nur im Toast?
6. Hält der Timer bei Mauszeiger und Fokus an?
7. Existiert die Live Region beim Laden der Seite bereits leer?
8. Ist status die Standardrolle und alert nur für dringende Fälle reserviert?
9. Bleibt der Fokus dort, wo er war?
10. Zeigen Symbol und Text den Typ, nicht nur die Farbe? Reicht der Kontrast?
11. Respektiert die Komponente die Einstellung für reduzierte Bewegung?
12. Erscheint immer nur eine Benachrichtigung?
13. Verdeckt sie auf dem Smartphone weder fixierte Buttons noch die Tastatur?

Ist jeder Punkt erfüllt, liefern Ihre Benachrichtigungen eine stimmige Erfahrung, visuell und über Hilfstechnologien.

Wer sollte das Benachrichtigungssystem auf Ihrer Website umsetzen?

Eine Toast Komponente bauen Sie also nicht für eine einzelne Seite. Sie gehört vielmehr in das Designsystem der gesamten Website. Farben, Symbole, Textmuster, Zeitregeln und Einstellungen zur Barrierefreiheit legen Sie einmal fest, und danach verhält sich die Komponente auf jeder Seite gleich. Deshalb müssen Design und Entwicklung hier zusammenarbeiten.

Bei Talha Aslan und Team gehören Komponenten für Rückmeldungen in unserem Webdesign Service von Anfang an zum Designsystem. Verschwinden Benachrichtigungen auf Ihrer aktuellen Website unbemerkt, bleiben Fehler unentdeckt oder schweigen Screenreader, gehen wir das gern gemeinsam mit Ihnen an.

Wir prüfen die Abläufe Ihrer Website, legen fest, welche Komponente zu welcher Aktion passt, und setzen diese Entscheidungen dann in Design und Code um. Um Ihr Projekt zu beschreiben und ein Angebot anzufragen, nutzen Sie das Kontaktformular auf unserer Seite zum Webdesign.