WCAG 2.1 vs. 2.2: Was sich geändert hat und warum

WCAG 2.2 wurde im Oktober 2023 zur W3C-Empfehlung. Wenn Ihre Website gegen WCAG 2.1 auditiert wurde, scheitert sie möglicherweise bereits an Kriterien, die heute die rechtliche Konformität in der EU, im Vereinigten Königreich und zunehmend auch in US-Durchsetzungsverfahren definieren. Dieser Leitfaden geht jede Änderung durch — was hinzugekommen ist, was entfallen ist und was jedes Kriterium in der Praxis bedeutet.

Kurzer Rückblick: Was WCAG 2.1 ergänzt hat

WCAG 2.1 (veröffentlicht 2018) erweiterte den ursprünglichen 2.0-Standard um 17 neue Erfolgskriterien mit Fokus auf drei bis dahin unterversorgte Gruppen:

Mobile Nutzende — Touch-Gesten, Bildschirmausrichtung, Zeigergenauigkeit
Nutzende mit Sehbehinderung — Umbruch (Reflow), Nicht-Text-Kontrast, Textabstände
Kognitive und sprachliche Behinderungen — Zeitlimits, Statusmeldungen

WCAG 2.2 baut direkt auf 2.1 auf. Jede Anforderung aus 2.1 gilt weiterhin. Die Frage lautet: Was hat 2.2 obendrauf ergänzt?

Was WCAG 2.2 ergänzt hat: 9 neue Erfolgskriterien

2.4.11 Fokus nicht verdeckt (Minimum) — Stufe AA

Wenn eine Komponente den Tastaturfokus erhält, darf sie nicht vollständig von anderen Inhalten verdeckt werden (Sticky-Header, Cookie-Banner, Chat-Widgets). Mindestens ein Teil des fokussierten Elements muss sichtbar bleiben.

Häufiger Fehler: Eine fixierte Navigationsleiste verdeckt das fokussierte Formularfeld, während sich eine nutzende Person mit der Tabulatortaste durch die Seite bewegt.

2.4.12 Fokus nicht verdeckt (Erweitert) — Stufe AAA

Strengere Version von 2.4.11 — die fokussierte Komponente muss vollständig sichtbar sein, nicht nur teilweise.

2.4.13 Fokus-Erscheinungsbild — Stufe AA

Tastatur-Fokusindikatoren müssen Mindestwerte für Größe und Kontrast erfüllen:

Die Fläche des Fokusindikators muss mindestens so groß sein wie ein 2 CSS-Pixel breiter Rahmen um die Komponente
Der Kontrast zwischen fokussiertem und nicht fokussiertem Zustand muss mindestens 3:1 betragen

Das geht weiter als das bestehende 2.4.7 (Fokus sichtbar), das lediglich verlangte, dass überhaupt ein Fokusindikator vorhanden ist.

Häufiger Fehler: Eine dünne, 1 Pixel breite gepunktete Umrandung mit geringem Kontrast erfüllt 2.4.7, scheitert aber an 2.4.13.

2.5.7 Ziehbewegungen — Stufe AA

Jede Aktion, die Ziehen erfordert, muss auch mit einem einzelnen Zeiger (Tippen oder Klicken) ausführbar sein. Das kommt Nutzenden mit motorischen Einschränkungen zugute, die Ziehvorgänge nicht zuverlässig steuern können.

Beispiel: Eine sortierbare Liste muss eine Alternative anbieten (etwa Auf-/Ab-Schaltflächen) für Menschen, die Elemente nicht ziehen können.

2.5.8 Zielgröße (Minimum) — Stufe AA

Interaktive Ziele (Schaltflächen, Links, Formularelemente) müssen mindestens 24×24 CSS-Pixel groß sein — oder ausreichenden Abstand zu benachbarten Zielen haben, sodass die gesamte Aktivierungsfläche den Schwellenwert erreicht.

Das ist die Minimalversion. Das erweiterte Kriterium (2.5.5, aus 2.1 auf Stufe AAA übernommen) empfiehlt 44×44 Pixel.

Häufige Fehler: Reine Symbol-Schaltflächen, Schließen-Symbole (×) und Inline-Textlinks in eng gesetzten Navigationsmenüs.

3.2.6 Konsistente Hilfe — Stufe A

Bietet eine Website einen Hilfemechanismus an (Telefonnummer, Chat-Link, Kontaktformular, FAQ-Link), muss dieser auf allen Seiten, auf denen er vorhanden ist, an derselben relativen Position erscheinen. Nutzende mit kognitiven Behinderungen sind häufig auf vorhersehbare Platzierung angewiesen.

3.3.7 Redundante Eingabe — Stufe A

Informationen, die eine nutzende Person in derselben Sitzung bereits übermittelt hat, dürfen nicht erneut verlangt werden — es sei denn, die erneute Eingabe ist wesentlich (z. B. ein Feld zur Passwortbestätigung) oder die Daten sind sicherheitsrelevant.

Beispiel: Ein mehrstufiger Checkout sollte in Schritt 3 nicht nach der Rechnungsadresse fragen, wenn sie in Schritt 1 bereits eingegeben wurde.

