Prüfwerkzeuge im Vergleich

Alle automatischen Prüfwerkzeuge rechnen mit derselben WCAG-Formel und liefern trotzdem verschiedene Ergebnisse. Der Grund ist nicht Qualität, sondern Umfang: Sie prüfen unterschiedliche Regelmengen und melden Vermutungen unterschiedlich streng. Diese Seite ordnet ein, welches Werkzeug welche Frage beantwortet – und welche Frage keines von ihnen beantwortet.

Das Wichtigste in Kürze

• Automatische Werkzeuge finden nach gängigen Erhebungen rund ein Drittel der WCAG-Erfolgskriterien. Der Rest verlangt menschliche Bewertung – ob ein Alt-Text sinnvoll ist, entscheidet kein Regelwerk.
• axe DevTools hat die wenigsten Fehlalarme und benennt zu jedem Befund das Erfolgskriterium. Es ist die beste Wahl, wenn du nur ein Werkzeug installierst.
• WAVE markiert Befunde direkt auf der Seite. Das macht es zum besten Werkzeug, wenn du jemandem ein Problem zeigen willst.
• Lighthouse liefert einen Zahlenwert für den Verlauf – aber die Barrierefreiheits-Wertung ist keine Konformitätsaussage, und der Bericht sagt das selbst.
• Pa11y und IBM Equal Access laufen auf der Kommandozeile und eignen sich für die CI-Pipeline: nicht als Nachweis, sondern als Regressionsbremse.
• Der BITV-Test ist kein Werkzeug, sondern ein Prüfverfahren mit Prüfschritten, Bewertung und Bericht durch Menschen. Er ist der einzige Eintrag in dieser Liste, der als Nachweis taugt.
• Overlay-Werkzeuge gehören nicht in diese Liste. Sie prüfen nichts, sie überdecken – und gelten weder nach BFSG noch nach EN 301 549 als Nachweis.
• Ein grüner Wert bedeutet: Die geprüften Regeln sind erfüllt. Er bedeutet nicht, dass die Seite bedienbar ist.

Was automatische Werkzeuge finden – und was nicht

Die Trennlinie verläuft nicht zwischen guten und schlechten Werkzeugen, sondern zwischen maschinell entscheidbaren und nicht entscheidbaren Fragen.

Die rechte Spalte ist der Grund, warum ein Prüfbericht mit null Fehlern nichts über die Nutzbarkeit sagt. Wie der manuelle Teil abläuft, steht unter Barrierefreiheit selbst testen.

Die Werkzeuge im Einzelnen

axe DevTools

Was es ist: Browser-Erweiterung von Deque, aufsetzend auf der Open-Source-Bibliothek axe-core. Dieselbe Bibliothek steckt in vielen anderen Werkzeugen, auch in Lighthouse.

Stärke: Sehr wenige Fehlalarme. Deque legt Wert darauf, nur zu melden, was eindeutig ein Verstoß ist; unsichere Fälle landen in einer eigenen Kategorie zum manuellen Prüfen. Jeder Befund nennt das Erfolgskriterium und einen Reparaturvorschlag.

Grenze: Was die Bibliothek nicht kennt, meldet sie nicht – und sie kennt bewusst nicht alles. Wer die Menge der Befunde für die Menge der Probleme hält, unterschätzt die Lage systematisch.

Wann ich es nehme: Bei jeder Prüfung als erster Durchlauf, und in der Entwicklung als ständiger Begleiter.

WAVE

Was es ist: Werkzeug von WebAIM, als Browser-Erweiterung und als Online-Prüfung für öffentlich erreichbare URLs.

Stärke: Die Darstellung. WAVE legt Symbole direkt auf die Seite – hier fehlt ein Alt-Text, dort ist ein Kontrast zu schwach, da steht eine Überschrift der falschen Ebene. Für Gespräche mit Redaktion, Design oder Geschäftsführung ist das unschlagbar, weil das Problem sichtbar wird statt in einer Liste zu stehen.

