Was ist neu in WCAG 2.2? Die 9 neuen Kriterien verständlich erklärt

Jemand bewegt sich mit der Tastatur durch Ihren Checkout. Der Fokus landet auf dem Button „Jetzt bezahlen“, aber ein fixiertes Cookie-Banner liegt darüber, und die Person sieht nicht mehr, wo sie ist. Nach WCAG 2.1 könnte diese Seite trotzdem bestehen. Nach WCAG 2.2 fällt sie durch.

Genau solche Lücken schließt das Update auf 2.2. Hier bekommt jedes neue Erfolgskriterium dieselbe Behandlung: was es besagt, wem es hilft, ein schneller Test und die übliche Lösung. Die vier Prinzipien und die Stufen auf einer Seite finden Sie in unserer englischsprachigen WCAG-2.2-Referenz.

Was ist WCAG 2.2?

WCAG 2.2 ist die aktuelle Version der Web Content Accessibility Guidelines (Richtlinien für barrierefreie Webinhalte), des W3C-Standards, auf den sich die meisten Barrierefreiheitsgesetze und -verträge beziehen. Sie wurde am 5. Oktober 2023 (öffnet in einem neuen Tab) zur W3C-Empfehlung, am 12. Dezember 2024 (öffnet in einem neuen Tab) aktualisiert und im Oktober 2025 als ISO/IEC 40500:2025 angenommen (öffnet in einem neuen Tab).

Die WCAG bestehen aus prüfbaren Aussagen, den Erfolgskriterien, jeweils mit einer Stufe: A (das Minimum), AA (was Gesetze meist verlangen) oder AAA (die strengste). „Wir brauchen WCAG 2.2 AA“ bedeutet: jedes Kriterium der Stufen A und AA in Version 2.2. Laut Spezifikation „baut 2.2 auf WCAG 2.1 auf und ist abwärtskompatibel“; die neue Version ergänzt 2.1 also, statt es zu ersetzen.

Was hat sich von WCAG 2.1 zu 2.2 geändert?

WCAG 2.2 fügt neun Erfolgskriterien hinzu und streicht eines. Sechs der neuen liegen auf Stufe A oder AA und zählen damit zum üblichen Ziel AA: 2.4.11, 2.5.7, 2.5.8, 3.2.6, 3.3.7 und 3.3.8. Die anderen drei sind AAA. Gestrichen wurde 4.1.1 Syntaxanalyse (Parsing), das das W3C inzwischen als überholt bezeichnet.

4.1.1 prüfte Fehler im Markup wie doppelte IDs. Die WCAG-2-FAQ (öffnet in einem neuen Tab) erklärt, dass solche Probleme jetzt unter andere Kriterien fallen, etwa 4.1.2 Name, Rolle, Wert. Ein Haken: Verlangt ein Vertrag noch WCAG 2.0 oder 2.1, müssen Sie 4.1.1 laut W3C „möglicherweise weiterhin testen und darüber berichten“.

Fokus nicht verdeckt und Fokus-Erscheinungsbild: Sehen Tastaturnutzer, wo sie sind?

Diese Kriterien halten das Element mit dem Tastaturfokus sichtbar. Auf Stufe AA (2.4.11) darf ein fokussierter Link oder Button nicht vollständig von Inhalten verdeckt sein, die Sie hinzugefügt haben, etwa einem fixierten Header, einem Cookie-Banner oder einer Chat-Blase. Auf Stufe AAA darf gar nichts darüberliegen (2.4.12), und der Fokusrahmen muss groß und deutlich kontrastreich sein (2.4.13).

• Wem es hilft: sehenden Menschen, die statt einer Maus die Tastatur verwenden, oft wegen einer motorischen Behinderung. Sehen sie den Fokus nicht, raten sie nur noch.
• Schneller Test: Laden Sie eine lange Seite, bei der Cookie-Banner, fixierter Header und Chat-Widget gleichzeitig sichtbar sind, und drücken Sie mehrmals die Tabulatortaste. Verschwindet der Fokus vollständig hinter etwas, ist das ein Verstoß gegen 2.4.11.
• Übliche Lösung: Ergänzen Sie per CSS ein Scroll-Padding in der Höhe Ihres fixierten Headers oder Footers, damit der Browser fokussierte Elemente daran vorbeiscrollt. Das W3C führt das als hinreichende Technik (öffnet in einem neuen Tab) auf. Ein Banner kann auch bestehen, wenn es modal ist und zuerst geschlossen werden muss.

