Accessibility Testing Tools sind Werkzeuge, die Webseiten und Anwendungen automatisiert oder teilautomatisiert auf Barrierefreiheit nach WCAG 2.2 prüfen. Sie reichen vom Linter im Editor über Engine-basierte Scanner wie axe-core bis zu Tests in der CI Pipeline und ersetzen dennoch nie die manuelle Prüfung mit echten Assistenztechnologien.

Ein professionelles Setup kombiniert daher mehrere Ebenen statt sich auf ein einziges Tool zu verlassen. Genau diese Kombination entscheidet, ob ein Produkt die Anforderungen aus dem Barrierefreiheitsstärkungsgesetz (BFSG) und dem European Accessibility Act erfüllt oder nur scheinbar grüne Werte liefert.

Wichtig zu verstehen: Automatisierte Tools sind ein Fundament, kein Freibrief. Sie gehören in jeden modernen Entwicklungsprozess, decken aber nur einen Teil der Prüfpunkte ab. Wie sich automatisiertes und manuelles Testen sinnvoll ergänzen, zeigt unser übergreifender Eintrag zum Accessibility Testing.

Never Code Alone testet seit über 15 Jahren Software auf Qualität und integriert Barrierefreiheit direkt in den Entwicklungsalltag. In unseren eigenen Frontends mit Astro, React und Vue laufen automatisierte Accessibility Tests mit dem cypress-axe Plugin fest in der CI Pipeline. Wir kennen die Tools nicht aus der Broschüre, sondern aus dem täglichen Einsatz und aus Beratungsprojekten zur BFSG Compliance.

Konkret unterstützen wir Teams beim barrierefreien Webdesign, bei der Einrichtung von axe DevTools und Cypress Accessibility Tests, beim Accessibility Audit bestehender Anwendungen, bei barrierefreien Formularen sowie bei sauberen ARIA Patterns und ausreichendem Farbkontrast. So wird aus einem grünen Testlauf echte Konformität statt einer Scheinsicherheit.

Barrierefreiheit lässt sich nicht mit einem einzigen Klick prüfen. Stattdessen greifen vier Ebenen ineinander, von der frühen statischen Analyse im Editor bis zur manuellen Prüfung mit echten Assistenztechnologien. Jede Ebene fängt andere Fehlerklassen ab, und erst ihre Kombination liefert belastbare Konformität. Das Prinzip dahinter heißt Shift Left: Je früher ein Fehler auffällt, desto günstiger ist seine Behebung.

Die folgende Tabelle ordnet die wichtigsten Tools ihrer Ebene zu und zeigt, wo sie im Workflow laufen. Die Grafik darunter visualisiert dieselben vier Ebenen als aufsteigende Testtiefe.

Die erste Ebene prüft Barrierefreiheit, bevor der Code überhaupt im Browser landet. eslint-plugin-jsx-a11y analysiert React und JSX direkt im Editor und meldet häufige Fehler wie fehlende Alt-Texte, falsche ARIA-Rollen oder Klick-Handler auf nicht-interaktiven Elementen. Das ist Shift Left in Reinform: Der Entwickler sieht das Problem in der Sekunde, in der es entsteht.

Der große Vorteil dieser Ebene ist ihr Preis. Sie kostet nahezu keine Laufzeit, läuft bei jedem Speichern und hält eine Basis an semantischem HTML und sauberen ARIA Attributen automatisch durch. Sie ersetzt aber keinen echten Browser-Test, weil sie nur den Quellcode betrachtet und nicht das gerenderte Ergebnis.

Die zweite Ebene prüft die fertig gerenderte Seite. axe-core von Deque ist die Open Source Engine, die unter vielen bekannten Werkzeugen steckt, etwa unter axe DevTools, dem Silktide Accessibility Checker und dem Stark Plugin. Lighthouse ist direkt in Chrome integriert und liefert einen schnellen Accessibility Score für den Einstieg.

Diese Tools erkennen zuverlässig technische Fehlerklassen. Dazu zählen typischerweise:

• fehlende Alt-Texte bei Bildern
• unzureichender Farbkontrast nach den Regeln der Color Accessibility
• fehlende Formular-Labels und doppelte IDs
• grundlegende ARIA-Fehler und falsche Rollen

Laut einer Deque Studie aus dem Jahr 2021 deckt die axe Engine über alle geprüften Seiten hinweg rund 57 Prozent der Accessibility Issues nach Volumen ab. Bezogen auf einzelne WCAG Erfolgskriterien liegt die automatisierte Abdeckung niedriger, bei etwa 30 bis 40 Prozent. Wer den Accessible Name einzelner Elemente nachvollziehen will, ergänzt manuelle Werkzeuge wie den ANDI Inspector.

