Die Versuchung ist groß: Man gibt „Barrierefreiheits-Test“ in die Suche ein, installiert das erstbeste Tool, lässt es laufen, sieht ein grünes Häkchen – und hält die Website für konform. Genau hier beginnt das Problem. Denn die unbequeme Wahrheit, die in den meisten Tool-Listen untergeht, lautet: Kein automatisches Werkzeug findet mehr als 30 bis 40 Prozent der relevanten Fehler. Ein Barrierefreiheits-Test ist deshalb keine Frage von „welches Tool“, sondern von „welche Ebenen der Prüfung“. In diesem Vergleich zeige ich Ihnen, was die wichtigsten Werkzeuge leisten, wo jedes an seine Grenze stößt, mit welchem Schichtenmodell Sie eine vollständige Prüfung aufbauen – und warum ein Lighthouse-Score von 100 trügerisch sein kann.

Was ein Barrierefreiheits-Test leisten muss

Ein Barrierefreiheits-Test prüft, ob eine Website, App oder ein Dokument die Anforderungen der WCAG erfüllt – also wahrnehmbar, bedienbar, verständlich und robust ist. So weit die Theorie. In der Praxis verbirgt sich hinter dem Wort „Test“ ein ganzes Spektrum von Methoden, die sehr Unterschiedliches leisten. Ein automatischer Scanner prüft anderes als ein Mensch mit einem Screenreader, und beide prüfen anderes als ein echter Nutzer mit einer Behinderung.

Der häufigste und teuerste Denkfehler ist, diese Methoden für austauschbar zu halten. Sie sind es nicht. Sie ergänzen sich – und keine ersetzt die andere. Wer das verinnerlicht, stellt nicht mehr die Frage „Welches ist das beste Tool?“, sondern „Welche Kombination deckt mein Risiko ab?“.

Die unbequeme Wahrheit: Warum kein Tool mehr als 30 bis 40 Prozent findet

Diese Zahl sollten Sie sich merken, weil sie alles andere relativiert: Automatische Test-Tools erfassen nur etwa 30 bis 40 Prozent der WCAG-Erfolgskriterien. Die übrigen 60 bis 70 Prozent lassen sich nur durch menschliche Prüfung beurteilen. Das ist kein Mangel einzelner Produkte, sondern eine grundsätzliche Grenze der Automatisierung – sie betrifft jedes Werkzeug am Markt gleichermaßen.

An dieser Stelle stiftet eine Marketing-Zahl regelmäßig Verwirrung. Der Hersteller der verbreiteten axe-Engine wirbt damit, etwa 57 Prozent der WCAG-Probleme automatisch zu finden. Das klingt nach mehr, misst aber etwas anderes: den Anteil gefundener Einzelprobleme, nicht den Anteil abgedeckter Erfolgskriterien. Beide Zahlen stimmen – sie zählen nur Verschiedenes. Für Ihre Risikoeinschätzung ist die konservative Lesart die richtige: Verlassen Sie sich darauf, dass ein automatischer Test grob ein Drittel der Anforderungen prüft, nicht mehr.

Konkret gibt es eine ganze Klasse von Barrieren, die Maschinen prinzipiell nicht erkennen können. Ob ein Alt-Text das Bild wirklich sinnvoll beschreibt oder nur bild123.jpg wiederholt. Ob die Fokus-Reihenfolge beim Durchtabben einem logischen Weg folgt. Ob eine Fehlermeldung verständlich und klar mit dem richtigen Feld verknüpft ist. Ob ein selbstgebautes Widget mit einem Screenreader bedienbar ist. Ob die Sprache verständlich ist. All das sind inhaltliche Urteile – und genau hier endet, was ein Skript leisten kann. Ein Lighthouse-Score von 100 bedeutet deshalb nicht, dass Ihre Seite barrierefrei ist. Er bedeutet, dass die automatisch prüfbaren Punkte stimmen.

Die fünf Ebenen eines vollständigen Barrierefreiheits-Tests

