Was sich in WCAG 2.2 gegenüber WCAG 2.1 geändert hat

Die Web Content Accessibility Guidelines (WCAG) sind der Standard, auf den die meisten Barrierefreiheitsgesetze verweisen. WCAG 2.2 wurde am 5. Oktober 2023 zur W3C-Empfehlung, fügte neun neue Erfolgskriterien hinzu und entfernte eines. Sie ist nun auch ISO/IEC 40500:2025. Wenn Sie 2026 eine Website, ein Design-System oder Produkt pflegen, ist die praktische Frage: Was hat sich geändert, was verlangt jedes neue Kriterium konkret, und wie priorisieren Sie die Fixes? Dieser Beitrag beantwortet jedes, mit Quellenangaben zum Selbstprüfen.

Eine kurze WCAG-Geschichte

Das W3C veröffentlichte die ersten Web Content Accessibility Guidelines am 5. Mai 1999. WCAG 1.0 war präskriptiv und HTML-spezifisch; sie veraltete schnell, als das Web von einfachen Dokumenten zu reichen Anwendungen weiterging.

WCAG 2.0 kam am 11. Dezember 2008. Sie abstrahierte die Leitlinien von einer einzelnen Technologie weg, ordnete sie unter den vier Prinzipien «Wahrnehmbar, Bedienbar, Verständlich, Robust» (POUR) und führte das dreistufige Konformitätsschema A/AA/AAA ein, das Praktizierende noch heute nutzen. Es ist die Version, auf die die meisten US- und internationalen Regulierungen ursprünglich verwiesen.

WCAG 2.1 folgte am 5. Juni 2018. Sie fügte 17 neue Kriterien hinzu, die Mobile (Orientierung, Touch-Targets, Bewegungsaktivierung), Nutzer mit Sehbehinderung (Reflow, Textabstand, Nicht-Text-Kontrast) und kognitive Zugänglichkeit (Label-in-Name, Statusmeldungen) abdecken. Sie ist die Version, die in den vom European Accessibility Act referenzierten Standard EN 301 549 v3.2.1 eingebacken ist.

WCAG 2.2 wurde am 5. Oktober 2023 veröffentlicht und mit redaktionellen Aktualisierungen am 12. Dezember 2024 neu publiziert. Sie fügt neun neue Kriterien hinzu, entfernt eines (4.1.1 Parsing) und ist nun auch ISO/IEC 40500:2025. WCAG 3, ein substanziell anderer Rahmen mit neuem Scoring, ist noch im Entwurf, eine allgemeine Übernahme wird nicht vor 2027 erwartet.

Die neun neuen Erfolgskriterien

Die neuen Kriterien fallen in drei thematische Cluster: Fokus, Eingabemodalität, kognitive Zugänglichkeit.

Fokus-Cluster

2.4.11 Fokus nicht verdeckt (Minimum), Stufe AA. Wenn eine UI-Komponente Tastaturfokus erhält, darf sie nicht vollständig von autorenerzeugten Inhalten (Sticky Headers, Cookie-Banner, Chat-Widgets) verdeckt sein. Die Komponente darf teilweise verdeckt sein; das Kriterium scheitert nur, wenn nichts sichtbar ist.

2.4.12 Fokus nicht verdeckt (Erweitert), Stufe AAA. Strengere Variante von 2.4.11: kein Teil der fokussierten Komponente darf verdeckt sein. Die AAA-Version, die die meisten Enterprise-Design-Systeme anpeilen.

2.4.13 Fokus-Darstellung, Stufe AAA. Der Fokus-Indikator selbst muss mindestens 2 CSS-Pixel dick um das fokussierte Steuerelement sein, und sein Kontrast gegen den benachbarten unfokussierten Zustand muss mindestens 3:1 betragen. Ein 1-Pixel-Browser-Default-Fokusring auf einem dunklen Button scheitert; ein 2-Pixel hoher Kontrastring besteht.

Eingabemodalitäts-Cluster

