Beste Tools zum Testen der Web-Barrierefreiheit: Top-Picks im Vergleich (2026)

Tools zum Testen der Web-Barrierefreiheit erkennen nur etwa ein Drittel der WCAG-Erfolgskriterien automatisch, sodass kein einzelnes Tool bestätigen kann, dass eine Website barrierefrei ist. Die minimal praktikable Kombination ist eine Browser-Erweiterung wie ax DevTools oder WAVE, ein Pipeline-Linter wie axe-core, Pa11y oder Lighthouse CI und manuelles Testen mit einem Bildschirmleser und einer Tastatur, da der Referenzstandard WCAG 2.2 ist.

Wenn Sie Websites in XHTML/CSS entwickeln und WCAG einhalten müssen, werden Sie früher oder später mit der gleichen Frage konfrontiert: Welche Tools zum Testen der Barrierefreiheit im Web verdienen einen Platz in Ihrem Workflow? Die kurze Antwort lautet: Kein Tool erkennt alles, und wenn Sie sich auf ein einziges Tool verlassen, können Sie am schnellsten glauben, dass Ihre Website zugänglich ist, obwohl dies in Wirklichkeit nicht der Fall ist. Die lange Antwort – welche entscheidend ist – hängt von der Art der Barriere ab, die Sie erkennen möchten, in welcher Entwicklungsphase Sie sich befinden und wie viel Zeit Sie für die manuelle Überprüfung aufwenden können.

Dieser Artikel vergleicht die wichtigsten Tools für spanischsprachige Entwickler, erklärt, was jedes einzelne erkennt, wo es versagt und wie man sie kombiniert, um die WCAG 2.2-Kriterien realistisch abzudecken. Dabei handelt es sich nicht um eine „Top 10“-Liste ohne Kriterien, sondern um eine Entscheidungshilfe.

Wichtige Erkenntnisse

• Kein automatisiertes Tool erkennt mehr als einen Bruchteil der WCAG-Kriterien. Typische Branchenschätzungen gehen davon aus, dass die automatische Abdeckung etwa ein Drittel der Erfolgskriterien ausmacht; der Rest erfordert eine menschliche Überprüfung.
• Die minimal praktikable Kombination von Tools zum Testen der Web-Barrierefreiheit ist: eine Browser-Erweiterung zur Stichprobenprüfung (Axe DevTools oder WAVE), ein in die Pipeline integrierter Linter (Axe-Core, Pa11y oder Lighthouse CI) und manuelle Tests mit Screenreader und Tastatur.
• Kontrast- und Strukturtools (wie die in den DevTools des Browsers integrierten) lösen konkrete Probleme schnell, ersetzen jedoch kein Audit.
• Der Referenzstandard ist WCAG 2.2, veröffentlicht vom W3C, mit den Stufen A, AA und AAA. Die meisten Gesetze erfordern AA.
• Automatisieren Sie das Wiederholen, humanisieren Sie das Komplexe. Formulare, interaktive Widgets und Fokusreihenfolge erfordern fast immer eine manuelle Überprüfung.

Welche Tools zum Testen der Web-Barrierefreiheit erkennen können und welche nicht

Bevor Sie Werkzeuge vergleichen, ist es hilfreich, die Grenzen zu kennen. Ein automatisches Tool analysiert das DOM, das berechnete CSS und in einigen Fällen den Barrierefreiheitsbaum. Es kann Folgendes zuverlässig erkennen:

• Unzureichender Farbkontrast (wenn die Hintergrundfarbe einfarbig und bekannt ist).
• Fehlende „Alt“-Attribute auf Bildern.
• Fehlende oder schlecht zugeordnete Formularbeschriftungen.
• Unterbrochene Überschriftenhierarchie oder Ebenensprünge.
• Ungültige oder missbrauchte ARIA-Attribute (nicht vorhandene Rollen, „aria-*“ ohne die entsprechende Rolle).
• Links mit leerem oder generischem Text.
• „lang“ fehlt im „html“-Element.
• Interaktive Elemente sind in bestimmten Fällen nicht über die Tastatur zugänglich.

Was es nicht zuverlässig erkennen kann:

• Wenn ein Alternativtext in seinem Kontext angemessen ist (er erkennt nur, dass er existiert).
• Ob die Tab-Reihenfolge einen logischen Sinn hat.
• Ob eine Fehlermeldung einem Screenreader korrekt angezeigt wird.
• Wenn der Inhalt eine verständliche semantische Struktur hat.
• Wenn sich benutzerdefinierte Widgets (Comboboxen, Schieberegler, Menüs) wie vom Benutzer der unterstützenden Technologie erwartet verhalten.
• Die Qualität des Erlebnisses mit 400 % Zoom oder mit vergrößertem Text.

