Schnellübersicht der Änderungen
Die im Oktober 2023 veröffentlichten WCAG 2.2 führen 9 neue Erfolgskriterien ein und entfernen Kriterium 4.1.1 Parsing. Diese Änderungen zielen hauptsächlich darauf ab, die Barrierefreiheit für Menschen mit kognitiven Beeinträchtigungen und mobile Nutzer zu verbessern. Die Verteilung nach Stufen zeigt 2 Kriterien der Stufe A, 5 der Stufe AA und 2 der Stufe AAA.
Dieses Update bleibt vollständig rückwärtskompatibel mit WCAG 2.1: Jede Website, die 2.2 entspricht, entspricht automatisch 2.1. Die neuen Kriterien adressieren konkrete Probleme wie Sichtbarkeit des Tastaturfokus, Größe klickbarer Bereiche, barrierefreie Authentifizierung und Vermeidung redundanter Eingaben. Für Entwickler, die bereits mit WCAG 2.1 vertraut sind, stellt der Übergang zu 2.2 eine natürliche Weiterentwicklung dar, keine komplette Neugestaltung.
Neue Erfolgskriterien in WCAG 2.2
Die 9 neuen Kriterien in WCAG 2.2 entstanden aus Konsultationen mit Communities von Menschen mit Behinderungen. Im Gegensatz zu früheren Versionen, die sich stärker auf Screenreader-Barrierefreiheit konzentrierten, erweitert WCAG 2.2 das Spektrum auf kognitive Beeinträchtigungen, Tastaturnavigation und mobile Ergonomie.
Jedes neue Kriterium wird von detaillierten Implementierungstechniken und Beispielen für Fehler begleitet. Kriterien der Stufe AA stellen für die meisten Organisationen die Priorität dar, da sie den gesetzlichen Anforderungen in vielen europäischen Ländern über die europäische Barrierefreiheitsrichtlinie entsprechen. AAA-Kriterien bleiben für die Grundkonformität optional, werden aber empfohlen.
2.4.11 Fokus nicht verdeckt (Minimum) - Stufe AA
Dieses Kriterium stellt sicher, dass ein Element mit Tastaturfokus nicht vollständig von überlagerndem Inhalt wie fixen Headern, Cookie-Bannern oder modalen Fenstern verdeckt wird. Mindestens ein Teil des Elements muss auf dem Bildschirm sichtbar bleiben. Wenn Sie beispielsweise mit der Tastatur auf einer Website mit einem 80px Sticky-Menü navigieren, dürfen fokussierte Elemente nicht komplett hinter diesem Menü verschwinden.
Die gängigste technische Lösung besteht darin, automatisches Scrollen mit einem Offset zu implementieren, der der Höhe fixer Elemente entspricht. Verwenden Sie in JavaScript `element.scrollIntoView({block: 'center'})` statt `'start'`, um das fokussierte Element zu zentrieren. CSS-Frameworks wie Tailwind bieten mittlerweile `scroll-mt-*`-Utilities zur deklarativen Verwaltung dieser Offsets.
2.4.12 Fokus nicht verdeckt (Erweitert) - Stufe AAA
Diese verstärkte Version von Kriterium 2.4.11 verlangt, dass das fokussierte Element vollständig sichtbar ist, ohne dass ein Teil von überlagerndem Inhalt verdeckt wird. Dies geht über das AA-Minimum hinaus, das teilweise Verdeckung toleriert. Diese Anforderungsstufe kommt besonders Menschen mit Aufmerksamkeitsstörungen oder leichten Sehbeeinträchtigungen zugute, die den gesamten Kontext sehen müssen.
Um dieses Kriterium zu erfüllen, passen Sie die Scroll-Margins an, um vollständige Sichtbarkeit zu garantieren. Testen Sie mit großen Elementen wie Karten oder komplexen Formularen. Ein Ansatz besteht darin, den benötigten Platz dynamisch zu berechnen: `const offset = header.offsetHeight + 20`, dann in CSS `scroll-margin-top: calc(var(--header-height) + 20px)` anwenden.
2.4.13 Fokusdarstellung - Stufe AAA
Dieses Kriterium definiert präzise Anforderungen für den Fokusindikator: Er muss eine Mindestfläche entsprechend einem Umfang von 2px CSS um die Komponente haben, ein Kontrastverhältnis von mindestens 3:1 zu angrenzenden Farben aufweisen und darf nicht von anderen Inhalten verdeckt werden. Dies ersetzt die vagen Empfehlungen früherer Versionen durch messbare Metriken.
In der Praxis reicht normalerweise ein solider 2px-Outline mit kontrastierender Farbe. Vermeiden Sie `outline: none` ohne Alternative. Für minimalistische Designs verwenden Sie `outline-offset: 2px`, um den Fokus visuell vom Element abzuheben. Die CSS-Eigenschaft `:focus-visible` ermöglicht es, den Fokus nur bei Tastaturnavigation anzuzeigen, was Mausbenutzer nicht stört und trotzdem barrierefrei bleibt.
2.5.7 Ziehbewegungen - Stufe AA
Jeder Mechanismus, der eine Ziehbewegung erfordert (Drag-and-Drop, Swipe, Slider), muss eine Alternative bieten, die mit einfachen Aktionen wie Klicks oder Taps nutzbar ist. Dieses Kriterium erkennt an, dass komplexe Gesten für Menschen mit Tremor, reduzierter Präzision oder assistiven Technologien problematisch sind.
Fügen Sie für ein Touch-Karussell Zurück/Weiter-Buttons hinzu. Für einen Preisspannen-Slider bieten Sie ergänzende numerische Eingabefelder an. Bei Kanban-Boards mit Drag-and-Drop implementieren Sie ein Kontextmenü mit tastaturzugänglichen "Verschieben nach..."-Optionen. Die React DnD Kit Library bietet native Tastaturunterstützung für diese Anwendungsfälle.
2.5.8 Zielgröße (Minimum) - Stufe AA
Interaktive Ziele müssen mindestens 24×24 CSS-Pixel groß sein, mit definierten Ausnahmen (Inline-Elemente in Sätzen, native Browser-Steuerelemente, essentielle Darstellung). Dieses Kriterium ist weniger streng als das AAA-Kriterium 2.5.5, das 44×44px verlangte, und erkennt damit Einschränkungen dichter Interfaces an, während es ein Mindestmaß an Barrierefreiheit gewährleistet.
Verwenden Sie `min-width: 24px; min-height: 24px` für alle Buttons, Links und Steuerelemente. Wenn das sichtbare Icon kleiner ist, erweitern Sie den klickbaren Bereich mit transparentem Padding. In CSS: `padding: 8px; margin: -8px;` vergrößert den interaktiven Bereich ohne das Erscheinungsbild zu ändern. Frameworks wie Chakra UI und Material-UI wenden diese Dimensionen mittlerweile standardmäßig auf ihre Komponenten an.
3.2.6 Konsistente Hilfe - Stufe A
Wenn ein Hilfemechanismus auf mehreren Seiten erscheint (Kontakt, FAQ, Chatbot), muss er konsistent in der relativen Seitenreihenfolge positioniert sein. Wenn der "Kontakt"-Link auf der Startseite an 3. Position im Footer erscheint, muss er auf allen Seiten, wo er vorkommt, die gleiche relative Position einnehmen.
Diese Konsistenz reduziert die kognitive Last für Nutzer mit Gedächtnis- oder Orientierungsproblemen. Erstellen Sie in der Praxis wiederverwendbare Footer-/Header-Komponenten mit fester Elementreihenfolge. Achten Sie auf Responsive-Varianten: Die Reihenfolge muss zwischen Desktop und Mobile konsistent bleiben, notfalls mit Flexbox-`order` visuell umorganisieren, während die DOM-Reihenfolge erhalten bleibt.
3.3.7 Redundante Eingabe - Stufe A
Informationen, die vom Nutzer bereits in einem Prozess eingegeben wurden, dürfen nicht erneut abgefragt werden, außer wenn es für die Sicherheit essentiell ist, die vorherige Information nicht mehr gültig ist oder der Nutzer die Daten ändern kann. Dieses Kriterium zielt auf Bestelltunnel, mehrstufige Formulare und Registrierungsprozesse ab, wo erneutes Abfragen von Adresse oder Name unnötige Reibung erzeugt.
Implementieren Sie Persistenz mit sessionStorage für temporäre Daten oder localStorage für dauerhafte Präferenzen. Für komplexe Formulare nutzen Sie Libraries wie React Hook Form mit `defaultValues`, die aus dem Kontext geladen werden. HTML5-`autocomplete`-Attribute helfen Browsern auch, Standardfelder vorzufüllen (name, email, address-line1, etc.).
3.3.8 Barrierefreie Authentifizierung (Minimum) - Stufe AA
Authentifizierungsprozesse dürfen nicht auf kognitiven Tests wie dem Merken komplexer Passwörter oder dem Lösen visueller CAPTCHAs basieren. Passwort-Manager, biometrische Authentifizierung, Codes per E-Mail oder SMS und Magic Links sind akzeptable Alternativen. Dieses Kriterium erkennt an, dass Sicherheit und Barrierefreiheit nicht unvereinbar sind.
Fügen Sie in der Praxis `autocomplete="username"` und `autocomplete="current-password"` zu Ihren Login-Feldern hinzu, damit Passwort-Manager funktionieren. Ersetzen Sie visuelle CAPTCHAs durch reCAPTCHA v3 (unsichtbares Scoring) oder hCaptcha im barrierefreien Modus. Für Multi-Faktor-Authentifizierung bieten Sie mehrere Optionen an: SMS, E-Mail, Authentifizierungs-App, physischer Sicherheitsschlüssel.
3.3.9 Barrierefreie Authentifizierung (Erweitert) - Stufe AAA
Diese AAA-Stufe geht weiter und eliminiert alle kognitiven Tests, einschließlich Objekterkennung oder Texttranskription. Nur Mechanismen ohne Gedächtnis- oder Erkennungsaufwand sind akzeptiert: Biometrie, physische Tokens, Magic Links, delegierte Authentifizierung (OAuth mit Google/Microsoft).
Implementieren Sie für diese Stufe WebAuthn für passwortlose Authentifizierung über Sicherheitsschlüssel oder Biometrie. Libraries wie SimpleWebAuthn (Node.js) oder Passkey (Python) vereinfachen die Integration. Bieten Sie OAuth als Hauptalternative an: Nutzer authentifizieren sich über einen bestehenden Account, ohne neue Credentials merken zu müssen.
Entferntes Kriterium: 4.1.1 Parsing
Kriterium 4.1.1, das validen HTML-Code ohne Parsing-Fehler verlangte, wurde aus WCAG 2.2 entfernt. Diese Entscheidung erkennt an, dass moderne Browser mittlerweile HTML5-Parsing konsistent implementieren und kleinere Fehler ohne Auswirkung auf die Barrierefreiheit tolerieren. Assistive Technologien verlassen sich auf den vom Browser generierten Accessibility Tree statt auf das rohe DOM.
Diese Entfernung bedeutet nicht, dass HTML-Codequalität unwichtig geworden ist. Semantisches, gut strukturiertes HTML bleibt essentiell für andere WCAG-Kriterien, insbesondere 1.3.1 Info und Beziehungen, 4.1.2 Name, Rolle, Wert und 4.1.3 Statusmeldungen. Validieren Sie Ihr HTML mit dem W3C Validator, um schwere Fehler zu erkennen, aber fokussieren Sie sich nicht mehr auf strikte Konformität als Barrierefreiheitsanforderung.
Was der European Accessibility Act verlangt
Der European Accessibility Act (EAA), der im Juni 2025 in Kraft tritt, verweist auf die Norm EN 301 549 v3.2.1, die auf WCAG 2.1 Stufe AA basiert. Technisch gesehen reicht WCAG 2.1 AA also aus, um die europäischen gesetzlichen Verpflichtungen zu erfüllen. Viele Experten empfehlen jedoch aus mehreren strategischen Gründen, direkt WCAG 2.2 anzustreben.
Erstens garantiert WCAG 2.2-Konformität durch Rückwärtskompatibilität automatisch WCAG 2.1-Konformität und damit die EAA-Erfüllung. Zweitens wird die Norm EN 301 549 in künftigen Revisionen aktualisiert, um WCAG 2.2 zu integrieren; diese Entwicklung vorwegzunehmen erspart Ihnen eine zweite Migration. Drittens adressieren die 9 neuen WCAG 2.2-Kriterien reale Barrierefreiheitslücken, die von Nutzern identifiziert wurden – Ihre Konformität jetzt zu verbessern, kommt Ihren Nutzern direkt zugute.
Sollten Sie WCAG 2.2 anstreben?
Die Antwort ist ja für die meisten Organisationen, besonders wenn Sie ein neues Projekt starten oder eine Neugestaltung planen. Die Rückwärtskompatibilität mit WCAG 2.1 bedeutet, dass keine bestehende Arbeit verloren geht: Sie bauen auf soliden Fundamenten auf, statt von vorne zu beginnen. Die 9 neuen Kriterien stellen einen moderaten Compliance-Aufwand im Verhältnis zu den gebotenen Barrierefreiheitsvorteilen dar.
Für Websites, die bereits WCAG 2.1 AA entsprechen, priorisieren Sie die 5 neuen AA-Kriterien (2.4.11, 2.5.7, 2.5.8, 3.3.7, 3.3.8), die die minimale Lücke zu WCAG 2.2 AA darstellen. Die beiden A-Kriterien (3.2.6, 3.3.7 bereits erwähnt) sind in der Regel einfach zu implementieren. AAA-Kriterien (2.4.12, 2.4.13, 3.3.9) können auf Phase 2 warten, außer Ihre Zielgruppe umfasst einen hohen Anteil von Nutzern mit kognitiven oder motorischen Beeinträchtigungen.
Wie man WCAG 2.2-Konformität testet
WCAG 2.2-Konformitätstests kombinieren automatisierte Tools und manuelle Audits. Automatisierte Tools wie Axe DevTools, WAVE oder Pa11y erkennen etwa 30-40% der Barrierefreiheitsprobleme, hauptsächlich technische (Kontrast, Alt-Attribute, Formularlabels). Für WCAG 2.2 stellen Sie sicher, dass Ihr Test-Tool aktuell ist: Axe Core 4.8+ und Pa11y 7.0+ unterstützen die neuen Kriterien.
Die manuelle Checkliste für WCAG 2.2 umfasst: Testen Sie vollständige Tastaturnavigation mit immer sichtbarem Fokus hinter fixen Headern (2.4.11), messen Sie Klickbereiche mit dem Browser-Inspektor zur Überprüfung des 24×24px-Minimums (2.5.8), durchlaufen Sie mehrstufige Prozesse zur Bestätigung fehlender redundanter Eingaben (3.3.7), versuchen Sie den Login mit einem Passwort-Manager (3.3.8), prüfen Sie Alternativen zu Drag-and-Drop (2.5.7) und bestätigen Sie konsistente Positionierung von Hilfemechanismen zwischen Seiten (3.2.6). Für ein vollständiges Audit engagieren Sie Menschen mit Behinderungen für reale Tests.