NCA Social Media
Dunkles Browser-Fenster mit Schriftzug Accessibility Testing und grüner Rakete

Was sind Accessibility Testing Tools?

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.

Accessibility Testing Tools mit NCA: Schnelle Hilfe vom Experten

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.

Lass uns sprechen

Finde das passende Angebot für dein Projekt

🤖

Hey! Ich bin CodeBot. Lass uns herausfinden, wie wir dein Projekt zum Fliegen bringen.

Was soll entstehen?

Die vier Ebenen der Accessibility Testing Toolchain

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.

Accessibility Testing Tools nach Ebene 2026

Ebene Tools Wo es läuft
Ebene 1: Statische Analyse eslint-plugin-jsx-a11y Editor und Pre Commit, Shift Left
Ebene 2: Engine Scan axe-core, Lighthouse Lokaler Browser, DevTools
Ebene 3: CI Integration cypress-axe, Pa11y Pipeline und Quality Gate
Ebene 4: Manuelle Prüfung NVDA, VoiceOver, TalkBack Mensch, kritische User Journeys
Säulendiagramm vier Accessibility Testing Ebenen aufsteigend Static bis Manual

Ebene 1: Statische Analyse mit eslint-plugin-jsx-a11y

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.

Code:
          

npm install --save-dev eslint-plugin-jsx-a11y

# .eslintrc: Plugin aktivieren
# "extends": ["plugin:jsx-a11y/recommended"]

Ebene 2: Engine Scan mit axe-core und Lighthouse

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.

Ebene 3: cypress-axe und Pa11y in der CI Pipeline

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:

Code:
          

import 'cypress-axe'

describe('Startseite Barrierefreiheit', () => {
  it('hat keine WCAG Verstöße', () => {
    cy.visit('/')
    cy.injectAxe()
    cy.checkA11y()
  })
})

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.

Code:
          

npm install -g pa11y
pa11y https://example.com

# mehrere URLs als Quality Gate
npx pa11y-ci --sitemap https://example.com/sitemap.xml

Ebene 4: Manuelle Prüfung mit Screenreadern und Tastatur

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.

Grenzen der Automatisierung: Fundament statt Freibrief

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.

Manual testing is a necessity for accessibility.

Marcy Sutton, Developer Advocate, Deque Systems – Deque Blog

Accessibility Testing Tools in NCA Projekten

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.

CYPRESS.IO Ambassador und IT Consultant für QA Engenieering und Qualität in PHP Projekten.

Erreichen Sie unsere Spezialisten zu barrierefreien Webdesign

Wir sind hier, um Ihnen zu helfen. Gemeinsam meistern wir Ihre digitalen Herausforderungen und fördern die Inklusion im Internet. Lassen Sie uns Ihre Projekte mit barrierefreiem Webdesign erfolgreich machen.

Häufige Fragen zu Accessibility Testing Tools

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

Welche Accessibility Testing Tools sind 2026 Standard?

Der Standard 2026 ist eine Kombination aus vier Ebenen: eslint-plugin-jsx-a11y für die statische Analyse, axe-core und Lighthouse für Engine-Scans, cypress-axe oder Pa11y für die CI Pipeline und Screenreader wie NVDA oder VoiceOver für die manuelle Prüfung. Kein einzelnes Tool deckt alles ab, erst das Zusammenspiel liefert verlässliche WCAG Konformität.

Lohnt sich automatisiertes Accessibility Testing 2026?

Ja. Automatisierte Tests verhindern, dass bekannte Fehlerklassen wie fehlende Alt-Texte oder Kontrastprobleme unbemerkt in die Produktion gelangen. Sie laufen bei jeder Code-Änderung, kosten kaum Laufzeit und schützen vor Regressionen. Seit dem Barrierefreiheitsstärkungsgesetz ist Barrierefreiheit für viele Unternehmen ohnehin Pflicht, automatisierte Tests sind dafür ein effizientes Fundament.