Grenze: Mehr Hinweise und Warnungen als axe, also mehr Rauschen. WAVE benennt viele Punkte, die ein Mensch prüfen soll – das ist gewollt, macht die Liste aber länger.

Wann ich es nehme: Wenn ich etwas erklären muss. Und für den schnellen Blick auf eine fremde Seite, ohne etwas zu installieren.

Lighthouse

Was es ist: In Chrome eingebaut, nutzt intern axe-core für den Barrierefreiheits-Teil und ergänzt Performance, SEO und Best Practices.

Stärke: Immer verfügbar, keine Installation, ein Zahlenwert für den Zeitverlauf. Für die Frage „ist es besser oder schlechter geworden?“ ist das praktisch.

Grenze: Der Wert verführt. Eine 100 im Barrierefreiheits-Abschnitt heißt: Die automatisch prüfbaren Punkte sind erfüllt – der Bericht schreibt selbst dazu, dass eine manuelle Prüfung nötig bleibt. Als Konformitätsaussage taugt der Wert nicht, und als Argument gegenüber einer Prüfstelle erst recht nicht.

Wann ich es nehme: Für den Verlauf und als Aufhänger, wenn jemand eine Zahl braucht. Nie als Abnahmekriterium.

Pa11y und IBM Equal Access

Was sie sind: Kommandozeilenwerkzeuge, die sich in Build- und CI-Prozesse einbinden lassen.

Stärke: Sie halten den erreichten Stand. Ein Build, der bei neuen Verstößen bricht, verhindert genau das Muster, das ich am häufigsten sehe: Eine Seite war sauber, dann kam ein neues Karussell.

Grenze: Dieselbe wie bei allen automatischen Werkzeugen – nur mit dem zusätzlichen Risiko, dass ein grüner Build als Freigabe missverstanden wird.

Wann ich sie nehme: Sobald ein Projekt eine Pipeline hat und der manuelle Stand einmal erreicht ist.

Der BITV-Test

Was er ist: Ein Prüfverfahren, kein Programm. Geprüft wird eine repräsentative Seitenauswahl anhand fest definierter Prüfschritte; jeder Schritt wird von einer Prüferin oder einem Prüfer bewertet und dokumentiert.

Stärke: Er beantwortet die Frage, die kein Werkzeug beantwortet – ist diese Website nutzbar und konform? Das Ergebnis ist ein nachvollziehbarer Bericht, der als Nachweis gegenüber Dritten dient.

Grenze: Aufwand und Zeitpunkt. Ein BITV-Test kurz vor dem Launch findet Dinge, für deren Behebung dann keine Zeit mehr ist. Er gehört nach der eigenen Vorprüfung, nicht statt ihr.

Wann ich ihn nehme: Im öffentlichen Sektor als Abnahme, im privaten Sektor immer dann, wenn eine belastbare Aussage nach außen gebraucht wird. Details unter BITV-Test, Audit & VPAT.

Warum zwei Werkzeuge verschiedene Zahlen liefern

Diese Frage kommt in jedem Projekt, meist mit einem Anflug von Misstrauen. Die Erklärung ist unspektakulär:

• Unterschiedliche Regelmengen. Jedes Werkzeug implementiert eine eigene Auswahl an Prüfregeln. Was nicht implementiert ist, wird nicht gemeldet.
• Unterschiedliche Strenge bei Vermutungen. Manche melden nur Eindeutiges, andere zusätzlich alles Verdächtige.
• Unterschiedliche Zählweise. Zählt ein fehlendes Label als ein Fehler oder als ein Fehler pro betroffenem Feld? Beides ist vertretbar und ergibt sehr verschiedene Zahlen.
• Unterschiedlicher Prüfzeitpunkt. Ein Werkzeug, das das ausgelieferte HTML betrachtet, sieht nicht, was JavaScript später nachlädt.

Praktische Folge: Vergleiche nie zwei Werkzeuge miteinander, sondern dasselbe Werkzeug über die Zeit. Und melde Befunde immer mit Werkzeug und Version.

