Accessibility Testing: Methoden und Prüfansätze

Automatisierte Prüfwerkzeuge gibt es als Browser-Erweiterungen, als in die Browser-Entwicklertools integrierte Module und als Kommandozeilen-Werkzeuge für die Pipeline. Gemeinsam ist ihnen, dass sie die aktuelle Seite gegen eine WCAG-Regelbasis prüfen. Die Ergebnisse werden in der Regel nach Schweregrad gruppiert (kritisch, schwer, moderat, gering) und enthalten Beschreibungen des Problems, des betroffenen Elements und einen Lösungshinweis. Für eine fundierte Einordnung bündeln wir diese Erkenntnisse in unserem WCAG-Audit.

Viele dieser Prüf-Engines liegen als Open-Source-Bibliotheken vor und lassen sich in automatisierte Test-Pipelines integrieren. In Kombination mit Testing-Frameworks können die Prüfungen bei jedem Build oder Pull Request ausgeführt werden. So lässt sich verhindern, dass neue, automatisch erkennbare Probleme in den Produktivcode gelangen. Für bestehende Projekte empfehlen wir einen Baseline-Scan, der den aktuellen Stand dokumentiert, gefolgt von einer schrittweisen Reduktion der Fehler.

Manche Werkzeuge erweitern den reinen Automatik-Scan um geführte manuelle Tests, die den Prüfer durch Kriterien leiten, die nicht automatisiert prüfbar sind. Solche geführten Tests kombinieren automatisierte Erkennung mit manueller Bestätigung und decken so einen größeren Teil der WCAG-Kriterien ab als ein rein automatisierter Lauf – ersetzen jedoch nicht die vollständige Experten-Prüfung.

Automatisierte Barrierefreiheitstests entfalten ihren größten Nutzen, wenn sie in die CI/CD-Pipeline integriert werden. Bei jedem Code-Commit prüft eine automatisierte Prüf-Engine die gerenderten Seiten auf automatisch erkennbare WCAG-Verstöße. Solche Verstöße werden erkannt, bevor sie in die Produktionsumgebung gelangen. Die Prüfwerkzeuge lassen sich in Build-Prozesse einbinden und blockieren Deployments, wenn kritische Barrierefreiheitsfehler gefunden werden.

Der Aufwand für die Einrichtung ist in der Regel überschaubar – oft genügt die Konfiguration einer automatisierten Prüf-Engine als Testschritt in der bestehenden Pipeline. Eine professionelle Einrichtung hilft, die Tests korrekt zu konfigurieren, damit sie aussagekräftige Ergebnisse liefern.

Screenreader-Tests simulieren die Nutzung der Website durch blinde und sehbehinderte Menschen. Der Tester navigiert mit einem Screenreader unter Windows oder macOS durch die Seite und prüft, ob alle Inhalte zugänglich sind. Werden Landmarks korrekt erkannt? Sind die Überschriften hierarchisch korrekt? Haben alle Bilder Alt-Texte? Sind Formulare korrekt beschriftet? Werden dynamische Inhalte über Live Regions angekündigt?

Der Screenreader-Test deckt Probleme auf, die weder automatisierte Tools noch der Tastatur-Test erkennen: Sinnlose Alt-Texte, die zwar vorhanden sind aber den Bildinhalt nicht beschreiben, ARIA-Attribute, die zwar gesetzt sind aber falsche Werte haben, Live Regions, die nicht funktionieren, und semantische Strukturen, die für Screenreader verwirrend sind.

Wir empfehlen Tests mit mindestens zwei verschiedenen Screenreadern, da jeder Screenreader ARIA-Attribute und HTML-Semantik leicht unterschiedlich interpretiert. Sinnvoll ist die Kombination aus einem unter Windows verbreiteten Screenreader und dem in macOS integrierten Screenreader. Für die mobile Nutzung empfehlen sich zusätzlich Tests mit den in iOS und Android integrierten Screenreadern.

