Wer Barrierefreiheit testen will, prüft, ob Menschen mit Behinderungen eine Anwendung finden, erreichen und bedienen können. In der Praxis besteht die Prüfung aus drei Schichten: automatisierte Prüfungen in der Pipeline, manuelle Expertenprüfung und Tests mit assistiver Technik. Der Grund für diese Aufteilung ist messbar. In der Auswertung von Deque Systems, dem Hersteller des Prüfwerkzeugs axe, wiesen 16 von 50 WCAG-2.1-Kriterien der Stufen A und AA automatisiert erkannte Fehler auf, rund 32 % (Deque Systems, 2021). Werkzeuge erledigen den mechanischen Teil schnell und wiederholbar. Alles, was mit Bedeutung, Reihenfolge und Gleichwertigkeit zu tun hat, bleibt beim Menschen. Beide Teile zusammen ergeben einen prüfbaren Nachweis, einer allein nicht.

Kurz gefasst: Barrierefreiheit testen heißt, automatisierte Prüfungen, manuelle Expertenprüfung und Tests mit assistiver Technik zu verbinden. Die Automatisierung deckt rund ein Drittel der WCAG-Erfolgskriterien ab (Deque Systems, Hersteller von axe, 2021) und findet Kontrast, fehlende Alternativtexte und Formularbeschriftungen zuverlässig. Konformität nach BFSG oder BITV 2.0 bestätigt am Ende ein Mensch, kein Scan.

Abbildung 1: Die drei Schichten der Barrierefreiheitspruefung

Was heißt Barrierefreiheit testen?

Barrierefreiheitstests sind Prüfverfahren, die feststellen, ob Menschen mit Behinderungen ein Produkt oder eine Dienstleistung ohne fremde Hilfe nutzen können. Geprüft wird gegen die Web Content Accessibility Guidelines (WCAG) des W3C, die vier Prinzipien und drei Konformitätsstufen kennen: A, AA und AAA (W3C WAI, 2024).

Die vier Prinzipien nennt das W3C „perceivable, operable, understandable, and robust”. Das deutsche Verordnungsrecht übernimmt sie wörtlich. § 3 BITV 2.0 formuliert: „Die in § 2 genannten Angebote, Anwendungen und Dienste der Informationstechnik sind barrierefrei zu gestalten. Dies erfordert, dass sie wahrnehmbar, bedienbar, verständlich und robust sind.” (BITV 2.0, 2023)

Der gesetzliche Maßstab für Produkte und Dienstleistungen steht in § 3 Absatz 1 BFSG (gesetze-im-internet.de, 2021):

„Produkte und Dienstleistungen sind barrierefrei, wenn sie für Menschen mit Behinderungen in der allgemein üblichen Weise, ohne besondere Erschwernis und grundsätzlich ohne fremde Hilfe auffindbar, zugänglich und nutzbar sind.”

Für QA-Teams, die Barrierefreiheit testen, ist diese Formulierung brauchbarer, als sie zunächst wirkt. Sie beschreibt einen Nutzungserfolg und lässt sich am Quelltext allein nicht ablesen. Ein Formular kann jedes technische Kriterium erfüllen und trotzdem daran scheitern, dass die Fehlermeldung erst nach dem Absenden erscheint und der Screenreader sie nie ankündigt.

Warum steht Barrierefreiheit jetzt auf der QA-Agenda?

Seit dem 28. Juni 2025 gelten die materiellen Pflichten des Barrierefreiheitsstärkungsgesetzes (BFSG), und § 37 Absatz 2 sieht Geldbußen bis zu hunderttausend Euro vor, in den übrigen Fällen bis zu zehntausend Euro (gesetze-im-internet.de, 2021). Betroffen sind unter anderem Bankdienstleistungen für Verbraucher, der elektronische Geschäftsverkehr, E-Books und Selbstbedienungsterminals.

Wichtig für die Abgrenzung: Das BFSG adressiert durchgehend Angebote an Verbraucher. Rein interne B2B-Anwendungen fallen nicht darunter. Welche Produkte und Dienstleistungen die Liste im Einzelnen nennt und welche Nachweise das Gesetz verlangt, klärt der Beitrag zu den BFSG-Anforderungen.

Die Marktüberwachung läuft. Die Marktüberwachungsstelle der Länder für die Barrierefreiheit von Produkten und Dienstleistungen (MLBF) ist eine gemeinsame Anstalt aller 16 Bundesländer mit Sitz in Magdeburg und hat ihre Tätigkeit im September 2025 aufgenommen (MLBF, 2026). Ihre Marktüberwachungsstrategien wurden am 29. Januar 2026 beschlossen.

