WCAG 2.2 — Was ändert sich für deutsche Websites?

Im Oktober 2023 hat das W3C die WCAG 2.2 veröffentlicht — die erste Aktualisierung der Web Content Accessibility Guidelines seit 2018. Neun neue Erfolgskriterien, fokussiert auf kognitive Barrierefreiheit, motorische Einschränkungen und bessere Fokus-Verwaltung. Dieser Artikel erklärt jedes einzelne Kriterium praxisnah und ordnet ein, was das für deutsche Webseitenbetreiber unter dem BFSG bedeutet.

Was ist WCAG 2.2?

WCAG 2.2 ist die Weiterentwicklung von WCAG 2.1. Sie ist rückwärtskompatibel: Alles, was nach 2.1 konform ist, bleibt konform. Die neuen Kriterien schließen Lücken, die in der Praxis besonders Menschen mit kognitiven Einschränkungen und motorischen Behinderungen betreffen.

Eine technische Änderung: Kriterium 4.1.1 Parsing wurde als „immer erfüllt“ deklariert (moderne Browser korrigieren Parsing-Fehler automatisch). Es wurde nicht entfernt, gilt aber als obsolet.

Die 9 neuen Erfolgskriterien im Detail

1. Focus Not Obscured (Minimum) — 2.4.11 (Level AA)

Was es verlangt: Wenn ein Element den Tastatur-Fokus erhält, darf es nicht vollständig von anderen Inhalten verdeckt werden — zum Beispiel durch Cookie-Banner, Sticky-Header oder Chat-Widgets.

Praxis-Beispiel: Ein Cookie-Banner am unteren Bildschirmrand verdeckt den „In den Warenkorb“-Button. Ein Tastatur-Nutzer tabbt auf den Button, sieht aber nichts — der Fokus ist hinter dem Banner versteckt. Das ist ein Verstoß.

Fix: Cookie-Banner müssen den Seiten-Inhalt nach oben verschieben (nicht überlagern) oder zumindest so positioniert sein, dass fokussierte Elemente sichtbar bleiben. Sticky-Header: scroll-padding-top in CSS setzen.

2. Focus Not Obscured (Enhanced) — 2.4.12 (Level AAA)

Strengere Variante: Das fokussierte Element darf überhaupt nicht verdeckt sein — auch nicht teilweise. Für die meisten Websites kein realistisches Ziel, aber gut zu kennen.

3. Focus Appearance — 2.4.13 (Level AAA)

Was es verlangt: Der Fokus-Indikator muss eine Mindestgröße und einen Mindestkontrast haben. Konkret: mindestens 2px Umriss mit 3:1 Kontrastverhältnis zum Hintergrund und zum Element selbst.

Praxis-Tipp: Die meisten modernen Design-Systeme erfüllen das bereits mit outline: 2px solid #1e40af; outline-offset: 2px;. Wer CSS-Resets mit outline: none nutzt, muss einen Ersatz definieren.

4. Dragging Movements — 2.5.7 (Level AA)

Was es verlangt: Jede Funktion, die Drag-and-Drop nutzt, muss eine Alternative per einfachem Klick (Single Pointer) bieten. Nicht jeder kann präzise ziehen — Tremor, Spastik, Touch-Geräte.

Praxis-Beispiele:

• Sortierbare Listen: Drag-and-Drop zum Umsortieren? Zusätzliche „Hoch“/„Runter“-Buttons anbieten.
• Kartenausschnitte: Google-Maps-Embeds? Zoom- und Scroll-Buttons als Alternative.
• Bild-Crop-Tools: Koordinatenfelder für den Zuschnitt als Fallback.

5. Target Size (Minimum) — 2.5.8 (Level AA)

Was es verlangt: Klickbare Elemente müssen mindestens 24×24 CSS-Pixel groß sein (oder ausreichend Abstand zu Nachbar-Zielen haben).

Ausnahmen: Inline-Links im Fließtext, Elemente deren Größe vom User-Agent bestimmt wird (native Checkboxen), und Elemente die bereits 24px Abstand zum nächsten Klick-Ziel haben.

Praxis-Tipp: Setze auf min-height: 44px; min-width: 44px; für Buttons und Links in der Navigation. Das erfüllt gleichzeitig das strengere AAA-Kriterium (44×44px) und ist auf Mobilgeräten ohnehin Standard.

6. Consistent Help — 3.2.6 (Level A)

Was es verlangt: Wenn eine Webseite Hilfe-Mechanismen anbietet (Kontakt-Telefon, Chat-Widget, FAQ-Link), müssen diese auf jeder Seite an der gleichen Stelle stehen.

Warum: Menschen mit kognitiven Einschränkungen können sich nicht merken, wo Hilfe zu finden war. Konsistenz reduziert kognitive Last.

Fix: Hilfe-Links im Footer oder Header — gleiche Position auf jeder Seite. Chat-Widgets: immer gleiche Ecke. Wenn eine Seite einen „Hilfe“-Link im Header hat, müssen alle Seiten diesen Link an der gleichen Stelle haben.

7. Redundant Entry — 3.3.7 (Level A)

