Barrierefreiheits-Testing: automatisch und manuell
Barrierefreiheits-Testing ist ein zweistufiger Prozess: Automatisierte Tools finden schnell und zuverlässig einen Teil der Probleme — aber nur manuelles Testing und echte Nutzertests decken alle Barrieren auf. Ein vollständiger Accessibility-Audit kombiniert beide Ansätze. Die Faustregel: Automatisierte Tools finden ~30-40% der WCAG-Verstöße. Die restlichen 60-70% erfordern menschliche Einschätzung.
Automatisierte Test-Tools
axe DevTools
Browser-Extension — Präzise, wenig False Positives, CI-Integration — Free / Pro
WAVE
Browser-Extension / Web — Visuelle Darstellung, verständliche Erklärungen — Kostenlos
Lighthouse
Chrome DevTools — Integriert, Score für Vergleiche — Kostenlos
Pa11y
CLI / CI — Automatisierung, CI/CD-Integration — Open Source
Deque Worldspace
Enterprise — Umfassend, Reporting, Team-Features — Kostenpflichtig
Siteimprove
SaaS — Gesamte Website, Monitoring — Kostenpflichtig
axe DevTools — der Standard-Startpunkt
axe DevTools ist die am weitesten verbreitete kostenlose Accessibility-Testing-Extension. Sie ist direkt in Chrome und Firefox DevTools integrierbar, hat sehr wenige False Positives und erklärt Fehler mit konkreten Handlungsempfehlungen.
Installation und Verwendung
axe DevTools als Chrome- oder Firefox-Extension installieren. Seite öffnen, DevTools öffnen (F12), axe DevTools Tab auswählen, Scan starten. Ergebnisse zeigen Fehler (definitive WCAG-Verstöße), Warnungen (zu prüfen) und Best Practices.
Ergebnisse interpretieren
Kritisch: sofort beheben, gravierender Barrierefreiheitsfehler. Schwerwiegend: bald beheben. Moderat: beheben wenn möglich. Gering: optional. Jeder Fehler enthält: betroffenes Element, WCAG-Kriterium, Erklärung, Codebeispiel für Lösung.
axe in CI/CD integrieren
axe-core (npm-Paket) ermöglicht automatisierte Accessibility-Tests in CI/CD-Pipelines. Mit Playwright oder Cypress kombiniert werden bei jedem Build alle Seiten automatisch gescannt. Neue Barrierefreiheitsfehler werden erkannt bevor sie live gehen.
Manuelle Test-Methoden
Tastatur-Only-Navigation
Maus wegstecken, nur Tastatur verwenden. Tab durch alle interaktiven Elemente, alle Funktionen auslösen. Prüfen: Ist Fokus immer sichtbar? Ist Tab-Reihenfolge logisch? Gibt es ungewollte Focus Traps? Sind alle Funktionen erreichbar?
Screenreader-Test
NVDA (Windows, kostenlos) oder VoiceOver (macOS/iOS, eingebaut) aktivieren und durch die Seite navigieren. Wichtigste Prüfpunkte: werden Bilder korrekt beschrieben? Werden Formular-Labels angesagt? Werden Fehlermeldungen kommuniziert? Macht die Lesereihenfolge Sinn?
200% Zoom
Browser-Zoom auf 200% setzen. Prüfen: Verschwindet Text? Überlappen Elemente? Geht Funktionalität verloren? Horizontales Scrollen (außer für spezielle Inhalte wie Tabellen) ist ein WCAG-Fehler.
Kontrast-Check
Kontrast-Checker für Text- und UI-Elemente prüfen. Browser DevTools Color Picker zeigt Kontrastverhältnisse direkt. Besonders kritisch: Platzhalter-Text in Formularen, deaktivierte Buttons, helle Textfarben auf farbigen Hintergründen.
Bilder ohne Styles
CSS deaktivieren (Browser-Extension oder DevTools) und prüfen ob die Seite ohne Styles verständlich und nutzbar ist. Zeigt ob Inhalt strukturell korrekt ist und nicht nur visuell aufgebaut.
Screenreader-Testing
Screenreader-Testing ist zeitaufwändig aber unverzichtbar für eine vollständige Barrierefreiheits-Bewertung. Es deckt Probleme auf die kein automatisiertes Tool findet — falsche Lesereihenfolge, sinnlose Ankündigungen, fehlende Kontext-Informationen.
NVDA
Windows — Kostenlos (Spende empfohlen) — Marktanteil: ~41%
JAWS
Windows — Kostenpflichtig (ab ~90$/Jahr) — Marktanteil: ~40%
VoiceOver
macOS, iOS — Eingebaut, kostenlos — Marktanteil: ~13%
Accessibility Audit — strukturierter Ablauf
Scope definieren
Welche Seiten und User Flows werden geprüft? Vollständige Website oder kritische Pfade (Homepage, Produkt, Checkout, Kontakt)? Für BFSG-Konformität: alle Seiten und Funktionen die Nutzer zum Ziel führen.
Automatisierten Scan durchführen
axe DevTools oder Lighthouse auf allen Scope-Seiten. Ergebnisse exportieren und nach Schweregrad sortieren. Dieser Schritt dauert 30-60 Minuten für eine mittelgroße Website.
Manuelle Tests für kritische Flows
Tastatur-Navigation, Screenreader-Test und Zoom-Test für die wichtigsten User Flows (Kauf-Prozess, Anmeldung, Formular-Einreichung). Dieser Schritt dauert 2-4 Stunden.
Findings dokumentieren und priorisieren
Jeder Fund: WCAG-Kriterium, Schweregrad, betroffene Seiten/Elemente, Empfehlung. Nach Schweregrad und Impact priorisieren. Kritische Fehler zuerst — Blocker für bestimmte Nutzergruppen.
Barrierefreiheitserklärung aktualisieren
Audit-Ergebnisse in der Barrierefreiheitserklärung dokumentieren: Konformitätsstatus, bekannte Probleme mit Zeitplan für Behebung.
Häufig gestellte Fragen
Wie oft sollte ich Barrierefreiheit testen?
Bei jeder signifikanten Änderung der Website. Automatisierte Tests idealerweise in CI/CD bei jedem Deployment. Manueller Audit mindestens jährlich oder nach größeren Redesigns. Screenreader-Tests nach Änderungen an komplexen UI-Komponenten.
Reichen automatisierte Tests für WCAG-Konformität?
Nein. Automatisierte Tools finden ~30-40% der WCAG-Verstöße verlässlich. Für eine WCAG-Konformitätserklärung ist manuelles Testing unverzichtbar. Die Kombination aus automatisierten Tests + Tastatur-Test + Screenreader-Test deckt den größten Teil der relevanten Probleme ab.
Was kostet ein professioneller Accessibility-Audit?
Für eine mittelgroße Website: 2.000-10.000€ je nach Scope und Tiefe. Ein Self-Audit mit kostenlosen Tools (axe, NVDA, manuelle Tests) ist kostenlos aber zeitaufwändig (1-3 Tage). Für BFSG-Pflicht ist ein professioneller Audit zur rechtlichen Absicherung empfehlenswert.
Kann ich Nutzer mit Behinderungen ins Testing einbeziehen?
Ja — und das ist die wertvollste Form des Accessibility-Testings. Nutzertests mit echten Screenreader-Nutzern oder Menschen mit motorischen Einschränkungen decken Probleme auf die kein Tool findet. Organisationen wie Aktion Mensch vermitteln Testende mit Behinderungen.