Diese Unterscheidung ist diejenige, die ein echtes Audit von einem „bestandenen Validator“ unterscheidet. Das W3C unterhält eine offizielle Seite zur Einhaltung der WCAG, deren Verfügbarkeit nützlich ist.

Verwandte: accessiBe — Superposición de IA, das die WCAG seit 48 Stunden unterstützt.

Tool-Vergleich nach Kategorien

Diese Tabelle enthält die wichtigsten Tools zum Testen der Barrierefreiheit im Web:

Tool	Typ	Ideal für	Abdeckung	Kosten
ax DevTools	Browser-Erweiterung	Punktuelle Inspektion, Entwickler	Hoch bei automatischen Regeln	Gratis (Basisversion)
WAVE	Erweiterung / Web	Schnelle visuelle Überprüfung, Dozenten	Mittel-hoch, sehr visuell	Gratis
Lighthouse	Integriert in Chrome / CI	Performance + Barrierefreiheit im Audit	Mittel	Gratis
axe-core	JS-Bibliothek	Integration in Tests und CI	Hoch, Motor vieler anderer	Kostenlos (Open Source)
Pa11y	CLI / CI	Automatisierung in Pipeline	Mittel-hoch	Kostenlos (Open Source)
IBM Equal Access	Erweiterung / CI	Breite Abdeckung, detaillierte Berichte	Hoch	Gratis
Einblicke in die Barrierefreiheit	Erweiterung / Escritorio	Guía paso a paso para revisión handbuch	Alta + Assistenzhandbuch	Kostenlos (Microsoft)
NVDA / VoiceOver	Screenreader	Echte manuelle Tests	Nicht anwendbar (manuell)	Gratis

Die Tools im Einzelnen

ax DevTools

Dies ist wahrscheinlich der üblichste Ausgangspunkt für Tools zum Testen der Barrierefreiheit im Internet. Es funktioniert als Erweiterung für Chrome, Firefox und Edge und basiert auf der axe-core-Engine, die Open Source ist und in viele andere Tools (einschließlich Lighthouse) integriert ist. Sein großer Vorteil besteht darin, Fehlalarme zu reduzieren: Wenn etwas gemeldet wird, handelt es sich normalerweise um ein echtes Problem.

Es erkennt gut Kontrast, ARIA, Überschriftsstruktur, Formen und Orientierungspunkte. Seine Einschränkung ist die gleiche wie bei allen anderen: Es bewertet weder die semantische Qualität noch die Erfahrung mit einem Bildschirmlesegerät. Die kostenlose Version deckt die meisten Bedürfnisse eines einzelnen Entwicklers ab; Kontinuierliche Überwachungsfunktionen und Teamberichte sind in kostenpflichtigen Plänen enthalten.

Einen Blick wert: UserWay — Widget für den kostenlosen Zugang mit Plan, damit Sie noch heute dort arbeiten können.

WAVE (WebAIM)

WAVE von WebAIM verfolgt einen sehr visuellen Ansatz: Es überlagert Symbole auf der Seite, um auf Fehler, Warnungen, korrekte Elemente und manuelle Überprüfungspunkte hinzuweisen. Es eignet sich hervorragend zum Unterrichten von Barrierefreiheit oder für einen schnellen ersten Durchgang, da es das Problem im Kontext zeigt.

Sein Schwachpunkt besteht darin, dass es viel „Lärm“ erzeugt: Bei vielen Warnungen handelt es sich um Warnungen, die menschliche Kriterien erfordern. Dennoch erleichtert es Anfängern das Verständnis erheblich, wenn sie die Symbole auf der Seite selbst sehen.

Leuchtturm

Lighthouse ist in Chrome DevTools integriert und kann auch über die Befehlszeile oder in CI ausgeführt werden. Bei der Prüfung der Barrierefreiheit wird Axe-Core verwendet, sodass die Regeln denen von Axe DevTools ähneln, der Bericht jedoch oberflächlicher ist und darauf ausgelegt ist, eine schnelle Bewertung zu liefern.

Nutzen Sie es als Ampel bei der kontinuierlichen Integration, nicht als Audit. Eine Punktzahl von 100 in Lighthouse bedeutet nicht, dass die Website zugänglich ist; Dies bedeutet, dass keine automatischen Probleme erkannt wurden.

