WCAG-Abdeckung

WCAG 2.2 umfasst 55 aktive Erfolgskriterien der Stufen A und AA. AllyProof führt automatisierte Regeln aus, die für 25 davon Fehlerbedingungen erkennen. Das ist eine Aussage über Erkennung, nicht über Konformität: Ein Scan ohne Befund hat lediglich die von seinen Regeln abgedeckten Fehlermuster ausgeschlossen – mehr nicht. Diese Seite erklärt, was die einzelnen Kategorien bedeuten und wo die Lücke liegt.

Was automatisiertes Testen tatsächlich misst

Die branchenweit zitierte Zahl lautet 57 % – und sie wird regelmäßig falsch verstanden. Sie stammt aus Deques Automated Accessibility Coverage Report, der rund 2.000 Audits mit über 13.000 Seiten und etwa 300.000 erfassten Problemen ausgewertet hat. In diesem Datensatz erkannte automatisiertes Testen 57,38 % der insgesamt erfassten Barrierefreiheitsprobleme.

Das ist ein Anteil am Problemvolumen, kein Anteil an den Erfolgskriterien. Derselbe Bericht stellt ausdrücklich fest, dass automatisiert erkennbare Probleme nur bei 16 von 50 untersuchten WCAG-2.1-Erfolgskriterien der Stufen A/AA auftraten. Automatisierte Regeln konzentrieren sich auf die häufigsten Fehler – fehlender Alt-Text, Kontrast, fehlende Formularbeschriftungen –, weshalb sie einen Großteil der Probleme erfassen, aber nur eine Minderheit der Kriterien berühren.

Die korrekte Aussage lautet daher:

Automatisiertes Testen der Barrierefreiheit erkennt viele verbreitete WCAG-Fehlermuster, kann WCAG-Konformität aber nicht belegen. In Deques Audit-Datensatz erkannte automatisiertes Testen 57,38 % der erfassten Barrierefreiheitsprobleme – ein Anteil am Problemvolumen, nicht der Anteil der WCAG-Erfolgskriterien, die sich vollständig automatisiert bewerten lassen. Die tatsächliche Abdeckung variiert je nach Website.

AllyProof hat keinen eigenen veröffentlichten Benchmark durchgeführt und nennt deshalb auch keine eigene Erkennungsquote. Was AllyProof stattdessen ausweist, ist kriterienweise, welche Kriterien die Regeln abdecken und welche nicht – siehe die Tabellen unten.

Was ein Ergebnis ohne Befund bedeutet

Ein automatisiertes Ergebnis ohne Befund bedeutet, dass der Scanner die von seinen Regeln abgedeckten Fehlermuster nicht gefunden hat. Es belegt keine Konformität mit dem Erfolgskriterium als Ganzem.