Statt nach dem einen Tool zu suchen, denken Sie in Ebenen. Ein belastbarer Barrierefreiheits-Test setzt sich aus fünf Schichten zusammen, die jeweils andere Fehler aufdecken. Diese Übersicht nutze ich, um Teams zu zeigen, wo sie stehen und was ihnen noch fehlt.

Die Ebenen bauen aufeinander auf. Ebene eins ist schnell, günstig und automatisierbar – der ideale Einstieg, aber eben nur ein Drittel der Strecke. Mit jeder weiteren Ebene steigt der Aufwand, aber auch die Aussagekraft. Erst die Ebenen vier und fünf prüfen, was am Ende zählt: ob ein blinder oder motorisch eingeschränkter Mensch Ihren Bestellprozess wirklich abschließen kann. Ein Programm, das bei Ebene eins stehen bleibt, testet ehrlich gesagt nur die Spitze des Eisbergs.

Die wichtigsten Tools im ehrlichen Vergleich

Innerhalb der automatischen Ebene gibt es eine Handvoll etablierter Werkzeuge, die sich in Zielgruppe und Charakter unterscheiden. Bemerkenswert ist, dass die meisten unter der Haube dieselbe Engine nutzen – die quelloffene axe-core-Bibliothek steckt auch in Lighthouse, Pa11y und Accessibility Insights. Die folgende Tabelle ordnet die wichtigsten ein.

Ein Unterschied in dieser Tabelle verdient besondere Aufmerksamkeit, weil er über den ersten Eindruck hinausgeht. Die etablierten Werkzeuge sind für Entwickler gebaut: Sie liefern technisch präzise, aber rohe Ergebnislisten und setzen voraus, dass jemand sie interpretieren kann. Für ein Entwicklungsteam ist das ideal. Wenn Sie aber als Verantwortlicher schlicht wissen wollen, wo Sie stehen und was zu tun ist, lassen diese Tools Sie mit einer Liste von Fehlercodes allein – und beim Befund endet ihre Hilfe. Genau hier setzt unser kostenloses Access Score an: Es prüft Ihre Website ebenfalls automatisch nach WCAG 2.2, übersetzt das Ergebnis aber in verständliches Entscheider-Deutsch und ist zugleich der erste Schritt eines durchgängigen Wegs – von der Diagnose über die Behebung bis zum belastbaren Zertifikat. Den ehrlichen Rahmen dieses Artikels behält es bei: Auch Access Score deckt die automatische Ebene ab, nicht mehr. Aber es lässt Sie danach nicht allein.

axe DevTools – der Entwicklerstandard

Wenn Sie entwickeln, führt an axe kaum ein Weg vorbei. Die Browser-Erweiterung liefert zuverlässige, fehlalarmarme Ergebnisse direkt in den Entwicklerwerkzeugen, und dieselbe Engine lässt sich in die CI/CD-Pipeline einbinden. Die kostenpflichtige Pro-Version ergänzt geführte Tests für manuelle Aspekte. Stärke und Grenze liegen dicht beieinander: axe ist der zuverlässigste automatische Test – und prüft eben nur, was automatisch prüfbar ist.

WAVE – der anschauliche Einstieg

WAVE vom gemeinnützigen WebAIM legt seine Befunde als Symbole direkt auf die Live-Seite. Das macht es besonders zugänglich für Redakteure, Designer und Entscheider, die kein Entwicklerwerkzeug bedienen wollen. Der Preis dafür: WAVE meldet großzügiger und verlangt mehr menschliche Interpretation, welcher Hinweis wirklich ein Problem ist.

Lighthouse und Accessibility Insights – schnell und geführt