Axe-Core und Pa11y für die Pipeline

Hier liegt der wahre Wert für Teams. axe-core ist eine JavaScript-Bibliothek, die Sie in Tests mit Jest, Playwright oder Cypress aufrufen können. Pa11y ist ein Befehlszeilentool, das Analysen für URLs durchführt und Ergebnisse in verschiedenen Formaten zurückgibt, ideal für die Integration in eine CI-Pipeline.

Der Vorteil der Automatisierung in CI besteht darin, dass Sie Regressionen vermeiden: Wenn jemand ein Bild ohne „Alt“ einführt oder den Kontrast unterbricht, schlägt der Build fehl. Der Nachteil besteht darin, dass es nur den automatischen Teil abdeckt und somit die manuelle Überprüfung nicht ersetzt, sondern diese lediglich ergänzt.

Verwandte: IAAP CPACC / WAS Certification — Die professionelle Zertifizierung erfordert Erfahrung und Zugang.

IBM Equal Access Accessibility Checker

Weniger bekannt als Axe, aber mit breiter Abdeckung und eigenen Regeln. Es bietet eine Browser-Erweiterung und eine Version für CI. Der Bericht unterscheidet zwischen Problemen und „Bedarfsüberprüfung“, was ehrlich und nützlich ist. Es ist eine gute zweite Meinung, wenn Sie die Ergebnisse mit axe vergleichen möchten.

Einblicke in die Barrierefreiheit (Microsoft)

Seine Stärke liegt darin, dass es die manuelle Überprüfung anleitet. Neben der automatischen Analyse bietet es einen „Assessment“-Modus, der Sie Schritt für Schritt durch die WCAG-Kriterien führt, mit konkreten Anweisungen, was wie zu prüfen ist. Für diejenigen, die lernen möchten, wie man wirklich auditiert, ist es eine der besten kostenlosen Optionen.

Screenreader: Der Test, den kein Tool ersetzt

NVDA (Windows, kostenlos) und VoiceOver (macOS/iOS, integriert) sind die Tools, die die Probleme aufdecken, die kein Analysegerät erkennt: verwirrende Lesereihenfolge, Steuerelemente, die ihren Status nicht bekannt geben, und Fehlermeldungen, die unbemerkt bleiben. Das Erlernen der Grundlagen eines Screenreaders ist für jeden Entwickler, der an Barrierefreiheit arbeitet, die Investition mit der höchsten Rendite.

Einen Blick wert: Deque axe DevTools Pro — Der Stand der Technik dient dazu, die Zugänglichkeit während der Fahrt zu testen.

So entscheiden Sie: praktische Kriterien

Wenn Sie sich für Tools zum Testen der Barrierefreiheit im Web entscheiden müssen, stellen Sie sich diese Fragen:

1. Arbeiten Sie alleine oder im Team? Einzelperson: Browsererweiterung + Screenreader. Team: CI mit axe-core oder Pa11y hinzufügen.
2. In welcher Phase befinden Sie sich? Lintern Sie während der Entwicklung den Editor und die Erweiterung. Vor der Veröffentlichung erfolgt eine vollständige Prüfung mit Accessibility Insights. In der Produktion kontinuierliche Überwachung.
3. Welche Vorschriften gelten? Wenn Sie bestimmte Gesetze einhalten müssen (z. B. die europäische Web-Barrierefreiheitsrichtlinie oder Abschnitt 508 in den USA), überprüfen Sie, ob das Tool seine Ergebnisse den entsprechenden WCAG-Kriterien zuordnet.
4. Wie hoch ist das Budget? Alle genannten Anbieter verfügen über eine funktionsfähige kostenlose Version. Die kostenpflichtigen bieten zusätzlich Berichte, Überwachung und Zusammenarbeit, nicht unbedingt eine bessere Erkennung.

Ein realistischer Ablauf für eine XHTML/CSS-Site könnte sein: Entfernen von DevTools während der Entwicklung, Pa11y in CI, Accessibility Insights vor jeder wichtigen Veröffentlichung und eine Sitzung mit NVDA oder VoiceOver für kritische Abläufe (Anmeldung, Formulare, Navigation).

Es treten Fehler bei der Verwendung dieser Werkzeuge auf