Fokus-Erscheinungsbild (2.4.13) verlangt eine Anzeige, die mindestens so groß ist wie ein 2 CSS-Pixel dicker Rahmen um das Element, mit einer Kontraständerung von mindestens 3:1 zwischen fokussiertem und nicht fokussiertem Zustand. Das ist AAA, aber ein durchgehender 2-Pixel-Rahmen in einer kräftigen Farbe reicht meistens. Wie Sie 3:1 messen, erklärt unser Leitfaden zum Farbkontrast.

Ziehbewegungen und Zielgröße: Lässt sich Ihre Website ohne präzises Zeigen bedienen?

Diese beiden Kriterien der Stufe AA helfen Menschen, denen feine Zeigerbewegungen schwerfallen. 2.5.7 besagt, dass alles, was per Ziehen funktioniert, auch mit einzelnen Klicks oder Taps funktionieren muss. 2.5.8 besagt, dass Ziele mindestens 24 × 24 CSS-Pixel groß sein müssen oder so viel Abstand haben, dass ein Kreis mit 24 Pixeln Durchmesser um jedes Ziel kein anderes Ziel berührt.

2.5.7 Ziehbewegungen

Denken Sie an einen Schieberegler für die Preisspanne im Shopfilter oder an eine Wunschliste, die man per Ziehen umsortiert. Für jemanden mit Tremor oder mit einer Kopfmaus kann Drücken, Halten, Bewegen und Loslassen sehr schwer sein.

Schneller Test: Erledigen Sie jede Ziehaufgabe nur mit Klicks oder Taps. Übliche Lösung: Lassen Sie Klicks an jeder Stelle der Reglerschiene zu, ergänzen Sie Felder für „min“ und „max“ daneben oder Buttons „Nach oben“ und „Nach unten“ in sortierbaren Listen. Tastaturbedienung allein reicht nicht: Das Understanding-Dokument (öffnet in einem neuen Tab) des W3C sagt, eine Tastaturalternative „erfüllt dieses Erfolgskriterium nicht automatisch“.

2.5.8 Zielgröße (Minimum)

Typische Fehler sind kleine „ד-Buttons in Pop-ups, eng gesetzte Seitenzahlen, Sternebewertungen und Reihen von Social-Media-Symbolen. Daneben zu tippen, ist für alle ärgerlich und für Menschen mit eingeschränkter Fingerfertigkeit eine echte Barriere.

• Ausnahmen: Links innerhalb eines Satzes, Ziele mit einem gleichwertigen Bedienelement an anderer Stelle der Seite, das die Größe erfüllt, Bedienelemente, deren Größe der Browser bestimmt und die Sie nicht umgestaltet haben, und Fälle, in denen eine bestimmte Größe wesentlich oder gesetzlich vorgeschrieben ist.
• Schneller Test: Probieren Sie auf dem Smartphone jedes kleine Symbol und jeden Button aus; zum Messen untersuchen Sie das Element in den Entwicklertools Ihres Browsers.
• Übliche Lösung: mehr Padding. Die klickbare Fläche wächst, auch wenn das Symbol gleich aussieht. Und betrachten Sie 24 Pixel als Untergrenze: Das ältere AAA-Kriterium 2.5.5 verlangt 44 × 44.

Konsistente Hilfe und Redundante Eingabe: Lassen Sie Menschen suchen oder alles wiederholen?

Beide liegen auf Stufe A. 3.2.6 Konsistente Hilfe besagt: Erscheinen Hilfeangebote wie Kontaktdaten, ein Chat oder ein FAQ-Link auf mehreren Seiten, müssen sie jedes Mal in derselben Reihenfolge relativ zum restlichen Seiteninhalt stehen. 3.3.7 Redundante Eingabe besagt, dass niemand Angaben neu eintippen muss, die er im selben Vorgang schon gemacht hat.