Lighthouse steckt bereits in jedem Chrome-Browser und liefert in Sekunden einen Score, der sich gut über die Zeit verfolgen lässt – ideal für einen schnellen Überblick und für Build-Pipelines. Accessibility Insights von Microsoft geht einen Schritt weiter: Sein FastPass erledigt die wichtigsten Checks in unter fünf Minuten, das Assessment führt strukturiert durch die manuellen Prüfschritte. Damit ist es eines der wenigen kostenlosen Werkzeuge, das die zweite Ebene ernst nimmt.

Aus der Praxis: Ein Team kam frustriert zu uns, weil sein automatischer Test dutzende „Fehler“ meldete, an denen die Entwickler tagelang arbeiteten – ohne dass sich an der echten Bedienbarkeit etwas änderte. Ein Teil der Meldungen waren Fehlalarme, ein anderer betraf Punkte, die ein Mensch in Sekunden als unkritisch eingeordnet hätte. Werkzeuge melden, was sie messen können; ob eine Meldung wirklich eine Barriere ist, bleibt ein menschliches Urteil. Die Interpretation der Ergebnisse ist deshalb so wichtig wie der Scan selbst.

Kostenlos oder kostenpflichtig – wann sich der Aufpreis lohnt

Die gute Nachricht zuerst: Für einen soliden automatischen Barrierefreiheits-Test brauchen Sie kein Budget. Access Score, axe, WAVE, Lighthouse und Accessibility Insights sind kostenlos und decken die erste Ebene zuverlässig ab. Geld lohnt sich erst, wenn besondere Anforderungen dazukommen. Kostenpflichtige Stufen wie axe Pro ergänzen geführte Tests für manuelle Aspekte. Cloud-Plattformen wie Siteimprove bieten kontinuierliches Monitoring über viele Seiten hinweg, Verlaufsberichte und Rechteverwaltung für große Teams. Diese Funktionen zahlen sich aus, wenn Sie zahlreiche Auftritte parallel betreuen oder Compliance über die Zeit dokumentieren müssen. Für eine einzelne Website ist der kostenlose Werkzeugkasten plus eine ehrliche manuelle Prüfung in aller Regel der wirtschaftlichere Weg.

WCAG 2.2 und die wachsende Grenze der Automatisierung

Ein Detail aus der Praxis zeigt, wie eng die Grenzen der Automatisierung wirklich sind – und dass sie eher enger werden. Von den neun Erfolgskriterien, die mit WCAG 2.2 hinzugekommen sind, lässt sich nur ein einziges zuverlässig automatisch prüfen: die Zielgröße von Bedienelementen (Kriterium 2.5.8). Der Hersteller von axe hat offen erklärt, dass dies voraussichtlich die einzige der neuen Regeln bleibt, die in die automatische Prüfung aufgenommen wird – die übrigen würden ohne menschliche Nachkontrolle zu viele Fehlalarme erzeugen.

Das ist ein bemerkenswerter Befund. Kriterien wie die zugängliche Authentifizierung (3.3.8), Ziehbewegungen (2.5.7) oder die Sichtbarkeit des fokussierten Elements hinter Cookie-Bannern und klebrigen Kopfzeilen (2.4.11) betreffen genau die interaktiven, dynamischen Teile moderner Anwendungen – und gerade die entziehen sich der Maschine. Je moderner und anspruchsvoller die Anforderungen werden, desto größer wird der Anteil, den nur ein Mensch beurteilen kann. Wer seine Teststrategie allein auf Automatisierung stützt, prüft ausgerechnet die zeitgemäßen Kriterien nicht.

Der pragmatische Test-Workflow für Ihr Team

Aus all dem lässt sich ein klarer, praktikabler Ablauf ableiten – abgestuft nach Ihrer Rolle, aber immer mit denselben menschlichen Ebenen als Pflichtteil.

• Für den Einstieg: WAVE und Lighthouse. Beide kostenlos, kein Setup, fangen die häufigsten Fehler ab.
• Für Entwickler: axe DevTools im Browser plus Pa11y in der CI/CD-Pipeline, damit kein neuer Code ungeprüft live geht.
• Für Designer: ein Kontrast- und Struktur-Werkzeug bereits im Entwurf, später WAVE zur Verifikation der Umsetzung.
• Für alle, immer: eine manuelle Tastaturprüfung und ein Screenreader-Test. Das ist der Schritt, der über echte Barrierefreiheit entscheidet – und der am häufigsten ausgelassen wird.

