WCAG 2.2 ist kein Ersatz für WCAG 2.1, sondern eine Erweiterung davon. Es fügt neun neue Erfolgskriterien hinzu (sechs auf Stufe AA), streicht ein durch moderne Browser überflüssig gewordenes Kriterium und behält alles andere aus 2.1 bei, sodass eine Website, die bereits 2.1 AA erfüllt, eine kurze, konkrete Lücke zu schließen hat, statt ein volles neues Audit vor sich zu haben.
Warum WCAG derzeit zwei aktuelle Versionen im Umlauf hat
Das W3C veröffentlichte WCAG 2.2 im Oktober 2023. Aber die meisten rechtlichen und regulatorischen Rahmenwerke bewegen sich langsamer als die Standardisierungsgremien, die sie definieren, weshalb viele aktive Compliance-Pflichten, einschließlich des harmonisierten technischen Standards EN 301 549 der EAA, in ihrer aktuell veröffentlichten Version weiterhin WCAG 2.1 AA zitieren statt 2.2. Deshalb sind 2026 noch beide Versionen relevant: 2.2 ist der aktuellere und vollständigere Standard, aber 2.1 ist der Standard, der im Gesetz häufig konkret benannt wird.
Diese Verzögerung ist normal dafür, wie technische Standards und Gesetzgebung zusammenwirken. Eine Vorschrift benennt typischerweise eine bestimmte, datierte Version eines Standards statt “die jeweils aktuelle Version”, teils aus Gründen der Rechtssicherheit und teils, weil die Aktualisierung der technischen Verweise eines Gesetzes einen eigenen Verwaltungsprozess durchläuft. EN 301 549 soll voraussichtlich irgendwann WCAG 2.2 einbeziehen (v4.1.1 ist die Version, die dafür allgemein erwartet wird), aber bis diese Aktualisierung formell verabschiedet und in Vorschriften referenziert wird, bleibt WCAG 2.1 AA die Version, an der die meiste EU-Compliance-Arbeit tatsächlich gemessen wird.
Was neu ist in WCAG 2.2
Die neuen Erfolgskriterien gruppieren sich um ein paar praktische Themen, statt zufällig über die Spezifikation verstreut zu sein.
Die Sichtbarkeit des Fokus erhält drei zusammenhängende Ergänzungen: 2.4.11 Fokus nicht verdeckt (Minimum), das verlangt, dass mindestens ein Teil eines fokussierten Elements sichtbar bleibt, wenn etwas wie ein Sticky-Header oder Cookie-Banner es sonst verdecken würde, sowie das verwandte 2.4.12 (erweiterte Version, AAA) und 2.4.13 Fokusdarstellung (AAA), die Mindestgröße und -kontrast für Fokusindikatoren festlegen.
Bei der Authentifizierung gibt es eine bedeutsame Ergänzung: 3.3.8 Barrierefreie Authentifizierung (Minimum), das verlangt, dass Anmeldeprozesse sich nicht allein auf einen kognitiven Funktionstest verlassen (wie sich ein Passwort merken oder ein Rätsel lösen), ohne eine Alternative, es sei denn, dieser Test ist etwas wie Objekterkennung oder wird anderweitig unterstützt.
Interaktion und Eingabeziele erhalten zwei: 2.5.7 Ziehbewegungen, das eine Alternative zu drag-basierten Interaktionen verlangt, und 2.5.8 Zielgröße (Minimum), das eine Mindestgröße von 24 mal 24 Pixeln für klickbare Ziele festlegt, sofern keine Ausnahmen greifen.
Die restlichen Ergänzungen decken konsistente Hilfsmechanismen ab (3.2.6 Konsistente Hilfe, verlangt, dass eine Hilfsoption wie ein Kontaktlink oder eine Chat-Funktion seitenübergreifend an derselben relativen Stelle erscheint, wo sie angeboten wird), redundante Eingabe (3.3.7 Redundante Eingabe, vermeidet, Nutzer zu bitten, Informationen erneut einzugeben, die sie bereits früher im selben Prozess angegeben haben, etwa eine Versandadresse erneut einzutippen, die bereits in einem vorherigen Schritt eingegeben wurde), und Seitenumbruch-Navigation (2.4.13, AAA-Stufe, ausgerichtet auf Inhalte mit Seitenzahlen wie ein E-Book oder ein langes Dokument).
Zwei weitere Ergänzungen auf Stufe AA runden die Liste ab: 2.4.11 hat ein erweitertes AAA-Gegenstück, und die vollständige Liste auf Stufe AA umfasst konkret sechs neue Kriterien, die die meisten Compliance-Programme tatsächlich prüfen müssen: Fokus nicht verdeckt (Minimum), Ziehbewegungen, Zielgröße (Minimum), Konsistente Hilfe, Redundante Eingabe und Barrierefreie Authentifizierung (Minimum).
Was entfernt wurde
WCAG 2.2 strich 4.1.1 Parsing, die alte Anforderung an wohlgeformtes HTML (keine doppelten IDs, korrekt verschachtelte Tags und so weiter). Moderne Browser und assistive Technologien gehen inzwischen so gut mit fehlerhaftem HTML um, dass das Kriterium keinen bedeutsamen Mehrwert mehr bot, weshalb es gestrichen statt weitergeführt wurde.
Welche neuen Kriterien in der Praxis am wichtigsten sind
Nicht alle neun Ergänzungen wiegen für eine typische Unternehmenswebsite gleich schwer. Fokus nicht verdeckt (2.4.11) ist wahrscheinlich am breitesten relevant, weil Sticky-Navigationsleisten, Cookie-Einwilligungsbanner und Chat-Widgets, die den sichtbaren Tastaturfokus verdecken, ein extrem verbreitetes reales Problem sind, kein Randfall. Zielgröße (2.5.8) zählt viel für mobillastige Websites mit kleinen Tippzielen. Barrierefreie Authentifizierung (3.3.8) zählt am meisten für alles mit einem Anmeldeprozess, besonders wenn dieser Ablauf CAPTCHAs oder gedächtnisbasierte Herausforderungen ohne alternativen Weg nutzt.
Redundante Eingabe (3.3.7) zählt meist am meisten bei mehrstufigen Prozessen: Ein Checkout, der nach einer Versandadresse und dann bei einem Rechnungsschritt erneut nach derselben Adresse fragt, ohne die frühere Eingabe zur Wiederverwendung anzubieten, ist ein ziemlich verbreitetes Muster, das genau dieses Kriterium ins Visier nimmt. Ziehbewegungen (2.5.7) zählen überproportional für Websites mit individuellen interaktiven Elementen wie Bild-Schiebereglern, sortierbaren Listen oder Kartenoberflächen, da reine Drag-Interaktion historisch in diesen Komponenten verbreitet war, ohne viel Rücksicht auf eine Nicht-Drag-Alternative.
Müssen Sie Ihr Audit wiederholen
Wenn eine Website bereits WCAG 2.1 AA erfüllt, bedeutet der Umstieg auf 2.2 nicht, von vorn zu beginnen. Da 2.2 abwärtskompatibel ist, besteht die praktische Arbeit darin, die Website konkret gegen die neun neuen Kriterien zu prüfen, statt alles erneut zu testen, was unter 2.1 bereits verifiziert wurde. Testwerkzeuge, die auf der axe-core-Engine basieren, wie die von Deque, haben ihre Regelsätze auf die 2.2-Ergänzungen aktualisiert, was diese Prüfung deutlich schneller macht als ein vollständiges Audit. Anbieter mit laufendem Monitoring, wie AudioEyes Plattform mit menschlicher Beteiligung, können ebenfalls kennzeichnen, wo eine zuvor konforme Website jetzt Lücken gegenüber den neueren Kriterien hat.
Eine praktische Reihenfolge: Führen Sie zuerst einen automatisierten Scan mit einem 2.2-fähigen Regelsatz durch, um mechanisch Erkennbares wie kleine Tippziele oder fehlende Konsistenz bei Hilfe-Links zu erfassen, und machen Sie dann einen gezielten manuellen Durchgang für die Kriterien, die menschliches Urteilsvermögen brauchen, besonders Fokus nicht verdeckt und Barrierefreie Authentifizierung, da beide davon abhängen, wie ein echter Nutzer die Seite erlebt, statt etwas, das ein statischer Scan vollständig bewerten kann.
Häufige Stellen, an denen Websites die neuen Kriterien nicht erfüllen
Ein paar Muster tauchen wiederholt auf, wenn Websites erstmals gegen 2.2 geprüft werden. Sticky-Header und schwebende Chat-Widgets, die den Tastaturfokusring verdecken, während ein Nutzer durch die Seite tabbt, sind wohl der häufigste neue Fehler, gerade weil das ein so weitverbreitetes modernes Designmuster ist. Anmelde- und Registrierungsabläufe, die sich auf ein CAPTCHA ohne alternative Verifizierungsmethode verlassen, scheitern eindeutig an Barrierefreie Authentifizierung. E-Commerce-Websites mit drag-basierten Interaktionen, wie einem per Drag neu sortierbaren Warenkorb oder einem nur per Ziehen steuerbaren Bildkarussell, scheitern an Ziehbewegungen, wenn es keinen Button oder keine tippbasierte Alternative gibt. Und mobile Navigations-Icons oder Schließen-Buttons, die deutlich unter dem 24-Pixel-Minimum liegen, sind ein häufiger Fehler bei Zielgröße, besonders auf Websites, die primär für den Desktop entworfen und erst nachträglich für mobile Geräte angepasst wurden.
Welche Version Sie anstreben sollten
Wenn Ihr geltendes Gesetz oder Ihr Vertrag konkret WCAG 2.1 AA nennt, bleibt die Erfüllung dieser Anforderung Ihre gesetzliche Grundpflicht, und Sie können 2.2-Konformität als vorausschauende Verbesserung behandeln, nicht als unmittelbare Pflicht. Wenn Sie Flexibilität haben oder etwas Neues bauen, ist es die zukunftssicherere Wahl, von Anfang an auf 2.2 AA zu zielen, da es eine strikte Obermenge von 2.1 AA minus einem veralteten Kriterium ist. So oder so ist unsere WCAG-2.1-AA-Checkliste eine nützliche Ausgangsreferenz, falls Sie noch nicht gegen die Grundlage auditiert haben.
Für die meisten Unternehmen lautet die praktische Antwort “beides, nacheinander”: Behandeln Sie WCAG 2.1 AA als die Grundlage, für die Sie heute rechtlich verantwortlich sind, und schichten Sie die WCAG-2.2-Ergänzungen als kurzfristiges Verbesserungsprojekt darauf, statt als separate Initiative. Da sich die beiden Standards fast vollständig überschneiden, gibt es wenig Grund, sie in verschiedene Audits oder verschiedene Anbieter-Engagements zu trennen. Ein einziger Testdurchgang, der den vollen Kriterienumfang von 2.2 abdeckt, deckt automatisch auch 2.1 AA ab, was oft der effizientere Ansatz ist, selbst wenn Ihre unmittelbare gesetzliche Pflicht nur die ältere Version betrifft.
Mit künftigen WCAG-Versionen Schritt halten
Die Versionsgeschichte von WCAG legt nahe, dass sich dieses Muster wiederholen wird. 2.0 war jahrelang die Grundlage, 2.1 fügte Überlegungen zu Mobilgeräten und Sehbehinderung hinzu, und 2.2 fügte die oben behandelten Kriterien hinzu; ein WCAG 3.0 ist mit einer wesentlich anderen Struktur in Entwicklung, bleibt aber ein Arbeitsentwurf statt eines fertigen Standards, und die Übernahme in Gesetze hinkt der Veröffentlichung unabhängig von der Version meist erheblich hinterher. Die praktische Erkenntnis für ein Unternehmen ist nicht, jedem neuen Entwurf hinterherzujagen, sondern eine regelmäßige erneute Prüfung in den eigenen Accessibility-Prozess einzubauen (jährlich ist für die meisten Websites vernünftig), damit Sie, sobald eine neue Version relevant wird, sei es durch aktualisierte Vorschriften oder echte bewährte Praxis, nicht bei null anfangen müssen, um herauszufinden, wo Sie stehen.