Konsistente Hilfe verpflichtet Sie nicht, überhaupt Hilfe anzubieten. Das Kriterium verlangt nur: Steht die Telefonnummer auf Produktseiten im Header, sollte sie im Checkout, wo man sie am dringendsten braucht, nicht in den Footer wandern. Am meisten profitieren Menschen mit Gedächtnis- oder Aufmerksamkeitsproblemen. Die Lösung ist meist ein gemeinsames Template, statt die Hilfe Seite für Seite zu platzieren.

Redundante Eingabe zielt auf mehrstufige Formulare. Ein Buchungsformular, das in Schritt 1 und noch einmal in Schritt 3 nach der E-Mail-Adresse fragt, fällt durch, ebenso ein Checkout, in dem man eine identische Rechnungsadresse neu eintippen muss. Füllen Sie das Feld automatisch aus oder lassen Sie es auswählen, zum Beispiel mit einem Kontrollkästchen „Rechnungsadresse entspricht der Lieferadresse“. Ausnahmen: Die erneute Eingabe ist wesentlich, aus Sicherheitsgründen nötig, oder die früheren Angaben gelten nicht mehr.

Barrierefreie Authentifizierung: Kommt man ohne Gedächtnistest ins Konto?

Erfolgskriterium 3.3.8 (Stufe AA) besagt, dass kein Schritt beim Anmelden von einem kognitiven Funktionstest abhängen darf, etwa sich ein Passwort zu merken, verzerrte Zeichen abzutippen oder ein Rätsel zu lösen, es sei denn, Sie bieten eine Alternative oder eine Hilfe an. In der Praxis heißt das: Lassen Sie Passwort-Manager die Felder ausfüllen, erlauben Sie das Einfügen und bieten Sie eine Methode an, die nicht vom Gedächtnis abhängt.

Die WCAG definieren einen kognitiven Funktionstest als „eine Aufgabe, bei der sich der Nutzer Informationen merken, sie verarbeiten oder abschreiben muss“. Name, E-Mail-Adresse oder Telefonnummer einzugeben, zählt nicht, weil diese Angaben persönlich und überall gleich sind. Ein Login-Schritt besteht auf Stufe AA, wenn er mindestens eine dieser Möglichkeiten bietet:

• Eine Alternative ohne kognitiven Test, etwa einen Passkey oder einen Link per E-Mail.
• Einen Mechanismus, der hilft, etwa Unterstützung für Passwort-Manager oder Kopieren und Einfügen, damit ein Einmalcode nicht abgetippt werden muss.
• Objekterkennung, zum Beispiel „Wählen Sie die Bilder mit einem Fahrrad aus“.
• Persönliche Inhalte, etwa ein Bild wiederzuerkennen, das man selbst hochgeladen hat.

Die AAA-Version 3.3.9 streicht die letzten beiden Möglichkeiten; ein Bild-CAPTCHA kann also auf Stufe AA bestehen, auf AAA nicht. Typische Fehler: Passwortfelder, die Einfügen oder Passwort-Manager blockieren, Felder für Einmalcodes, die beim Einfügen streiken, und ein Text-CAPTCHA ohne Alternative. Am meisten profitieren Menschen mit Legasthenie oder Gedächtnisbeeinträchtigungen, aber das Problem kennt jeder, der sich nach einem langen Tag ausgesperrt hat.

Ist WCAG 2.2 gesetzlich vorgeschrieben?

Das hängt davon ab, wo Sie sind und wer Sie sind. Gesetze nennen selten direkt eine WCAG-Version, und mehrere verweisen noch auf WCAG 2.1 AA. Weil WCAG 2.2 abwärtskompatibel ist, erfüllt 2.2 AA auch 2.1 AA, abgesehen vom gestrichenen 4.1.1. Wer 2.2 anstrebt, deckt beides ab. Nennt ein Vertrag eine Version, gilt der Vertrag.