Aus der Praxis: Ein Kunde präsentierte uns stolz seinen Lighthouse-Score von 98 von 100 und hielt das Thema damit für erledigt. Im manuellen Test scheiterte derselbe Auftritt schon am zweiten Schritt: Die Hauptnavigation ließ sich per Tastatur nicht aufklappen, und der Screenreader sagte beim selbstgebauten Filter nur „Schaltfläche“ ohne Funktion. Der Score war nicht falsch – er prüfte nur nichts von alldem. Genau dieser blinde Fleck zwischen einem guten Testergebnis und tatsächlicher Bedienbarkeit kostet Unternehmen am Ende am meisten.

Worauf es beim manuellen Barrierefreiheits-Test ankommt

Weil die menschlichen Ebenen über echte Barrierefreiheit entscheiden, hier das Wesentliche, das Sie auch ohne Spezialwissen selbst prüfen können. Der Tastatur-Test ist der schnellste Erkenntnisgewinn: Legen Sie die Maus beiseite und navigieren Sie nur mit Tabulator-, Pfeil- und Eingabetaste durch Ihre wichtigsten Seiten. Achten Sie auf drei Dinge – ob Sie jedes Bedienelement erreichen, ob jederzeit sichtbar ist, wo der Fokus gerade steht, und ob die Reihenfolge logisch dem sichtbaren Aufbau folgt.

Der Screenreader-Test geht einen Schritt weiter. Mit dem kostenlosen NVDA unter Windows oder dem in macOS integrierten VoiceOver hören Sie, was ein blinder Mensch wahrnimmt. Prüfen Sie, ob Bilder sinnvoll beschrieben werden, ob Formularfelder ihren Zweck ansagen und ob Statusmeldungen – etwa „in den Warenkorb gelegt“ – überhaupt vorgelesen werden. Schon zehn Minuten in diesen beiden Tests offenbaren mehr über die tatsächliche Bedienbarkeit als jeder automatische Scan.

Eine dritte manuelle Prüfung wird fast immer vergessen, kostet aber kaum eine Minute: Zoomen Sie Ihre Seite im Browser mit Strg und Plustaste auf 200 Prozent und stellen Sie die Schriftgröße hoch. Bleibt alles lesbar und bedienbar, ohne dass Text abgeschnitten wird oder Inhalte horizontal aus dem Bild scrollen? Genau das verlangen die Kriterien 1.4.4 (Textvergrößerung) und 1.4.10 (Reflow) – und genau hier brechen starre, pixelgenau gebaute Layouts, die ein automatischer Scan anstandslos durchwinkt.

Wie oft müssen Sie testen?

Ein verbreiteter Irrtum ist, ein Barrierefreiheits-Test sei ein einmaliges Ereignis – einmal geprüft, Haken dran. Tatsächlich ist Barrierefreiheit ein beweglicher Zustand. Jeder neue Inhalt, jedes Theme-Update, jede umgebaute Komponente kann frische Barrieren einführen. Der WebAIM-Million-Report 2026 belegt genau diesen Effekt: Nach Jahren der Besserung stiegen die Fehlerzahlen erstmals wieder, weil Websites schneller komplexer werden, als ihre Barrierefreiheit nachzieht.

Daraus folgt: Die Prüfung gehört in den laufenden Betrieb, nicht in eine jährliche Sonderaktion. Für Entwicklungsteams lässt sich die automatische Ebene direkt in die Pipeline einbinden – ein Kommandozeilen-Werkzeug wie Pa11y, aufgerufen mit npx pa11y auf eine URL, prüft bei jedem Build und kann einen Pull Request blockieren, sobald neue Fehler auftauchen. Für die menschlichen Ebenen heißt es, in sinnvollen Abständen und nach jedem größeren Relaunch erneut zu prüfen. Wer nur einmal testet, hat ein Foto von einem Zustand, der sich am nächsten Tag schon geändert haben kann.