Die dritte Ebene macht Barrierefreiheit zu einem festen Bestandteil der Qualitätssicherung. Mit dem cypress-axe Plugin läuft die axe Engine in jedem End-to-End-Test mit, sodass kein vergessenes Label und kein defektes ARIA-Attribut unbemerkt in die Produktion gelangt. Wir setzen genau dieses Setup bei Never Code Alone produktiv ein. Wie es konkret aufgesetzt wird, zeigt unsere Seite zu axe DevTools und Cypress Accessibility Testing.

Ein typischer Test sieht so aus:

Pa11y verfolgt denselben Zweck als eigenständiges CLI Tool. Es eignet sich besonders für Teams, die Accessibility Checks ohne vollen End-to-End Stack in GitHub Actions oder GitLab CI einhängen wollen. Pa11y lässt sich per Konfigurationsdatei auf ganze URL Listen ansetzen und als Quality Gate definieren, das den Build bei Verstößen abbricht.

Die vierte Ebene leistet, was keine Automatisierung kann. Echte Assistenztechnologien wie NVDA unter Windows, VoiceOver unter macOS und iOS sowie TalkBack unter Android decken die Fehler auf, die ein Scanner nie sieht. Ergänzt wird das durch konsequente Tastaturbedienung: Maus weglegen und die gesamte Seite nur mit Tab, Shift und Enter durchlaufen.

Typische Probleme, die erst der Mensch findet:

• ob ein Alt-Text inhaltlich sinnvoll ist oder nur formal existiert
• ob die Tab-Reihenfolge einer logischen Lesereihenfolge folgt
• ob ein Screenreader Statusänderungen verständlich ankündigt
• ob ein mehrstufiger Prozess mit Fehlermeldungen bedienbar bleibt

Genau hier liegt der Grund, warum die ersten drei Ebenen ein Fundament bilden und die vierte den Ausschlag gibt. Die Kombination aller vier Ebenen ist der einzige Weg zu belastbarer WCAG Konformität.

Ein grüner Score verführt zu falscher Sicherheit. Selbst wenn die axe Engine rund 57 Prozent der Issues nach Volumen findet, bleiben die komplexen 40 bis 70 Prozent übrig: Fokus-Reihenfolge, sinnvolle Screenreader-Ankündigungen und durchgängig bedienbare Interaktionen. Ein bestandener automatischer Scan bedeutet nur, dass die automatisierbaren Prüfungen bestanden wurden, nicht dass die Seite barrierefrei ist.

In NCA-Beratungsprojekten sehen wir regelmäßig Seiten mit hohem Lighthouse Score, die ein Screenreader-Nutzer trotzdem nicht bedienen kann. Deshalb behandeln wir Tools als Boden, nicht als Decke. Ein vollständiges Bild liefert erst die Kombination aus automatischem Testing, einem gründlichen Accessibility Audit als Baseline und laufendem Accessibility Testing im Alltag. Die vier Grundprinzipien dahinter fasst das POUR Modell zusammen.

In unseren Projekten ist die Toolchain kein theoretisches Modell, sondern gelebte Praxis. Wir richten cypress-axe in der Pipeline ein, definieren sinnvolle Quality Gates und verbinden den automatischen Lauf mit gezielten manuellen Checks. So fangen wir Regressionen früh ab, während die kritischen Pfade weiterhin von Menschen geprüft werden.

Wiederkehrende Baustellen sind dabei fast immer dieselben: barrierefreie Formulare mit sauberen Labels, ausreichender Farbkontrast nach WCAG, zugängliche Icons und ein dokumentierter Status über einen Accessibility Conformance Report. Wer tiefer in einzelne Werkzeuge einsteigen will, findet bei uns auch eine Anleitung zu den Firefox Accessibility Testing Tools.

Ob ein einzelnes Tool zu deinem Projekt passt, klären wir im Rahmen unseres Accessibility Webdesign Consultings. Wir empfehlen nichts, was wir nicht selbst im Einsatz haben, und ordnen jedes Werkzeug ehrlich nach Stärken und Grenzen ein.

Die folgenden Antworten beruhen auf den aktuellen WCAG 2.2 Vorgaben, dem Barrierefreiheitsstärkungsgesetz und unserer eigenen Praxis aus Beratungsprojekten.