• Europäische Union: Nach dem European Accessibility Act, in Deutschland umgesetzt durch das BFSG, wird Konformität vermutet, wenn Sie die harmonisierte Norm EN 301 549 erfüllen. Laut AccessibleEU (öffnet in einem neuen Tab) übernimmt die im September 2026 veröffentlichte Version 4.1.1 WCAG 2.2, ist aber noch nicht die rechtlich maßgebliche Referenz; bis ihre Fundstelle im Amtsblatt veröffentlicht ist, gilt v3.2.1 (auf Basis von WCAG 2.1 AA). Für wen das Gesetz gilt, erklärt unser Beitrag zum BFSG und European Accessibility Act.
• Vereinigtes Königreich: Laut Leitfaden der Regierung (öffnet in einem neuen Tab) müssen Websites und Apps des öffentlichen Sektors WCAG 2.2 AA erfüllen. Das gilt für öffentliche Stellen, nicht für private Unternehmen.
• USA: Die Regel des Justizministeriums für Bundesstaaten und Kommunen verwendet WCAG 2.1 AA; die Fristen wurden im April 2026 (öffnet in einem neuen Tab) auf den 26. April 2027 und den 26. April 2028 verschoben. Für private Unternehmen sagen die Leitlinien von 2022 (öffnet in einem neuen Tab), dass der ADA auch für ihre Websites gilt, legen aber keine bestimmte technische Norm fest.

Und WCAG 3?

WCAG 3 ist ein Entwurf; niemand kann ihn also schon erfüllen. Das W3C hat im September 2026 aktualisierte Entwürfe veröffentlicht und rechnet damit, dass WCAG 3 erst „in ein paar Jahren“ ein fertiger Standard ist. WCAG 2 wird danach noch mehrere Jahre nicht für veraltet erklärt; für die Arbeit heute ist also 2.2 die richtige Version.

Wie prüfen Sie die neuen Kriterien in 15 Minuten?

Die meisten Verstöße gegen die sechs Kriterien der Stufen A und AA finden Sie in etwa 15 Minuten, mit Tastatur, Smartphone und Ihrer eigenen Login-Seite. Das ersetzt weder ein vollständiges Audit noch Tests mit Menschen mit Behinderungen, zeigt Ihnen aber, wo Sie anfangen sollten, und gibt Entwicklern eine konkrete Liste.

1. Gehen Sie mit der Tabulatortaste durch Startseite, Produktseite und Checkout, während alle Banner sichtbar sind. Sehen Sie den Fokus immer? (2.4.11)
2. Bedienen Sie jeden Schieberegler und erledigen Sie jede Drag-and-drop-Aufgabe nur mit Klicks oder Taps. (2.5.7)
3. Probieren Sie auf dem Smartphone jeden Schließen-Button, jede Seitenzahl und jedes kleine Symbol aus. (2.5.8)
4. Vergleichen Sie, wo Hilfe und Kontaktdaten auf drei Seitentypen stehen. (3.2.6)
5. Gehen Sie einen Kauf oder eine Buchung durch und notieren Sie jede Frage, die Sie zweimal beantworten. (3.3.7)
6. Melden Sie sich mit einem Passwort-Manager an, und fügen Sie dann ein Passwort und einen Einmalcode aus der Zwischenablage ein. Hat jedes CAPTCHA eine Alternative? (3.3.8)

Für die übrigen WCAG-Kriterien beschreibt unser Leitfaden Barrierefreiheit einer Website testen kostenlose Tools und manuelle Prüfungen, und unsere Checkliste für barrierefreie Websites macht aus häufigen Fehlern eine Aufgabenliste. Was Sie noch nicht beheben können, gehört in Ihre Erklärung zur Barrierefreiheit.

Ein Hinweis zu Widgets, unseres eingeschlossen: Keines dieser Kriterien lässt sich über ein Panel für Besucher erfüllen. Ein großer Mauszeiger macht kleine Ziele leichter zu treffen, aber nicht 24 Pixel breit, und eine Fokushervorhebung schiebt kein fixiertes Banner aus dem Weg. Jedes neue Kriterium betrifft die Art, wie Ihre Seiten gebaut sind; die Lösung steckt also in Ihren Templates und Ihrem Code.