WCAG-Abdeckung

WCAG 2.2 Level AA umfasst 56 Erfolgskriterien. Der Multi-Engine-Scanner von AllyProof kann etwa 57–70 % davon automatisch testen. Diese Seite erklärt, was abgedeckt ist, was nicht, und warum die Lücke besteht.

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. Befunde, die einem dieser neun zuzuordnen sind, tragen auf der Problem-Detailseite ein Neu in 2.2-Badge, sodass Kunden, die auf 2.2-Konformität prüfen, auf einen Blick sehen, welche ihrer 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 Fokusdarstellung – 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

Regelkatalog – Schwierigkeit & Verifikation

Jede Problem-Detailseite nutzt einen statischen Regelkatalog, der dort, wo die Regel schon oft genug beobachtet wurde, um sie einzustufen, Folgendes angibt:

Schwierigkeitsstufe – einfach (mechanisches Markup, unter 5 Min.), mittel (Code + kleinere Design-Entscheidung, 5–20 Min.), schwer (Design-Review, Content-Überarbeitung oder architektonische Änderung, über 20 Min.).
Zeitschätzung – grober Median in Minuten, um ein Vorkommen zu beheben, sichtbar in der Aufwand-Zeile des Metadaten-Streifens.
AT-Verifikationsrezept – Werkzeug (NVDA, VoiceOver, JAWS, Tastatur, DevTools) und nummerierte Schritte zur Bestätigung des Fixes. Wird als Abschnitt "Mit NVDA prüfen" unter dem KI-Fix-Vorschlag angezeigt, sodass QA-Personal ohne Vollzeit-Barrierefreiheits-Spezialisierung die manuelle Prüfung durchführen kann.

Die Problemliste hat außerdem einen Quick-Wins-Chip, der die offenen Probleme der aktuellen Website auf die Schwierigkeitsstufe einfach filtert – nützlich, um "was kann ein Junior heute Nachmittag erledigen?" ohne JQL zu beantworten.

Die 57-%-Basislinie

Die vielzitierte "57 %"-Zahl stammt aus Untersuchungen zur Regelabdeckung von axe-core gegenüber WCAG-2.x-Erfolgskriterien. Mit axe-core allein hat etwa 57 % der WCAG-2.2-AA-Kriterien mindestens eine automatisierte Regel, die Fehler erkennen kann.

Durch das Hinzufügen von HTML_CodeSniffer als zweite Engine erweitert AllyProof die Abdeckung auf etwa 67–70 %. Die zusätzlichen Regeln finden Probleme, die axe-cores strikte Zero-False-Positive-Richtlinie überspringt.

Abdeckung nach WCAG-Prinzip

Prinzip	AA-Kriterien gesamt	Vollständig automatisierbar	Teilweise automatisierbar	Nur manuell
1. Wahrnehmbar	16	7	4	5
2. Bedienbar	20	6	5	9
3. Verständlich	11	4	3	4
4. Robust	9	3	3	3
Gesamt	56	~20	~15	~21

Vollständig automatisierbare Kriterien

Diese Kriterien können mit hoher Konfidenz durch automatisierte Regeln getestet werden. Ein bestandenes Scan-Ergebnis ist ein starker Hinweis auf Konformität:

1.1.1 Nicht-Text-Inhalte – Erkennt Bilder ohne Alt-Attribute, leeren Alt-Text bei nicht dekorativen Bildern
1.3.1 Informationen und Beziehungen – Prüft korrekte Überschriftenstruktur, Formularbeschriftungen, Tabellen-Markup
1.4.3 Kontrast (Minimum) – Berechnet Vordergrund-/Hintergrund-Farbkontrastverhältnisse
1.4.11 Nicht-Text-Kontrast – Prüft Kontrast von UI-Komponenten und grafischen Objekten
2.1.1 Tastatur – Erkennt interaktive Elemente, die nicht per Tastatur erreichbar sind
2.4.1 Blöcke überspringen – Prüft auf Skip-Navigation-Links oder Landmarken
2.4.2 Seite betitelt – Verifiziert, dass Seiten aussagekräftige Titel haben
2.4.4 Linkzweck (im Kontext) – Erkennt leere Links und Links mit nicht aussagekräftigem Text
3.1.1 Sprache der Seite – Prüft das lang-Attribut am HTML-Element
3.1.2 Sprache von Teilen – Erkennt Inhalte in anderen Sprachen ohne lang-Attribute
4.1.1 Parsing – Erkennt doppelte IDs und andere Markup-Fehler
4.1.2 Name, Rolle, Wert – Prüft ARIA-Rollen, -Zustände und -Eigenschaften

Und etwa 8 weitere mit starker automatisierter Abdeckung.

Teilweise automatisierbare Kriterien

