Was ist die WCAG 2.2 – und warum ist sie wichtig?
Die Web Content Accessibility Guidelines (WCAG) 2.2 sind seit dem 5. Oktober 2023 die aktuelle W3C-Empfehlung für barrierefreie Webinhalte. Sie ergänzen die WCAG 2.1 um neun neue Erfolgskriterien und streichen ein veraltetes. Für Unternehmen, die unter das Barrierefreiheitsstärkungsgesetz fallen, ist die 2.2 der empfohlene Stand der Technik – auch wenn die EN 301 549 formal noch auf 2.1 verweist.
Die Stoßrichtung der neuen Kriterien ist klar: Sie verbessern die Bedienbarkeit für Menschen mit motorischen Einschränkungen, mit kognitiven Beeinträchtigungen und für alle, die ohne Maus arbeiten. Wer die Grundlagen der vier WCAG-Prinzipien kennt, findet sich schnell zurecht – die Neuerungen verteilen sich auf die Prinzipien „bedienbar” und „verständlich”.
Welche Kriterien sind neu in WCAG 2.2?
Neun Erfolgskriterien kommen hinzu: zwei auf Stufe A, vier auf Stufe AA und drei auf Stufe AAA. Für die Konformitätsstufe AA – den Maßstab von BFSG und BITV 2.0 – sind also sechs neue Anforderungen relevant:
- 2.4.11 Fokus nicht verdeckt (Minimum) – AA
- 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
Dazu kommen drei AAA-Kriterien: 2.4.12 Fokus nicht verdeckt (Erweitert), 2.4.13 Fokus-Erscheinungsbild und 3.3.9 Barrierefreie Authentifizierung (Erweitert). Gestrichen wurde 4.1.1 Syntaxanalyse – moderne Browser und Hilfstechnologien kommen mit kleineren HTML-Fehlern zurecht, das Kriterium war praktisch überholt.
Fokus nicht verdeckt: Der Tastaturfokus muss sichtbar bleiben
Kriterium 2.4.11 verlangt, dass ein Element mit Tastaturfokus niemals vollständig von anderen Inhalten verdeckt wird. Die typischen Übeltäter: Cookie-Banner, Sticky-Header, Chat-Widgets und aufklappende Fußzeilen. Wer mit der Tab-Taste durch eine Seite navigiert und der Fokus verschwindet hinter einem fixierten Banner, verliert die Orientierung komplett.
In der Praxis heißt das: Prüfen Sie jede fixierte Fläche Ihrer Website mit der Tastatur. Ein scroll-padding in Höhe des Sticky-Headers löst das Problem oft mit einer einzigen CSS-Zeile. Das AAA-Kriterium 2.4.12 geht weiter und verlangt, dass gar kein Teil des fokussierten Elements verdeckt wird – erstrebenswert, aber nicht Pflicht.
Zielgröße: Mindestens 24 mal 24 Pixel für Bedienelemente
Kriterium 2.5.8 fordert für interaktive Ziele eine Größe von mindestens 24 × 24 CSS-Pixeln – oder einen entsprechenden Abstand zu benachbarten Zielen. Zu kleine Buttons, eng gesetzte Icon-Leisten und gedrängte Linklisten sind eine der häufigsten Hürden für Menschen mit Tremor, eingeschränkter Feinmotorik oder schlicht großen Daumen auf kleinen Displays.
Ausnahmen gibt es für Links im Fließtext, für Ziele mit ausreichend Abstand und für Fälle, in denen eine gleichwertige größere Alternative existiert. Faustregel für die Umsetzung: Icon-Buttons auf mindestens 24 Pixel Klickfläche bringen, besser 44 – das deckt auch die strengeren Mobile-Empfehlungen ab. Wie Sie solche Anforderungen von Anfang an einplanen, zeigt unsere Checkliste für barrierefreie Websites.
Ziehbewegungen: Drag-and-Drop braucht eine Alternative
Kriterium 2.5.7 verlangt, dass jede Funktion, die eine Ziehbewegung erfordert, auch mit einfachen Klicks oder Taps bedienbar ist. Betroffen sind Slider, Kanban-Boards, sortierbare Listen, Karten-Interfaces und Datei-Uploads per Drag-and-Drop. Für Menschen, die einen Kopfzeiger, eine Sprachsteuerung oder einen Taster nutzen, sind präzise Ziehbewegungen oft unmöglich.
Die Lösung ist meist einfach: Ein Slider bekommt Plus-Minus-Buttons oder ein Eingabefeld, eine sortierbare Liste bekommt „nach oben/unten”-Schaltflächen, der Upload-Bereich akzeptiert auch einen klassischen Dateidialog. Wichtig: Die Alternative muss dieselbe Funktion vollständig abdecken, nicht nur einen Teil.
Konsistente Hilfe und redundante Eingabe: Weniger Hürden in Formularen
Zwei neue A-Kriterien zielen auf kognitive Barrieren. Konsistente Hilfe (3.2.6) verlangt, dass Hilfeangebote – Kontaktlink, Telefonnummer, Chat – auf allen Seiten an derselben Stelle in derselben Reihenfolge erscheinen. Wer Hilfe sucht, soll sie nicht auf jeder Seite neu suchen müssen.
Redundante Eingabe (3.3.7) verbietet, dass Nutzer dieselbe Information in einem Prozess mehrfach eintippen müssen. Das klassische Beispiel: Die Lieferadresse ist bereits erfasst, die Rechnungsadresse muss trotzdem komplett neu eingegeben werden. Zulässig sind stattdessen eine Checkbox („Rechnungsadresse entspricht Lieferadresse”), Autofill oder eine sichtbare Übernahme der Daten. Gerade in Checkout-Strecken von Online-Shops ist das ein Kriterium mit direktem Umsatz-Effekt: Jede unnötige Eingabe kostet Abschlüsse.
Barrierefreie Authentifizierung: Login ohne Gedächtnistest
Kriterium 3.3.8 ist die vielleicht spürbarste Neuerung: Ein Login darf keinen „kognitiven Funktionstest” erzwingen – also kein Auswendiglernen, Abtippen oder Puzzle-Lösen ohne Alternative. Konkret problematisch sind: Passwortfelder, die Einfügen per Copy-and-Paste blockieren, CAPTCHAs mit verzerrten Zeichen und Rätsel-Aufgaben ohne barrierefreie Ausweichoption.
Konform sind dagegen: Passwort-Manager-freundliche Felder (Einfügen erlaubt, autocomplete-Attribute gesetzt), Passkeys, Magic Links per E-Mail und Objekterkennungs-CAPTCHAs als Ausnahme. Für die meisten Websites ist die Umsetzung trivial – sie besteht darin, vorhandene Blockaden zu entfernen, statt etwas Neues zu bauen. Das AAA-Pendant 3.3.9 lässt auch die Objekterkennungs-Ausnahme entfallen.
Was bedeutet WCAG 2.2 für BFSG-pflichtige Unternehmen?
Das BFSG verweist über die harmonisierte Norm EN 301 549 derzeit auf WCAG 2.1 AA – die WCAG 2.2 AA wird jedoch ausdrücklich empfohlen und dürfte mit der nächsten Normfassung verbindlich werden. Wer jetzt Barrieren abbaut, sollte direkt gegen 2.2 AA prüfen: Der Mehraufwand gegenüber 2.1 ist gering, und eine erneute Nachrüstung in ein bis zwei Jahren entfällt.
Ob Ihr Unternehmen überhaupt unter das Gesetz fällt, klärt unser BFSG-Check in fünf Fragen. Und da automatische Tools nur einen Teil der Kriterien erkennen, gehört zu jeder 2.2-Prüfung auch ein manueller Durchgang – wie das geht, zeigt unser Leitfaden zum Testen der Barrierefreiheit.
Wie prüfe ich meine Website auf WCAG 2.2?
Der pragmatische Einstieg in drei Schritten: Erstens ein automatischer Scan, der Verstöße gegen maschinell prüfbare Kriterien findet – etwa Kontraste, fehlende Alternativtexte und Formular-Labels. Zweitens ein manueller Tastatur-Durchgang: Tab-Reihenfolge, Fokus-Sichtbarkeit hinter Sticky-Elementen, Bedienbarkeit aller Drag-Funktionen ohne Ziehen. Drittens ein Blick auf Login und Formulare: Einfügen erlaubt? Doppeleingaben vermieden? Hilfe konsistent platziert?
friendlyuse unterstützt genau diesen Zyklus: automatisches Scannen nach dem aktuellen WCAG-2.2-Katalog, priorisierte Befunde mit konkreten Selektoren und fortlaufendes Monitoring, damit neue Inhalte keine neuen Barrieren einschleppen. So wird aus der einmaligen Prüfung ein dauerhafter Konformitätsnachweis.