Zum ersten Jahr schreibt das zuständige Ministerium in Sachsen-Anhalt: „Aktuell liegt der Schwerpunkt auf dem abschließenden Aufbau der organisatorischen und fachlichen Grundlagen sowie auf der Bearbeitung von fast 700 eingegangenen Meldungen.” (Ministerium für Arbeit, Soziales, Gesundheit und Gleichstellung Sachsen-Anhalt, 2026). Öffentlich dokumentierte Einzelbußgelder nach § 37 BFSG gibt es bislang keine. Wer eine Bußgeldwelle ankündigt, hat dafür keine belastbare Quelle.

Die Zielgruppe ist groß, und die Zahlen messen Unterschiedliches. In der EU berichteten 23,9 % der Menschen ab 16 Jahren 2024 eine dauerhafte Aktivitätseinschränkung, davon 6,7 % eine schwere (Eurostat, 2025).

In Deutschland lebten Ende 2025 gut 7,8 Millionen Menschen mit amtlich festgestellter Schwerbehinderung, ein Grad der Behinderung ab 50, das sind 9,4 % der Bevölkerung (Destatis, 2026). Die Werte beruhen auf verschiedenen Definitionen und lassen sich nicht gegeneinander rechnen.

Für Banken und Versicherer kommt die Pflicht zu einem ohnehin dichten Prüf- und Nachweisregime hinzu. Wie sich Barrierefreiheitsnachweise in bestehende Freigabeprozesse einordnen, behandelt der Beitrag zum Testen in regulierten Branchen.

Wie viel Barrierefreiheit lässt sich automatisiert testen?

Abbildung 2: Kriteriendeckung und Fehlerdeckung messen Verschiedenes

Automatisierte Werkzeuge decken je nach Messweise rund 32 % der WCAG-Erfolgskriterien oder rund 57 % der einzelnen Fehlerinstanzen ab, und beide Zahlen stammen von Deque Systems, dem Hersteller des Prüfwerkzeugs axe (Deque Systems, 2021). Die zwei Werte messen zwei verschiedene Dinge und werden regelmäßig verwechselt.

Deque wertete über 2.000 Erstaudits mit mehr als 13.000 Seiten und Seitenzuständen und rund 300.000 gefundenen Fehlern aus, geprüft mit der eigenen axe-Suite. Ergebnis: 57,38 % der Fehlerinstanzen fand die Automatisierung, und bei 16 von 50 WCAG-2.1-Kriterien der Stufen A und AA traten automatisiert erkannte Fehler auf, das sind 32 % der Kriterien.

Beides ist gleichzeitig richtig. Wenige Kriterien erzeugen den Großteil der realen Fehler, deshalb liegt die Fehlerdeckung deutlich über der Kriteriendeckung. Für die Planung ist genau das nützlich: Eine Automatisierung, die Kontrast, Alternativtexte und Beschriftungen abräumt, entlastet ein manuelles Audit spürbar.

Beide Werte sind Herstellerangaben aus eigenen Daten ohne unabhängige Replikation. Die peer-reviewte Gegenrechnung ist älter und fällt vorsichtiger aus: Vigo, Brown und Conway prüften sechs Werkzeuge gegen WCAG 2.0 und kamen auf „at most 50% of the success criteria are covered”, bei einer Vollständigkeit von 14 bis 38 % und einer Korrektheit von 66 bis 71 % (Vigo et al., W4A ‘13, 2013).

Die Werkzeuge von 2013 sind nicht die von heute. Die Größenordnung der Kriteriendeckung deckt sich trotzdem mit Deques eigener Zahl.

Das W3C formuliert die Grenze ohne Umschweife (W3C WAI, 2024):

„Tools cannot check all accessibility aspects automatically. Human judgement is required.”

Auf derselben Seite steht der Satz, der jede Konformitätsdiskussion beendet: „Web accessibility evaluation tools can not determine accessibility, they can only assist in doing so.” Ein grüner Scan bleibt damit ein Zwischenergebnis im Prüfprozess.

Was Werkzeuge finden und was Menschen beurteilen müssen

Die linke Spalte deckt sich mit den Fehlertypen, die WebAIM in der Million-Studie automatisiert zählt. Die rechte Spalte folgt der oben zitierten W3C-Aussage zum menschlichen Urteil.

Eine zweite Einschränkung betrifft die Werkzeugwahl selbst: Prüfwerkzeuge sind untereinander nicht austauschbar. In einer Untersuchung von neun automatisierten Prüfwerkzeugen über 121 Seiten fand jedes Werkzeug Verstöße, die andere übersahen (Pool, W4A ‘23, 2023). Wer die Auswahl konkret plant, findet den Vergleich im Beitrag Barrierefreiheit einer Website testen.

