Was ist automatisiertes Barrierefreiheitstesten?

Was ist automatisiertes Barrierefreiheitstesten?

Automatisiertes Barrierefreiheitstesten nutzt Software, etwa eine Regel-Engine, ein Browser-Audit oder einen Linter, um eine Seite oder Komponente auf Barrierefreiheitsfehler zu prüfen, die ein Programm erkennen kann: fehlende Alt-Texte, Formularfelder ohne Label, zu geringer Farbkontrast, ungültiges ARIA. Es ist schnell und wiederholbar und damit ideal, um Regressionen zu fangen, deckt aber nur einen Teil von WCAG ab. Den Rest muss ein Mensch beurteilen.

So funktioniert es

Ein Tool lädt das gerenderte DOM, wendet Regeln darauf an und meldet jedes Element, das durchfällt, meist mit Regel, WCAG-Kriterium und Korrekturvorschlag. Gängige Varianten:

• Regel-Engines wie axe-core, eingebunden in Unit-, Komponenten- oder End-to-End-Tests, sodass eine verletzte Regel den Build fehlschlagen lässt.
• Browser-Audits wie Lighthouse, das automatisierte Audits zu einem Barrierefreiheitswert von 0 bis 100 zusammenfasst. Lighthouse gewichtet die Audits mit den Auswirkungsbewertungen von axe, jedes Audit ist bestanden oder nicht, ein Button ohne Beschriftung lässt also das ganze Audit zu Button-Namen durchfallen.
• Linter im Editor oder in der CI, die Probleme im Markup melden, bevor es ausgeliefert wird.

Was es nicht kann

Laut W3C-Leitfaden zur Evaluierung kann kein Tool allein feststellen, ob eine Website Barrierefreiheitsstandards erfüllt, und es braucht sachkundige Prüfung durch Menschen. Das README von axe-core selbst sagt, es finde im Durchschnitt 57 % der WCAG-Probleme automatisch und melde unsichere Elemente als „incomplete“ zur manuellen Prüfung. Das ist die Angabe des Herstellers für die eigenen Regeln, also ein grober Richtwert, keine Garantie. Ein Tool sieht, dass ein Bild einen Alt-Text hat, aber nicht, ob er aussagekräftig ist. Es erkennt nicht, ob die Tab-Reihenfolge sinnvoll ist, ob eine Fehlermeldung verständlich ist oder was eine Person mit Screenreader tatsächlich erlebt. Lighthouse selbst führt manuelle Prüfungen auf, etwa logische Tab-Reihenfolge und Fokusführung, die nicht in den Wert eingehen.

Ein Beispiel in der Pipeline

Ein Team baut axe-core in seine End-to-End-Tests für Registrierung und Checkout ein. Bei jedem Pull Request schlägt der Build fehl, wenn eine neue Regelverletzung auftaucht, etwa ein Eingabefeld ohne Label. Vor jedem Release geht ein Tester diese Seiten mit der Tab-Taste und einem Screenreader durch. Der automatische Lauf fängt Regressionen bei jedem Commit, der manuelle Durchgang findet, was Regeln nicht sehen, siehe manuelle Tests für Barrierefreiheit.

Häufige Fehler

• Einen Lighthouse-Wert von 100 als Beweis für Barrierefreiheit oder WCAG-Konformität zu nehmen.
• Nur die Startseite zu scannen, nicht eingeloggte Zustände, Dialoge, Fehlerzustände und den Checkout.
• „Incomplete“- oder „Prüfen“-Ergebnisse nie anzusehen.
• Die Warnung des Tools zu beheben, ohne das echte Erlebnis zu prüfen, etwa einen sinnlosen Alt-Text einzutragen, nur damit die Regel erfüllt ist.
• Es einmal vor dem Launch zu laufen, statt bei jeder Änderung.

Einordnung in Testen und Monitoring

Automatisiertes Testen ist eine Schicht. Es steht neben Tastaturprüfungen, Screenreader-Tests und den formalen Methoden aus Accessibility Conformance Testing. Auch ein gründliches Audit ist kein Konformitätsbericht: Was dieses Dokument ist, steht unter Accessibility Conformance Report. LoadFocus Page-Speed-Monitoring führt geplante Lighthouse-Audits aus und erfasst die Kategorie Barrierefreiheit neben Performance, SEO und Best Practices, sodass du den Wert als Trend siehst. Es ist ein Monitor für Regressionen, kein Barrierefreiheits-Audit und kein Konformitätsbericht. Mehr dazu in Performance-Tests und Barrierefreiheit und im Überblick über Tools für Barrierefreiheitstests.

Häufige Fragen: Automatisiertes Barrierefreiheitstesten

Wie viel Prozent der Barrierefreiheitsprobleme finden automatische Tools?

Das hängt von Tool und Website ab. Das axe-core-README nennt im Durchschnitt 57 % der WCAG-Probleme, eine eigene Schätzung von Deque für seine Regeln. In jedem Fall braucht ein Teil manuelle Tests.

Ist Lighthouse ein Barrierefreiheits-Audit?

Nein. Es führt automatisierte Audits aus und liefert einen gewichteten Wert. 100 Punkte heißen, dass diese Audits bestanden wurden, nicht dass die Seite barrierefrei ist.

Macht automatisiertes Testen meine Website WCAG-konform?

Nein. Es hilft, viele Fehler zu finden und zu verhindern, aber Konformität braucht eine manuelle Prüfung gegen die Erfolgskriterien.

Wann sollte ich automatisierte Tests ausführen?

Bei jedem Pull Request oder Build für wichtige Seiten und Komponenten, und für Live-Seiten nach Zeitplan, damit Regressionen früh auffallen.

Was prüfe ich von Hand?

Tastaturbedienung und Fokusreihenfolge, Screenreader-Verhalten, Zoom und Reflow, aussagekräftige Alt-Texte, Fehlermeldungen und jedes eigene Widget.