Diese Kriterien haben automatisierte Regeln, die manche Fehler erkennen, aber nicht alle. Ein sauberes Scan-Ergebnis garantiert keine Konformität – eine manuelle Prüfung wird weiterhin empfohlen:

1.3.2 Sinnvolle Reihenfolge – Kann einige CSS-Umordnungsprobleme erkennen, aber nicht beurteilen, ob die Lesereihenfolge sinnvoll ist
1.3.5 Eingabezweck identifizieren – Kann autocomplete-Attribute in Formularen prüfen, aber nicht verifizieren, dass sie korrekt sind
1.4.4 Textgröße ändern – Kann feste Schriftgrößen erkennen, aber das Layout bei 200 % Zoom nicht verifizieren
2.4.6 Überschriften und Beschriftungen – Kann leere Überschriften und Beschriftungen erkennen, aber nicht beurteilen, ob sie aussagekräftig sind
2.4.7 Fokus sichtbar – Kann outline: none ohne Ersatz erkennen, aber die Sichtbarkeit des Fokusindikators nicht in allen Zuständen beurteilen
3.3.2 Beschriftungen oder Anweisungen – Kann fehlende Beschriftungen erkennen, aber nicht beurteilen, ob Anweisungen ausreichend sind

Und etwa 9 weitere mit teilweiser automatisierter Abdeckung.

Nur manuell prüfbare Kriterien

Diese Kriterien können von automatisierten Werkzeugen nicht sinnvoll getestet werden. Sie erfordern menschliches Urteilsvermögen, Tests mit assistiver Technologie oder eine Bewertung der inhaltlichen Bedeutung:

1.2.1–1.2.5 Zeitbasierte Medien – Erfordern menschliche Bewertung von Untertiteln, Audiodeskriptionen und Transkripten
1.3.3 Sensorische Eigenschaften – Anweisungen, die sich allein auf Form, Farbe, Größe oder Position stützen
2.1.2 Keine Tastaturfalle – Erfordert interaktives Testen aller fokussierbaren Elemente
2.2.1 Zeitlimits anpassbar – Erfordert Testen von Sitzungs-Timeouts und zeitgesteuerten Interaktionen
2.4.5 Mehrere Wege – Erfordert Bewertung alternativer Navigationsmöglichkeiten der Website
3.2.3 Konsistente Navigation – Erfordert seitenübergreifenden Vergleich von Navigationsmustern
3.3.3 Fehlervorschlag – Erfordert Testen von Formularvalidierungsmeldungen auf Hilfreichkeit
3.3.4 Fehlervermeidung (Rechtlich, Finanziell, Daten) – Erfordert Testen von Bestätigungs- und Überprüfungsschritten

Und etwa 13 weitere, die eine rein manuelle Bewertung erfordern.

Was "Nicht bewertet" in VPATs bedeutet

Wenn AllyProof ein Entwurfs-VPAT generiert, werden Kriterien der Kategorie "nur manuell" als Nicht bewertet gekennzeichnet. Diese Konformitätsstufe bedeutet:

Das Kriterium wurde nicht getestet, weil keine automatisierte Regel es abdeckt
Dies ist nicht dasselbe wie "Wird nicht unterstützt" – es bedeutet, dass das Ergebnis unbekannt ist
Ein menschlicher Barrierefreiheitsprüfer sollte diese Kriterien bewerten und das VPAT entsprechend der tatsächlichen Konformität aktualisieren

Die VPAT-Anmerkungsspalte für "Nicht bewertet"-Kriterien enthält einen Hinweis, welche Art von manuellem Test empfohlen wird (z. B. "Screenreader-Test erforderlich" oder "Nur-Tastatur-Navigationstest erforderlich").

Warum nicht 100 %?

Viele WCAG-Kriterien erfordern das Verständnis von Absicht und Bedeutung, was automatisierte Werkzeuge grundsätzlich nicht beurteilen können:

Ist dieser Alt-Text korrekt? (Werkzeuge können verifizieren, dass er existiert, nicht, dass er richtig ist.)
Sind diese Anweisungen klar? (Erfordert menschliches Verständnis.)
Ergibt die Lesereihenfolge Sinn? (Erfordert Verständnis der Inhaltsstruktur.)
Sind Untertitel synchron und korrekt? (Erfordert das Ansehen des Videos.)
Kann ein Nutzer eine Aufgabe abschließen, nur mit der Tastatur? (Erfordert interaktives Testen.)

Dies ist eine inhärente Einschränkung aller automatisierten Barrierefreiheits-Testwerkzeuge, nicht spezifisch für AllyProof. Die Zahl von 57–70 % ist branchenweit konsistent. AllyProof maximiert die automatisierte Abdeckung und zeigt klar auf, wo manuelles Testen nötig ist.