Welches Werkzeug wofür

Die letzten drei Zeilen sind die wichtigsten – und in genau diesen Zeilen steht kein automatisches Werkzeug.

Häufiger Fehler in der Praxis

Die Zahl der Befunde als Fortschrittsmaß. Von 120 auf 8 Fehler klingt nach Fortschritt und kann bedeuten, dass jemand die schwer prüfbaren Bereiche hinter JavaScript versteckt hat. Aussagekräftig ist, welche Kriterien erfüllt sind, nicht wie viele Zeilen der Bericht hat.

Nur die Startseite geprüft. Sie ist die am besten gepflegte Seite und die mit der geringsten Bedeutung für den Vorgang. Formular, Checkout und Suchergebnisseite entscheiden.

Werkzeug gewechselt, wenn das Ergebnis nicht gefällt. Wer so lange sucht, bis ein Werkzeug grün meldet, hat ein Werkzeug gefunden und kein Problem gelöst.

Den Screenreader-Test durch ein Werkzeug ersetzt. Kein Prüfprogramm hört zu. Was angesagt wird und ob es reicht, entscheidet nur ein Durchlauf – siehe Screenreader-Grundlagen.

Häufige Fragen

Welches Werkzeug ist das beste?

axe DevTools, wenn du dich für eines entscheiden musst: wenige Fehlalarme, klare Zuordnung zum Erfolgskriterium, konkrete Reparaturvorschläge. Sobald du etwas erklären willst, ist WAVE besser. Beide zusammen kosten nichts und decken den automatisch prüfbaren Teil gut ab.

Reicht ein Lighthouse-Wert von 100 als Nachweis?

Nein. Der Wert bezieht sich auf die automatisch prüfbaren Punkte und sagt das im Bericht auch. Für einen Nachweis brauchst du eine Prüfung, die den manuellen Teil abdeckt – im öffentlichen Sektor in der Regel einen BITV-Test.

Wie viel Prozent der Probleme finden Werkzeuge wirklich?

Die verbreitete Größenordnung liegt bei rund einem Drittel der Erfolgskriterien. Die Zahl schwankt je nach Erhebung und je nachdem, ob man Kriterien oder Einzelbefunde zählt. Verlässlich ist die Richtung: Die Mehrheit der Anforderungen ist maschinell nicht entscheidbar.

Kann ich Barrierefreiheit automatisiert überwachen?

Für Regressionen ja – mit Pa11y oder IBM Equal Access in der CI-Pipeline. Für Konformität nein. Der sinnvolle Einsatz ist: einmal manuell auf einen guten Stand kommen, dann automatisiert verhindern, dass er verloren geht.

Warum tauchen Overlay-Tools hier nicht auf?

Weil sie nichts prüfen. Sie blenden eine zweite Bedienoberfläche über die vorhandene Seite, ändern die Ursachen im Markup nicht und kollidieren mit vorhandener Hilfstechnik. Als Nachweis gegenüber Marktüberwachung oder Prüfstelle taugen sie nicht.

Verwandte Themen

• Tools für Barrierefreiheit & SEO – die vollständige, kommentierte Werkzeugliste
• Barrierefreiheit selbst testen – der manuelle Teil, den kein Werkzeug übernimmt
• BITV-Test, Audit & VPAT – das Prüfverfahren mit Nachweischarakter
• Kontrast-Check – die ganze Seite auf einmal messen
• Cheat-Sheets & Checklisten – die Punkte zum Abhaken nach dem Werkzeugdurchlauf

Quellen

• axe-core (Deque – die Regelbibliothek hinter axe DevTools und Lighthouse)
• WAVE Web Accessibility Evaluation Tool (WebAIM)
• Lighthouse Accessibility Scoring (Google – Hinweis, dass der Wert nur automatisch prüfbare Punkte abdeckt)
• BITV-Test (BIK – Prüfschritte, Bewertung und Bericht)