Was automatisierte Tests zur Barrierefreiheit nachweisen können und was nicht

Automatisierte Tests zur Barrierefreiheit können zeigen, dass Teile einer Seite bestimmte Anforderungen nicht erfüllen: Ein Bild hat keine Textalternative, ein Formularfeld hat keine Beschriftung, die Seite gibt keine Sprache an, oder ein Text hat weniger Farbkontrast, als die WCAG verlangen. Dass eine Seite oder ein ganzer Shop mit WCAG 2.2 Stufe AA konform ist, können sie nicht nachweisen.

Was Prüfwerkzeuge nicht können, steht in den Hinweisen des W3C zur Auswahl solcher Werkzeuge, Selecting Web Accessibility Evaluation Tools. Dort heißt es (Zitate aus englischsprachigen Quellen sind auf dieser Seite übersetzt): „Tools können nicht alle Aspekte der Barrierefreiheit automatisch prüfen. Es braucht menschliches Urteilsvermögen. Manchmal liefern Prüfwerkzeuge falsche oder irreführende Ergebnisse. Prüfwerkzeuge für die Barrierefreiheit im Web können Barrierefreiheit nicht feststellen, sie können dabei nur unterstützen.“

Das W3C sieht beide Arten von Tests vor. Understanding Conformance, Teil der erläuternden Dokumente des W3C zu WCAG 2.2 (Understanding WCAG 2.2), hält fest, dass alle Erfolgskriterien von WCAG 2 als prüfbare Kriterien formuliert sind, und fügt hinzu: „Das Testen der Erfolgskriterien würde eine Kombination aus automatisierten Tests und menschlicher Bewertung umfassen.“

Die Grenze zwischen beiden verläuft mitten durch die Erfolgskriterien. Viele verlangen etwas, das ein Programm finden kann, und zugleich etwas, das ein Mensch beurteilen muss. Erfolgskriterium 1.1.1 verlangt eine Textalternative, „die dem gleichwertigen Zweck dient“. Erfolgskriterium 2.4.6 lautet vollständig: „Überschriften und Beschriftungen beschreiben Thema oder Zweck.“ Ein Programm kann die Textalternative, die Überschrift und die Beschriftung finden. Ob sie ihren Zweck erfüllen, verlangt ein Urteil über ihre Bedeutung.

Ein Scanner, der auf einer Regel-Engine wie axe-core aufbaut, lädt eine Seite in einem Browser und wendet eine Reihe von Regeln auf die vom Browser dargestellte Seite an. Jede Regel sucht nach einer bestimmten Art von Fehler, etwa einer Schaltfläche ohne zugänglichen Namen, und meldet das Element, an dem sie ihn gefunden hat.

axe-core, die Open-Source-Regel-Engine von Deque Systems, die der Scanner von Validiscan ausführt, hat Regeln für WCAG 2.0, 2.1 und 2.2 auf den Stufen A, AA und AAA und dazu Regeln zur guten Praxis (README von axe-core). Für diesen Ratgeber hat Validiscan die Regelliste von axe-core 4.13.0 ausgezählt: Sie führt 63 Regeln unter den WCAG-Stufen A und AA, ohne die Regeln, die sie als experimentell oder veraltet kennzeichnet. Zusammen sind diese 63 Regeln 20 der 55 Erfolgskriterien zugeordnet, die WCAG 2.2 auf diesen Stufen hat.

Ein Scan sieht die Seite so, wie sie in dem Moment ist, in dem die Regeln laufen. Die API-Dokumentation von axe-core zählt die Schritte eines Tests auf, und der letzte lautet: „Für alle inaktiven oder nicht dargestellten Inhalte wiederholen, nachdem sie sichtbar gemacht wurden“. Ein Menü, ein Dialog oder eine Fehlermeldung, die erst nach einem Klick oder nach dem Absenden eines Formulars erscheint, wird nur getestet, wenn vorher etwas sie öffnet. Manche Prüfungen interagieren deshalb mit der Seite: Sie gehen sie mit der Tab-Taste durch oder stellen sie in geringer Breite dar und messen, was dabei passiert. Welche Prüfungen dieser Art Validiscan ausführt, steht weiter unten.

Nein. Ein Fehler, den eine Regel meldet, ist ein Beleg dafür, dass eine Anforderung nicht erfüllt ist. Ein bestandener Test zeigt nur, dass die Regel keinen Fehler der Art gefunden hat, nach der sie sucht.

