🚀 Feature: Toasts - Nutzen vom Button "Alle Schließen" für Screenreader Nutzende nicht ersichtlich

[Chrisdo82]

Goals

1. Es betrifft den "Alle Schließen" Button vom ToastService
2. Dieser Button erscheint nur, wenn mindestens 2 Toasts offen sind

Non-Goals

No response

Background

Der Button zum Schließen aller Toasts heißt "Alle schließen" > Wenn aber Toasts und ein Modal offen sind, ist für Screenreader Nutzende nicht erkennbar, was geschlossen werden soll. Das Modal? Oder etwas ganz anderes?

Proposal

Wording anpassen zu "Alle Benachrichtigungen schließen" oder eine Property zum umbenennen bereitstellen.

[deleonio]

Hi @Chrisdo82,

vielen Dank für den Verbesserungsvorschlag.

Weiterführendes:

Aus Sicht von Barrierefreiheit und speziell für KoliBri ergibt sich ein recht klares Bild:

Problematische Punkte bei Toasts

1. Fokusverlust & Ablenkung
   Toasts erscheinen häufig außerhalb des Fokusflusses. Screenreader-Nutzende erfahren entweder gar nichts davon oder werden plötzlich aus ihrem Kontext gerissen. Parallel zu einem Dialog führt das zu Verwirrung: Der Dialog beansprucht den Fokus exklusiv, während der Toast eine konkurrierende Ansage erzwingt.

2. Kognitive Last
   Wenn ein Toast beim Arbeiten in einem Dialog eingeblendet wird, müssen Nutzer*innen zwei Dinge gleichzeitig verarbeiten: den Dialog und die Toast-Information. Gerade für Menschen mit kognitiven Einschränkungen oder Screenreader-User ist das eine Überforderung.

3. Zeitabhängigkeit
   Toasts verschwinden automatisch. Das widerspricht dem Prinzip der Wahrnehmbarkeit (WCAG 2.2.1 "Timing Adjustable"), da die Information unter Umständen zu schnell weg ist und nicht mehr erneut aufgerufen werden kann.

4. Assistive Technologien
   Manche Screenreader erkennen Toasts gar nicht als relevante ARIA-Live-Region, oder sie werden an unerwarteten Stellen vorgelesen. Das führt zu unvorhersehbarem Verhalten.

Aus KoliBri-Sicht

Vision & Mission von KoliBri betonen Zuverlässigkeit, Verständlichkeit und Barrierefreiheit als Kernkriterien. Ein Toast erfüllt diese Kriterien nur schwer.

Qualitätskriterien (z. B. "State must be perceivable and persistent") werden verletzt, da Toasts flüchtig sind.

Manifest fordert "resilient UI", d. h. die Nutzererfahrung darf nicht von zufälligen UI-Patterns abhängen. Ein Toast ist hier ein Anti-Pattern.

Empfehlung

Dialogs & Modals sind die kontrollierte, barrierefreie Variante: Fokusmanagement, klare Ansage durch Screenreader, beständige Informationen.

Toasts eher vermeiden. Stattdessen:

Inline-Feedback im Kontext des Elements (z. B. Bestätigung unter einem Formularfeld).

Status-Bereiche mit role="status" oder aria-live="polite" an definierter, fester Stelle im Layout.

Benachrichtigungscenter (persistent, abrufbar, nicht automatisch verschwindend).

👉 Fazit:

Die Entscheidung, Toasts in KoliBri v5 abzuschaffen, ist aus Sicht der Barrierefreiheit und Konsistenz absolut sinnvoll. Es stärkt die Robustheit des Frameworks und reduziert Fehlanwendungen bei Konsumenten.

[Chrisdo82]

@deleonio Nehmt ihr dann die Anpassung des Button Labels trotzdem noch vor oder sollten wir alternativ mit der Eigenentwicklung des ToastServices beginnen, das wir dann nach unseren Bedürfnissen anpassen können?

[deleonio]

wir haben hierzu jetzt ein ticket #8611