Was es verlangt: Informationen, die der Nutzer bereits in einem früheren Schritt eingegeben hat, dürfen nicht erneut abgefragt werden — es sei denn, es ist sicherheitsrelevant (z.B. Passwort-Bestätigung).

Praxis-Beispiel: Ein mehrseitiger Checkout fragt Rechnungsadresse auf Seite 2 und Lieferadresse auf Seite 3. Wenn beides identisch ist, sollte eine Checkbox „Lieferadresse = Rechnungsadresse“ vorausgefüllt sein — nicht der Nutzer alles nochmal tippen müssen.

Weitere Beispiele: Formulare, die E-Mail-Adresse auf Seite 1 und nochmal auf Seite 3 abfragen. Flugbuchungen, die Passagiernamen mehrfach eingeben lassen.

8. Accessible Authentication (Minimum) — 3.3.8 (Level AA)

Was es verlangt: Der Login-Prozess darf keine kognitiven Funktionstests voraussetzen — also kein Erinnern an Passwörter (ohne Passwort-Manager-Unterstützung), kein Lösen von Rätseln, kein Erkennen von Objekten.

Erlaubt: Passwort-Felder, die Copy-Paste und Autofill zulassen. Biometrische Authentifizierung (Fingerabdruck, Face ID). WebAuthn/Passkeys. 2FA per SMS/E-Mail.

Problematisch: CAPTCHAs, die Rätsel-Lösung erfordern (Bilder auswählen, verzerrte Texte lesen). Websites, die autocomplete="off" auf Passwort-Feldern setzen und damit Passwort-Manager blockieren.

Fix: autocomplete="current-password" auf Login-Felder setzen. CAPTCHAs durch reCAPTCHA v3 (unsichtbar, Score-basiert) oder hCaptcha Accessibility ersetzen. Passwort-Manager nicht blockieren.

9. Accessible Authentication (Enhanced) — 3.3.9 (Level AAA)

Strengere Variante: Überhaupt keine kognitive Anforderung beim Login. Praktisch: nur biometrisch oder Passkey-basiert. Für die meisten Websites unrealistisch, aber die Richtung ist klar.

Übersichtstabelle: Alle 9 Kriterien auf einen Blick

Davon BFSG-relevant (wenn 2.2 übernommen wird): Level A + AA — also 6 von 9 Kriterien: 2.4.11, 2.5.7, 2.5.8, 3.2.6, 3.3.7, 3.3.8.

Was bedeutet das für bf-check und deinen Scan?

bf-check prüft aktuell gegen WCAG 2.1 Level AA — das ist der gesetzliche Stand unter dem BFSG. Sobald die EN 301 549 auf WCAG 2.2 aktualisiert wird, werden die neuen Kriterien in unseren Scanner integriert.

Im Footer jeder Seite findest du den Hinweis: „Aktuell geprüft: WCAG 2.1 AA (letzte Aktualisierung: April 2026)“

Sofort-Maßnahmen: Was du jetzt schon umsetzen kannst

Auch wenn WCAG 2.2 noch nicht gesetzlich verpflichtend ist, lohnt sich die Umsetzung dieser Punkte sofort — sie verbessern die Nutzererfahrung und kosten wenig:

1. Target Size prüfen: Sind alle Buttons und Links mindestens 44px hoch? Auf Mobilgeräten ist das sowieso Best Practice.
2. Cookie-Banner-Position: Verdeckt dein Banner fokussierte Elemente? Teste mit Tab-Taste.
3. autocomplete auf Login-Feldern: autocomplete="current-password" und autocomplete="username" setzen. Passwort-Manager nicht blockieren.
4. Hilfe-Link konsistent: Wenn du Kontakt/Hilfe anbietest, steht der Link auf jeder Seite an der gleichen Stelle?
5. Mehrstufige Formulare: Werden Daten automatisch übernommen oder muss der Nutzer alles zweimal eingeben?
6. Drag-and-Drop: Gibt es überall eine Klick-Alternative?

WCAG 2.2 vs. WCAG 3.0 — was kommt als Nächstes?

WCAG 3.0 (Silver) ist seit Jahren in Entwicklung und wird das gesamte Bewertungsmodell überarbeiten: statt A/AA/AAA ein Scoring-System, stärkerer Fokus auf kognitive Barrierefreiheit, Tests mit echten Nutzern. Realistische Veröffentlichung: frühestens 2028. Für aktuelle Planung irrelevant — WCAG 2.2 ist das Ziel.

Zusammenfassung

1. WCAG 2.2 ist seit Oktober 2023 veröffentlicht, aber in Deutschland noch nicht gesetzlich verpflichtend.
2. 9 neue Kriterien fokussieren sich auf Fokus-Verwaltung, motorische Barrierefreiheit und kognitive Zugänglichkeit.
3. 6 davon sind Level A oder AA und werden voraussichtlich 2027/2028 in die EN 301 549 und damit ins BFSG übernommen.
4. Wer jetzt 2.1 AA erfüllt, hat den größten Teil der Arbeit erledigt. Die 2.2-Neuerungen sind gezielte Ergänzungen, kein Neuanfang.
5. Sofort umsetzbar: Target Size, Cookie-Banner-Position, autocomplete, konsistente Hilfe.