Websites sind nicht alles: Dokumente brauchen eigene Tests

Ein blinder Fleck vieler Teststrategien sind Dokumente. Ein Barrierefreiheits-Test der Website sagt nichts über die hunderten PDF-Rechnungen, Verträge oder Geschäftsberichte aus, die Sie zum Download anbieten. PDFs werden gegen einen eigenen Standard geprüft – PDF/UA – und mit eigenen Werkzeugen. Der verbreitetste kostenlose Prüfer ist der PDF Accessibility Checker (PAC), der ein Dokument gegen das technische Matterhorn-Protokoll testet. Aber auch hier gilt die Grundregel dieses Artikels: Der automatische Prüfer erkennt die formalen Mängel, nicht jedoch, ob die Lesereihenfolge inhaltlich Sinn ergibt. Sind solche Dokumente Teil Ihrer Dienstleistung, gehören sie zwingend in Ihre Prüfung – wie Sie die Barrierefreiheit von PDF-Dokumenten sicherstellen, ist ein Thema für sich.

Warum Overlays kein Barrierefreiheits-Test sind

Ein Wort zu einer Produktkategorie, die in diesem Zusammenhang oft missverstanden wird: Overlay-Widgets. Sie sind kein Test-Tool. Sie prüfen nichts, sondern injizieren JavaScript, das Barrieren zur Laufzeit zu überdecken versucht. Sie beheben keine Fehler im Code und können assistive Technologien sogar stören. Ein Overlay liefert Ihnen weder eine belastbare Diagnose noch eine Lösung – es ist das Gegenteil eines ehrlichen Barrierefreiheits-Tests. Wer wissen will, wo er steht, kommt um eine echte Prüfung nicht herum.

Vom Selbsttest zum belastbaren Ergebnis

Sie haben jetzt das Werkzeug, um Ihre eigene Teststrategie einzuordnen – und die naheliegende nächste Frage lautet: Wo steht meine Website konkret? Der schnellste Weg zu einer ersten Antwort ist ein automatischer Scan, also die erste der fünf Ebenen.

Genau dafür gibt es Access Score, unser kostenloses Einstiegs-Werkzeug. Es prüft Ihre Website gegen die WCAG 2.2 und übersetzt das Ergebnis in einen verständlichen Score samt konkreter Mängelliste – Code-Fehler in klares Entscheider-Deutsch, nicht in rohe Fehlercodes. Und hier liegt der Unterschied zu jedem anderen kostenlosen Scanner: Die übrigen Werkzeuge zeigen Ihnen Ihre Fehler und überlassen Sie dann sich selbst. Access Score ist der erste Schritt eines durchgängigen Wegs – von der ehrlichen Diagnose über die Behebung bis zum rechtlich belastbaren Zertifikat. Sie bekommen nicht nur einen Befund, sondern einen Anschluss.

Ich sage dabei offen, was Sie nach diesem Artikel ohnehin wissen: Ein automatischer Scan deckt die maschinell prüfbare Ebene ab, also rund 30 bis 40 Prozent. Er ersetzt keinen Screenreader-Test und kein menschliches Tiefen-Audit wie Access Ready, das die übrigen Ebenen abdeckt. Aber genau deshalb ist er der richtige Anfang: Er macht Ihren Handlungsbedarf in Minuten sichtbar, kostenlos, und zeigt Ihnen, welche Ebenen Sie als Nächstes brauchen. Verlieren Sie keine Zeit mit Raten. Testen Sie jetzt kostenlos den Status Ihrer Website – und machen Sie den ersten Schritt, der nicht im Nichts endet. Mehr Kontext zum gesamten Feld finden Sie in meinem Überblick zur digitalen Barrierefreiheit.