Wie viel Prozent der Fehler finden Tools 2026?

Laut einer Deque Studie aus 2021 deckt die axe Engine 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. Die restlichen Prüfpunkte wie Fokus-Reihenfolge und Screenreader-Ankündigungen erfordern manuelle Tests.

Welches Tool eignet sich 2026 für die CI Pipeline?

Für Teams mit Cypress ist das cypress-axe Plugin die naheliegende Wahl, weil es Accessibility direkt in bestehende End-to-End-Tests integriert. Ohne Cypress eignet sich Pa11y als Kommandozeilen-Tool, das URLs direkt in GitHub Actions oder GitLab CI prüft. Beide brechen den Build bei einer Regression und wirken so als Quality Gate.

Ersetzen Accessibility Tools 2026 die manuelle Prüfung?

Nein. Automatisierte Tools sind ein Fundament, kein Freibrief. Sie erkennen technische Fehler zuverlässig, können aber nicht beurteilen, ob ein Alt-Text sinnvoll ist, ob die Tab-Reihenfolge logisch wirkt oder was ein Screenreader tatsächlich ankündigt. Diese Prüfpunkte verlangen echte Assistenztechnologien und menschliches Urteil.

Was ist axe-core?

axe-core ist eine Open Source Engine von Deque, die Webseiten programmatisch auf Barrierefreiheit prüft. Sie steckt unter vielen bekannten Werkzeugen wie axe DevTools, dem Silktide Checker und cypress-axe. Die Engine ist flexibel konfigurierbar und gilt als Industriestandard für automatisierte WCAG Prüfungen.

Was ist der Unterschied zwischen axe-core und Lighthouse?

Lighthouse ist direkt in Chrome integriert und liefert einen schnellen Accessibility Score samt Performance- und SEO-Werten, ideal für den Einstieg. axe-core ist eine spezialisierte Engine, die sich tief in Test-Frameworks und CI Pipelines einbinden lässt. Lighthouse nutzt intern ebenfalls Regeln aus dem axe Umfeld, ist aber weniger granular steuerbar.

Was ist Pa11y?

Pa11y ist ein Open Source Kommandozeilen-Tool, das einzelne URLs oder ganze Sitemaps automatisiert auf Barrierefreiheit prüft. Es eignet sich besonders für CI Pipelines ohne bestehendes Cypress Setup. Mit pa11y-ci lassen sich mehrere Seiten als Quality Gate testen, sodass der Build bei Verstößen fehlschlägt.

Was macht eslint-plugin-jsx-a11y?

Das Plugin prüft React und JSX bereits im Editor auf häufige Accessibility-Fehler, etwa fehlende Alt-Texte, falsche ARIA-Rollen oder Klick-Handler auf nicht-interaktiven Elementen. Es arbeitet rein statisch auf dem Quellcode und meldet Probleme, bevor der Code im Browser läuft. Damit ist es der Shift-Left-Baustein der Toolchain.

Funktioniert cypress-axe mit jeder Projektgröße?

Ja. cypress-axe ist in wenigen Minuten eingerichtet, Open Source und für jede Projektgröße flexibel. Es ergänzt bestehende Cypress Tests um Accessibility-Checks, ohne den Workflow umzubauen. Gerade bei großen Teams und häufigen Deployments verhindert es, dass Barrierefreiheits-Regressionen unbemerkt live gehen.

Welche Screenreader sollte ich zum Testen nutzen?

Für realistische Tests empfehlen sich die verbreiteten Screenreader pro Plattform: NVDA unter Windows, VoiceOver unter macOS und iOS sowie TalkBack unter Android. Wichtig ist, mindestens einen Screenreader regelmäßig im echten Bedienfluss zu nutzen statt nur die automatische Ausgabe zu lesen. Ergänzend gehört die reine Tastaturbedienung zu jedem manuellen Test.

