GitHub verwendet Toasts nicht mehr

 (primer.style)
16 Punkte von GN⁺ 2025-12-12 | 1 Kommentare | Auf WhatsApp teilen
  • Toast-Benachrichtigungen als UI werden bei GitHub aufgrund von Barrierefreiheitsproblemen nicht mehr empfohlen
  • Die temporäre Benachrichtigungsstruktur, die automatisch verschwindet, birgt das Risiko, visuelle und funktionale Barrierefreiheitskriterien (WCAG) zu verletzen
  • GitHub schlägt Banner und Dialoge als dauerhafte und barrierefreie Formen von Feedback als Alternativen vor
  • Toasts bringen außerdem zahlreiche Usability-Probleme mit sich, etwa bei großen Bildschirmen, Multitasking und dem Ignorieren von Bannern
  • Für Barrierefreiheit und eine konsistente User Experience wird die Verwendung von Toasts im gesamten Primer-Designsystem eingestellt

Überblick über Toasts

  • Ein Toast ist ein kleines rechteckiges Benachrichtigungsfenster, das kurz in einer unteren Ecke des Bildschirms erscheint und durch Aktionen von Nutzer:innen oder dem System ausgelöst wird
  • Da es nach einer bestimmten Zeit automatisch verschwindet, bringt diese Struktur Probleme bei Barrierefreiheit und Usability mit sich
  • Aus diesen Gründen empfiehlt GitHub stabilere und besser zugängliche Kommunikationsformen

Alternativen zu Toasts

  • Je nach Verwendungszweck sollte eine passende UI gewählt werden
    • Einfache Erfolgsmeldungen lassen sich direkt über die Ergebnisseite selbst bestätigen, ohne separates Feedback
    • Bei komplexeren Vorgängen kann der Erfolgsstatus über Banner oder schrittweise eingeblendete Inhalte vermittelt werden
    • Fehlgeschlagene Vorgänge sollten Fehlerinformationen über Banner oder Dialoge bereitstellen
  • Bei Formularübermittlungen ist bei einfachen Formularen keine zusätzliche Bestätigung nötig; bei komplexen Formularen sollten Zwischenbestätigungsseiten oder Banner verwendet werden
  • Für Eingabevalidierung sollten die vorhandenen Formularvalidierungs-Komponenten von Primer genutzt werden
  • Länger laufende Aufgaben sollten ihren Abschlussstatus über Banner oder andere Kanäle wie E-Mail- oder Push-Benachrichtigungen mitteilen
  • Wenn eine Sitzungs-Asynchronität auftritt, sollte per Dialog oder Banner auf die Notwendigkeit eines Neuladens hingewiesen werden

Aspekte der Barrierefreiheit (Accessibility Considerations)

  • Toast-UIs können gegen mehrere WCAG-Erfolgskriterien verstoßen
    • 2.2.1 Timing Adjustable (A) : Sie sollten bestehen bleiben, bis Nutzer:innen sie selbst schließen
    • 1.3.2 Meaningful Sequence (A) : Eine Abweichung zwischen DOM-Reihenfolge und visueller Reihenfolge kann bei der Nutzung assistiver Technologien Verwirrung auslösen
    • 2.1.1 Keyboard (A) : Interaktionen innerhalb des Toasts müssen per Tastatur steuerbar sein
    • 4.1.3 Status Messages (AA) : Assistive Technologien müssen auf nicht störende Weise über ihre Existenz informiert werden
  • Zusätzlich können weitere Kriterien verletzt werden
    • 1.4.4 Resize text (AA) : Beim Anpassen der Textgröße kann es dazu kommen, dass Inhalte verdeckt werden oder überlaufen
    • 1.4.10 Reflow (AA) : Bei horizontalem Scrollen muss die Tastaturzugänglichkeit gewährleistet bleiben
    • 2.4.3 Focus Order (A) : Die Fokusreihenfolge kann unklar werden
    • 3.2.4 Consistent Identification (AA) : Konsistenz im Code muss gewahrt bleiben

Usability-Aspekte (Usability Considerations)

  • Auf großen Bildschirmen können Toasts außerhalb des Blickfelds liegen und unbemerkt bleiben
  • Bei automatischem Ausblenden besteht das Risiko, dass Nutzer:innen die Meldung während anderer Tätigkeiten verpassen
  • Überdeckung der UI: Toasts können wichtige Elemente wie untere Buttons verdecken
  • Nutzer:innen mit Bildschirmvergrößerung sehen Toasts möglicherweise nicht, wenn sie außerhalb des vergrößerten Bereichs liegen
  • Probleme mit dem Arbeitsgedächtnis: Durch das automatische Verschwinden kann die Information nicht erneut geprüft werden
  • Banner-Ignoranz: Bei übermäßiger Nutzung neigen Nutzer:innen dazu, sie zu ignorieren
  • Positionsinkonsistenz: Die physische Distanz zwischen auslösender UI und Toast kann die Zuordnung erschweren
  • Falsches Schließverhalten: Mit der Esc-Taste kann versehentlich auch andere UI mit geschlossen werden

