WCAG 2.2 vs WCAG 2.1: Was ist neu und was Sie aktualisieren müssen

Mehr als 96% aller Startseiten verfehlen weiterhin grundlegende WCAG-Anforderungen, wie die Barrierefreiheitsanalyse 2024 von WebAIM zeigt – und das im Vergleich zu einem Standard, der zu diesem Zeitpunkt bereits fünf Jahre alt war. Am 5. Oktober 2023 veröffentlichte das W3C WCAG 2.2 als offiziellen Webstandard und erhöhte die Messlatte mit neun neuen Erfolgskriterien, während ein Kriterium, das obsolet geworden war, entfernt wurde. Wenn Sie eine Website verwalten, digitale Produkte entwickeln oder für Compliance verantwortlich sind, ist dies ein Update, das Sie nicht auf unbestimmte Zeit aufschieben können. Vorschriften in der EU, im Vereinigten Königreich und zunehmend in US-Bundesstaaten beziehen sich bereits auf WCAG 2.2 als Referenzstandard.

Ein kurzer Rückblick: Von WCAG 2.1 zu WCAG 2.2

Die Web Content Accessibility Guidelines haben sich seit der Einführung von WCAG 2.0 im Dezember 2008 stetig weiterentwickelt. WCAG 2.1 erschien im Juni 2018 und fügte 17 neue Erfolgskriterien hinzu, mit besonderem Fokus auf mobile Nutzer sowie Menschen mit Sehbehinderungen oder kognitiven Beeinträchtigungen. Fünf Jahre lang diente es als faktischer Compliance-Maßstab für Gesetze wie den ADA, Section 508 und die EU-Webzugänglichkeitsrichtlinie.

WCAG 2.2 knüpft genau dort an, wo 2.1 aufgehört hat. Das W3C startete die Arbeit mit dem ausdrücklichen Ziel, die Barrierefreiheitsrichtlinien für drei große Nutzergruppen weiter zu verbessern: Menschen mit kognitiven oder Lernbehinderungen, Menschen mit Sehbehinderungen und Menschen mit Behinderungen auf mobilen Geräten. Diese Entwicklungslinie ist wichtig, weil sie bedeutet, dass das Update evolutionär ist, nicht revolutionär – aber dennoch bedeutsam genug, um Maßnahmen Ihrerseits erforderlich zu machen.

Einer der wichtigsten strukturellen Punkte ist, dass WCAG 2.2 vollständig abwärtskompatibel zu WCAG 2.1 ist. Wenn Sie WCAG 2.2-konform sind, sind Sie automatisch auch konform mit WCAG 2.1 und WCAG 2.0. Wenn Ihre Organisation derzeit WCAG 2.1 AA erfüllt, müssen Sie nur die neuen Kriterien aus 2.2 adressieren – Sie fangen nicht von vorne an. Das W3C empfiehlt außerdem, dass Organisationen zwar weiterhin WCAG 2.0 und 2.1 als gültige Empfehlungen betrachten können, aber WCAG 2.2 nutzen sollten, um die zukünftige Anwendbarkeit ihrer Barrierefreiheitsarbeit zu maximieren.

Es wird außerdem weithin erwartet, dass WCAG 2.2 die letzte Punktversion der WCAG-2.x-Familie sein wird. Die nächste Hauptversion, WCAG 3.0, ist ein völlig anderes Konstrukt – ein grundlegendes Umdenken, wie Barrierefreiheitsrichtlinien strukturiert sind. Das macht WCAG 2.2 zum endgültigen Endpunkt einer Entwicklungslinie, die bis 2008 zurückreicht – und zu der Version, die Sie jetzt richtig umsetzen müssen.

Die Zahlen: Was sich tatsächlich geändert hat

Seien wir präzise beim Umfang der Änderungen. WCAG 2.1 enthielt 78 Erfolgskriterien über drei Konformitätsstufen (A, AA und AAA). WCAG 2.2 fügt neun neue Erfolgskriterien hinzu und entfernt eines – Erfolgskriterium 4.1.1 Parsing – sodass insgesamt 86 aktive Kriterien verbleiben. Von diesen neun neuen Kriterien liegen zwei auf Level A, vier auf Level AA und drei auf Level AAA.

