Barrierefreiheit selbst testen: Tools & Workflow

Barrierefreiheit selbst testen heißt kombinieren: ein automatischer Scan mit axe, WAVE oder Lighthouse plus manuelle Prüfungen mit Tastatur, Zoom, Kontrastmessung und Screenreader. Automatische Tools finden nur bei 16 von 50 WCAG-A/AA-Kriterien überhaupt Befunde, und auch dort nie alle – die häufigsten Fehler erwischen sie trotzdem. Für den Rest brauchst du zwei Formate: einen 15-Minuten-Schnelltest für zwischendurch und eine strukturierte Tagesprüfung vor jedem Launch.

Prüfmaßstab ist die WCAG 2.2 auf Stufe AA – 4 Prinzipien, 13 Richtlinien, 86 Erfolgskriterien, jedes mit Testanleitung in der Kriterien-Referenz. Hier steht der Arbeitsablauf drumherum.

Das Wichtigste in Kürze

• Automatische Tools liefern nur bei 16 von 50 WCAG-2.1-A/AA-Kriterien überhaupt Befunde (32 %) – decken aber 57,38 % des Fehler-Volumens ab (Deque-Report, 2021).
• Im GDS-Experiment mit 143 bekannten Barrieren fand das beste Tool 41 %, alle zehn Tools zusammen 71 % – 29 % fand kein einziges (2017).
• WebAIM Million (Februar 2026): 95,9 % von einer Million Startseiten haben automatisch erkennbare WCAG-Fehler, im Schnitt 56,1 pro Seite.
• Der 15-Minuten-Schnelltest: Scan, Tastatur, Zoom auf 200 %, Überschriften-Outline, Kontrast-Stichprobe, Seitentitel und Sprache.
• Kontrast-Grenzwerte (Stufe AA): 4,5:1 für Text, 3:1 für großen Text und für Bedienelemente (SC 1.4.3 und 1.4.11).
• Der BIK BITV-Test umfasst 98 Prüfschritte nach EN 301 549; der Preis hängt an Seitenzahl und Komplexität – BIK rechnet für sieben Seiten rund 4.200 € netto vor.
• Das BFSG gilt seit dem 28.06.2025; Verstöße können bis zu 100.000 € Bußgeld kosten (§ 37 BFSG).

Abgrenzung – hier prüfst du selbst. Werkzeuge, Schnelltest und Tagesprüfung in Eigenregie. Die formale Prüfung durch eine Prüfstelle – mit 98 Prüfschritten und belastbarem Bericht – beschreibt BITV-Test, Audit & VPAT.

Was automatische Tools wirklich finden

Die kursierenden Zahlen – mal „20–30 %“, mal „40 %“ – vermischen zwei Metriken, beide für sich korrekt:

• Nach Kriterien: Nur bei 16 der 50 Erfolgskriterien von WCAG 2.1 auf Stufe A/AA (32 %) finden automatische Tools überhaupt Befunde – und auch dort nur einen Teil.
• Nach Volumen: Trotzdem findet axe-core laut Deque-Coverage-Report 57,38 % aller Barrierefreiheits-Issues – gemessen an über 13.000 geprüften Seiten mit knapp 300.000 Befunden (veröffentlicht März 2021). Der Grund: Wenige Fehlertypen – fehlende Alt-Attribute, schwache Kontraste – stellen die Masse.

Wie groß die Lücke bleibt, zeigte das britische Government Digital Service 2017 an einer Testseite mit 143 bewusst eingebauten Barrieren: Das beste von zehn Tools fand 41 %, das schlechteste 17 %, alle zehn zusammen 71 %. Fast ein Drittel fand kein Tool – darunter lange Kursiv-Passagen, leere Tabellenzellen und nur durch Farbe erkennbare Links.

Dass sich der automatische Teil trotzdem lohnt, zeigt die WebAIM Million (Erhebung Februar 2026): 95,9 % von einer Million getesteter Startseiten haben automatisch erkennbare WCAG-Fehler, im Schnitt 56,1 pro Seite, häufigster Befund zu geringer Kontrast auf 83,9 % der Seiten.

Das Standardbeispiel: Ob ein Bild ein alt-Attribut hat, prüft jedes Tool in Millisekunden. Ob der Text taugt, keins:

<!-- Besteht jeden automatischen Test - und bleibt eine Barriere -->
<img src="diagramm-umsatz.webp" alt="Bild1">

<!-- Erst das macht die Grafik zugänglich -->
<img src="diagramm-umsatz.webp"
     alt="Balkendiagramm: Umsatz 2025 nach Quartalen, Q4 mit 1,2 Mio. Euro am höchsten">