Weiterführende Materialien

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-12-12
Hacker-News-Kommentare
  • Jemand berichtete, dass er während eines Vortrags über Barrierefreiheit eine Situation erlebt habe, in der nach einem Klick eine Verzögerung von 3 Sekunden auftrat und es so wirkte, als gäbe es überhaupt keine Reaktion.
    • Beim Klick auf ein Banner musste man ohne jeden Hinweis warten und wurde erst später auf eine nicht zusammenhängende Seite weitergeleitet, was frustrierend war.
    • Das Problem sei das fehlende Feedback, das anzeigt, dass gerade geladen wird.
    • Jemand anderes sagte, das sei einfach nur ein ``-Link, und die Verzögerung liege lediglich daran, dass die Seite unnötig groß sei.
    • Eine weitere Person merkte an, dass es selbst in langsamem 4G sofort reagiere, und vermutete eher ein Browser- oder Netzwerkproblem.
  • Jemand fand die Dokumentation von GitHub Primer interessant.
    • Auch wenn man nicht allem zustimme, könne man daraus etwas lernen, und es sei deutlich besser als bloßes Bauchgefühl.
    • Zur Einordnung: Auch Apple und Android bieten jeweils Design Guidelines an.
  • Hoffentlich setzt sich dieser Trend nun endlich stärker durch.
    • Wegen Toast-Benachrichtigungen seien schon viel zu viele Nachrichten verpasst worden.
    • Eine andere Person stimmte der Aussage „Toasts werden wegen Barrierefreiheitsproblemen nicht empfohlen“ voll zu und betonte, ein Benachrichtigungszentrum wäre zumindest etwas besser gewesen, aber immer noch keine gute Lösung.
  • Ich mag Toasts für nicht störende Bestätigungen, halte sie aber für ungeeignet, um wichtige Informationen zu vermitteln.
    • Eine andere Person erklärte den Nutzungskontext von Toasts genauer.
      • Sofortige Reaktion auf einen Button-Klick → besser direkt am Button Feedback geben
      • Reaktion auf einen Shortcut → in Ordnung
      • Benachrichtigung über den Abschluss einer lang laufenden Aufgabe → in Ordnung, aber es braucht ein dauerhaftes Benachrichtigungsfach
      • Warnhinweis beim Betreten einer Seite → wenn wichtig, sollte er als permanente Benachrichtigung auf der Seite selbst erscheinen
    • In React werde der globale Aufruf toast() leicht überstrapaziert, aber eine Struktur wie useAlerts() sei deutlich besser.
  • Für mich sind Toasts wie ein Tourniquet.
    • Sie sind nützlich, um ein dringendes Problem vorübergehend zu stoppen, sollten aber langfristig nicht bestehen bleiben.
    • In neuen Projekten könne man sie vorübergehend einsetzen, wenn Feedback fehle, und sie dann beim Verbessern der UI nach und nach wieder entfernen.
    • Große Organisationen wie GitHub bräuchten solche Behelfslösungen nicht, kleinere Teams dagegen möglicherweise schon.
  • Jemand mochte in der GitHub-Dokumentation die Aussage, dass bei der „Erstellung vieler Issues zusätzliche Rückmeldung nötig ist“.
    • So ein Feedback wäre auch bei GitHub Actions wünschenswert, da es nach dem Start viel zu lange dauere, bis Ergebnisse erscheinen.
  • Die Idee, Toasts als Aktionsprotokoll in der gesamten UI zu verwenden, gefiel jemandem.
    • Statt bei jedem Klick verschwindendes Feedback zu zeigen, gebe es gut umgesetzte Beispiele wie Sonner.
  • Es sei vielleicht an der Zeit, über native Unterstützung für Toasts auf Browser-Ebene nachzudenken.
    • Damit ließen sich Barrierefreiheitsverbesserungen wie Timing-Steuerung, Benachrichtigungszentrum und Screenreader-Integration erreichen.
    • Optisch seien sie zwar in Ordnung, verschwänden aber oft zu schnell und würden deshalb verpasst.
    • Die Probleme sehbehinderter Menschen könne man selbst schwer direkt nachvollziehen, aber man würde gern hören, wie sich ihre Zugänglichkeit verbessern ließe.
  • Der Vorteil von Toasts ist, dass sie leicht zu implementieren sind und wenig Designaufwand erfordern.
    • Der Nachteil ist, dass sie leicht übersehen werden und andere Informationen überdecken können.
    • Wenn man genug Spielraum habe, sei es besser, Toasts ganz zu vermeiden.
    • Eine andere Person wies darauf hin, dass sie gerade deshalb, weil sie leicht zu bauen sind, häufig als falsche Scheinlösung für ein Problem missbraucht würden.
    • Wieder jemand anderes sagte, er habe Toasts einfach als beruhigendes Feedback verwendet.
    • Dagegen hielt eine andere Person Toasts für ein nützliches Werkzeug, um bei wenig wichtigen Ereignissen sofortiges Feedback zu geben, und für effizienter als Modalfenster oder fest verankerte Bereiche.
    • Sie kritisierte ein Schwarz-Weiß-Denken, das ein Werkzeug wegen seines Missbrauchs komplett ausschließen wolle.
  • Jemand habe einen Beitrag gesehen, laut dem „GitHubs Entfernung von Toasts schlechte Nachrichten für die Barrierefreiheit“ sei.
    • Eine Person fand diese Behauptung merkwürdig.
      • Zu sagen, GitHub hätte statt der Abschaffung von Toasts lieber über das W3C einen Browser-Standard schaffen sollen, sei ihrer Meinung nach ein zu großer Sprung.
      • Dass neu erstellte Elemente einfach in einer Liste erscheinen, sei als Feedback bereits ausreichend.
    • Eine andere Person sagte, es sei widersprüchlich zu behaupten, Toasts seien schlecht für Barrierefreiheit und UX, und GitHub zugleich dafür zu kritisieren, dass es sie nicht im Browser standardisiert habe.