In jedem zweiten Audit treffe ich auf Teams, die ihre Website noch gegen WCAG 2.1 prüfen lassen und glauben, damit auf dem aktuellen Stand zu sein. Das ist ein Missverständnis mit Folgen. Die WCAG 2.2 ist seit Oktober 2023 die offizielle Empfehlung des W3C, und sie bringt neun zusätzliche Erfolgskriterien, die genau dort ansetzen, wo moderne Websites in der Praxis am häufigsten scheitern: bei Cookie-Bannern, Drag-and-Drop-Slidern, winzigen Touch-Zielen und nervigen Login-Hürden. In diesem Ratgeber erkläre ich Ihnen die neun Neuerungen verständlich, mit konkreten Vorher-Nachher-Beispielen, damit Sie sofort erkennen, wo Ihre eigene Website nachbessern muss.
Was WCAG 2.2 ist und was sich gegenüber 2.1 geändert hat
Die WCAG 2.2 (Web Content Accessibility Guidelines, Version 2.2) ist der internationale Standard für barrierefreie Webinhalte, herausgegeben vom World Wide Web Consortium. Sie baut vollständig auf der Vorgängerversion 2.1 auf – alle dortigen Erfolgskriterien gelten weiter – und ergänzt neun neue Kriterien, die vor allem Menschen mit motorischen und kognitiven Einschränkungen sowie Nutzern mit eingeschränkter Sehfähigkeit zugutekommen. Ein einziges altes Kriterium, 4.1.1 Parsing, wurde für obsolet erklärt. Wer heute baut oder prüft, sollte WCAG 2.2 auf Konformitätsstufe AA als Maßstab nehmen, nicht mehr 2.1.
Die neun neuen Erfolgskriterien der WCAG 2.2 im Überblick
Bevor wir in die Beispiele gehen, hier die kompakte Übersicht. Die Stufe entscheidet über die Relevanz: A und AA sind der gesetzlich geforderte Bereich, AAA ist freiwilliges Premium-Niveau.
| Kriterium | Stufe | Worum es geht |
|---|---|---|
| 2.4.11 Fokus nicht verdeckt (Minimum) | AA | Das fokussierte Element darf nicht vollständig verdeckt sein |
| 2.4.12 Fokus nicht verdeckt (Erweitert) | AAA | Das fokussierte Element darf gar nicht verdeckt sein |
| 2.4.13 Erscheinungsbild des Fokus | AAA | Mindestgröße und Mindestkontrast des Fokus-Indikators |
| 2.5.7 Ziehbewegungen | AA | Drag-and-Drop-Funktionen brauchen eine Alternative ohne Ziehen |
| 2.5.8 Zielgröße (Minimum) | AA | Klickziele mindestens 24×24 CSS-Pixel |
| 3.2.6 Konsistente Hilfe | A | Hilfe-Mechanismen über Seiten hinweg an gleicher Stelle |
| 3.3.7 Redundante Eingaben | A | Bereits eingegebene Daten nicht erneut abfragen |
| 3.3.8 Barrierefreie Authentifizierung (Minimum) | AA | Kein kognitiver Funktionstest beim Login ohne Alternative |
| 3.3.9 Barrierefreie Authentifizierung (Erweitert) | AAA | Wie 3.3.8, aber ohne die Ausnahmen |
Die praxisrelevanten Neuerungen mit Vorher und Nachher
Sechs der neun Kriterien liegen auf den Stufen A und AA und sind damit Teil dessen, was Sie rechtlich erfüllen müssen. Diese sechs gehe ich jetzt mit konkreten Beispielen durch, so wie ich sie in Audits immer wieder sehe.
2.4.11 Fokus nicht verdeckt – das Cookie-Banner-Problem
Vorher: Ein Nutzer bedient Ihr Anmeldeformular mit der Tastatur und tabbt von Feld zu Feld. Sobald er beim unteren Bereich ankommt, schiebt sich ein klebriger Cookie-Banner oder eine Sticky-Leiste über das gerade aktive Feld. Der Tastatur-Nutzer sieht nicht mehr, wo er steht – er tippt blind.
Nachher: Das fokussierte Element bleibt sichtbar. Entweder weicht der Banner aus, oder die Seite scrollt so, dass das aktive Feld nie vollständig verdeckt wird. In der Praxis ist das eines der am häufigsten verletzten neuen Kriterien, weil Sticky-Elemente und Consent-Layer überall verbaut sind.
2.5.7 Ziehbewegungen – die Slider-Falle
Vorher: Ein Preisfilter im Shop funktioniert ausschließlich über einen Schieberegler, den man mit der Maus ziehen muss. Wer eine motorische Einschränkung, einen Tremor oder nur einen Touchscreen ohne Feinmotorik hat, kann den Wert nicht einstellen.
Nachher: Zusätzlich zum Ziehen gibt es Plus- und Minus-Schaltflächen oder ein direktes Eingabefeld für den Wert. Die Funktion ist mit einem einzelnen Tippen erreichbar, ohne dass eine kontinuierliche Ziehbewegung nötig ist.
2.5.8 Zielgröße – Schluss mit Mini-Buttons
Vorher: Die Social-Media-Icons in Ihrem Footer sind 16×16 Pixel groß und stehen dicht nebeneinander. Auf dem Smartphone trifft der Nutzer regelmäßig das falsche Icon oder gar keins.
Nachher: Jede interaktive Fläche misst mindestens 24×24 CSS-Pixel – oder es gibt genug Abstand zwischen den Zielen, sodass keine versehentliche Aktivierung passiert. Das klingt banal, ist aber in mobilen Layouts ein Dauerthema.
3.2.6 Konsistente Hilfe – Verlässlichkeit statt Suchspiel
Vorher: Der Hilfe-Link steht auf der Startseite oben rechts, im Checkout unten links und auf der Kontaktseite an wieder anderer Stelle. Nutzer müssen ihn auf jeder Seite neu suchen.
Nachher: Hilfe-Mechanismen wie Kontaktdaten, FAQ-Link oder Chat erscheinen über alle Seiten hinweg in derselben relativen Reihenfolge und Position. Wer einmal gelernt hat, wo die Hilfe sitzt, findet sie überall wieder.
3.3.7 Redundante Eingaben – nicht zweimal dasselbe abfragen
Vorher: Im Checkout soll der Kunde seine Lieferadresse eingeben, obwohl sie identisch mit der bereits erfassten Rechnungsadresse ist. Dieselbe Information wird im selben Prozess ein zweites Mal verlangt.
Nachher: Bereits eingegebene Daten werden automatisch übernommen oder per Auswahl angeboten – etwa über eine Checkbox „Lieferadresse entspricht Rechnungsadresse“. Ausnahmen bleiben dort erlaubt, wo die erneute Eingabe sicherheitsrelevant ist, etwa bei der Passwort-Bestätigung.
3.3.8 Barrierefreie Authentifizierung – das Captcha-Ende
Vorher: Beim Login muss ein verzerrtes Captcha entziffert oder ein Bilderrätsel gelöst werden („Wählen Sie alle Felder mit Ampeln“). Beides ist ein kognitiver Funktionstest, der Menschen mit kognitiven Einschränkungen, aber auch viele ältere Nutzer ausschließt.
Nachher: Die Anmeldung erlaubt Passwort-Manager und Copy-Paste, bietet biometrische Verfahren oder einen Magic-Link per E-Mail. Wo eine Verifikation nötig ist, gibt es eine Alternative, die keine Gedächtnis- oder Rätselleistung verlangt. Gerade Banking- und Versicherungs-Logins fallen hier in Audits regelmäßig durch.
Die drei AAA-Kriterien – relevant oder nicht?
Drei der neun Neuerungen liegen auf Stufe AAA: das strengere Fokus-Kriterium 2.4.12, die Vorgaben zum Erscheinungsbild des Fokus-Indikators in 2.4.13 und die verschärfte Authentifizierung in 3.3.9. Für die meisten Unternehmen sind sie nicht verpflichtend, weil der gesetzliche Maßstab in EN 301 549, BFSG und BITV 2.0 die Stufe AA ist, nicht AAA. Trotzdem lohnt ein Blick: Das Erscheinungsbild des Fokus-Indikators etwa ist ein Detail, das die Bedienbarkeit für Tastatur-Nutzer spürbar verbessert, auch wenn es formal nur AAA ist. Welches Konformitätslevel für Ihre Situation wirklich sinnvoll ist, habe ich in WCAG-Konformitätsstufen A, AA und AAA: Welches Level Sie wirklich brauchen aufgeschlüsselt.
Was mit dem alten Kriterium 4.1.1 Parsing passiert ist
Eine Änderung sorgt regelmäßig für Verwirrung: Das Erfolgskriterium 4.1.1 Parsing, das in WCAG 2.0 und 2.1 noch HTML-Syntaxfehler bemängelte, gilt in WCAG 2.2 als obsolet und wird als immer erfüllt gewertet. Der Grund ist pragmatisch: Moderne Browser und assistive Technologien gehen mit kleineren Markup-Fehlern inzwischen zuverlässig um, sodass das Kriterium seinen Zweck verloren hat. Wenn Ihr altes Audit-Tool dieses Kriterium noch als Mangel meldet, arbeitet es nach einem überholten Stand.
Was das für Ihre Website konkret bedeutet
Die gute Nachricht: Wenn Ihre Website bereits WCAG 2.1 AA erfüllt, ist der Weg zu 2.2 überschaubar. Die sechs neuen A- und AA-Kriterien sind in der Regel mit gezielten Anpassungen umsetzbar – Cookie-Banner entschärfen, Slider mit Alternativen versehen, Touch-Ziele vergrößern, Hilfe konsistent platzieren, doppelte Eingaben eliminieren, Captchas durch barrierefreie Verfahren ersetzen. Die schlechte Nachricht: Genau diese Punkte betreffen oft die zentralen Conversion-Pfade – Login, Filter, Checkout. Ein Fehler hier kostet Sie nicht nur Compliance, sondern unmittelbar Kunden.
Der schnellste Weg, den Stand Ihrer Website gegen WCAG 2.2 zu prüfen, ist unser kostenloser Access Score. Er führt ein automatisiertes WCAG-2.2-Audit Ihrer Domain durch, erkennt unter anderem Tastatur-Fallen und verdeckte Fokus-Elemente und übersetzt die rohen Code-Befunde in verständliche Handlungsempfehlungen. Das ersetzt kein vollständiges Tiefen-Audit – die rund 60 Prozent der Kriterien, die nur ein Mensch beurteilen kann, deckt erst ein manuelles Audit ab –, aber es zeigt Ihnen in wenigen Minuten, wo Sie stehen und welche der neuen 2.2-Anforderungen Sie aktuell verletzen. Ein häufig unterschätztes Detailthema, die Kontrastwerte, vertiefe ich übrigens in Kontraste nach WCAG richtig prüfen: Mindestwerte und typische Fehler.