Wie solche Beschreibungen entstehen, steht unter Alt-Texte schreiben.

Die Werkzeugmatrix: was welches Tool findet

Zwei Grenzen aus der Prüfpraxis: Kontrast-Checker versagen bei Text auf Bildern und Farbverläufen, weil ein eindeutiger Hintergrundwert fehlt – immerhin bewertet der Kontrast-Check alle Text-Hintergrund-Paare einer URL vor. Und Shadow DOM ist für manche Tools unsichtbar – bei Web Components hilft die Tool-Dokumentation.

In die Build-Pipeline gehört ein automatischer Test: axe-core als Bibliothek, Pa11y auf der Kommandozeile oder Lighthouse CI; in React fängt eslint-plugin-jsx-a11y Fehler noch früher.

// Pa11y in der CI: bricht den Build bei Verstößen ab
const pa11y = require("pa11y");

pa11y("https://example.de/kontakt.html", {
  standard: "WCAG2AA",
  runners: ["axe"],
}).then((ergebnis) => {
  if (ergebnis.issues.length > 0) {
    console.table(ergebnis.issues.map((befund) => befund.code));
    process.exit(1);
  }
});

Kommerziell kommen axe DevTools Pro mit geführten manuellen Tests (Deque nennt öffentlich keinen Listenpreis mehr; zur Einführung 2021 waren es 45 US-Dollar im Monat), Polypane, Eye-Able oder A11YPLAN dazu – dieser Artikel kommt mit kostenlosen Tools aus.

So testest du es

Vorbild des 15-Minuten-Schnelltests sind die Easy Checks der W3C-WAI (Stand März 2024: 13 Prüfungen, ausdrücklich als nicht erschöpfend deklariert); meine sechs Schritte greifen die treffsichersten heraus:

1. Automatischen Scan starten (2 Minuten). WAVE- oder axe-Extension auf der wichtigsten Seite: fehlende Alt-Attribute, leere Links, unbeschriftete Felder notieren, noch nicht bewerten. Ohne Extension geht es auch mit dem Struktur-Check – zwölf Prüfungen in einem Aufruf, inklusive Fundstelle und Weg zur Behebung.
2. Maus weglegen, mit Tab durch die Seite (4 Minuten). Jedes Bedienelement muss erreichbar sein, der Fokus immer sichtbar, die Reihenfolge nachvollziehbar – und nirgends darfst du hängen bleiben. In Widgets wie Tabs oder Radiogruppen springt Tab zur Komponente, die Pfeiltasten navigieren innerhalb (ARIA Authoring Practices).
3. Zoom prüfen (3 Minuten). Erst 200 %: Text muss lesbar bleiben, nichts überlappen (SC 1.4.4). Dann Fenster auf 1280 Pixel, Zoom 400 % – das entspricht 320 CSS-Pixeln Reflow-Breite: kein waagerechter Scrollbalken, kein verschwindender Inhalt (SC 1.4.10).
4. Überschriften-Outline prüfen (2 Minuten). Mit HeadingsMap: genau eine h1, keine übersprungenen Ebenen, jede Überschrift beschreibt ihren Abschnitt (Überschriften-Hierarchie).
5. Kontrast-Stichprobe (2 Minuten). Fließtext, Navigation, Buttons und Platzhaltertexte messen – Grenzwerte aus SC 1.4.3: 4,5:1 für normalen Text, 3:1 für großen Text (ab 24 px, fett ab 18,66 px) – und aus SC 1.4.11: 3:1 für Bedienelemente und Grafiken.
6. Seitentitel und Sprache (2 Minuten). Ist der Seitentitel eindeutig und steht die wichtigste Information vorn? Stimmt das lang-Attribut im html-Element?

Die Bundesfachstelle Barrierefreiheit stuft solche Schnelltests als groben Eindruck ein – zu Recht: Eine Seite kann alle sechs Punkte bestehen und trotzdem erhebliche Barrieren haben.

Die Tagesprüfung: ein Arbeitstag, sechs Schichten

Vor einem Relaunch oder Audit plane ich einen Arbeitstag in Schichten.

Seitenauswahl zuerst. Nicht nur die Startseite: 3 bis 5 repräsentative Seiten (Startseite, Inhaltsseite, Übersichtsliste, Formular, Suchergebnis) plus vollständige Prozess-Strecken – vom Warenkorb bis zur Bestellung, vom Kontaktformular bis zur Bestätigung. Vollständige Prozesse verlangt auch die W3C-Evaluationsmethodik WCAG-EM; eine feste Seitenzahl gibt sie nicht vor – dort hängt die Stichprobe an Umfang und Komplexität.

