Automatisiert Testen

Automatisierte Tests ermöglichen eine schnelle und skalierbare Erkennung häufiger Barrieren. Sie eignen sich besonders für den Einsatz in frühen Phasen der Entwicklung und zur kontinuierlichen Qualitätssicherung im Projektverlauf.

Inhalte dieser Seite:

Ziele automatisierter Tests: Effiziente Identifikation typischer Fehler, schnelle Rückmeldung für Entwicklerteams, Integration in Build- und CI/CD-Prozesse

Typische Fehlerarten:

Fehlende Alternativtexte bei Bildern
Kontrastprobleme zwischen Text und Hintergrund
Fehlende oder unklare Formularbeschriftungen
Leere Links oder Buttons ohne semantische Rolle

Wie automatisierte Tools arbeiten:

Automatisierte Prüfwerkzeuge analysieren den Quellcode einer Seite – insbesondere die Struktur des DOM (Document Object Model) – und wenden regelbasierte Heuristiken an, um bekannte Verstöße gegen die WCAG-Kriterien zu erkennen. Dabei kommen vordefinierte Regel-Sets zum Einsatz, die sich in der Regel auf WCAG 2.1 oder 2.2 auf Stufe A oder AA beziehen. Tools wie Axe oder Lighthouse markieren problematische Stellen visuell und geben Hinweise zur Korrektur.

Dabei ist zu beachten: Automatisierte Tests können nur etwa 20–30 % der WCAG-Erfolgskriterien zuverlässig abdecken. Viele Anforderungen, insbesondere zur semantischen Bedeutung, Nutzbarkeit und Verständlichkeit, lassen sich nicht maschinell erkennen. Dies kann zu “False Negatives” (nicht erkannte Fehler) oder “False Positives” (fälschlich gemeldete Probleme) führen.

Gängige Tools und Besonderheiten:

WAVE: Browser-Extension zur visuellen Analyse
Axe DevTools: Entwicklerfreundlich, gut integrierbar in Dev-Umgebungen
Lighthouse: In Chrome integriert, deckt auch Performance und SEO ab
Microsoft Accessibility Insights: Bietet sowohl Schnelltests als auch Schritt-für-Schritt-Checks
BAAT (BITV-Testwerkzeug): Geeignet für deutsche Anforderungen

Toolvergleich Einzelne Tools im Vergleich und Details beim Testen

Grenzen automatisierter Tests:

Keine Beurteilung von Tastaturbedienung oder Screenreader-Kompatibilität
Kein Verständnis für Kontext, Bedeutung oder Nutzerführung
Keine ganzheitliche Einschätzung zur Nutzerfreundlichkeit für Menschen mit Behinderungen

Empfohlene Praxis:

Kombination mit manuellen Tests zur vollständigen Abdeckung
Automatisierte Tests als Teil des kontinuierlichen Qualitätsprozesses
Nutzung als Vorprüfung für gesetzlich relevante Prüfungen (z. B. BITV, BFSG)
Verwendung im Pull-Request-Prozess oder als Teil automatisierter Builds (CI/CD)