WCAG 2.2 verständlich erklärt: Alle Erfolgskriterien im Überblick

Wer Webseiten zugänglich gestalten will, kommt an den Web Content Accessibility Guidelines nicht vorbei. Im Oktober 2023 veröffentlichte das World Wide Web Consortium (W3C) die Version 2.2 dieser Standards – ein Meilenstein, der bestehende Anforderungen schärft und neun zusätzliche Erfolgskriterien einführt. Dieser Artikel erklärt WCAG 2.2 strukturiert und praxisnah: von den vier Grundprinzipien über die drei Konformitätsstufen bis zu den konkreten neuen Kriterien, die insbesondere mobile Nutzerinnen und Nutzer mit Behinderungen besser absichern.

Was sind die WCAG und warum wurde Version 2.2 eingeführt?

Die Web Content Accessibility Guidelines sind ein internationaler Standard, der definiert, wie digitale Inhalte für alle Menschen zugänglich gemacht werden können – unabhängig von körperlichen, sensorischen oder kognitiven Einschränkungen. Das W3C entwickelt diese Leitlinien im Rahmen der Web Accessibility Initiative (WAI) seit den späten 1990er-Jahren. WCAG 1.0 erschien 1999, WCAG 2.0 folgte 2008, und 2018 wurde WCAG 2.1 um 17 neue Kriterien ergänzt – vor allem für mobile Endgeräte und Nutzerinnen mit Lernschwierigkeiten.

WCAG 2.2 adressiert nun insbesondere Lücken, die in der Praxis aufgefallen waren: Fokus-Sichtbarkeit bei Tastaturnavigation, Authentifizierungsprozesse ohne kognitive Hürden und konsistentere Hilfsmechanismen. Gleichzeitig wurde das Kriterium 4.1.1 (Parsing) als überholt gestrichen, da moderne Browser Markup-Fehler mittlerweile zuverlässig selbst kompensieren. Wer heute eine barrierefreie Webseite betreiben möchte, sollte WCAG 2.2 als verbindliche Referenz nutzen – auch weil die EU-Richtlinie 2016/2102 sowie das Barrierefreiheitsstärkungsgesetz (BFSG) auf diesem Standard aufbauen. Mehr zur rechtlichen Perspektive erfahren Sie in unserem Beitrag BFSG: Was Unternehmen ab 2025 beachten müssen.

Die vier Grundprinzipien: POUR

Alle WCAG-Richtlinien – von 2.0 bis 2.2 – fußen auf vier Grundprinzipien, die unter dem Akronym POUR bekannt sind. Sie bilden den konzeptionellen Rahmen, in den sich jedes einzelne Erfolgskriterium einordnet.

• Perceivable (Wahrnehmbar): Inhalte und Benutzeroberflächenkomponenten müssen so präsentiert werden, dass Nutzerinnen und Nutzer sie wahrnehmen können – unabhängig von Sinneskanal oder Hilfsmittel. Beispiele: Textalternativen für Bilder, Untertitel für Videos.
• Operable (Bedienbar): Die Benutzeroberfläche und Navigation müssen über verschiedene Eingabemethoden bedienbar sein. Das schließt vollständige Tastaturbedienbarkeit, ausreichende Zeitlimits und die Vermeidung blinkender Inhalte ein.
• Understandable (Verständlich): Informationen und die Bedienung der Oberfläche müssen verständlich sein. Darunter fällt die Angabe der Sprache im HTML-Code, konsistente Navigation und klare Fehlermeldungen in Formularen.
• Robust (Robust): Inhalte müssen so robust implementiert sein, dass sie von aktuellen und künftigen Hilfstechnologien – etwa Screenreadern oder Sprachsteuerungen – zuverlässig interpretiert werden können.

Jedes der insgesamt 87 Erfolgskriterien in WCAG 2.2 lässt sich einem dieser vier Prinzipien zuordnen. Das Verständnis des POUR-Rahmens erleichtert die Priorisierung bei Barrierefreiheits-Audits erheblich.

Die drei Konformitätsstufen A, AA und AAA

Die Erfolgskriterien sind in drei Stufen unterteilt, die den Grad der Barrierefreiheit und den damit verbundenen Implementierungsaufwand widerspiegeln.

Stufe A umfasst 30 Kriterien, die als absolutes Minimum gelten. Werden sie nicht erfüllt, ist eine Webseite für bestimmte Nutzergruppen schlicht nicht nutzbar – etwa wenn ein Video keine Untertitel hat oder Bilder keinerlei Textalternative besitzen. Stufe AA (25 Kriterien) ist die in der Praxis am häufigsten geforderte Konformitätsstufe. Sie ist Grundlage für gesetzliche Anforderungen in der EU und wird von den meisten öffentlichen und kommerziellen Auftraggebern verlangt. Stufe AAA (32 Kriterien) stellt das höchste Anforderungsniveau dar. Das W3C empfiehlt ausdrücklich, nicht von vornherein vollständige AAA-Konformität für gesamte Webseiten anzustreben, da manche Kriterien für bestimmte Inhaltstypen schlicht nicht umsetzbar sind.