Für die große Mehrheit der Organisationen, die eine Konformität auf Level AA anstreben – das Niveau, auf das sich die meisten Gesetze und Vorschriften beziehen – bedeutet dies in der Praxis sechs neue Kriterien, die umgesetzt werden müssen. Die drei neuen Level-AAA-Kriterien gelten als Best Practice und werden häufig für den öffentlichen Sektor und den Gesundheitsbereich empfohlen, sind aber in den meisten Rechtsordnungen derzeit keine strikte gesetzliche Pflicht.

Die neuen Kriterien adressieren in erster Linie vier Problemfelder, die in realen Barrierefreiheitsaudits immer wieder als unterversorgt durch den bestehenden Standard identifiziert wurden: Sichtbarkeit des Tastaturfokus, Touch- und Zeigerinteraktionen, kognitive Barrierefreiheit und Hürden bei der Authentifizierung. Das sind keine theoretischen Probleme. Es handelt sich um Barrieren, die Menschen mit Behinderungen regelmäßig daran hindern, alltägliche Aufgaben wie das Einloggen, das Ausfüllen eines Formulars oder das Navigieren auf einer Seite mit Sticky-Header zu erledigen.

Die neun neuen Erfolgskriterien erklärt

Hier ist eine Aufschlüsselung jedes neuen Kriteriums, was es verlangt und warum es in der Praxis wichtig ist. Die Kriterien sind nach Konformitätsstufe geordnet, damit Sie Ihre Nachbesserungsarbeiten priorisieren können.

Level A (Minimum – für alle erforderlich)

• 2.4.11 Fokus nicht verdeckt (Minimum): Wenn eine UI-Komponente den Tastaturfokus erhält, darf sie nicht vollständig durch vom Autor erstellte Inhalte verdeckt werden. Die häufigsten Übeltäter sind hier Sticky-Header, schwebende Cookie-Banner und Live-Chat-Widgets, die über dem Seiteninhalt liegen. Wenn ein Nutzer mit der Tab-Taste auf einer Schaltfläche landet, die vollständig von Ihrer fixierten Navigationsleiste überdeckt wird, ist dieses Kriterium verletzt. Beachten Sie, dass teilweise verdeckt auf Level A zulässig ist – das Element darf nur nicht zu 100% verborgen sein.
• 2.5.7 Ziehbewegungen: Jede Funktionalität, die eine Ziehbewegung erfordert – denken Sie an Drag-and-drop-Datei-Uploads, sortierbare Listenelemente oder Schieberegler – muss auch mit einer einzelnen Zeigeraktion (z. B. Klick oder Tipp) ohne Ziehen bedienbar sein. Dies ist entscheidend für Nutzer mit motorischen Beeinträchtigungen, die keine kontrollierten Ziehgesten ausführen können. Die Anforderung gilt für vom Autor erstellte Inhalte; native Browserverhalten sind ausgenommen.

Level AA (Erforderlich für Standardkonformität)

