Wie testet man dynamische Inhalte auf Barrierefreiheit?

Dynamische Inhalte auf Barrierefreiheit zu testen erfordert eine Kombination aus automatisierten Scans, manuellen Prüfungen und gezielten Screenreader-Tests. Anders als statische Seiten verändern sich dynamische Inhalte zur Laufzeit, was viele klassische Testmethoden an ihre Grenzen bringt. Die folgenden Abschnitte beantworten die wichtigsten Fragen rund um das Thema, von typischen Barrieren über ARIA live regions bis hin zu den relevanten WCAG-Kriterien.

Welche Barrieren entstehen typischerweise bei dynamischen Inhalten?

Bei dynamischen Inhalten entstehen Barrieren vor allem dann, wenn Änderungen im Seiteninhalt für Hilfsmittel wie Screenreader unsichtbar bleiben oder der Tastaturfokus nach einer Interaktion verloren geht. Typische Problemstellen sind Modaldialoge, Live-Suchergebnisse, Benachrichtigungen, Carousels und Single-Page-Application-Übergänge.

Konkret begegnen Entwicklern und Prüfenden dabei folgende Barrierenkategorien:

• Fehlende Statusmeldungen: Wenn ein Formular abgeschickt wird und eine Erfolgsmeldung erscheint, ohne dass Screenreader davon erfahren, bleibt die Rückmeldung für blinde Nutzende unsichtbar.
• Fokusverlust nach DOM-Änderungen: Öffnet sich ein Overlay oder verschwindet ein Element, landet der Fokus oft an einer unerwarteten Stelle, was die Tastaturnavigation desorientiert.
• Unzureichende ARIA-Attribute: Dynamisch geladenen Komponenten wie Tabs, Akkordeons oder Dropdown-Menüs fehlen häufig die notwendigen Rollen und Zustände, etwa aria-expanded oder aria-selected.
• Zeitlich begrenzte Inhalte: Automatisch rotierende Banner oder Toasts, die nach wenigen Sekunden verschwinden, geben Nutzenden mit Hilfsmitteln oft keine ausreichende Zeit zur Wahrnehmung.
• Unklare Ladereihenfolge: Asynchron nachgeladene Inhalte können die logische Lesereihenfolge im DOM durcheinanderbringen.

Viele dieser Barrieren lassen sich durch ein Barrierefreiheit-Test-Tool zumindest teilweise identifizieren, allerdings erfordert die vollständige Prüfung dynamischer Szenarien immer auch manuelle Testschritte.

Was sind ARIA live regions und wie funktionieren sie?

ARIA live regions sind HTML-Attribute, die Screenreader anweisen, Änderungen in einem bestimmten Bereich der Seite automatisch anzukündigen, ohne dass Nutzende dorthin navigieren müssen. Das zentrale Attribut lautet aria-live mit den Werten polite, assertive oder off.

So funktioniert das Prinzip im Detail:

• aria-live="polite": Der Screenreader wartet, bis der Nutzende aufgehört hat zu tippen oder zu navigieren, und liest die Änderung dann vor. Geeignet für Statusmeldungen und Suchergebnisse.
• aria-live="assertive": Die Meldung wird sofort und unterbrechend vorgelesen. Nur für kritische Fehlermeldungen geeignet, da es den aktuellen Lesefluss unterbricht.
• role="status" und role="alert": Diese implizieren jeweils aria-live="polite" bzw. aria-live="assertive" und sind semantisch klarer.

Ein häufiger Implementierungsfehler ist, die live region erst zusammen mit dem dynamischen Inhalt in den DOM einzufügen. Screenreader erkennen eine live region nur dann zuverlässig, wenn das Element bereits beim Laden der Seite im DOM vorhanden ist und der Inhalt später dynamisch eingetragen wird. Wird die Region nachträglich eingefügt, ignorieren viele Screenreader die Ankündigung.

Welche Tools eignen sich zum Testen dynamischer Inhalte auf Barrierefreiheit?

Für den Barrierefreiheitstest dynamischer Inhalte sind spezialisierte Tools notwendig, die über einfache HTML-Analysen hinausgehen. Eine Kombination aus Browser-Erweiterungen, Screenreadern und automatisierten Scan-Plattformen liefert die besten Ergebnisse.

Browser-basierte Prüfwerkzeuge

Die Browser-Erweiterung axe DevTools analysiert die gerenderte Seite inklusive dynamisch geladener Inhalte direkt in den Chrome- oder Firefox-DevTools. Sie erkennt ARIA-Fehler, Kontrastprobleme und fehlende Labeling-Attribute im aktuellen DOM-Zustand. WAVE von WebAIM bietet ähnliche Funktionen und visualisiert Probleme direkt auf der Seite, was für Nicht-Entwickler besonders verständlich ist. Der Accessibility Insights for Web-Inspector von Microsoft ermöglicht zudem geführte manuelle Tests für Tastaturnavigation und Fokusreihenfolge.