2.5.7 Ziehbewegungen, Stufe AA. Alles, was mit einer Ziehgeste möglich ist, muss auch ohne sie möglich sein. Beispiele: sortierbare Listen, die nur auf Ziehen reagieren, Slider, Kartenschwenk. Das Kriterium verbietet Ziehen nicht; es verlangt eine Alternative wie Auf/Ab-Pfeile zum Umsortieren oder ein Texteingabefeld für Slider-Werte.

2.5.8 Zielgröße (Minimum), Stufe AA. Zeiger-Ziele müssen mindestens 24 mal 24 CSS-Pixel groß sein, außer sie sind inline (Links in einem Absatz), in einem User-Agent-Default exponiert (ein <select>), essenziell für die Funktion, oder es gibt anderswo auf der Seite ein äquivalentes Steuerelement, das 24x24 erfüllt. Das frühere WCAG-2.1-Kriterium 2.5.5 setzte die Schwelle auf 44x44, aber auf Stufe AAA; 2.5.8 macht einen kleineren 24x24-Boden auf Stufe AA verpflichtend.

Cluster kognitive Zugänglichkeit

3.2.6 Konsistente Hilfe, Stufe A. Wenn Hilfemechanismen («Kontakt», Chat-Widget, Hilfe-Link, Hilfe-Telefon) auf mehreren Seiten erscheinen, müssen sie auf jeder Seite in derselben relativen Reihenfolge erscheinen. Ziel ist die Senkung der kognitiven Last.

3.3.7 Redundante Eingabe, Stufe A. Nutzer sollten Informationen, die sie im selben Prozess bereits eingegeben haben, nicht erneut eingeben müssen. Mehrstufige Formulare müssen sich frühere Eingaben merken. Das Kriterium verbietet erneutes Fragen nicht, wenn es essenziell ist (Sicherheitsverifikation) oder die Information sich geändert hat.

3.3.8 Zugängliche Authentifizierung (Minimum), Stufe AA. Authentifizierung darf keine kognitiven Funktionstests verlangen, wie sich an ein Passwort erinnern, ein Puzzle lösen oder ein bildbasiertes CAPTCHA transkribieren, sofern keine Alternative geboten wird. Akzeptable Alternativen: Passwort-Manager, Einmalcode, Biometrie, Hardware-Token.

3.3.9 Zugängliche Authentifizierung (Erweitert), Stufe AAA. Strengere Variante: Objekterkennung und persönliche-Inhalt-Puzzles ebenfalls untersagt, sofern keine Alternative.

Das eine entfernte Kriterium

4.1.1 Parsing wurde als überholt zurückgezogen. Es verlangte, dass Inhalte parsbar sind: vollständige Start-/End-Tags, keine doppelten IDs, ordnungsgemäß verschachtelte Elemente. 2008 zählte das, weil unterstützende Technologien HTML selbst parsten und an malformiertem Markup scheiterten. 2024 konsumiert jede unterstützende Technologie den Accessibility-Baum des Browsers, nicht das rohe HTML; der Browser erholt sich bereits von malformiertem Markup. WCAG 2.2 erkennt dies an, indem sie das Kriterium fallen lässt. Es erscheint weiterhin in WCAG-2.0- und 2.1-Konformität, in 2.2 nicht.

Konformitätsstufen-Rekap

Praktische Auswirkungen, womit zuerst beginnen

