- 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
Noch keine Kommentare.