Wer eine Website auf Barrierefreiheit testen will, braucht drei Ebenen: automatisierte Prüfungen in der Pipeline, manuelle Expertenprüfung und einen Durchlauf mit assistiver Technologie. Werkzeuge decken nur einen Teil der WCAG-Kriterien ab, deshalb ersetzt kein Scan die menschliche Bewertung. Wie groß das Problem in der Praxis ist, zeigt die WebAIM Million 2026: Auf 95,9 Prozent der untersuchten Startseiten fanden sich automatisch erkennbare WCAG-Verstöße, im Schnitt 56,1 pro Seite (WebAIM, 2026). Dieser Leitfaden beschreibt den Testablauf Schritt für Schritt, vergleicht die gängigen Werkzeuge und zeigt, welcher Teil davon in eine CI/CD-Pipeline gehört.

Kurz gefasst: Wer eine Website auf Barrierefreiheit testen will, kombiniert automatisierte Scans, manuelle Prüfung und Tests mit assistiver Technologie. Werkzeuge wie axe-core finden vor allem Kontrast-, Alt-Text- und Label-Fehler. Sechs Fehlerarten machen 96 Prozent aller erkannten Fehler aus (WebAIM, 2026). Alles, was Bedeutung, Reihenfolge und Verständlichkeit betrifft, bleibt manuell.

Abbildung 1: Der Testablauf in sechs Schritten.

Wie testet man eine Website auf Barrierefreiheit?

Sie können eine Website auf Barrierefreiheit testen, indem Sie drei Ebenen kombinieren: automatisierte Regelprüfungen im Build, manuelle Prüfschritte durch geschulte Tester und einen Durchlauf mit assistiver Technologie. Jede Ebene findet Fehler, die die anderen beiden nicht sehen.

• Automatisiert: Regel-Engines prüfen das gerenderte DOM auf maschinell entscheidbare Verstöße, etwa fehlende Alternativtexte, unbeschriftete Formularfelder oder zu geringen Kontrast.

• Manuell: Ein Prüfer bewertet Fokusreihenfolge, den Sinn von Alternativtexten, die Überschriftenlogik und das Verhalten komplexer Widgets.

• Assistive Technologie: Bedienung nur mit der Tastatur, Durchlauf mit einem Screenreader, Vergrößerung und Reflow.

Das britische GOV.UK Service Manual fasst die Aufteilung in einem Satz zusammen:

„It’s important to do both types of testing - you’ll miss some issues if you only do automated testing.” (GOV.UK Service Manual, 2026)

Welche Anteile überhaupt automatisierbar sind, ordnet der Überblick zum Barrierefreiheitstesting ein.

Wie läuft ein Barrierefreiheitstest Schritt für Schritt ab?

Barrierefreiheit testen Sie in acht Schritten, von der Seitenauswahl bis zum priorisierten Bericht. Der automatisierte Scan kommt zuerst, damit teure manuelle Prüfzeit nicht für Kontrastwerte draufgeht.

1. Prüfumfang festlegen. Das BIK-Prüfverfahren nennt als Orientierung: „Die Minimalanzahl bei einfachen, kleinen und einheitlich gestalteten Webangeboten sind drei Seiten, bei komplexen Angeboten können es 5-10 oder auch mehr Seiten sein.” (BIK BITV-Test, 2026)

2. Automatisierten Scan fahren. Über alle ausgewählten Seiten und über die relevanten Seitenzustände, nicht nur über den Initialzustand.

3. Befunde triagieren. Eindeutige Verstöße ins Backlog, unsichere Ergebnisse an einen Menschen.

4. Tastaturdurchlauf. Die komplette Funktionalität ohne Maus bedienen, Fokus immer sichtbar, keine Fokusfallen.

5. Screenreader-Durchlauf. Formulare, Fehlermeldungen, Dialoge und Live-Regionen abgehen.

6. Zoom und Reflow. Fenster auf 1280 x 1024, Browserzoom auf 400 Prozent, jede Seite auf Verluste prüfen.

7. Kontrast messen. SC 1.4.3 verlangt für Text mindestens 4,5:1, mit Ausnahmen für große Schrift, dekorative Elemente und Logos (W3C Quick Reference, 2026).

8. Bericht und Nachprüfung. Nach Schweregrad priorisieren, Fixes umsetzen, den Ablauf für die betroffenen Seiten wiederholen.

Welche Werkzeuge gibt es für automatisierte Prüfungen?

Fünf Werkzeuge decken den größten Teil der automatisierten Praxis ab. Sie prüfen unterschiedliche Regelsätze und liefern deshalb unterschiedliche Ergebnisse für dieselbe Seite.

axe-core fährt eine strenge Linie bei Falschmeldungen. Im Repository steht: „It returns zero false positives (bugs notwithstanding).” Der Preis dafür: Wo die Engine nicht sicher entscheiden kann, markiert sie den Fall als incomplete und übergibt ihn an einen menschlichen Prüfer (Deque, 2026).

Lighthouse benennt seine Grenze im eigenen Quellcode, und derselbe Satz steht in jedem Report: „Automatic detection can only detect a subset of issues and does not guarantee the accessibility of your web app, so manual testing is also encouraged.” (Google Lighthouse, 2026)