• 2.4.12 Fokus nicht verdeckt (Erweitert): Eine strengere Version von 2.4.11. Auf Level AA darf kein Teil des Fokusindikators durch vom Autor erstellte Inhalte verdeckt werden, wenn ein Element den Tastaturfokus erhält. Dies schließt die Lücke in der Level-A-Version und verlangt, dass fokussierte Elemente vollständig sichtbar sind – nicht nur teilweise.
• 2.5.8 Zielgröße (Minimum): Der klick- oder tippbare Bereich interaktiver Elemente muss mindestens 24×24 CSS-Pixel groß sein, mit bestimmten Ausnahmen für Inline-Textlinks, vom User-Agent gesteuerte Elemente und Fälle, in denen sich in unmittelbarer Nähe ein gleichwertiges 24×24-Ziel befindet. Dies ist eine bedeutende Änderung gegenüber WCAG 2.1, wo eine Zielgröße von 44×44 Pixel nur auf AAA-Ebene empfohlen wurde. Jetzt ist eine Mindestbasis auf AA-Ebene durchsetzbar. Beachten Sie, dass 24×24px die Untergrenze ist; das AAA-Kriterium (2.5.5) empfiehlt weiterhin 44×44px, und das bleibt der Goldstandard für touchfreundliches Design.
• 3.2.6 Konsistente Hilfe: Wenn eine Website Hilfemechanismen bereitstellt – Kontaktdaten von Personen, Self-Service-Tools, automatisierten Chat oder ein Kontaktformular – und diese Mechanismen auf mehreren Seiten erscheinen, müssen sie auf diesen Seiten an derselben relativen Position erscheinen. Nutzer, die Hilfe benötigen, insbesondere Menschen mit kognitiven Beeinträchtigungen, sollten sie immer am gleichen Ort finden können, ohne suchen zu müssen.
• 3.3.7 Redundante Eingabe: Informationen, die ein Nutzer in einem vorherigen Schritt desselben Prozesses bereits eingegeben hat, müssen entweder automatisch für ihn vorausgefüllt oder zur Auswahl bereitgestellt werden, damit er sie nicht erneut eingeben muss. Denken Sie an mehrstufige Checkout-Prozesse, die nach einer Rechnungsadresse fragen und anschließend erneut nach einer Lieferadresse – Nutzern sollte eine Möglichkeit angeboten werden, das bereits Eingetragene zu übernehmen. Ausnahmen sind zulässig, wenn das erneute Eingeben aus Sicherheitsgründen wesentlich ist (z. B. Passwortbestätigung) oder wenn die zuvor eingegebenen Daten nicht mehr gültig sind.
• 3.3.8 Barrierefreie Authentifizierung (Minimum): Kognitive Funktionstests – wie das Lösen eines Rätsels, das Merken eines Passworts oder das Abschreiben von Zeichen aus einem Bild-CAPTCHA – dürfen nicht als einziges Mittel zur Authentifizierung verlangt werden. Es muss eine alternative Methode verfügbar sein oder ein Mechanismus, der den Nutzer unterstützt (z. B. die Nutzung eines Passwortmanagers oder das Zulassen von Copy-and-paste in das Passwortfeld). Dieses Kriterium verbietet CAPTCHAs nicht grundsätzlich, verlangt aber, dass sie niemals die einzige Option für Nutzer sind, die sie nicht lösen können.

Level AAA (Erweitert – empfohlen, aber für die meisten nicht verpflichtend)

• 2.4.13 Fokusdarstellung: Wenn der Tastaturfokusindikator sichtbar ist, muss er bestimmte Mindestanforderungen an Größe und Kontrast erfüllen: Der Fokusbereich muss mindestens so groß sein wie ein 2 CSS-Pixel dicker Rahmen um das Element, und es muss ein Kontrastverhältnis von mindestens 3:1 zwischen fokussiertem und nicht fokussiertem Zustand bestehen. Dieses Kriterium war ursprünglich für Level AA geplant, wurde aber aufgrund seiner Komplexität auf AAA verschoben. Das bedeutet, dass es für eine reine AA-Konformität weiterhin keine normativ definierte Mindestgröße für einen Fokusindikator gibt – nur die Anforderung, dass einer sichtbar sein muss.
• 2.5.9 Ziehbewegungen (Erweitert): Moment – es gibt in dieser Version kein 2.5.9. Die AAA-Erweiterung zu Ziehbewegungen ist im folgenden 3.3.9 enthalten.
• 3.3.9 Barrierefreie Authentifizierung (Erweitert): Eine strengere Version von 3.3.8. Auf Level AAA sind auch Objekterkennungs- und persönliche Inhaltstests (wie „Klicken Sie auf alle Ampeln“ oder „Wählen Sie Fotos aus Ihrem Konto“) untersagt, nicht nur die Ausnahmen, die auf Level AA zugelassen sind. Statt vier bleiben nur zwei Ausnahmen bestehen.

Was entfernt wurde: 4.1.1 Parsing

WCAG 2.2 entfernt ein Erfolgskriterium, das seit WCAG 2.0 bestand: 4.1.1 Parsing. Dieses Kriterium verlangte ursprünglich, dass HTML wohlgeformt ist, mit vollständigen Start- und End-Tags, korrekter Verschachtelung und ohne doppelte Attribute. Ziel war es sicherzustellen, dass Browser und unterstützende Technologien Markup zuverlässig parsen und Inhalte korrekt für Nutzer darstellen können.