Deshalb wandelt AllyProof das Ausbleiben von Befunden nie in eine Konformitätsaussage um. In einem Entwurfs-Accessibility Conformance Report erhält ein Kriterium ohne erkannten Fehler einen Nachweisstatus („Automatisierte Prüfungen abgeschlossen – kein Fehler erkannt") und eine leere Konformitätsstufe, die eine fachkundige Person ausfüllt – nicht „Supports".

WCAG 2.2 – neu seit Oktober 2023

WCAG 2.2 (W3C-Empfehlung, Okt. 2023; ISO/IEC 40500:2025) hat neun Erfolgskriterien zu WCAG 2.1 hinzugefügt und eines entfernt. Befunde, die einem der neun neuen Kriterien zugeordnet sind, tragen auf der Detailseite ein Neu in 2.2-Label, damit Kundinnen und Kunden mit 2.2 als Zielstandard auf einen Blick sehen, welche Probleme unter dem früheren Standard nicht existiert hätten.

2.4.11 Fokus nicht verdeckt (Minimum) – AA
2.4.12 Fokus nicht verdeckt (Erweitert) – AAA
2.4.13 Fokus-Erscheinungsbild – AAA
2.5.7 Ziehbewegungen – AA
2.5.8 Zielgröße (Minimum) – AA
3.2.6 Konsistente Hilfe – A
3.3.7 Redundante Eingabe – A
3.3.8 Barrierefreie Authentifizierung (Minimum) – AA
3.3.9 Barrierefreie Authentifizierung (Erweitert) – AAA

4.1.1 Parsing ist entfallen

Das Erfolgskriterium 4.1.1 Parsing ist obsolet und wurde in WCAG 2.2 entfernt. Es ist keine aktive WCAG-2.2-Anforderung, und AllyProof stellt es auch nicht als solche dar.

Der Scanner führt weiterhin Regeln zu doppelten IDs und fehlerhaftem Markup aus, weil sie nützliche Qualitätssignale bleiben und Fehler anderer Kriterien sichtbar machen können. Laut W3C gilt 4.1.1 für HTML und XML inzwischen als stets erfüllt; Auswirkungen doppelter IDs oder fehlerhaften Markups sind unter dem tatsächlich betroffenen Kriterium zu berichten. Editionen für ältere Standards behalten aus strukturellen Gründen eine klar gekennzeichnete Legacy-Zeile, weisen ihr aber nicht automatisch eine Konformitätsstufe zu.

Wie AllyProof Kriterien einordnet

Die Kategorien beschreiben den Nachweis, den Automatisierung erbringen kann – nicht, wie „automatisierbar" ein Kriterium ist. Nichts davon impliziert, dass ein Ergebnis ohne Befund Konformität belegt.

Kategorie	Bedeutung
Automatisierte Fehlererkennung verfügbar	Regeln erkennen die häufigen Fehlerbedingungen dieses Kriteriums zuverlässig. Ein erkannter Fehler ist ein belastbarer Nachweis für ein Problem; ein Ergebnis ohne Befund ist kein Nachweis für Konformität.
Teilweise automatisiert prüfbar	Regeln erfassen einige Fehlerbedingungen. Wesentliche Teile des Kriteriums liegen außerhalb dessen, was ein Scanner beobachten kann.
Manuelle Bewertung erforderlich	Keine automatisierte Regel deckt dieses Kriterium ab. Es braucht einen Menschen.

Regelkatalog – Aufwand & Verifikation

Jede Detailseite eines Problems nutzt einen statischen Regelkatalog, der – sofern wir die Regel oft genug gesehen haben, um sie zu kalibrieren – Folgendes angibt:

Aufwandsklasse – leicht (mechanisches Markup, unter 5 Min.), mittel (Code + kleinere Designentscheidung, 5–20 Min.), schwer (Design-Review, Textüberarbeitung oder architektonische Änderung, über 20 Min.).
Zeitschätzung – ungefährer Median in Minuten pro Vorkommen, sichtbar in der Zeile „Aufwand" der Metadaten-Leiste.
AT-Verifikationsrezept – Werkzeug (NVDA, VoiceOver, JAWS, Tastatur, DevTools) und nummerierte Schritte zur Bestätigung der Behebung. Wird als Abschnitt „Mit NVDA verifizieren" unter dem KI-Fix-Vorschlag dargestellt, damit auch QA ohne Vollzeit-Spezialisierung die manuelle Prüfung durchführen kann.

Die Problemliste hat außerdem einen Quick-Wins-Filter, der die offenen Probleme der Website auf die Aufwandsklasse leicht eingrenzt.

Abdeckung nach WCAG-Prinzip

Die Zahlen stammen aus dem Kriterienkatalog von AllyProof, der die 55 aktiven WCAG-2.2-A/AA-Erfolgskriterien enthält.

Prinzip	Aktive A/AA-Kriterien	Automatisierte Fehlererkennung	Teilweise prüfbar	Manuelle Bewertung erforderlich
1. Wahrnehmbar	20	4	8	8
2. Bedienbar	20	5	3	12
3. Verständlich	13	2	1	10
4. Robust	2	1	1	0
Gesamt	55	12	13	30

Kriterien mit automatisierter Fehlererkennung

Es gibt Regeln, die die häufigen Fehlerbedingungen dieser Kriterien zuverlässig erkennen. Lesen Sie jede Zeile als wie ein Fehler für den Scanner aussieht – nicht als Checkliste, mit der das Kriterium erfüllt wäre.

1.3.1 Info und Beziehungen – erkennt Fehler in Überschriftenstruktur, Formularbeschriftungen und Tabellen-Markup. Ob jede visuelle Beziehung programmatisch abgebildet ist, kann die Regel nicht bestätigen.
1.3.4 Ausrichtung – erkennt Ausrichtungssperren in CSS und Viewport-Metadaten.
1.4.3 Kontrast (Minimum) – berechnet Vordergrund-/Hintergrund-Kontrastverhältnisse, sofern beide auflösbar sind.
1.4.12 Textabstand – erkennt Deklarationen, die Nutzer-Overrides für Textabstände verhindern.
2.4.1 Blöcke umgehen – erkennt das Fehlen eines Sprunglinks oder einer Landmark-Struktur.
2.4.2 Seite mit Titel – erkennt fehlende oder leere <title>-Elemente. Ob der Titel die Seite beschreibt, kann die Regel nicht beurteilen.
2.4.4 Linkzweck (im Kontext) – erkennt leere Links und bekannte nichtssagende Linktexte. Ob der Zweck aus dem Kontext hervorgeht, kann die Regel nicht beurteilen.
2.5.3 Beschriftung im Namen – erkennt sichtbare Beschriftungen, die nicht im zugänglichen Namen enthalten sind.
2.5.8 Zielgröße (Minimum) – misst gerenderte Zielgrößen gegen das Minimum von 24 × 24 CSS-Pixeln.
3.1.1 Sprache der Seite – erkennt fehlendes oder ungültiges lang-Attribut am <html>-Element.
3.1.2 Sprache von Teilen – erkennt ungültige lang-Werte an Inline-Elementen. Unmarkierte fremdsprachige Passagen erkennt sie nicht.
4.1.2 Name, Rolle, Wert – validiert ARIA-Rollen, -Zustände und -Eigenschaften und erkennt Bedienelemente ohne zugänglichen Namen. Ob Name, Rolle und Wert in jedem Anwendungszustand korrekt sind, kann die Regel nicht bestätigen.

Teilweise automatisiert prüfbar

Regeln erfassen einige Fehler und können den Rest nicht sehen. Ein Ergebnis ohne Befund ist hier ein noch schwächerer Hinweis.

1.1.1 Nicht-Text-Inhalt – erkennt fehlendes oder leeres alt. Ob die Textalternative angemessen ist, kann nicht beurteilt werden.
1.3.2 Bedeutungstragende Reihenfolge – erkennt einige CSS-Umsortierungsmuster. Ob die Lesereihenfolge sinnvoll ist, nicht.
1.3.5 Eingabezweck bestimmen – erkennt fehlendes autocomplete an wahrscheinlichen Feldern. Ob das Token korrekt ist, nicht.
1.4.1 Verwendung von Farbe – erkennt einige rein farbliche Linkunterscheidungen. Nicht jeden Fall von Information-durch-Farbe.
1.4.2 Audio-Steuerelement – erkennt automatisch startende Medienelemente. Ob ein Bedienelement auffindbar ist, nicht.
1.4.4 Textgröße ändern – erkennt fixe Schriftgrößen. Das Layout bei 200 % Zoom kann nicht verifiziert werden.
1.4.10 Reflow – erkennt horizontales Überlaufen im Reflow-Viewport. Inhaltsverlust kann nicht beurteilt werden.
1.4.11 Nicht-Text-Kontrast – misst Kontraste an erkennbaren UI-Kanten. Nicht jedes grafische Objekt.
2.2.2 Pausieren, Beenden, Ausblenden – erkennt automatisch aktualisierende und animierte Inhalte. Ob ein Pausenmechanismus funktioniert, nicht.
2.4.3 Fokusreihenfolge – erkennt positives tabindex und ähnliche Anti-Patterns. Ob die Reihenfolge die Bedeutung erhält, nicht.
2.4.6 Überschriften und Beschriftungen – erkennt leere Überschriften und Beschriftungen. Ob sie aussagekräftig sind, nicht.
3.3.2 Beschriftungen oder Anweisungen – erkennt fehlende Beschriftungen. Ob Anweisungen ausreichen, nicht.
4.1.3 Statusmeldungen – erkennt Live-Region-Markup. Ob Statusänderungen tatsächlich angesagt werden, nicht.

Manuelle Bewertung erforderlich

30 der 55 Kriterien haben überhaupt keine automatisierte Regel. Sie erfordern menschliches Urteilsvermögen, Tests mit assistiver Technologie oder eine Bewertung von Bedeutung. Beispiele:

1.2.1–1.2.5 Zeitbasierte Medien – erfordern eine menschliche Bewertung von Untertiteln, Audiodeskription und Transkripten
1.3.3 Sensorische Eigenschaften – Anweisungen, die auf Form, Farbe, Größe oder Position beruhen
2.1.1 Tastatur und 2.1.2 Keine Tastaturfalle – erfordern die tatsächliche Bedienung ohne Maus
2.2.1 Zeitanpassung – erfordert das Durchspielen von Session-Timeouts und zeitgesteuerten Interaktionen
2.4.5 Verschiedene Wege – erfordert die Bewertung seitenübergreifender Navigationsalternativen
2.4.7 Fokus sichtbar – erfordert die Beurteilung der Indikator-Sichtbarkeit in realen Zuständen
3.2.3 Konsistente Navigation – erfordert einen seitenübergreifenden Vergleich
3.3.3 Fehlervorschlag und 3.3.4 Fehlervermeidung – erfordern das Durchspielen von Formularvalidierung und Bestätigungsschritten

Die Seite Manuelle AT-Verifikation enthält Schritt-für-Schritt-Rezepte, um einzelne Behebungen von Hand zu prüfen.

Warum nicht 100 %

Viele WCAG-Kriterien betreffen Absicht und Bedeutung, was automatisierte Werkzeuge grundsätzlich nicht bewerten können:

Ist dieser Alt-Text zutreffend? (Werkzeuge prüfen, ob er existiert – nicht, ob er stimmt.)
Sind diese Anweisungen verständlich? (Erfordert menschliches Textverständnis.)
Ergibt die Lesereihenfolge Sinn? (Erfordert Verständnis des Inhalts.)
Sind Untertitel synchron und korrekt? (Erfordert das Ansehen des Videos.)
Kann jemand eine Aufgabe allein mit der Tastatur abschließen? (Erfordert interaktives Testen.)

Das ist eine grundsätzliche Grenze jedes automatisierten Barrierefreiheitswerkzeugs, nicht eine Besonderheit von AllyProof. Wozu AllyProof sich verpflichtet: klar auszuweisen, auf welcher Seite dieser Linie jedes Kriterium liegt – damit ein Scan ohne Befund nie mit einem Konformitätsergebnis verwechselt wird.