• Glauben, dass „null Fehler“ gleichbedeutend mit Zugänglichkeit sind. Falsch. Dies bedeutet lediglich, dass diese Tools zum Testen der Web-Barrierefreiheit keine automatischen Probleme erkannt haben.
• Warnungen ignorieren. Viele Tools trennen Fehler von Warnungen; Warnungen liegen oft dort, wo die eigentlichen Probleme liegen.
• Nicht mit der Tastatur getestet. Das Durchblättern der Seite zeigt Fokusprobleme, die keine Erweiterung gut signalisiert.
• Zoom und erweiterter Text vergessen. Test bei 200 % und 400 %; Reflow ist ein relevantes WCAG 2.2-Kriterium.
• Automatisieren ohne zu verstehen. Ein bestandener Test bringt nichts, wenn Sie nicht wissen, was er überprüft.

Fazit

Die besten Tools zum Testen der Barrierefreiheit im Web sind nicht diejenigen mit den meisten Funktionen, sondern diejenigen, die in Ihren Arbeitsablauf passen und Sie dazu drängen, den manuellen Teil zu erledigen. Beginnen Sie mit axe DevTools oder WAVE für die offensichtlichen Probleme, automatisieren Sie mit axe-core oder Pa11y, um Regressionen zu vermeiden, und nehmen Sie sich Zeit für Tests mit der Tastatur und dem Bildschirmleser. Diese Kombination bringt eine Website, mehr als jedes isolierte Tool, der tatsächlichen Einhaltung der WCAG näher.

Quellen und weiterführende Literatur

• Web-Barrierefreiheit – Wikipedia: Web-Barrierefreiheit oder eAccessibility ist die umfassende Praxis, sicherzustellen, dass es keine Barrieren gibt, die die Interaktion mit oder den Zugriff auf Websites auf der Welt verhindern …

Häufig gestellte Fragen

Ist das die beste kostenlose Software zum Testen der Web-Zugangsberechtigung?

Unter den Tools zum Testen der Web-Barrierefreiheit gibt es kein einzelnes bestes Tool, da jedes unterschiedliche Dinge abdeckt. Für die Stichprobenkontrolle werden axe DevTools und WAVE am häufigsten verwendet und sind kostenlos. Zur Automatisierung in CI sind axe-core und Pa11y Open Source und sehr zuverlässig. Um das manuelle Auditieren zu erlernen, ist Microsofts Accessibility Insights in seiner kostenlosen Version schwer zu schlagen.

¿Lasst die automatische Steuerung alle Probleme mit der Zugänglichkeit erkennen?

Nein. Sie erkennen einen Teil der WCAG-Kriterien, hauptsächlich diejenigen, die sich auf Attribute, Kontrast und Struktur beziehen. Probleme wie die Fokusreihenfolge, die Qualität des Alternativtexts oder das Verhalten benutzerdefinierter Widgets erfordern eine menschliche Überprüfung mit der Tastatur und dem Bildschirmlesegerät.

Was ist der Unterschied zwischen WCAG 2.1 und WCAG 2.2?

WCAG 2.2 fügt im Vergleich zu 2.1 neue Erfolgskriterien hinzu, die sich hauptsächlich auf die Interaktion mit dem Zeiger, den Fokus und Eingabehilfen konzentrieren. Die Level A, AA und AAA werden beibehalten. Die meisten Rechtsvorschriften erfordern weiterhin die Stufe AA, und es ist ratsam, zu prüfen, auf welche Version sich die für Sie geltende Verordnung bezieht.

Können Zugriffstests in meine CI-Pipeline integriert werden?

Ja, es ist sehr zu empfehlen. Mit Tools wie axe-core (über Playwright, Cypress oder Jest) und Pa11y können Sie bei jedem Build eine automatische Analyse durchführen und scheitern, wenn Regressionen erkannt werden. Sie decken nur die automatischen Teile ab, verhindern aber, dass bereits gelöste Probleme erneut auftreten.

Müssen Sie einen Bildschirmlektor verwenden?

Wenn Sie ernsthaft an Barrierefreiheit arbeiten, ja. NVDA unter Windows und VoiceOver unter macOS sind kostenlos und reichen aus, um Probleme zu erkennen, die keine Erweiterung erkennt. Sie müssen kein Experte sein: Die Kenntnis der grundlegenden Navigation anhand von Überschriften, Links und Formularen liefert bereits wertvolle Informationen.

Garantiert eine hohe Lighthouse-Punktzahl, dass meine Website barrierefrei ist?

Nein. Lighthouse verwendet darunter Axe-Core und wertet nur automatische Regeln aus. Eine Punktzahl von 100 bedeutet, dass keine automatischen Probleme erkannt wurden und nicht, dass die Website den WCAG entspricht. Die tatsächliche Konformität erfordert zusätzliche manuelle Tests.