Dynamische Änderungen barrierefrei gestalten

Dynamische Änderungen auf Webseiten können die Usability und User Experience (UX) verbessern – insbesondere bei Single-Page-Applikationen (SPAs). Allerdings stellen sie Entwicklerinnen vor die Herausforderung, diese Veränderungen so aufzubereiten, dass sie auch von assistiven Technologien wie Screenreadern korrekt verarbeitet werden.

Grundsätzlich lässt sich bei dynamischen Änderungen zwischen zwei Arten unterscheiden:

1. Informierende Änderungen: Das Element gibt eine Information an den Screenreader weiter, ohne den Tastaturfokus des Nutzers zu verschieben.
2. Fokusverändernde Änderungen: Der Tastaturfokus wird gezielt auf das neue oder geänderte Element versetzt.

Grundregel: Eine Verschiebung oder Catching des Fokus sollte ausschließlich dann erfolgen, wenn es zwingend erforderlich ist.

1. Überlagernde Elemente und Menüs

Modale Dialoge (Modals)

Ein Modal legt sich als Overlay über den Inhalt der Webseite (z. B. ein Cookie-Banner). Der Hintergrund wird visuell ausgegraut und für Interaktionen gesperrt.

• Barrierefreie Umsetzung: Solange das Modal geöffnet ist, muss der Fokus im Modal gefangen bleiben. Interaktionen mit dem ausgegrauten Hintergrund dürfen nicht möglich sein.
• Praxisproblem: Viele Implementierungen sind fehlerhaft, da Nutzer mit dem Hintergrund weiterinteragieren können oder das Öffnen des Modals gar nicht mitbekommen.

Pop-Outs

Pop-Outs ähneln Modalen, allerdings bleibt der Hintergrund sichtbar.

• Fokus-Management: Bewegt sich der Fokus in den aufklappenden Bereich, muss der Screenreader explizit über den Kontextwechsel informiert werden. Blinde Nutzer müssen nachvollziehen können, dass ein Bereich aufgegangen ist und wie sie diesen wieder verlassen.
• Schließen: Beim Schließen des Pop-Outs muss der Fokus automatisch auf den Trigger (das auslösende Element) zurückgesetzt werden.

Flyouts und Untermenüs

Flyouts sind ausklappbare Menustrukturen.

• Status-Kommunikation: Der Zustand (expanded / collapsed) muss der assistiven Technologie mitgeteilt werden.
• Tastaturbedienung: Es ist ratsam, dem Nutzer die Möglichkeit zu geben, das Untermenü jederzeit über die Esc-Taste zu schließen und zum Trigger-Element zurückzukehren.

Viele argumentieren, dass der Fokus im Untermenü bleiben sollte. Bei Single Page Applikationen ist das aus meiner Sicht auch sinnvoll, das entspricht dem Verhalten in Desktop-Apps. Bei Flyouts in Website-Navigationen sehe ich das nicht als essentiell, solange das Menü nicht automatisch zuklappt, sobald man das Menü verlässt und dem Screenreader-User klar ist, dass er das Menü verlässt oder betritt.

2. Benachrichtigungen und Statusmeldungen

Formularvalidierung und Fehlermeldungen

Dynamische Fehler- oder Erfolgsmeldungen in Formularen sind in der Regel nicht interaktiv.

• Fokus: Der Fokus sollte nicht verschoben werden.
• ARIA-Attribute: Die Meldung gehört in eine aria-live-Region. Zusätzlich sollte das entsprechende Eingabefeld über aria-describedby mit der ID der Fehlermeldung verknüpft werden.

Toast Messages / Alerts

Toast Messages ploppen meist kurzzeitig am Bildschirmrand auf.

• Keine Fokusverschiebung: Der Fokus sollte keinesfalls kurz auf das Pop-up springen und zurückspringen, da dies extrem verwirrend ist.
• Interaktive Toasts (z. B. „Rückgängig machen“): Wenn Toasts Buttons enthalten, sollte der Fokus dennoch nicht zwingend versetzt werden. Stattdessen empfiehlt sich die Bereitstellung eines globalen Tastaturkürzels oder eine Platzierung im DOM, die ein schnelles Erreichen ermöglicht (z. B. am Anfang des Inhaltsbereichs).

3. Dynamische Inhaltsänderungen und Formulare

• Änderungen nach/unter dem Trigger: Verändern sich Formularfelder unterhalb einer Benutzereingabe (z. B. Zusatzfelder je nach Auswahl des Familienstands), ist eine direkte Ansage nicht immer erforderlich, da der Nutzer beim Weiternavigieren automatisch darauf stößt.
• Änderungen vor/über dem Trigger: Ändert sich ein Bereich oberhalb der aktuellen Position (z. B. eine dynamische Trefferanzahl oberhalb eines Suchfeldes), muss diese Information zwingend angesagt werden.
• Auto-Suggest / Vorschlagslisten: Bei Suchfeldern mit dynamischer Vorschlagsliste muss der Screenreader melden, dass Vorschläge vorhanden sind und wie diese erreicht werden können (z. B. über die Pfeiltasten).

4. Fortschritts- und Ladeanzeigen

Progress Bars (Fortschrittsbalken)

• Intervall-Wahl: Bei schnellen Fortschrittsanzeigen (z. B. ein Ladebalken von 0–100 % innerhalb weniger Sekunden) darf nicht jede Prozentänderung angesagt werden. Dies führt zu einem Informations-Overload und macht die Anwendung unbenutzbar.
• aria-live-Modi:
  • polite (empfohlen): Der Screenreader wartet, bis die aktuelle Sprachausgabe beendet ist, bevor er das Update vorliest.
  • assertive: Unterbricht die aktuelle Sprachausgabe sofort. Dies sollte nur für zeitkritische Notfälle reserviert sein (z. B. „Automatischer Logout in 10 Sekunden“).

Ladeindikatoren (Spinner)

Blockiert ein Ladevorgang die gesamte Seite oder einen Bereich, kann analog zu einem Modal vorgegangen werden: Das ARIA-Attribut teilt mit, dass die Anwendung arbeitet, während der Fokus während des Ladevorgangs im Ladeindikator gehalten wird.

5. Komplexe UI-Muster und moderne Web-Applikationen

Infinite Scroll (Unendliches Nachladen)

Bei Plattformen mit unendlichem Scrollen (z. B. Feed-Inhalte in Social Media) muss das Nachladen neuer Inhalte kommuniziert werden. Andernfalls verstehen Screenreader-Nutzer nicht, warum sie beim Scrollen/Navigieren nicht zu nachfolgenden Seitenbereichen (wie etwa einer rechten Seitenleiste) gelangen.

Standard-HTML-Komponenten (Akkordeons, Tabs, Selects)

Wandelt man Menüs, Akkordeons oder Tab-Panel-Strukturen mit nativem HTML und Standard-ARIA-Attributen um, bleibt der Aufwand gering:

• Zustand über aria-expanded / aria-selected kommunizieren.
• Nicht aktive Inhalte über hidden oder CSS-Eigenschaften für Screenreader unsichtbar schalten, solange der Tab/das Akkordeon geschlossen ist.

Dynamische URL-Änderungen ohne Neuladen (Single Page Applications)

Wird die URL dynamisch angepasst (z. B. beim Durchblättern von Medieninhalten), ohne dass ein echter Seiten-Reload stattfindet, bleibt der Screenreader-Fokus an Ort und Stelle.

• Lösung: Der document.title kann via JavaScript aktualisiert werden. Screenreader registrieren diese Aktualisierung und lesen den neuen Seitentitel vor, was dem Nutzer eine saubere Orientierung ermöglicht.