Farbkontraste gehören zu den häufigsten Barrierefreiheits-Problemen: Auf 81 Prozent (WebAIM Million Report, 2024) der Startseiten der eine Million meistbesuchten Websites fand sich zu kontrastarmer Text. Die Prüfung ist dabei vergleichsweise einfach: Das WCAG-Kontrastminimum beträgt 4,5:1 für normalen Text und 3:1 für großen Text (ab 18pt oder 14pt fett). Automatisierte Kontrast-Prüfwerkzeuge berechnen das Kontrastverhältnis für beliebige Farbkombinationen und zeigen sofort, ob die Anforderung erfüllt ist.

Über das reine Kontrastverhältnis hinaus prüfen spezialisierte Tools die Lesbarkeit unter verschiedenen Sehbedingungen: Simulationen für Farbenblindheit (Protanopie, Deuteranopie, Tritanopie), Sehschärfereduktion und Katarakt zeigen, wie Inhalte für betroffene Nutzer erscheinen. Diese Simulationen decken Probleme auf, die bei reiner Kontrastmessung nicht sichtbar werden – etwa zwei Farben mit ausreichendem Kontrast, die bei Rot-Grün-Schwäche nicht mehr unterscheidbar sind. Eine professionelle Barrierefreiheitsprüfung kombiniert automatisierte Kontrastprüfung mit visuellen Simulationen für ein genaueres Bild.

Die Schriftprüfung ergänzt die Farbprüfung: Neben dem Kontrast beeinflussen Schriftgröße, Zeilenabstand und Zeichenabstand die Lesbarkeit maßgeblich. WCAG 2.2 fordert, dass Nutzer Text auf bis zu 200 Prozent vergrößern können, ohne dass Inhalte abgeschnitten werden oder die Funktionalität leidet. Responsive Designs, die ausschließlich mit Viewport-Einheiten arbeiten, erfüllen diese Anforderung oft nicht, weil die Schriftgröße an die Bildschirmbreite statt an die Nutzereinstellungen gekoppelt ist.

Ein professionelles WCAG-Audit verbindet automatisierte und manuelle Testmethoden zu einer umfassenden Prüfung. Der typische Ablauf beginnt mit der Auswahl repräsentativer Seiten: Startseite, Kategorieseite, Produktdetailseite, Checkout-Prozess, Kontaktformular, Login-Bereich und mindestens eine Inhaltsseite. Diese Stichprobe deckt die wichtigsten Seitentypen und Interaktionsmuster ab.

Jede ausgewählte Seite wird gegen alle relevanten WCAG 2.2 AA-Kriterien geprüft. Automatisierte Scans identifizieren die offensichtlichen Probleme. Manuelle Tests prüfen Tastaturnavigation, die Ausgabe für Screenreader und kognitive Verständlichkeit. Die Ergebnisse werden in einem priorisierten Maßnahmenplan zusammengefasst: Kritische Probleme (blockieren den Zugang), schwere Probleme (erhebliche Beeinträchtigung), moderate Probleme (störend, aber umgehbar) und leichte Probleme (Verbesserungspotenzial).

Der Maßnahmenplan enthält für jedes Problem eine Beschreibung, die betroffene Seite und das betroffene Element, das verletzte WCAG-Kriterium, die Priorität und einen konkreten Lösungsvorschlag. Auf Basis des Plans kann die Umsetzung systematisch erfolgen und der Fortschritt nachverfolgt werden. Ein Re-Audit nach der Umsetzung validiert die Korrekturen und identifiziert gegebenenfalls neue Probleme.

Die Dokumentation des Audits ist ebenso wichtig wie die Durchführung: Ein professioneller WCAG-Audit-Bericht listet nicht nur die gefundenen Probleme auf, sondern priorisiert sie nach Schweregrad, betroffener Nutzergruppe und Aufwand der Behebung. Kritische Barrieren, die den Zugang vollständig blockieren (z.B. nicht bedienbare Formulare, fehlende Alternativtexte für zentrale Inhalte), stehen ganz oben. Mittlere Probleme beeinträchtigen die Nutzererfahrung, verhindern aber nicht den Zugang. Niedrige Prioritäten sind Optimierungsmöglichkeiten, die die Barrierefreiheit verbessern, aber keine Pflichtanforderung verletzen. Diese Priorisierung ermöglicht eine schrittweise Barrierefreiheits-Umsetzung mit dem größten Nutzen zuerst.