Wie barrierefrei sind Websites heute tatsächlich?

Abbildung 3: Automatisch erkennbare Fehler in der WebAIM Million 2026

95,9 % der eine Million meistbesuchten Startseiten hatten im Februar 2026 automatisch erkennbare WCAG-2-Verstöße, im Durchschnitt 56,1 Fehler pro Seite (WebAIM Million, 2026). Im Vorjahr waren es 94,8 %.

Sechs Fehlertypen machen 96 % aller erkannten Fehler aus: zu geringer Textkontrast (auf 83,9 % der Startseiten), fehlende Alternativtexte (53,1 %), fehlende Formularbeschriftungen (51 %), leere Links (46,3 %), leere Schaltflächen (30,6 %) und fehlende Dokumentsprache (13,5 %). WebAIM merkt an, dass diese Liste seit sieben Jahren unverändert ist.

Der Trend hat 2026 gedreht. Die durchschnittliche Fehlerzahl stieg von 51 auf 56,1, ein Plus von 10,1 %, und beendet damit eine mehrjährige Verbesserung. Gleichzeitig wuchs die durchschnittliche Zahl der Elemente pro Startseite auf 1437, ein Zuwachs von 22,5 % in einem Jahr. Seiten mit ARIA hatten mehr Fehler als Seiten ohne ARIA, 59,1 gegenüber 42 im Schnitt.

WebAIM setzt selbst die entscheidende Einschränkung unter die eigene Studie:

„Absence of detected errors does not indicate that a page is accessible or conformant.”

Für alle, die Barrierefreiheit testen, heißt das zweierlei. Der automatisiert prüfbare Teil ist in der Breite noch nicht erledigt, obwohl er der einfachste ist. Und eine fehlerfreie Auswertung markiert den Startpunkt der manuellen Prüfung.

Welche Standards und Fassungen gelten für die Prüfung?

Für die Prüfung in Europa ist EN 301 549 V3.2.1 (2021-03) die einzige harmonisierte Fassung, und sie baut auf WCAG 2.1 Stufe AA auf (Durchführungsbeschluss (EU) 2021/1339, 2021). V4.1.0 liegt als Entwurf vom November 2025 in der formellen Abstimmung der europäischen Normungsorganisationen bis August 2026 (ETSI, 2026).

WCAG 2.2 erschien am 5. Oktober 2023 als W3C-Empfehlung, eine Aktualisierung folgte am 12. Dezember 2024. Die Fassung ergänzt neun Erfolgskriterien und streicht eines. Das W3C stellt klar: „WCAG 2.0, WCAG 2.1, and WCAG 2.2 are all existing standards. WCAG 2.2 does not deprecate or supersede WCAG 2.1” (W3C WAI, 2024).

Daraus folgt eine Kleinigkeit mit Prüfrelevanz. Kriterium 4.1.1 Parsing ist in WCAG 2.2 entfallen, unter EN 301 549 V3.2.1 gilt aber weiterhin WCAG 2.1. Das W3C schreibt dazu, Autoren, die per Vorgabe WCAG 2.0 oder 2.1 erfüllen müssen, „may need to continue to test and report 4.1.1” (W3C, 2024). Für BITV-Prüfungen bleibt der Prüfschritt damit auf der Liste.

Für das BFSG ist die Rechtslage offener. § 3 BFSGV verweist auf den Stand der Technik, nennt keine konkrete Norm und begründet keine Konformitätsvermutung (gesetze-im-internet.de, 2022).

AccessibleEU schreibt zu EN 301 549: „The standard is currently being updated to also support the European Directive 2019/882 on the accessibility requirements for products and services.” (AccessibleEU, 2026). Eine unter dem European Accessibility Act harmonisierte Fassung existiert derzeit nicht.

Praktisch prüfen die meisten DACH-Teams gegen WCAG 2.1 AA als Pflichtteil und nehmen die neuen 2.2-Kriterien freiwillig dazu. Welche neun Kriterien das sind und welche davon automatisiert prüfbar sind, steht im Beitrag zu WCAG 2.2.

Wie läuft eine Barrierefreiheitsprüfung ab?

Wenn Sie Barrierefreiheit testen, läuft die Prüfung nach einem festen Ablauf ab, von der Festlegung des Geltungsbereichs bis zum veröffentlichten Bericht, und die automatisierten Schritte stehen am Anfang dieses Ablaufs. Der folgende Weg entspricht der Struktur etablierter Prüfverfahren:

1. Geltungsbereich festlegen: welche Anwendungen, welche Standardfassung, welche Konformitätsstufe, welche Endgeräte und welche assistiven Technologien.

2. Repräsentative Seitenauswahl treffen. Beim BIK BITV-Test gilt: „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)

3. Automatisierten Scan fahren, um Kontrast, fehlende Alternativtexte, Beschriftungen und Strukturfehler vorab zu beseitigen.

4. Tastaturprüfung durchführen: jede Funktion ohne Maus erreichbar, Fokus sichtbar, keine Fokusfallen.

5. Screenreader-Prüfung durchführen, mit der Kombination aus Screenreader und Browser, die die Zielgruppe verwendet.

6. Vergrößerung und Reflow prüfen, bei 400 % Zoom auf 1280 mal 1024 Pixel, weil 320 CSS-Pixel Breite genau diesem Fall entsprechen (W3C, 2026).

7. Jeden Prüfschritt bewerten und den Bericht erstellen, inklusive der Erklärung zur Barrierefreiheit nach § 14 BFSG für Dienstleistungen.

8. Prüfungen in den Releasebetrieb überführen, damit Regressionen zwischen den Audits auffallen.

Im DACH-Raum ist der BITV-Test das etablierte Prüfverfahren. Er wird von der DIAS GmbH in Hamburg betreut, umfasst 98 Prüfschritte zu 88 Anforderungen und dauert inklusive Qualitätssicherung typischerweise vier bis sechs Wochen (BIK BITV-Test, 2026). Bewertet wird nach einem fünfstufigen Schema von „erfüllt” bis „nicht erfüllt”; konform ist eine Seite nur, wenn alle Prüfschritte mit „erfüllt” oder „eher erfüllt” bewertet wurden.

Ein Detail, das sich in Ausschreibungen hartnäckig hält: Die alte Punktbewertung mit der 90-Punkte-Schwelle für „gut zugänglich” wird seit 2019 nicht mehr verwendet. Wie das Verfahren heute bewertet und wer es durchführen darf, steht im Beitrag zum BITV-Test.

Wer testet was?

Abbildung 4: Was ein Werkzeug feststellt und was ein Mensch beurteilen muss

Teams, die Barrierefreiheit testen, verteilen die Arbeit auf vier Rollen mit klar getrennten Aufgaben, und keine davon kann die anderen ersetzen. Die Aufteilung entscheidet darüber, ob Befunde früh oder erst im Audit auftauchen.

• Entwicklung: Linting im Editor, Komponententests mit axe-Assertions, semantisches HTML und ARIA nur dort, wo natives Markup nicht ausreicht.

• QA und Testautomatisierung: automatisierte Prüfungen im bestehenden Testlauf, Tastaturpfade in den funktionalen Tests, Regressionsüberwachung zwischen den Audits.

• Prüfstelle: das formale Audit. Ein BITV-Test „kann nur von BIK Prüfstellen durch qualifizierte BIK Prüfende durchgeführt werden” (BIK BITV-Test, 2026).

• Nutzerinnen und Nutzer mit Behinderungen: der Realitätsabgleich, den keine Checkliste liefert.

Zur letzten Rolle ist das W3C deutlich: „Evaluating with users with disabilities and with older users identifies usability issues that are not discovered by conformance evaluation alone.” (W3C WAI, 2024). Eine Seite kann jedes Kriterium erfüllen und trotzdem einen Kontoeröffnungsprozess haben, den niemand mit Screenreader in vertretbarer Zeit abschließt.

Für die Einordnung in den restlichen Testbetrieb hilft die Übersicht über die verschiedenen Testarten im Software-Testing. Barrierefreiheitstests sind dort eine nichtfunktionale Prüfung mit eigener Nachweispflicht.

Wie kommt Barrierefreiheit in die Testautomatisierung?

Barrierefreiheit testen Sie in derselben Pipeline wie funktionale Tests, mit einer definierten Abbruchbedingung. Section508.gov empfiehlt ausdrücklich, „Define the criteria for failing the CI/CD build when critical accessibility issues are detected” (Section508.gov, 2026). Dieselbe Quelle warnt vor Fehlmeldungen bei falsch konfigurierten Werkzeugen.

Bewährt hat sich eine gestufte Anordnung:

• Lint- und Statikprüfungen im Editor und vor dem Commit

• axe-Assertions in Komponenten- und Unittests

• Prüfungen in den bestehenden E2E-Tests, etwa über @axe-core/playwright, ohne separate Testsuite