Das W3C zieht diese Grenze bei seinen eigenen Testregeln. Die ACT-Regeln beschreiben, wie sich die Konformität mit WCAG und WAI-ARIA testen lässt, und eine ACT-Regel kann einen einzelnen Aspekt einer Anforderung testen: „Eine ACT-Regel könnte testen, ob eine Tabellenzelle eine Kopfzelle hat, statt das Erfolgskriterium 1.3.1 ‚Info and Relationships‘ vollständig zu testen.“ Bestehen Inhalte eine ACT-Regel nicht, erfüllen sie die entsprechende Anforderung nicht. Bestehen sie die Regel, wurden „keine entsprechenden Fehler festgestellt“, was „nicht unbedingt bedeutet, dass die Inhalte alle Aspekte der entsprechenden Anforderung an die Barrierefreiheit erfüllen“. ACT-Regeln sind informativ: Um die Konformität mit WCAG festzustellen, sind sie nicht erforderlich.

Unter den Grundsätzen von axe-core steht im README: „Es liefert keine falsch positiven Ergebnisse (Programmfehler ausgenommen).“ Weiter heißt es dort, dass axe-core Elemente als „incomplete“ zurückgibt, wo es sich nicht sicher sein konnte, und dass dann eine manuelle Prüfung nötig ist. Das ist die eigene Aussage des Projekts über sein Konzept, keine unabhängige Messung. Die oben zitierten Hinweise des W3C warnen zudem ganz allgemein, dass Prüfwerkzeuge falsche oder irreführende Ergebnisse liefern können. Eines macht das Konzept aber deutlich: Die Zahl der gemeldeten Fehler ist keine Gesamtzahl. Sie zählt, was die Regeln feststellen konnten, nicht alles, was nicht stimmt.

Drei Regeln von axe-core 4.13.0 zeigen, wo die Grenze verläuft:

• Bilder. Bei der Regel für Bilder besteht ein Bild, das ein alt-Attribut oder, neben einigen anderen Möglichkeiten, ein ARIA-Label hat. Ihre Prüfung meldet ein Bestehen mit dem Text „Element has an alt attribute“, auf Deutsch „Element hat ein alt-Attribut“ (Prüfung has-alt). Die Prüfung testet, ob das Attribut vorhanden ist, nicht, was darin steht. Auch ein leeres alt, das ein Bild als dekorativ kennzeichnet, besteht. Ob der Text das Bild beschreibt und ob das Bild wirklich dekorativ ist, muss ein Mensch beurteilen.
• Untertitel bei Videos. Bei der Regel für Untertitel besteht ein Video, das eine Untertitelspur hat. Fehlt die Spur, kann die Regel das Video nicht als Verstoß werten, denn, so ein Kommentar in ihrem Code, „Medien können eine andere Methode für Untertitel verwenden“. Sie liefert dann „zu prüfen“ mit der Meldung „Check that captions are available for the element“, auf Deutsch „Prüfen, ob für das Element Untertitel verfügbar sind“ (Prüfung caption). Ob die Untertitel korrekt sind, kann sie nicht beurteilen.
• Farbkontrast. Die Kontrastprüfung berechnet das Kontrastverhältnis zwischen Text und Hintergrund und nennt 15 Gründe, aus denen sie stattdessen „zu prüfen“ liefert, darunter ein Hintergrundbild, einen Hintergrundverlauf und ein Element, das von einem anderen überdeckt wird (Prüfung color-contrast). Text auf einem Hintergrundbild, etwa in einem Banner, wird als „zu prüfen“ eingestuft.

Nach eigener Einschätzung von Validiscan kann eine automatisierte Prüfung bei wenigen Erfolgskriterien von WCAG 2.2 die meisten Fälle entscheiden. Bei den meisten Kriterien kann eine Prüfung einige Fehler feststellen, aber ob das Kriterium erfüllt ist, entscheidet ein Mensch. Bei etwa einem Drittel kann nur ein Mensch entscheiden.

Diese Einteilung ist keine Klassifizierung des W3C. Sie stützt sich auf den Wortlaut jedes Erfolgskriteriums in WCAG 2.2, auf die ACT-Regeln des W3C, auf die Regelliste von axe-core 4.13.0 und auf einen Arbeitsentwurf des W3C, Challenges with Accessibility Guidelines Conformance and Testing, and Approaches for Mitigating Them. Der Entwurf wird hier, wie er selbst darum bittet, als laufende Arbeit zitiert. Er fasst das allgemeine Problem so zusammen: „Wir wissen, wie man das Vorkommen von relevantem Markup automatisch testet und zählt. Wir wissen aber noch nicht, wie man die Qualität dessen automatisch überprüft, was dieses Markup der Nutzerin oder dem Nutzer vermittelt.“

Nach dieser Einteilung fallen die 55 Erfolgskriterien von WCAG 2.2 auf den Stufen A und AA in drei Gruppen:

Die Einteilung beschreibt, was eine Prüfung grundsätzlich feststellen kann. Was ein bestimmtes Tool testet, ist enger gefasst und unterscheidet sich von Tool zu Tool.

In einer vollständigen Prüfung unterstützen Tools, und Menschen bewerten. Die Evaluierungsmethodik des W3C gibt Tools zwei Aufgaben: Sie helfen, eine repräsentative Stichprobe zu bestimmen, und sie unterstützen die Menschen, die diese Stichprobe anschließend prüfen.

WCAG-EM 2.0, die Evaluierungsmethodik für WCAG (WCAG Evaluation Methodology), hat die Accessibility Guidelines Working Group des W3C am 23. Juli 2026 als Group Note veröffentlicht. Die Methodik umfasst fünf Schritte:

1. Den Umfang der Evaluierung festlegen.
2. Das zu prüfende digitale Produkt erkunden.
3. Eine repräsentative Stichprobe auswählen.
4. Die ausgewählte Stichprobe evaluieren.
5. Über die Ergebnisse der Evaluierung berichten.

Zu Tools schreibt WCAG-EM 2.0: „Auch wenn sich die meisten Prüfungen der Barrierefreiheit nicht vollständig automatisieren lassen, können Prüfwerkzeuge Prüferinnen und Prüfer während der Evaluierung erheblich unterstützen und zu einer wirksameren Evaluierung beitragen.“ Als Beispiel nennt die Methodik: „Manche Prüfwerkzeuge für Barrierefreiheit können ein ganzes digitales Produkt scannen und so helfen, relevante Stichproben für die manuelle Evaluierung zu bestimmen.“

WCAG-EM 2.0 grenzt außerdem große Erhebungen von der Evaluierung eines einzelnen Produkts ab. Erhebungen über viele Produkte werden „in der Regel vor allem mit automatisierten Prüfwerkzeugen durchgeführt“, und solche Evaluierungen „erreichen gewöhnlich nicht die nötige qualitative Tiefe der Konformitätsprüfung je Produkt, für die diese Methodik gedacht ist“.

In einem veröffentlichten Test mit einer bekannten Menge an Barrieren fand keines der getesteten automatisierten Tools mehr als die Hälfte davon. Der Government Digital Service (GDS) der britischen Regierung baute absichtlich 142 Barrieren in eine Inhaltsseite ein und ließ 13 automatisierte Tools darüber laufen. In seiner Untersuchung Accessibility tool audit, zuletzt aktualisiert am 13. April 2018, fand das beste Tool 40 % der Barrieren und das schlechteste 13 %. Zählt man die Barrieren mit, die ein Tool zur Prüfung durch einen Menschen markierte, etwa ob Alternativtexte zutreffend waren, kam das beste Tool auf 50 %. Das README des Projekts fasst zusammen: Automatisierte Prüfprogramme sind „gut, um einfache und offensichtliche Probleme zu finden, können aber viele Probleme der Barrierefreiheit nicht erkennen“. Die Zahlen stammen von Tool-Versionen aus den Jahren 2017 und 2018 und von einer eigens dafür gebauten Testseite, nicht von einem echten Shop. Sie zeigen also eine Spanne, keine Quote für einen Shop von heute.

Für dieselbe Seite können Tools unterschiedliche Zahlen melden. Sie testen nicht alle dasselbe, wie die Spanne im Audit des GDS zeigt, und sie legen die WCAG nicht alle gleich aus. Der Leitfaden von axe-core für Regelvorschläge hält fest, dass „nicht alle Testerinnen und Tester die Richtlinien zur Barrierefreiheit gleich auslegen“ und dass alle Regeln von axe-core mit der Auslegung von Deque Systems, dem Unternehmen hinter axe-core, übereinstimmen müssen.

Große automatisierte Erhebungen zeigen dieselbe Grenze von der anderen Seite. Die Analyse von WebAIM zu den Startseiten der Top 1.000.000 Websites stellte mit Daten vom Februar 2026 auf 95,9 % dieser Startseiten WCAG-2-Fehler fest. WebAIM merkt dazu selbst an: „Da nur automatisch erkennbare WCAG-Fehler berücksichtigt wurden, deutet dies darauf hin, dass der Anteil vollständiger Konformität mit WCAG 2 A/AA mit Sicherheit unter 4,1 % lag.“ Alle sechs Fehlerarten, die WebAIM am häufigsten fand, kann eine automatisierte Regel erkennen: Text mit geringem Kontrast, fehlende Alternativtexte für Bilder, fehlende Beschriftungen von Formularfeldern, leere Links, leere Schaltflächen und eine fehlende Angabe der Dokumentsprache. Eine solche Liste zeigt, was Tools sehen können. Eine Rangliste aller Barrieren ist sie nicht.