Was finden automatisierte Werkzeuge nicht?

Abbildung 2: Sechs Fehlerarten stehen fuer 96 Prozent aller erkannten Fehler.

Automatisierte Werkzeuge finden formale Fehler und verfehlen alles, was Bedeutung und Kontext betrifft. Die WebAIM Million 2026 zeigt die Konzentration: Sechs Fehlerarten machen 96 Prozent aller erkannten Fehler aus (WebAIM, 2026). Genau diese sechs sind maschinell gut prüfbar.

Ein Scan sieht, dass ein Alternativtext vorhanden ist. Ob dieser Text das Bild sinnvoll ersetzt, entscheidet ein Mensch. Dasselbe gilt für Fokusreihenfolge, verständliche Fehlermeldungen und ARIA-lastige Widgets wie Comboboxen.

WebAIM zieht daraus eine klare Konsequenz: „Absence of detected errors does not indicate that a page is accessible or conformant.” Ein grüner Scan ist ein Zwischenstand. Welche Kriterien überhaupt maschinell prüfbar sind, ordnet der Artikel zu WCAG 2.2 ein.

Wie testen Sie mit Tastatur und Screenreader?

Abbildung 3: Screenreader-Verbreitung, Europa gegen weltweit.

Der Tastaturtest kommt vor der Screenreader-Prüfung, weil er ohne Spezialwissen durchführbar ist und die meisten Bedienprobleme sofort zeigt. Legen Sie die Maus weg und bedienen Sie jede Funktion mit Tab, Shift+Tab, Enter, Leertaste und Pfeiltasten. Sichtbarer Fokus an jeder Station, logische Reihenfolge, keine Fokusfalle.