„Conformance to WCAG 2.2 requires meeting all of the Success Criteria at the specified conformance level." — W3C, WCAG 2.2 Understanding Conformance

Für die meisten Betreiber gilt in der Praxis: AA-Konformität ist Pflicht, AAA-Kriterien sollten wo möglich als Verbesserungsanreiz genutzt werden. Wichtig ist auch, dass WCAG 2.2 abwärtskompatibel ist – wer bereits WCAG 2.1 AA erfüllt, muss nur die neun neuen Kriterien prüfen und ggf. nachbessern.

Die neun neuen Erfolgskriterien in WCAG 2.2 im Detail

Das Kernstück von WCAG 2.2 sind die neun neuen Erfolgskriterien. Sie adressieren reale Nutzungsprobleme, die in Studien und Praxisberichten wiederholt dokumentiert wurden – insbesondere für Personen mit motorischen Einschränkungen, kognitiven Beeinträchtigungen und ältere Nutzerinnen und Nutzer.

Fokus und Tastaturnavigation

2.4.11 – Focus Not Obscured (Minimum) [AA]: Der sichtbare Tastaturfokus darf nicht vollständig von anderen Elementen überdeckt werden, beispielsweise durch sticky Header oder Chat-Widgets. 2.4.12 – Focus Not Obscured (Enhanced) [AAA]: Hier gilt die strengere Variante: Der Fokus-Indikator darf gar nicht verdeckt sein. 2.4.13 – Focus Appearance [AAA]: Der Fokus-Indikator muss eine Mindestgröße und einen ausreichenden Kontrastwert aufweisen – konkret einen Umriss von mindestens 2 CSS-Pixeln Breite und ein Kontrastverhältnis von 3:1 zum umgebenden Bereich.

Diese Kriterien sind eine direkte Reaktion auf die weitverbreitete Praxis, den nativen Browser-Fokusring per CSS auszublenden (outline: none) ohne einen zugänglichen Ersatz zu bieten. Für Tastaturnutzerinnen und -nutzer – darunter viele Menschen mit motorischen Einschränkungen – ist ein gut sichtbarer Fokus unverzichtbar.

Zielgröße von interaktiven Elementen

2.5.8 – Target Size (Minimum) [AA]: Klick- und Tippziele müssen mindestens 24 × 24 CSS-Pixel groß sein oder ausreichend Abstand zu benachbarten Zielen aufweisen. 2.5.5 – Target Size (Enhanced) [AAA]: Diese bereits aus WCAG 2.1 bekannte Regel fordert 44 × 44 CSS-Pixel. Das Kriterium 2.5.8 schafft nun eine erreichbarere Zwischenstufe, die für mobile Interfaces besonders relevant ist. Kleine Icons, enge Link-Reihen oder winzige Checkboxen ohne Beschriftungsklick-Bereich sind häufige Verstöße in der Praxis.

Konsistente Hilfsmechanismen

3.2.6 – Consistent Help [A]: Wenn eine Webseite einen Hilfe-Mechanismus anbietet – sei es eine Telefonnummer, ein Live-Chat oder eine FAQ-Seite – muss dieser an konsistenter Stelle erscheinen, wenn er auf mehreren Seiten vorkommt. Dieses Kriterium hilft vor allem Menschen mit kognitiven Beeinträchtigungen, die sich auf wiederkehrende Muster verlassen.

Authentifizierung ohne kognitive Last

3.3.7 – Redundant Entry [A]: Innerhalb eines Prozesses (z. B. eines mehrstufigen Formulars) dürfen Informationen nicht mehrfach abgefragt werden, wenn sie zuvor bereits eingegeben wurden – es sei denn, eine erneute Eingabe ist aus sicherheitstechnischen Gründen zwingend notwendig. 3.3.8 – Accessible Authentication (Minimum) [AA]: Kognitive Tests – etwa das Abtippen von verzerrtem Text (CAPTCHA) oder das Lösen von Rätseln – dürfen nicht als einzige Authentifizierungsmethode eingesetzt werden, ohne dass eine barrierefreie Alternative existiert. 3.3.9 – Accessible Authentication (Enhanced) [AAA]: Dieses Kriterium schließt auch die Ausnahmen aus Stufe AA weitgehend aus und fordert vollständig kognitionsfreie Authentifizierungsmethoden.

Gerade das Thema CAPTCHA ist ein jahrelanges Ärgernis für Nutzerinnen und Nutzer mit Legasthenie, visuellen Einschränkungen oder kognitiven Beeinträchtigungen. Passwort-Manager-Unterstützung, Magic Links per E-Mail oder biometrische Authentifizierung sind konforme Alternativen.

Typische Fehler bei der WCAG-2.2-Umsetzung