Der Scanner von Validiscan führt automatisierte Regeln aus, und ein Mensch arbeitet eine manuelle Checkliste ab. Welche Erfolgskriterien die Regeln testen und welche einen Punkt auf der Checkliste haben, ist für jedes Kriterium einzeln veröffentlicht.

Der Scanner führt 102 Regeln aus: 79 Regeln von axe-core und 23 Prüfungen, die Validiscan selbst geschrieben hat, viele davon für das, was axe-core nicht testet, etwa Tastaturfallen, Fokusreihenfolge und Umbruch bei Vergrößerung (Reflow). Weitere 11 Regeln von axe-core sind abgeschaltet, weil eine der eigenen Prüfungen von Validiscan dasselbe testet; so erzeugt ein Element nie zwei Befunde. Nicht ausgeführt werden 15 Regeln, weil axe-core sie als experimentell oder veraltet kennzeichnet oder weil sie nur Stufe AAA prüfen. Der Regelkatalog führt jede Regel mit ihrem Status auf.

Einige der eigenen Prüfungen von Validiscan interagieren mit der Seite. Die Beschreibung der einen lautet „Folgt der Tab-Reihenfolge und erkennt Schleifen und Sackgassen“, die einer anderen „Stellt Seiten in einer Breite von 320 CSS-Pixeln dar (das entspricht 400 Prozent Zoom)“. Sie messen Verhalten. Die Bedeutung beurteilen sie nicht.

Von den 55 Erfolgskriterien von WCAG 2.2 auf den Stufen A und AA werden 33 von mindestens einer Regel getestet, die der Scanner ausführt. Die übrigen 22 testet keine Regel, die der Scanner ausführt, und jedes davon hat einen Punkt auf der manuellen Checkliste mit 35 Punkten. Die Checkliste hat außerdem Punkte für einige Kriterien, die eine Regel nur zum Teil testet, etwa die Bedienung per Tastatur, die Fokusreihenfolge und Untertitel. Für die übrigen Kriterien, die eine Regel testet, hat die Checkliste keinen Punkt. Die Kriterienmatrix zeigt für jedes Erfolgskriterium die Regeln, die es testen, und ob die manuelle Checkliste einen Punkt dazu hat.

Für jeden Punkt der Checkliste hält Validiscan „Bestanden“, „Nicht bestanden“ oder „Nicht anwendbar“ fest, mit Notizen und, wo es eine gibt, einer Belegdatei. Die Ergebnisse stehen im Remediation Evidence Package, im Abschnitt „Manuelle Prüfung und ausgeschlossene Befunde“. Der Abschnitt „Umfang und Methodik“ des Pakets nennt die Grenzen der Prüfung, darunter:

• „Automatisierte Tests finden nur einen Teil aller Barrieren. Ein Kriterium gilt nur dann als unterstützt, wenn automatisierte Tests es vollständig abdecken oder eine manuelle Prüfung bestanden wurde.“
• „Inhalte in Frames anderer Herkunft (Cross-Origin) und in geschlossenem Shadow DOM, etwa Zahlungsfelder sowie einige Einwilligungstools und Widgets, werden nicht automatisch geprüft.“

In der Anwendung von Validiscan gilt ein Kriterium als vollständig von automatisierten Prüfungen abgedeckt, wenn eine Regel, die der Scanner ausführt, es testet und die manuelle Checkliste keinen Punkt dazu hat. Bei einem solchen Kriterium beruht das Ergebnis „Unterstützt“ im Paket allein auf automatisierten Prüfungen. Stand 6. Oktober 2026 gehören dazu auch Kriterien, die nach der Einteilung oben ein Mensch entscheiden muss, etwa 1.1.1 Non-text Content und 2.4.4 Link Purpose (In Context).

Ergebnisse, die eine Regel als „zu prüfen“ markiert, speichert der Scanner derzeit nicht; sie erscheinen deshalb nicht als Befunde. Die Seite Methode und Standards führt das unter den Grenzen auf.

Das Paket gibt Kriterium für Kriterium die Konformität mit den Erfolgskriterien von WCAG 2.1 Stufe AA und WCAG 2.2 Stufe AA an, wie sie auf den aufgeführten Seiten an den angegebenen Tagen geprüft wurde. Dieses Paket belegt eine Prüfung und die durchgeführten Arbeiten zur Behebung. Es ist kein Zertifikat und trifft keine Aussage über die Einhaltung gesetzlicher Vorgaben. Der kostenlose Check ist rein automatisiert und enthält keine manuellen Prüfungen; die Liste der Fehler, die er meldet, ist deshalb nicht vollständig.