Schicht 1 – HTML validieren. Der Nu-Validator des W3C findet kaputte Verschachtelungen, doppelte IDs und ungültige Attribute. Das frühere Kriterium 4.1.1 Parsing ist in WCAG 2.2 gestrichen – Validierung ist kein Konformitätskriterium mehr, bleibt aber der billigste Aufräumschritt.

Schicht 2 – zwei automatische Engines. axe DevTools und WAVE auf jeder ausgewählten Seite, alle Befunde in eine Liste – bewertet wird in der Triage.

Schicht 3 – manuelle Prüfungen. Der komplette Schnelltest auf jeder Seite, plus:

• Formulare: Ein Klick aufs Label muss das Feld fokussieren – passiert nichts, fehlt die Verknüpfung (Labels und Beschriftungen). Pflichtfelder müssen erkennbar sein, Fehlermeldungen das betroffene Feld benennen.
• Textabstände: per Bookmarklet die Testwerte aus SC 1.4.12 injizieren – nichts darf abgeschnitten werden oder überlappen:

/* Textabstands-Test nach SC 1.4.12 - per Bookmarklet oder DevTools */
* {
  line-height: 1.5 !important;
  letter-spacing: 0.12em !important;
  word-spacing: 0.16em !important;
}
p { margin-bottom: 2em !important; }

• CSS deaktivieren: Ergibt die Inhaltsreihenfolge ohne Layout noch Sinn? Das prüft die bedeutungstragende Reihenfolge schneller als jedes Tool.
• WCAG-2.2-Neuerungen: Zielgröße mindestens 24 × 24 CSS-Pixel für Bedienelemente und Fokus nicht verdeckt durch Sticky-Header oder Cookie-Banner – beides Stufe AA, keins zuverlässig automatisch prüfbar.

Schicht 4 – Screenreader. Mit NVDA (Windows, kostenlos) oder VoiceOver (macOS, Cmd+F5) jede Seite durchgehen: Überschriften-Sprungliste, Landmark-Navigation, Linkliste, Formulare wirklich ausfüllen. Die kompletten Durchläufe stehen unter Mit NVDA testen und Mit VoiceOver am Mac testen, mobil unter VoiceOver auf iPhone und iPad und TalkBack, Grundbegriffe erklärt Screenreader-Grundlagen.

Schicht 5 – weitere Eingabewege. Stichprobe mit Sprachsteuerung (Windows Voice Access, macOS Voice Control): Lassen sich Buttons über ihre sichtbare Beschriftung ansprechen? Und mit der Bildschirmlupe ab vierfacher Vergrößerung: Findet man Fehlermeldungen außerhalb des Ausschnitts?

Schicht 6 – Dokumente. PDFs mit dem kostenlosen PDF Accessibility Checker (PAC), Office-Dateien mit der eingebauten Barrierefreiheitsprüfung – Details unter PDF-Barrierefreiheit.

Dokumentiert wird mit zwei kostenlosen Werkzeugen: dem WCAG-EM Report Tool des W3C, das die fünfschrittige Evaluationsmethodik abbildet, und der BIK-BITV-Selbstbewertung – Selbsteinschätzung, kein offizieller Nachweis. Meine Checkliste zum Abhaken steckt im Gratis-E-Book.

False Positives: die Warnliste ist keine Fehlerliste

Tools liefern zwei Arten von Befunden: Fehler und Warnungen („needs review“, „Alerts“). Wer beide ungefiltert abarbeitet, verschwendet Zeit oder verschlimmbessert. Meine Triage für jede Warnung:

1. Kontext ansehen. Ein „redundanter Link“ auf Logo und Site-Name nebeneinander ist meist harmlos; derselbe Befund in einer Kartenliste deutet auf ein echtes Strukturproblem (klickbare Cards).
2. Im DOM prüfen. Meldet WAVE unsicheren Kontrast auf Text über einem Bild, die hellste und die dunkelste Stelle des Hintergrunds einzeln nachmessen.
3. Mit assistiver Technologie gegenprüfen. Im Zweifel entscheidet der Screenreader-Durchgang, nicht das Tool: Wird das Element mit korrektem Namen und korrekter Rolle angesagt, ist die Warnung erledigt.

axe DevTools wirbt damit, keine False Positives zu melden – für die als Fehler markierten Befunde ist das belastbar. Die „needs review“-Kategorie bleibt Handarbeit.

Befunde priorisieren: erst Blocker, dann Volumen