Selbst erfahrene Entwicklungsteams stolpern bei der WCAG-konformen Umsetzung immer wieder über dieselben Problemstellen. Die folgende Liste fasst die häufigsten Fehler zusammen, die bei Barrierefreiheits-Audits regelmäßig auftauchen:

1. Fehlender oder ausgeblendeter Fokus-Indikator: outline: none ohne zugänglichen Ersatz ist der klassische Fehler Nr. 1 – und betrifft jetzt explizit die Kriterien 2.4.11 bis 2.4.13.
2. Zu kleine Touch-Targets: Icons mit 16 × 16 Pixeln, enge Linkgruppen in der Navigation oder Formularbeschriftungen, die nicht klickbar sind, verstoßen gegen 2.5.8.
3. CAPTCHA ohne Alternative: Ausschließlich visuelle Captchas ohne Audio-Variante oder Login-per-E-Mail-Link verletzen 3.3.8.
4. Formulardaten-Wiederholung: Mehrstufige Checkout-Prozesse, die E-Mail-Adresse oder Lieferadresse mehrfach abfragen, widersprechen 3.3.7.
5. Inkonsistente Hilfe-Platzierung: Ein Support-Chat, der je nach Seite an verschiedenen Positionen erscheint oder manchmal fehlt, verletzt 3.2.6.
6. Unzureichende Farbkontraste in Fokuszuständen: Oft wird der Kontrastwert des Fokus-Rings nicht separat geprüft, obwohl 2.4.13 spezifische Mindestwerte vorschreibt.

WCAG 2.2 im Kontext: Prüfmethoden, Tools und rechtliche Relevanz

WCAG 2.2 ist kein Selbstzweck – sie entfaltet ihre Wirkung im Zusammenspiel mit konkreten Prüfmethoden und rechtlichen Rahmenbedingungen. Die WCAG 2.2 erklärt-Dokumentation des W3C stellt für jedes Kriterium sogenannte „Understanding"-Dokumente und „Techniques"-Seiten bereit, die konkrete Implementierungsbeispiele geben.

Für automatisierte Tests sind Tools wie axe DevTools, WAVE oder Lighthouse unverzichtbar. Sie erkennen jedoch nur etwa 30–40 % aller Barrierefreiheitsfehler. Manuelle Tests – insbesondere mit echten Hilfstechnologien wie NVDA, JAWS oder VoiceOver – sowie Nutzertests mit betroffenen Personen sind für eine vollständige Prüfung unerlässlich. Der European Accessibility Act, in Deutschland durch das Barrierefreiheitsstärkungsgesetz umgesetzt, verlangt ab dem 28. Juni 2025 von vielen privaten Unternehmen die Einhaltung von WCAG 2.2 AA für digitale Produkte und Dienstleistungen.

Neben Webseiten betrifft Barrierefreiheit auch Dokumente. Wer PDF-Dateien publiziert, sollte sich mit dem Standard PDF/UA vertraut machen – eine detaillierte Anleitung bietet unser Beitrag Barrierefreie PDFs erstellen: Schritt für Schritt zur PDF/UA-Konformität. Die Kombination aus barrierefreier Webseite und barrierefreien Dokumenten ist die Grundlage für eine vollständig inklusive digitale Präsenz.

Ein strukturierter Ansatz zur WCAG-Implementierung empfiehlt sich in drei Phasen: Zunächst ein initiales Audit auf Basis automatisierter Tools und manueller Prüfung, anschließend die Priorisierung und Behebung von Barrieren nach Schweregrad und Auswirkung, und schließlich die Integration von Barrierefreiheitsprüfungen in den regulären Entwicklungs- und Publishing-Prozess – etwa durch CI/CD-Pipelines mit automatisierten axe-Tests oder redaktionelle Checklisten für Content-Teams.

Ausblick: WCAG 3.0 und die Zukunft der digitalen Barrierefreiheit

Parallel zu WCAG 2.2 arbeitet das W3C bereits an WCAG 3.0, intern auch als „Silver" bekannt. Dieser zukünftige Standard bricht mit dem bisherigen binären Konformitätsmodell (erfüllt / nicht erfüllt) und führt ein graduelles Bewertungssystem ein. Statt Erfolgskriterien in drei Stufen soll ein Punktesystem den Reifegrad der Barrierefreiheit differenzierter abbilden.

WCAG 3.0 befindet sich noch im frühen Entwurfsstadium, ein finaler Release wird nicht vor 2027–2028 erwartet. Bis dahin bleibt WCAG 2.2 der maßgebliche Standard – und wer jetzt die Grundlagen solide implementiert, wird den Übergang zu WCAG 3.0 deutlich leichter meistern. Investitionen in Barrierefreiheit zahlen sich zudem mehrfach aus: Sie verbessern die Nutzererfahrung für alle, stärken die SEO-Performance und reduzieren rechtliche Risiken nachhaltig.