3.3.8 Barrierefreie Authentifizierung (Minimum) — Stufe AA

Authentifizierungsschritte dürfen nicht auf einem kognitiven Funktionstest beruhen — Objekte erkennen, Zeichen abtippen oder Rätsel lösen — es sei denn, es wird eine Alternative angeboten oder der Test besteht darin, nutzergesteuerte Inhalte zu erkennen (etwa ein selbst hochgeladenes Foto).

Häufige Fehler: CAPTCHAs, bei denen verzerrter Text ohne Audio-Alternative erkannt werden muss, oder „Klicken Sie alle Bilder mit Ampeln an”-Aufgaben.

3.3.9 Barrierefreie Authentifizierung (Erweitert) — Stufe AAA

Die erweiterte Version streicht sogar die Ausnahme für nutzergesteuerte Inhalte. Im Authentifizierungsablauf ist kein kognitiver Funktionstest zulässig.

Was WCAG 2.2 gestrichen hat: 4.1.1 Parsen

WCAG 2.1 enthielt 4.1.1 Parsen (Stufe A), das wohlgeformtes HTML verlangte — eindeutige Element-IDs, korrekt verschachtelte Tags und vollständige Start-/End-Tag-Paare. Moderne Browser wurden so gut darin, fehlerhaftes HTML stillschweigend zu korrigieren, dass dieses Kriterium in der Praxis nicht mehr messbar war.

In WCAG 2.2 ist 4.1.1 Parsen als überholt gekennzeichnet und gilt stets als erfüllt. Sie müssen es nicht mehr auditieren, auch wenn sauberes HTML nach wie vor bewährte Praxis bleibt.

Übersichtstabelle

Kriterium	Stufe	Thema
2.4.11 Fokus nicht verdeckt (Min.)	AA	Tastaturfokus
2.4.12 Fokus nicht verdeckt (Erweitert)	AAA	Tastaturfokus
2.4.13 Fokus-Erscheinungsbild	AA	Fokusindikator
2.5.7 Ziehbewegungen	AA	Zeigereingabe
2.5.8 Zielgröße (Minimum)	AA	Touch-Ziele
3.2.6 Konsistente Hilfe	A	Vorhersehbarkeit
3.3.7 Redundante Eingabe	A	Formulare
3.3.8 Barrierefreie Authentifizierung (Min.)	AA	Login / CAPTCHA
3.3.9 Barrierefreie Authentifizierung (Erweitert)	AAA	Login / CAPTCHA
~~4.1.1 Parsen~~	A	Gestrichen

Wer muss umstellen?

Praktisch alle. WCAG 2.2 ist inzwischen die Basis, auf die sich Folgendes bezieht:

Der European Accessibility Act (EAA), in Kraft seit Juni 2025
Der harmonisierte Standard EN 301 549 (aktualisiert mit Verweis auf WCAG 2.2)
Die britischen Public Sector Bodies Accessibility Regulations (aktualisierte Leitlinien)
Zahlreiche US-Bundesstaatengesetze und informelle Durchsetzungspositionen des DOJ

Wenn Ihr letztes vollständiges Audit gegen WCAG 2.1 AA lief, konzentrieren Sie Ihre Umstellung auf diese fünf Kriterien, die die meisten Websites betreffen: 2.4.11, 2.4.13, 2.5.8, 3.3.8 und 3.3.7 (falls Sie mehrstufige Formulare oder Checkouts haben).

So auditieren Sie die neuen Kriterien

Die meisten automatisierten Scanner markieren inzwischen 2.5.8 (Zielgröße) und Teilfälle von 2.4.13 (Fokus-Erscheinungsbild). Folgendes erfordert jedoch manuelles Testen:

2.4.11 / 2.4.12 — Bewegen Sie sich mit der Tabulatortaste durch jede Seite bei aktiven Sticky-Headern/-Footern und bestätigen Sie, dass fokussierte Elemente sichtbar sind
2.4.13 — Messen Sie Abmessungen und Kontrast des Fokusindikators mit den Browser-DevTools oder einem Kontrast-Checker
2.5.7 — Identifizieren Sie jede Ziehinteraktion und prüfen Sie, ob eine Alternative mit einem einzelnen Zeiger existiert
3.2.6 — Prüfen Sie, ob Hilfe-Links seitenübergreifend an konsistenten Positionen erscheinen
3.3.7 — Gehen Sie alle mehrstufigen Abläufe durch und bestätigen Sie, dass keine Daten zweimal abgefragt werden
3.3.8 — Testen Sie jeden Login-, Registrierungs- und Verifizierungsschritt auf kognitive Funktionstests

WCAG 2.2 ist kein völliger Neuentwurf — es ist ein gezielter Satz von Ergänzungen, der reale Barrieren adressiert, die 2.1 übersehen hat. Die gute Nachricht: Die meisten neuen AA-Kriterien lassen sich mit fokussierter Nachbesserungsarbeit lösen, statt mit einem kompletten Website-Neubau.

Verwandt: Website WCAG 2.2-konform machen · Leitfaden zu manuellen Barrierefreiheits-Audits