Zwei Datenpunkte sortieren die lange Fundliste: Laut Deque stellen wenige Kriterientypen über 80 % des gesamten Issue-Volumens; die WebAIM Million zeigt seit sieben Jahren dieselben sechs Spitzenreiter, zusammen rund 96 % aller automatisch erkannten Fehler (Stand Februar 2026): zu geringer Kontrast (83,9 % der Seiten), fehlende Alt-Texte (53,1 %), fehlende Formular-Labels (51 %), leere Links (46,3 %), leere Buttons (30,6 %), fehlendes lang-Attribut (13,5 %). Daraus ergibt sich meine Behebungsreihenfolge:

1. Blocker aus dem manuellen Test: Tastaturfallen, unsichtbarer Fokus, unbedienbare Dialoge (Tastaturbedienung und Fokus). Sie sperren Menschen komplett aus.
2. Die sechs Volumen-Fehler von oben – Kontraste zuerst, meist billig zu beheben und mit der größten Breitenwirkung.
3. Struktur: Überschriften, Landmarks, Fokus-Reihenfolge.
4. Der Rest nach der Schweregrad-Einstufung des Tools.

Selbsttest, BITV-Test oder Audit?

Ein Selbsttest findet Baustellen, ein Konformitätsnachweis ist er nicht – der führt über den Expertentest: Der BIK BITV-Test (Web) umfasst 98 Prüfschritte auf Basis der EN 301 549, die mit ihren zusätzlichen Kapiteln mehr abdeckt als die WCAG allein. Der Preis entsteht aus Seitenzahl und Komplexität: Das Rechenbeispiel von BIK nennt für sieben Seiten rund 4.200 € netto plus Grundgebühr, komplexe Anwendungen liegen deutlich darüber. Freie Audits ohne Prüfsiegel sind nach meiner Erfahrung günstiger. Ablauf und Vorbereitung beschreibt BITV-Test und Audit.

Den Maßstab setzt der rechtliche Rahmen: Für öffentliche Stellen gilt die BITV 2.0, für die private Wirtschaft seit dem 28. Juni 2025 das Barrierefreiheitsstärkungsgesetz. Es sieht Bußgelder bis 100.000 € vor (§ 37 BFSG), nimmt Kleinstunternehmen als Dienstleister aus (§ 3 Abs. 3 BFSG) und lässt vor dem Stichtag geschlossene Verträge längstens bis zum 27. Juni 2030 weiterlaufen (§ 38 BFSG). Rechtlicher Maßstab ist über die EN 301 549 noch die WCAG 2.1 – getestet wird sinnvollerweise gegen die WCAG 2.2, die alle 2.1-Kriterien bis auf das gestrichene 4.1.1 Parsing enthält und neun ergänzt. Ob dein Angebot unter das Gesetz fällt, klärt die BFSG-Prüfung in 16 Fragen; laufende Entwicklungen sammelt Aktuelles zum BFSG. Diese Seite erklärt die Rechtslage, ersetzt aber keine Rechtsberatung.

Häufiger Fehler in der Praxis

Lighthouse 100 als Freigabekriterium. Ein Relaunch-Projekt feierte den Accessibility-Score von 100 – und hatte eine Tastaturfalle im Cookie-Banner: Wer per Tab hineingeriet, kam ohne Maus nicht wieder heraus.

Doppelt gescannt statt breit geprüft. Teams lassen axe und Lighthouse laufen und halten das für zwei unabhängige Prüfungen. Es ist eine – beide nutzen axe-core. Die zweite Meinung liefert erst WAVE oder ein manueller Durchgang.

Warnungen mit ARIA weggeflickt. Ein Entwickler arbeitete eine WAVE-Warnliste ab, indem er auf jedes gemeldete Element ein aria-label setzte – und überschrieb sichtbare Beschriftungen mit abweichenden Texten, was die Sprachsteuerung lahmlegte. Die erste Regel von ARIA gilt auch beim Abarbeiten von Befunden.

Nur die Startseite getestet. Sie ist fast immer die gepflegteste Seite. Die Barrieren stecken in Formular-Strecken, Suchergebnissen und PDF-Downloads – dort, wo Menschen Aufgaben erledigen.

Häufige Fragen

Wie viel Prozent der Barrierefreiheitsfehler finden automatische Tools wirklich?