1. 2.5.8 Zielgröße (Minimum), 24x24 CSS-Pixel. Buttons, Icon-Links und kleine Toggles auditieren. Steuerelemente kleiner als 24x24 brauchen entweder eine größere Klickfläche, mehr Abstand drumherum oder ein äquivalentes größeres Steuerelement auf der Seite. Häufigste 2.2-Verfehlung auf bestehenden Seiten.
2. 2.4.11 Fokus nicht verdeckt (Minimum). Nach Sticky-Bottom-Bars, Sticky-Footers, Chat-Widgets, Cookie-Bannern suchen, die den unteren Bereich des Viewports überlagern. Wenn ein fokussierbares Element hinter eines davon scrollt, scheitert das Kriterium. Fix: scroll-margin-bottom auf fokussierbare Elemente gleich der Höhe der Sticky-Bar.
3. 3.3.8 Zugängliche Authentifizierung (Minimum). Bildbasierte CAPTCHAs aus Login-Flüssen entfernen; durch unsichtbares CAPTCHA oder ratelimitierten Ansatz ersetzen. Passwort-Manager erlauben (autocomplete auf Passwortfeldern nicht deaktivieren). Einfügen von Einmalcodes erlauben.
4. 2.5.7 Ziehbewegungen. Eine Nicht-Zieh-Alternative für jede Nur-Zieh-Interaktion bereitstellen. Sortierbare Listen: Auf/Ab-Pfeile. Slider: Zahleneingabe. Karten: Schwenkschaltflächen.
5. 3.2.6 Konsistente Hilfe. Wenn Ihr «Kontakt»- oder «Hilfe»-Link auf mehreren Seiten erscheint, konsistent positionieren.
6. 3.3.7 Redundante Eingabe. Mehrstufige Formulare müssen sich frühere Eingaben merken.

Häufige Fallen bei der Umsetzung neuer Kriterien

• 4.1.1 Parsing überall als weg behandeln. 4.1.1 ist in WCAG 2.2 entfernt, aber von WCAG 2.0 und 2.1 weiterhin verlangt. Wenn Ihr Vertrag oder Ihre Regulierung 2.1 spezifiziert, gilt die Parsing-Regel weiter.
• 2.5.8 Zielgröße fehlinterpretieren. Das 24x24-Minimum gilt für das Ziel, nicht für das sichtbare Icon. Ein 16x16-Icon in einem 24x24-Button besteht. Ein 16x16-Icon in einem 16x16-Button scheitert.
• Ausnahmen zu 2.5.8 vergessen. Inline-Links in Absätzen, Standard-User-Agent-Steuerelemente, essentielle Ziele und äquivalente größere Steuerelemente anderswo auf der Seite sind ausgenommen.
• 3.3.8 durch Entfernung aller CAPTCHAs umsetzen. Sie können CAPTCHAs behalten; Sie brauchen nur einen barrierefreien Alternativpfad. Reverse-Turing-Tests, Ratenlimits, Magic Links, Passkeys oder Hardware-Token qualifizieren.
• 2.4.11 mit 2.4.13 verwechseln. Fokus nicht verdeckt (2.4.11) betrifft, ob das fokussierte Element überhaupt sichtbar ist. Fokus-Darstellung (2.4.13) betrifft den Fokus-Indikator selbst, der dick und kontrastreich sein muss. Verschiedene Anforderungen auf verschiedenen Stufen.
• 2.4.13 überspringen, weil AAA. Mehrere Regierungen (Norwegen, Teile Kanadas) haben AAA-Regeln für Public-Sector-Seiten übernommen.

Werkzeuge zur Prüfung der WCAG-2.2-Konformität

Automatisierte Werkzeuge erfassen selbst im besten Fall etwa 30 bis 40 % der WCAG-Verfehlungen. Die neuen 2.2-Kriterien sind besonders schwer zu automatisieren (2.5.7, 3.2.6, 3.3.7, 3.3.8), weil sie das Verständnis des Nutzerflusses erfordern, nicht nur das Markup. Planen Sie pro Release manuelle Tastatur-Tests ein.

Datenschutz und die Werkzeuge

Der Kontrast-Checker, der WCAG-Überschriften-Checker und der Generator für zugängliche Paletten auf Absolutool laufen alle vollständig in Ihrem Browser. Das HTML oder die Farbwerte, die Sie einfügen, werden von JavaScript auf Ihrem Gerät verarbeitet, die Ergebnisse auf der Seite gerendert und nichts an einen Server gesendet. Keine Telemetrie über die Eingabe, keine Drittskripte, die den Inhalt berühren, kein Cache nach Navigation. Für interne Design-System-Audits, noch unveröffentlichte Markenfarben oder Audit-Daten unter Embargo ist dieser strikt lokale Ablauf die richtige Voreinstellung. Die Werkzeuge können offline laufen, sobald die Seite geladen ist, was Sie überprüfen können, indem Sie das Netzwerk abschalten und ein Kontrastpaar erneut prüfen.