Screenreader-Tests

Kein automatisiertes Tool ersetzt den Test mit einem echten Screenreader. Für Windows ist NVDA (kostenlos) oder JAWS (kostenpflichtig) Standard, auf macOS und iOS kommt VoiceOver zum Einsatz. Beim Test dynamischer Inhalte sollten Sie gezielt prüfen, ob live regions korrekt angekündigt werden, ob der Fokus nach dem Öffnen eines Modals ins Modal springt und ob er beim Schließen an die auslösende Stelle zurückkehrt.

Automatisierte Scan-Plattformen

Plattformen, die Websites auf Barrierefreiheit prüfen, können in der Regel den gerenderten DOM-Zustand analysieren und dabei viele WCAG-Kriterien automatisiert überprüfen. Solche Tools eignen sich besonders gut für die kontinuierliche Überwachung von Websites, damit Änderungen an dynamischen Komponenten nicht unbemerkt neue Barrieren einführen. Wichtig dabei: Automatisierte Scans decken typischerweise einen Teil der prüfbaren WCAG-Kriterien ab, ersetzen aber keine vollständige manuelle Prüfung.

Wie testet man Fokus-Management nach DOM-Änderungen?

Fokus-Management nach DOM-Änderungen testet man, indem man ausschließlich die Tastatur zur Bedienung nutzt und prüft, ob der Fokus nach jeder Interaktion an einer sinnvollen Stelle landet. Das bedeutet: kein Mauseinsatz während des Tests, vollständige Bedienung per Tab, Shift+Tab, Enter und Escape.

Folgende Szenarien sollten Sie gezielt durchspielen:

1. Modaldialog öffnen: Springt der Fokus beim Öffnen ins Modal? Ist der Fokus auf das erste interaktive Element oder die Überschrift des Dialogs gesetzt?
2. Modaldialog schließen: Kehrt der Fokus nach dem Schließen zur auslösenden Schaltfläche zurück?
3. Fehlermeldungen: Wird der Fokus nach dem Absenden eines Formulars mit Fehlern auf die Fehlerzusammenfassung oder das erste fehlerhafte Feld gesetzt?
4. Dynamisch nachgeladene Inhalte: Bleibt der Fokus beim Nachladen von Suchergebnissen an einer logischen Stelle, oder verschwindet er im Nichts?
5. Fokusfalle prüfen: Ist der Fokus innerhalb eines geöffneten Modals eingeschlossen (Fokusfalle als gewolltes Verhalten), verlässt er aber das Modal nicht ungewollt?

Zur Unterstützung können Sie in den Chrome DevTools unter dem Reiter Accessibility den aktuellen Fokuszustand beobachten. Die Browser-Erweiterung Accessibility Insights bietet außerdem eine Tab-Stops-Visualisierung, die die Reihenfolge aller fokussierbaren Elemente auf einen Blick zeigt.

Warum reichen automatisierte Scans für dynamische Inhalte oft nicht aus?

Automatisierte Scans reichen für dynamische Inhalte oft nicht aus, weil sie in der Regel nur den initialen DOM-Zustand oder einen einzelnen Seitenzustand analysieren. Interaktionsabhängige Zustände, wie ein geöffnetes Modal, eine ausgeklappte Dropdown-Liste oder eine Fehlermeldung nach dem Formularabsenden, werden von vielen Tools nicht automatisch ausgelöst und geprüft.

Hinzu kommen inhärente Grenzen automatisierter Prüfmethoden:

• Semantische Verständlichkeit: Ob ein Linktext oder eine Schaltflächenbeschriftung im Kontext verständlich ist, lässt sich nicht algorithmisch beurteilen.
• Zeitliches Verhalten: Ob eine Benachrichtigung lange genug sichtbar bleibt oder ob eine Animation pausierbar ist, erfordert menschliche Beurteilung.
• Komplexe Interaktionsmuster: Drag-and-Drop, mehrstufige Wizards oder kontextabhängige Menüs können nur durch gezielte Bedienung getestet werden.
• Screenreader-Kompatibilität im echten Einsatz: Ob eine live region von verschiedenen Screenreader-Browser-Kombinationen korrekt verarbeitet wird, zeigt sich erst im realen Test.

Aus diesem Grund empfiehlt die WCAG selbst eine Kombination aus automatisierten und manuellen Prüfmethoden. Automatisierte Tools sind wertvoll, um bekannte Muster schnell und konsistent zu erkennen und eine Basis für die BITV-Prüfung zu schaffen. Für eine belastbare Bewertung der tatsächlichen Nutzbarkeit dynamischer Komponenten sind manuelle Tests jedoch unverzichtbar.