Automatische Tools liefern nur bei 16 von 50 WCAG-2.1-A/AA-Kriterien überhaupt Befunde (32 %) und auch dort nicht alle, decken laut Deque-Report aber 57,38 % des Fehler-Volumens ab, weil wenige Fehlertypen die Masse ausmachen (Datenbasis 2021: über 13.000 Seiten, knapp 300.000 Befunde). Kursierende Zahlen wie „20–30 %“ oder „40 %“ vermischen diese beiden Metriken. Im GDS-Experiment fanden zehn Tools zusammen 71 % von 143 bekannten Barrieren.

Reicht ein Lighthouse-Score von 100, damit meine Website barrierefrei ist?

Nein. Lighthouse basiert auf axe-core und prüft nur automatisch testbare Regeln – 100 Punkte heißen: keine maschinell erkennbaren Fehler in dieser Teilmenge. Tastaturfallen, unsinnige Alt-Texte, verdeckter Fokus und unlogische Reihenfolgen bleiben unsichtbar. Der Score taugt als Verlaufskontrolle in der CI-Pipeline, nicht als Konformitätsaussage.

Wie kann ich kostenlos prüfen, ob meine Website barrierefrei ist?

Komplett kostenlos geht es mit der WAVE- oder axe-Extension für den Scan, Tastatur und Browser-Zoom für die manuellen Checks, NVDA oder VoiceOver als Screenreader und der BIK-BITV-Selbstbewertung als strukturierter Checkliste. Damit deckst du den gesamten Workflow dieses Artikels ab. Geld kostet erst der offizielle Nachweis durch einen Expertentest.

Was ist der Unterschied zwischen Selbsttest und BITV-Test?

Der Selbsttest ist deine eigene Einschätzung mit kostenlosen Mitteln – gut, um Barrieren zu finden und zu priorisieren. Der BIK BITV-Test ist ein Expertentest mit 98 Prüfschritten nach EN 301 549 und liefert einen belastbaren Konformitätsnachweis; der Preis richtet sich nach Seitenzahl und Komplexität – das BIK-Rechenbeispiel nennt für sieben Seiten rund 4.200 € netto plus Grundgebühr. Öffentliche Stellen brauchen ihn regelmäßig, Unternehmen vor allem im Streit- oder Nachweisfall.

Woher weiß ich, ob meine Website BFSG-konform sein muss?

Das BFSG gilt seit dem 28. Juni 2025 für Produkte und Dienstleistungen für Verbraucher – etwa Onlineshops, Buchungs- und Banking-Angebote; Kleinstunternehmen als Dienstleister sind ausgenommen (§ 3 Abs. 3 BFSG). Reine B2B-Angebote und private Seiten fallen nicht darunter. Ob dein Angebot betroffen ist, klärst du in vier Fragen mit dem BFSG-Schnelltest.

Verwandte Themen

• Mit NVDA testen – der komplette Screenreader-Durchgang unter Windows, Schritt für Schritt
• Mit JAWS testen – derselbe Durchgang mit dem Screenreader, der in Behörden vorgegeben ist
• Mit VoiceOver am Mac testen – dasselbe für macOS
• Mit VoiceOver auf iPhone und iPad testen und mit TalkBack – die mobilen Durchläufe
• Barrierefreiheits-Overlays – warum ein Widget keinen dieser Schritte ersetzt
• Reflow, Zoom & Textabstände – die drei Anpassbarkeits-Kriterien mit Testrezept im Detail
• Tastaturbedienung & sichtbarer Fokus – was hinter dem wichtigsten manuellen Test steckt
• BITV-Test und Audit – Ablauf, Kosten und Vorbereitung des Expertentests
• BFSG-Checkliste – die Punkte, die Tools nicht abdecken, zum Abhaken

Quellen

• Deque – Automated Accessibility Coverage Report (57,38 % Issue-Abdeckung, automatisierte Befunde bei 16 von 50 Kriterien; März 2021)
• WebAIM – The WebAIM Million (Erhebung Februar 2026: 95,9 % fehlerhafte Startseiten, Ø 56,1 Fehler pro Seite)
• GOV.UK Accessibility Blog – Testseite mit 143 Barrieren (bestes Tool 41 %, alle zehn zusammen 71 %; 2017)
• W3C WAI – Easy Checks (13 Schnellprüfungen, Stand März 2024)
• W3C – WCAG-EM (vollständige Prozesse verpflichtend, keine feste Seitenzahl)
• W3C WAI – What's New in WCAG 2.2 (neun neue Kriterien, 4.1.1 Parsing gestrichen)
• BIK BITV-Test (FAQ-Rechenbeispiel: sieben Seiten rund 4.200 € netto plus Grundgebühr)
• Barrierefreiheitsstärkungsgesetz (BFSG) (Volltext bei gesetze-im-internet.de; § 3, § 37, § 38)