Die Entfernung ist nicht umstritten – sie spiegelt eine tatsächliche Veränderung der technischen Landschaft wider. Seit 2008 sind Browser außerordentlich gut darin geworden, fehlerhaftes HTML robust zu verarbeiten, indem sie einem konsistenten, standardisierten Fehlerkorrektur-Algorithmus folgen. Unterstützende Technologien wie Screenreader verlassen sich heute auf das Document Object Model (DOM) des Browsers, nicht auf den reinen HTML-Quellcode. Das W3C kam zu dem Schluss, dass das Kriterium in der modernen Umgebung keinen nennenswerten Barrierefreiheitsnutzen mehr bietet. Barrierefreiheitsprobleme, die früher von 4.1.1 erfasst wurden, sind weiterhin durch spezifischere Kriterien wie 1.3.1 (Info und Beziehungen) und 4.1.2 (Name, Rolle, Wert) abgedeckt.

Die praktischen Auswirkungen für Ihr Team: Wenn Ihre automatisierten Testtools bisher Verstöße gegen 4.1.1 Parsing gemeldet haben, sind diese nach WCAG 2.2 keine Probleme mehr. Sie werden möglicherweise eine Reduktion der gemeldeten Fehler allein durch das Versionsupgrade sehen – nicht, weil tatsächlich etwas behoben wurde. Dennoch bleibt das Schreiben von validem, gut strukturiertem HTML eine wichtige Best Practice – es ist nur nicht mehr für sich genommen eine Compliance-Anforderung.

Regulatorische und rechtliche Auswirkungen

Die neuen Kriterien zu verstehen, ist das eine. Zu verstehen, was sie für Ihr rechtliches Risiko bedeuten, ist etwas anderes. Die kurze Antwort lautet: WCAG 2.2 wird in mehreren Rechtsordnungen zum geltenden Standard, und der Zeitplan bewegt sich schneller, als vielen Organisationen bewusst ist.

Im Vereinigten Königreich sind öffentliche Stellen bereits verpflichtet, WCAG 2.2 Level AA gemäß den Public Sector Bodies Accessibility Regulations zu erfüllen. In der Europäischen Union befindet sich EN 301 549 – die technische Norm, die dem European Accessibility Act zugrunde liegt – im Prozess, WCAG 2.2 als Basis zu übernehmen. Der EAA selbst hat eine Durchsetzungsfrist im Juni 2025 für die meisten privaten Organisationen, die Produkte und Dienstleistungen in der EU anbieten. Mehrere US-Bundesstaaten, darunter Colorado, haben ebenfalls die Absicht bekundet, ihre Barrierefreiheitsgesetze von WCAG 2.1 auf WCAG 2.2 zu aktualisieren.

In den Vereinigten Staaten verweist ADA Title II derzeit auf WCAG 2.1 AA als technischen Standard für Websites von staatlichen und kommunalen Behörden. US-Gerichte berufen sich jedoch zunehmend auf WCAG 2.2 in Barrierefreiheitsklagen, und die Entwicklung ist eindeutig. Darauf zu warten, dass ein formales bundesweites Mandat erlassen wird, bevor man handelt, ist eine Compliance-Strategie mit wachsendem rechtlichem Risiko – insbesondere für E-Commerce-, Finanzdienstleistungs- und Gesundheitsorganisationen, die attraktive Ziele für Barrierefreiheitsklagen sind.

Selbst wenn Ihre Organisation noch nicht rechtlich verpflichtet ist, WCAG 2.2 zu erfüllen, wird die frühzeitige Umsetzung der neuen Erfolgskriterien sicherstellen, dass Sie den sich ändernden Vorschriften voraus sind – und, noch wichtiger, den realen Barrieren, denen Ihre Nutzer heute gegenüberstehen.

So prüfen und aktualisieren Sie Ihre Website

Wenn Sie bereits WCAG 2.1 AA-konform sind, ist der Upgrade-Pfad zu WCAG 2.2 gut handhabbar. Hier ist ein praxisnaher Rahmen für das Vorgehen.