Welche WCAG-Kriterien sind für dynamische Inhalte besonders relevant?

Für dynamische Inhalte sind vor allem die WCAG-Erfolgskriterien relevant, die Statusmeldungen, Fokussteuerung, zeitliches Verhalten und die Robustheit gegenüber assistiven Technologien betreffen. Diese fallen überwiegend in die Prinzipien Wahrnehmbar, Bedienbar und Robust.

Die wichtigsten Kriterien im Überblick:

• 1.4.3 und 1.4.11 (Kontrast): Dynamisch erscheinende Elemente wie Tooltips, Benachrichtigungen oder Overlay-Inhalte müssen die Kontrastanforderungen erfüllen, auch im eingeblendeten Zustand.
• 2.1.1 (Tastatur): Alle dynamischen Funktionen müssen vollständig per Tastatur bedienbar sein, ohne dass eine Maus erforderlich ist.
• 2.1.2 (Keine Tastaturfalle): Nutzende dürfen nicht in einem dynamisch geöffneten Bereich gefangen bleiben, es sei denn, es handelt sich um eine bewusste, dokumentierte Ausnahme wie ein Modal.
• 2.2.1 und 2.2.2 (Zeitsteuerung und Pausieren): Automatisch aktualisierende oder rotierende Inhalte müssen pausierbar, stoppbar oder in ihrer Geschwindigkeit anpassbar sein.
• 2.4.3 (Fokusreihenfolge): Der Fokus muss in einer logischen Reihenfolge durch dynamisch eingeblendete Inhalte geführt werden.
• 3.2.2 (Eingabe): Nutzereingaben dürfen keine unerwarteten Kontextänderungen auslösen, ohne dass die Nutzenden vorher informiert wurden.
• 4.1.2 (Name, Rolle, Wert): Dynamische Komponenten wie Tabs, Akkordeons oder Schalter müssen programmatisch korrekte Rollen und Zustände kommunizieren.
• 4.1.3 (Statusmeldungen): Statusmeldungen, die ohne Fokuswechsel erscheinen, müssen so implementiert sein, dass Screenreader sie automatisch ankündigen, etwa über ARIA live regions.

Besonders Kriterium 4.1.3 wird im Kontext dynamischer Inhalte häufig übersehen, obwohl es in WCAG 2.1 explizit für Szenarien wie Warenkorb-Updates oder Formular-Feedback eingeführt wurde. Wer eine Website auf Barrierefreiheit prüfen möchte, sollte dieses Kriterium gezielt in die manuelle Prüfliste aufnehmen.

So unterstützt decareto beim Testen auf Barrierefreiheit

Wir bei decareto haben unsere Plattform so entwickelt, dass sie sowohl automatisierte als auch manuelle Prüfschritte abdeckt, gerade für die komplexen Anforderungen dynamischer Inhalte. Das leistet unser Tool konkret:

• Automatisierter Barrierefreiheits-Scan: Wir analysieren Websites seitenübergreifend nach WCAG 2.1/2.2 und BITV-Kriterien, einschließlich gerenderter DOM-Zustände, und liefern priorisierte Ergebnisse nach Schweregrad.
• Manuelle Probleme erfassen: Barrieren, die sich nur durch menschliche Prüfung erkennen lassen, wie Fokusmanagement oder Screenreader-Verhalten, können direkt im decareto-Dashboard dokumentiert und dem Bericht hinzugefügt werden.
• Konkrete Handlungsempfehlungen: Zu jedem gefundenen Problem liefern wir verständliche Hinweise zur Behebung, formuliert sowohl für Entwickler als auch für Berater ohne tiefes technisches Vorwissen.
• Kontinuierliche Überwachung: Wir überwachen Websites dauerhaft und benachrichtigen Sie automatisch, wenn Änderungen neue Barrieren einführen, damit dynamische Updates nicht unbemerkt bleiben.
• Reports teilen und dokumentieren: Barrierefreiheits-Reports lassen sich direkt mit Kunden teilen, per Link oder PDF-Download, und optional mit Ihrem eigenen Logo versehen.

Möchten Sie sehen, wie decareto Ihre Websites auf Barrieren prüft? Jetzt kostenlos testen und einen ersten Scan starten.

Dieser Text wurde mit Hilfe von KI erstellt und könnte Fehler beinhalten.

Ähnliche Artikel

• Wie erkenne ich, ob meine Website personenbezogene Daten unzulässig verarbeitet?
• Was ist ein Accessibility-Audit-Report und was steht darin?
• Wie skaliere ich DSGVO-Website-Prüfungen für hunderte Websites gleichzeitig?
• Welche Barrierefreiheitspflichten gelten für Web-Agenturen seit dem BFSG?
• Welche Datenschutzrisiken bestehen bei der Verarbeitung von Bewerberdaten auf Karriereseiten?