Beim Screenreader stellt sich die Frage, welches Programm zuerst dran ist. Weltweit führt JAWS mit 40,5 Prozent vor NVDA mit 37,7 Prozent. In Europa dreht sich das Verhältnis um: NVDA kommt auf 37,2 Prozent, JAWS auf 29,7 Prozent (WebAIM Screen Reader User Survey #10, 2024). Die regionale Verteilung bestimmt die Reihenfolge im Testplan.

Für ein DACH-Team heißt das: NVDA unter Windows kommt zuerst, JAWS als zweiter Durchlauf. Beide gehen unterschiedlich mit ARIA um.

Zwei Einschränkungen gehören zur Zahl: Die Umfrage ist selbstselektiert, und die Daten stammen aus Dezember 2023 bis Januar 2024 bei 1.539 Teilnehmenden.

Warum wird Reflow bei 1280 x 1024 und 400 Prozent Zoom geprüft?

Der Reflow-Test läuft bei 1280 x 1024 Pixeln Fenstergröße und 400 Prozent Browserzoom, weil diese Kombination die Bedingung aus SC 1.4.10 herstellt. Das Kriterium verlangt Darstellung ohne Informationsverlust und ohne Scrollen in zwei Richtungen bei 320 CSS-Pixeln Breite und 256 CSS-Pixeln Höhe.

Die Rechnung dahinter: 1280 CSS-Pixel Ausgangsbreite geteilt durch 400 Prozent Zoom ergeben 320, 1024 geteilt durch 400 Prozent ergeben 256. W3C nennt in der Erläuterung zum Kriterium ausdrücklich „a starting viewport width of 1280 CSS pixels wide at 400% zoom” (W3C zu SC 1.4.10, 2026).

Geprüft wird: Verschwinden Inhalte, entsteht horizontales Scrollen, überlappen Elemente, werden Bedienelemente unerreichbar? Sticky-Header, Datentabellen und Modals fallen hier am häufigsten durch.

Wie bringen Sie Barrierefreiheitstests in die CI/CD-Pipeline?

Abbildung 4: Shift-Left in sechs Ebenen, mit dem manuellen Audit an der Spitze.

Barrierefreiheit testen Sie am besten direkt in der Pipeline, sobald sich die Prüfungen automatisieren lassen, damit jede Codeänderung geprüft wird und nicht erst das Release. Section508.gov der US-Bundesverwaltung formuliert die Regel für das Gate wörtlich: „Define the criteria for failing the CI/CD build when critical accessibility issues are detected” (Section508.gov, 2026).

Die Staffelung nach links, von der Tastatur des Entwicklers bis zum Audit:

1. Lint im Editor und vor dem Commit. axe-linter und eslint-plugin-jsx-a11y fangen Markup-Fehler vor dem Repository ab.

2. Komponententests mit axe-Assertions. jest-axe und @axe-core/react prüfen Komponenten isoliert. jest-axe stammt aus der Community, nicht von Deque.

3. Assertions in bestehenden E2E-Suites. @axe-core/playwright und @axe-core/webdriverjs hängen die Prüfung an Testfälle, die ohnehin laufen. Keine zweite Suite zum Pflegen.

4. Build-brechendes Gate. pa11y-ci, axe-core/cli oder der IBM accessibility-checker mit definierten Schweregrad-Schwellen.

5. Geplante Gesamtscans. Pa11y Dashboard oder ein Cron-Job über die ganze Site, für Trends statt Einzelbefunde.

6. Regelmäßiges manuelles Audit. BITV-Test oder WCAG-Test plus Tests mit Nutzern mit Behinderungen. Die Schritte 1 bis 5 ersetzen diese Ebene nicht.

Section508.gov warnt gleichzeitig vor „possible false results, particularly if tools are configured incorrectly”. Schwellenwerte behandelt der Beitrag zu Quality Gates, die Pipeline-Mechanik der Artikel zur Testautomatisierung in CI/CD.

In Autemos-Testworkflows hängt diese Prüfung an der vorhandenen Automatisierung: Die Workflows nehmen eigene Code-Blöcke und bestehende Playwright-Tests auf, sodass eine axe-core-Prüfung über @axe-core/playwright im selben Lauf wie die funktionalen Regressionstests ausgeführt wird. Die Ergebnisse gehen nach Allure und Jira wie jedes andere Testergebnis, und Barrierefreiheits-Regressionen werden im selben Report sichtbar. Autemos prüft keine Konformität und ersetzt die manuelle Auditebene nicht.

Welche Fehler machen Teams beim Barrierefreiheitstest?

Drei Fehler tauchen in fast jedem Projekt auf, in dem Teams Barrierefreiheit testen: der grüne Scan als Konformitätsnachweis, die Beschränkung auf die Startseite und das Auslassen ARIA-lastiger Komponenten.

Der grüne Scan. Ein Lauf ohne Befunde bedeutet, dass die maschinell prüfbaren Regeln greifen. Für BFSG-Zwecke ist ein Scan-Protokoll ein Baustein der technischen Dokumentation, kein Nachweis; welche Nachweise verlangt sind, steht in der Übersicht zu den BFSG-Anforderungen.

Nur die Startseite. Anmeldung, Checkout, Formularstrecken, Fehlerzustände und PDF-Downloads sind die Stellen, an denen Nutzer scheitern. In einem Startseiten-Scan kommen sie nicht vor.

ARIA-lastige Komponenten. Startseiten mit ARIA hatten in der WebAIM Million 2026 im Schnitt 59,1 Fehler, Seiten ohne ARIA 42 (WebAIM, 2026). Falsch eingesetzte ARIA-Attribute verschlechtern das Ergebnis, und genau diese Komponenten brauchen den Screenreader-Durchlauf am dringendsten.

Häufig gestellte Fragen

Reicht ein automatisierter Scan als Nachweis der Barrierefreiheit?

Nein. Ein automatisierter Scan prüft nur maschinell entscheidbare Regeln und belegt keine WCAG-Konformität. W3C stellt fest: „Tools cannot check all accessibility aspects automatically. Human judgement is required.” (W3C WAI, 2024).

Mit welchem Werkzeug fängt man an?

Mit axe-core, weil Browser-Extension, CLI und Bibliothek denselben Regelsatz nutzen und sich später ohne Bruch in die Pipeline übernehmen lassen. Version 4.12.1 vom 10.06.2026 bringt rund 124 Regeln mit (GitHub, 2026).

Welchen Screenreader sollte ein DACH-Team zuerst testen?

NVDA. In Europa liegt NVDA mit 37,2 Prozent vor JAWS mit 29,7 Prozent, global führt JAWS mit 40,5 Prozent (WebAIM Survey #10, 2024). JAWS gehört als zweiter Durchlauf dazu.

Wie viele Seiten muss ich auf Barrierefreiheit testen?

Für einfache, einheitlich gestaltete Angebote nennt das BIK-Prüfverfahren drei Seiten als Minimum, für komplexe Angebote 5 bis 10 oder mehr (BIK BITV-Test, 2026). Ausgewählt wird nach Repräsentativität.

Lassen sich Barrierefreiheitstests in bestehende E2E-Tests einbauen?

Ja. Pakete wie @axe-core/playwright hängen eine axe-core-Prüfung an vorhandene Testfälle an, sodass keine zweite Suite entsteht. Section508.gov empfiehlt genau diese Einbettung mit Prüfung bei jedem Commit (Section508.gov, 2026).

Fazit

Eine Website auf Barrierefreiheit testen heißt, drei Ebenen zu betreiben und keine davon zu überschätzen. Der automatisierte Scan räumt die häufigen, formalen Fehler weg, und das sind mengenmäßig die meisten: sechs Fehlerarten stehen für 96 Prozent aller erkannten Fehler (WebAIM, 2026). Fokusreihenfolge, Sinn von Alternativtexten und komplexe Widgets bleiben Handarbeit.

Der praktikable Einstieg für ein Team mit laufender Testautomatisierung: axe-core in die bestehenden E2E-Tests hängen, ein Gate mit definierten Schweregraden setzen, Tastatur- und NVDA-Durchlauf als feste Prüfschritte etablieren, ein manuelles Audit einplanen. Den Rahmen liefert der Überblick zum Barrierefreiheitstesting.

Wenn Sie Barrierefreiheitsprüfungen in eine bestehende Testautomatisierung einbauen wollen, sprechen Sie mit uns.