Beginnen Sie mit einem gezielten Audit der sechs neuen Level-AA-Kriterien. Dies sind die Kriterien, die für die meisten Organisationen rechtlich relevant sind. Konzentrieren Sie sich insbesondere auf 2.4.11 und 2.4.12 (verdeckt fokussierte Elemente), 2.5.8 (Zielgröße), 3.2.6 (konsistente Hilfe), 3.3.7 (redundante Eingabe) und 3.3.8 (barrierefreie Authentifizierung). Ein erfahrener Barrierefreiheitsingenieur kann diese Kriterien für eine Website mittlerer Komplexität in der Regel innerhalb weniger Stunden manuell prüfen.

Prüfen Sie zuerst Ihre Sticky-/fixierten Elemente. Die Kriterien zum verdeckten Fokus (2.4.11 und 2.4.12) werden durch einige der häufigsten UI-Muster im Web verletzt – Sticky-Header, Floating-Action-Buttons, Cookie-Bars und Chat-Widgets. Gehen Sie Ihre gesamte Website nur mit der Tab-Taste durch und beobachten Sie, ob ein fokussiertes Element jemals unter einer fixierten Ebene verschwindet. Ein CSS-Fix ist in der Regel unkompliziert:

/* Verhindert, dass der Sticky-Header fokussierte Elemente überdeckt */
:focus {
  scroll-margin-top: 80px; /* Höhe Ihres Sticky-Headers */
}

Prüfen Sie die Tipp-/Klickziele aller interaktiven Elemente. Dies ist oft ein schneller Gewinn sowohl in Bezug auf Compliance als auch auf User Experience. Buttons, Links, Formularelemente und Icons benötigen alle mindestens 24×24 CSS-Pixel. Viele Designsysteme überschreiten diese Schwelle bereits, aber kleine Icon-Buttons – Schließen-Icons, Social-Share-Buttons und Inline-Aktionslinks – sind häufige Problemfälle. Untersuchen Sie Ihre Komponenten und fügen Sie bei Bedarf Padding hinzu oder passen Sie die Abmessungen an.

Überprüfen Sie Ihre Authentifizierungsabläufe sorgfältig. SC 3.3.8 (Barrierefreie Authentifizierung) hat spürbare Auswirkungen. Wenn Sie ein CAPTCHA verwenden, das nicht umgangen oder über eine alternative Methode gelöst werden kann, sind Sie wahrscheinlich nicht konform. Prüfen Sie, ob Ihre Login-, Registrierungs- und Zwei-Faktor-Authentifizierungsabläufe Passwortmanagern das automatische Ausfüllen erlauben, Copy-and-paste zulassen, eine alternative Verifizierungsmethode (z. B. Magic Link oder Einmalcode) anbieten oder andere Vorkehrungen für Nutzer bereitstellen, die eine kognitive Herausforderung nicht bewältigen können.

Prüfen Sie mehrstufige Formulare auf redundante Eingaben. Kartieren Sie alle Prozesse, die sich über mehrere Schritte erstrecken – Checkouts, Onboarding-Flows, Antragsprozesse – und identifizieren Sie jede Stelle, an der Nutzer aufgefordert werden, Informationen erneut anzugeben, die sie bereits geliefert haben. Fügen Sie dort, wo es sinnvoll ist, Logik zur automatischen Übernahme oder eine Option „wie oben“ hinzu. Dies ist typischerweise eine Änderung im Backend oder im Formularzustands-Management, keine komplexe architektonische Umstellung.

Stellen Sie sicher, dass Hilfemechanismen konsistent positioniert sind. Wenn Sie ein Chat-Widget, einen Hilfe-Link oder eine Telefonnummer haben, die in einer Fußzeile oder Seitenleiste auf mehreren Seiten erscheint, prüfen Sie, ob sich ihre relative Position nicht verschiebt. Dies ist in der Regel ein Template- oder Layout-Thema und kein Seiten-zu-Seiten-Problem – beheben Sie es in Ihrer Komponentenbibliothek oder Ihrem CMS-Template, und die Änderung wirkt sich überall aus.

Nutzen Sie automatisierte Tools für die erste Bestandsaufnahme, aber bleiben Sie nicht dabei stehen. Automatisierte Scanner können etwa 40% der WCAG-2.2-Probleme erkennen – sie sind hilfreich, um Verstöße gegen Zielgrößen und offensichtliche Fokus-Management-Probleme zu finden, können aber nicht beurteilen, ob ein CAPTCHA die einzige Authentifizierungsoption ist oder ob ein Hilfemechanismus konsistent positioniert ist. Manuelle Tests, einschließlich reiner Tastaturnavigation und Screenreader-Tests, bleiben unverzichtbar. Tests mit echten Nutzerinnen und Nutzern mit Behinderungen decken Probleme auf, die kein automatisiertes Tool jemals finden wird.