• ein Build-Gate mit definierten Schweregraden

• geplante Vollscans für die Trendbeobachtung

• das periodische manuelle Audit, das die Schritte davor nicht ersetzen können

Genau an dieser Stelle setzt Autemos an. Autemos ist eine KI-gestützte Testautomatisierungsplattform für Web, Mobile, API und Desktop. Ihre Test-Workflows nehmen eigene Code-Blöcke und bestehende Playwright-Tests auf, sodass eine axe-core-Prüfung im selben automatisierten Workflow läuft wie die funktionalen Regressionstests. Die Ergebnisse landen in Allure und Jira wie jedes andere Testergebnis. Details dazu zeigt die Seite zu den Test-Workflows.

Die Grenze ist ebenso klar. Autemos verkauft kein Barrierefreiheits-Audit und bescheinigt keine Konformität nach BFSG, BITV 2.0 oder WCAG. Die manuelle Prüfung und die Bewertung durch eine Prüfstelle bleiben menschliche Arbeit. In Kundenprojekten sehen wir vor allem einen Effekt: Sobald die automatisierbaren Fehlerklassen im Regressionslauf mitlaufen, kommen sie zwischen zwei Audits nicht mehr unbemerkt zurück.

Häufig gestellte Fragen

Reicht ein automatisierter Scan als Nachweis der Barrierefreiheit?

Nein. Ein Scan belegt keine Konformität, weder nach WCAG noch nach BFSG oder BITV 2.0. Das W3C stellt fest: „Tools cannot check all accessibility aspects automatically. Human judgement is required.” (W3C WAI, 2024). Der Nachweis entsteht aus manueller Prüfung, dokumentierter Bewertung und Bericht.

Wie viel Prozent der WCAG-Kriterien lassen sich automatisiert prüfen?

Rund ein Drittel, gemessen an den Erfolgskriterien: 16 von 50 WCAG-2.1-Kriterien der Stufen A und AA wiesen in Deques Auswertung automatisiert erkannte Fehler auf (Deque Systems, 2021). Deque nennt zugleich 57,38 % der einzelnen Fehlerinstanzen, misst damit aber Fehlervolumen statt Kriterien.

Gilt das BFSG auch für interne Fachanwendungen?

Nein. Das BFSG richtet sich durchgehend an Angebote für Verbraucher, etwa Bankdienstleistungen, elektronischen Geschäftsverkehr und E-Books (gesetze-im-internet.de, 2021). Rein interne B2B-Werkzeuge fallen nicht darunter. Für Bundesbehörden gilt stattdessen die BITV 2.0.

Gegen welche WCAG-Fassung sollten wir Barrierefreiheit testen?

Gegen WCAG 2.1 Stufe AA als verbindlichen Teil, weil EN 301 549 V3.2.1 als einzige harmonisierte Fassung darauf aufbaut (Durchführungsbeschluss (EU) 2021/1339, 2021). Die neun zusätzlichen Kriterien aus WCAG 2.2 lohnen sich freiwillig, weil eine aktualisierte Normfassung erwartet wird.

Mit welchem Screenreader sollten wir in Europa Barrierefreiheit testen?

In Europa führt NVDA mit 37,2 % vor JAWS mit 29,7 %, während global JAWS mit 40,5 % vor NVDA mit 37,7 % liegt (WebAIM Screen Reader Survey #10, 2024). Die Erhebung ist eine selbstselektierte Onlinebefragung mit 1.539 Antworten, kein Zufallsstichprobenverfahren.

Fazit

Barrierefreiheit testen heißt, zwei Arbeitsweisen sauber zu trennen und beide zu betreiben. Die Automatisierung übernimmt rund ein Drittel der WCAG-Erfolgskriterien und den Großteil der Fehlermasse, jeden Tag und ohne Diskussion. Die Bewertung von Bedeutung, Reihenfolge, Verständlichkeit und Gleichwertigkeit bleibt beim Menschen, und die Konformitätsaussage kommt aus einem dokumentierten Prüfverfahren. Mit dem BFSG seit Juni 2025 und einer aktiven Marktüberwachung ist der Nachweis Teil des Releasebetriebs geworden.

Der pragmatische Einstieg: automatisierbare Fehlerklassen in den bestehenden Testlauf hängen, ein Build-Gate definieren, dann ein manuelles Audit ansetzen, das keine Zeit mehr mit Kontrastwerten verliert. Wenn Sie prüfen möchten, wie sich axe-core-Prüfungen in Ihre bestehenden Testabläufe einfügen, sprechen Sie mit uns über Ihr Testszenario.