Sind Accessibility Tests wegen BFSG Pflicht?

Das Barrierefreiheitsstärkungsgesetz schreibt seit Juni 2025 für viele B2C-Angebote barrierefreie digitale Produkte vor und verweist technisch auf die Norm EN 301 549, die auf WCAG aufbaut. Das Gesetz fordert keine bestimmten Tools, aber automatisierte und manuelle Tests sind der praktikable Weg, die geforderte Konformität nachzuweisen und zu halten.

A11Y

Was ist A11Y? Definition, WCAG 2.2, BFSG-Pflichten und technische Umsetzung fuer barrierefreie Websites 2026.

Accessibility Audit

Was ist ein Accessibility Audit? Ablauf, Tools, WCAG-Stufen und BFSG-Anforderungen 2026 – mit 12 FAQs und Praxis-Tipps für PHP-Projekte.

Accessibility Testing

Was ist Accessibility Testing? Drei Ebenen, Cypress/axe-core Integration, manuelle Checkliste und BFSG-Konformität 2026.

Accessible Forms

Was sind Accessible Forms? HTML-Attribute, ARIA, Fehlermeldungen und BFSG-konforme Implementierung barrierefreier Formulare 2026.

ACR (Accessibility Conformance Report)

Was ist ein ACR? Accessibility Conformance Report nach VPAT 2.5 mit WCAG 2.2 und EN 301 549 als BFSG-konformer Compliance-Nachweis für digitale Produkte 2026.

Alternative Eingabegeräte

Alternative Eingabegeräte ermöglichen Menschen mit motorischen Einschränkungen die selbstständige Nutzung digitaler Systeme. NCA erklärt Typen, WCAG Anforderungen und Umsetzung 2026.

Alternativtext (Alt-Text)

Was ein guter Alt Text 2026 leistet, wie er BFSG und WCAG erfüllt, welche KI Tools helfen und welche Fehler du vermeiden solltest. Im NCA Glossar.

Americans with Disabilities Act (ADA)

Der ADA verpflichtet auch deutsche Unternehmen mit US-Geschäft zur digitalen Barrierefreiheit nach WCAG 2.1 Level AA. Pflichten, Klagerisiko und Vergleich zu EAA und BFSG.

Audiodeskription (AD)

Audiodeskription 2026: was AD ist, wie sie BFSG und WCAG erfüllt, wann sie Pflicht ist und wie du Videos zugänglich machst. Im NCA Glossar.

CAPTCHA

Klassische CAPTCHAs blockieren Nutzer mit Behinderungen und gefährden die BFSG Konformität. Friendly Captcha, Cloudflare Turnstile und Altcha im Vergleich 2026.

Cascading Style Sheets (CSS)

CSS gestaltet barrierefreie Webseiten. Mit WCAG 2.2, focus-visible, prefers-reduced-motion und relativen Einheiten erreichst du Compliance und bessere UX für alle.

Color Accessibility

Erfahren Sie, wie Color Accessibility die Zugänglichkeit von digitalen Inhalten durch bewusste Farbwahl und Kontraste verbessert.

Compliance (Konformität)

Erfahren Sie, was Compliance im Kontext der digitalen Barrierefreiheit bedeutet und wie Sie sicherstellen können, dass Ihre digitalen Produkte und konform sind.

Contrast Enhancement

Lernen Sie, was Contrast Enhancement bedeutet und wie es beiträgt, die Lesbarkeit von Texten für Menschen mit Sehbehinderungen zu verbessern.

Digitale Barrierefreiheit (DA)

Erfahren Sie, was digitale Barrierefreiheit bedeutet und wie Sie sicherstellen können, dass Ihre digitalen Inhalte für alle zugänglich sind.

Diktieren (Dictation)

Entdecken Sie, wie Diktieren die digitale Barrierefreiheit verbessert, indem es Nutzern ermöglicht, Text durch Spracheingabe zu generieren.