WCAG 2.2 und Overlay-Widgets: Was Sie wissen sollten

Barrierefreiheits-Overlay-Widgets und SDKs – Tools wie Accsible – können einen sinnvollen Beitrag leisten, bestimmte Kategorien von Barrierefreiheitsproblemen sichtbar zu machen und zu beheben, insbesondere für Nutzer, die Echtzeitanpassungen wie größere Schrift, Kontraständerungen oder verbesserte Tastaturnavigation benötigen. Es ist wichtig, sich klarzumachen, was Overlays im Kontext der WCAG-2.2-Konformität leisten können und was nicht.

Overlays können helfen, bestimmte Probleme mit der Fokus-Sichtbarkeit zu adressieren, alternative Navigationsmodi bereitzustellen und nutzerseitige Anpassungen zu ermöglichen, die einige Designschwächen kompensieren. Sie sind eine nützliche Schicht im Barrierefreiheits-Stack, insbesondere für Teams, die die User Experience schnell verbessern müssen, während langfristige Nachbesserungen laufen. Sie sind jedoch kein Ersatz für die Behebung des zugrunde liegenden Codes. Die neuen WCAG-2.2-Kriterien – insbesondere zu Authentifizierung (3.3.8), redundanter Eingabe (3.3.7) und Ziehbewegungen (2.5.7) – erfordern strukturelle Änderungen an der Art, wie Ihre Anwendung gebaut ist, nicht nur an ihrer Darstellung.

Der effektivste Ansatz kombiniert ein gut implementiertes Overlay für nutzerseitige Anpassbarkeit mit sauberen Code-Fixes für die neuen 2.2-Kriterien. Betrachten Sie ein Overlay-SDK als Kraftmultiplikator: Es erweitert Ihre Reichweite, verbessert die Erfahrung für mehr Nutzer und schließt Lücken – aber das Fundament muss dennoch solide sein.

Wichtigste Erkenntnisse

• WCAG 2.2 fügt neun neue Erfolgskriterien hinzu und entfernt eine obsolet gewordene Regel (4.1.1 Parsing). Es ist vollständig abwärtskompatibel zu 2.1, sodass Ihre bisherige Compliance-Arbeit nicht verloren ist – Sie müssen nur das Neue ergänzen.
• Für eine Konformität auf Level AA konzentrieren Sie sich auf sechs spezifische neue Kriterien: Fokus nicht verdeckt (2.4.11 und 2.4.12), Mindestzielgröße (2.5.8), konsistente Hilfe (3.2.6), redundante Eingabe (3.3.7) und barrierefreie Authentifizierung (3.3.8). Dies sind die rechtlich relevanten Kriterien für die meisten Organisationen.
• Die regulatorische Übernahme beschleunigt sich. Der öffentliche Sektor im Vereinigten Königreich setzt WCAG 2.2 bereits durch, die EU stellt im Rahmen des European Accessibility Act darauf um, und US-Gerichte berufen sich zunehmend darauf. Warten Sie nicht auf ein formales Mandat in Ihrer Rechtsordnung, bevor Sie handeln.
• Automatisierte Tools erkennen nur etwa 40% der WCAG-2.2-Probleme – manuelle Tests, Tastaturnavigations-Durchläufe und Tests mit echten Nutzerinnen und Nutzern sind entscheidend, um echte Konformität zu erreichen, insbesondere bei den neuen Kriterien zu Authentifizierung und kognitiver Barrierefreiheit.
• Die häufigsten Quick Wins sind das Beheben von Sticky-Headern, die fokussierte Elemente verdecken, das Vergrößern kleiner Tippziele und das Prüfen Ihrer Login-/Authentifizierungsabläufe auf eine Abhängigkeit von CAPTCHAs. Diese Änderungen sind oft mit geringem Aufwand verbunden und haben große Wirkung – ein guter Ausgangspunkt für Ihren WCAG-2.2-Remediation-Sprint.