European Accessibility Act (EAA)

Der European Accessibility Act revolutioniert die digitale Barrierefreiheit in der EU. Erfahren Sie, wie Sie die gesetzlichen Anforderungen bis 2025 meistern.

Farbkontrast

Erfahre, was Farbkontrast ist, die Bedeutung für die digitale Barrierefreiheit und wie Sie sicherstellen können, dass Ihre digitalen Inhalte zugänglich sind.

Headless

Erfahren Sie, wie die Trennung von Backend und Frontend die Entwicklung agiler, anpassungsfähiger digitaler Erlebnisse ermöglicht.

Keyboard Navigation

Erfahren Sie, was Keyboard Navigation bedeutet und wie sie die Zugänglichkeit von Webseiten durch die reine Nutzung der Tastatur verbessert.

Konformität (Conformance)

Vertiefen Sie Ihr Verständnis von Konformität im Kontext der digitalen Barrierefreiheit, entdecken Sie, warum sie entscheidend ist.

Leichte Sprache und Einfache Sprache

Erfahren Sie mehr über Leichte und Einfache Sprache, zwei wichtige Formen der sprachlichen Vereinfachung, die darauf abzielen, Texte für Menschen zugänglicher zu machen.

Lupe (Magnification) und Digitale Barrierefreiheit

Erfahren Sie alles über die Nutzung von Lupenfunktionen zur Verbesserung der digitalen Barrierefreiheit, entdecken Sie, wie Vergrößerungswerkzeuge die Zugänglichkeit erhöhen, und lernen Sie Best Practices für die Implementierung in digitalen Inhalten kennen.

Offene Beschriftungen (Open Captions) und Digitale Barrierefreiheit

Entdecken Sie, wie offene Beschriftungen (Open Captions) die Zugänglichkeit von Videoinhalten verbessern, indem sie eine permanente Untertitelung bieten, die für alle Zuschauer sichtbar ist, und lernen Sie, wie Sie Open Captions effektiv in Ihren digitalen Medien einsetzen können.

Operabilität in der Digitalen Barrierefreiheit

Entdecken Sie, warum Operabilität ein Schlüsselaspekt der digitalen Barrierefreiheit ist, und lernen Sie, wie Sie sicherstellen können, dass Ihre digitalen Inhalte und Anwendungen für alle Nutzer bedienbar sind.

Responsive Design

Erfahren Sie, was Responsive Design ist und wie es durch flexible und adaptive Layouts die Zugänglichkeit von Webseiten verbessert.

Semantic HTML

Erfahren Sie, was Semantic HTML ist und wie es die Webzugänglichkeit durch verbesserte Strukturierung und Bedeutung von Webinhalten unterstützt.

Silktide Accessibility Checker

Entdecken Sie, wie der Silktide Accessibility Checker Ihre Website WCAG-konform und zugänglich für alle macht. Umfassende Prüfungen, einfache Lösungen.

Stark

Stark: Die All-in-One-Plattform für digitale Barrierefreiheit. Beschleunigen Sie Compliance und Workflows mit integrierten Tools für Designer und Entwickler.

Text-to-Speech

Erfahren Sie, was Text-to-Speech ist, wie es funktioniert und wie es digitale Zugänglichkeit für Menschen mit Sehbehinderungen oder Leseschwierigkeiten erhöht.

Universal Design

Entdecken Sie, wie Universal Design hilft, Produkte, Umgebungen und digitale Medien für alle Menschen nutzbar zu machen.

Untertitel für Hörgesschädigte

Erfahren Sie, was Closed Captions sind und wie sie die Zugänglichkeit von audiovisuellen Medien für Gehörlose und Schwerhörige verbessern.

Voice Recognition

Erfahren Sie mehr über Voice Recognition und wie sie die Interaktion mit digitalen Geräten für Menschen mit verschiedenen Behinderungen vereinfacht.