- WCAG 2.2 ist seit Oktober 2023 der aktuelle Standard. Gegenüber 2.1 kommen neun neue Erfolgskriterien hinzu, ein veraltetes fällt weg.
- Für Stufe AA neu verpflichtend: Fokus darf nicht vollständig verdeckt werden (2.4.11), Drag-and-Drop braucht eine Tipp-Alternative (2.5.7), Klickziele müssen mindestens 24×24 Pixel groß sein (2.5.8), und Anmeldung darf keinen Gedächtnistest verlangen (3.3.8).
- Hinzu kommen zwei neue Stufe-A-Kriterien: konsistente Hilfenavigation (3.2.6) und Schutz vor doppelter Eingabe (3.3.7).
- 4.1.1 Parsing wurde als überholt gestrichen. Wer WCAG 2.1 AA erfüllt hat, muss nur die neuen Punkte nachprüfen, kein Neuaufbau nötig.
Seit Oktober 2023 ist WCAG 2.2 der aktuelle Stand der Technik für barrierefreie Webinhalte. Wer ab dem 28. Juni 2025 unter das Barrierefreiheitsstärkungsgesetz fällt, muss sich daran messen lassen: Das BFSG verweist auf EN 301 549, und diese europäische Norm referenziert die WCAG. Gegenüber Version 2.1 sind mehrere Kriterien dazugekommen, einige davon für Stufe AA verpflichtend. Was das für eine Unternehmenswebsite oder einen Onlineshop praktisch bedeutet.
Was WCAG ist und warum 2.2 jetzt relevant ist
WCAG steht für Web Content Accessibility Guidelines. Das W3C, das Standardisierungsgremium des Webs, veröffentlicht sie als Richtlinienwerk für barrierefreie digitale Inhalte. Die Kriterien sind in vier Grundsätze gegliedert: Inhalte müssen wahrnehmbar, bedienbar, verständlich und robust sein. Daraus leiten sich konkrete Prüfpunkte ab, die in drei Konformitätsstufen eingeteilt sind: A als Pflicht-Untergrenze, AA als der verbreitete Zielwert und AAA als höchste Stufe, die in der Praxis selten vollständig erreichbar ist.
Für Unternehmen in Deutschland ist Version 2.2 die relevante Fassung, weil das BFSG und der Onlineshop-Betrieb auf EN 301 549 verweisen und diese Norm die WCAG als technische Referenz einsetzt. WCAG 2.2 erschien im Oktober 2023 und ist seitdem der Stand der Technik.
Was WCAG 2.2 gegenüber 2.1 wirklich verändert
WCAG 2.2 baut direkt auf 2.1 auf. Wer 2.1 AA erfüllt hat, muss keinen Neuaufbau planen. Die neuen Kriterien betreffen drei Bereiche, die in der Praxis bislang häufig zu kurz kamen: Fokussichtbarkeit bei modernen Layouts mit Sticky-Elementen, Touch-Bedienbarkeit für Menschen mit motorischen Einschränkungen und geringere Hürden bei Formularen und Anmeldeprozessen.
Gleichzeitig wurde 4.1.1 Parsing gestrichen. Dieses Kriterium hatte technische HTML-Fehler wie doppelte ID-Attribute oder falsch verschachtelte Tags als Barrierequelle erfasst. Moderne Browser und Screenreader gleichen solche Fehler inzwischen zuverlässig aus, sodass der praktische Schutzwert weggefallen ist. Sauberes HTML bleibt die richtige Praxis, es ist nur kein eigener Prüfpunkt mehr.
Von den neun neuen Kriterien liegen vier auf Stufe AA: 2.4.11, 2.5.7, 2.5.8 und 3.3.8. Zwei weitere (3.2.6 und 3.3.7) sind Stufe A, also in einer AA-Konformität ohnehin enthalten. Die restlichen drei (2.4.12, 2.4.13 und 3.3.9) liegen auf Stufe AAA und sind für den üblichen Konformitätszielwert nicht verpflichtend.
Alle 9 neuen Kriterien im Überblick
Die Tabelle zeigt alle Neuzugänge mit Konformitätsstufe, praktischer Bedeutung und einem konkreten Beispiel. Die AA- und A-Kriterien sind für eine BFSG-konforme Website verbindlich.
| Kriterium | Stufe | Was es verlangt | Typisches Beispiel |
|---|---|---|---|
| 2.4.11 Fokus nicht verdeckt (Minimum) | AA | Fokussiertes Element darf nicht vollständig hinter Autor-Inhalten verborgen sein | Sticky Header überdeckt den Tab-Fokus auf dem dritten Link |
| 2.4.12 Fokus nicht verdeckt (Erweitert) | AAA | Fokussiertes Element darf überhaupt nicht verdeckt sein (null Überlappung) | Schärfere Variante von 2.4.11, vollständig sichtbar |
| 2.4.13 Fokus-Erscheinungsbild | AAA | Fokusindikator: Mindestfläche (2-px-Rahmen) und Kontrast 3:1 zwischen fokussiert und nicht fokussiert | Kein unsichtbarer outline oder rein farblicher Fokus ohne ausreichende Fläche |
| 2.5.7 Ziehbewegungen | AA | Jede Drag-Funktion muss auch per einfachem Klick oder Tipp erreichbar sein | Schieberegler, sortierbare Listen, Kanban-Karten |
| 2.5.8 Zielgröße (Minimum) | AA | Klickziele mind. 24×24 CSS-Pixel oder ausreichend Freiraum um kleinere Ziele | Icon-Button zum Schließen eines Dialogs mit 18×18 px ohne Rand |
| 3.2.6 Konsistente Hilfe | A | Vorhandene Hilfe-Mechanismen erscheinen auf allen Seiten an derselben Position | Chat-Widget auf Startseite oben rechts, auf Unterseiten unten links |
| 3.3.7 Redundante Eingabe | A | Bereits eingegebene Daten werden im selben Prozess auto-gefüllt oder zur Auswahl angeboten | Checkout: Lieferadresse muss trotz identischer Rechnungsadresse erneut getippt werden |
| 3.3.8 Zugängliche Authentifizierung (Minimum) | AA | Anmeldung darf keinen kognitiven Test verlangen, solange keine zugängliche Alternative vorhanden ist | CAPTCHA ohne Audio-Alternative, Passwort-Einfügen blockiert |
| 3.3.9 Zugängliche Authentifizierung (Erweitert) | AAA | Wie 3.3.8, aber auch Objekterkennung (Bilder auswählen) ist kein zulässiger Test mehr | „Wählen Sie alle Bilder mit einem Bus aus“ als Anmeldeaufgabe |
Fokus-Management: sichtbar und nicht verdeckt
Sticky Header, Cookie-Banner am unteren Bildrand und eingeblendete Chat-Boxen haben in modernen Layouts einen Nebeneffekt: Wer die Seite mit der Tastatur bedient, verliert dabei manchmal den Fokus. Der Tab-Sprung landet auf einem Element, das ein überlagerndes Layer vollständig verdeckt. 2.4.11 setzt genau daran an.
Ein Sticky Header mit `scroll-padding-top` auf dem `html`-Element oder `scroll-margin-top` an den Zielelementen löst das in CSS ohne JavaScript. Wer einen Cookie-Banner per JavaScript einblendet, der die gesamte Seite überlagert aber keinen modalen Fokus fängt, hat hier ebenfalls Handlungsbedarf.
Das Fokus-Erscheinungsbild selbst (2.4.13) bleibt AAA und ist damit für den AA-Zielwert nicht verpflichtend. Es legt Mindestmaße für den Fokusrahmen fest: eine Fläche, die mindestens dem Umriss eines 2 CSS-Pixel breiten Rahmens entspricht, und ein Kontrastverhältnis von 3:1 zwischen fokussiertem und nicht fokussiertem Zustand. Trotzdem sind konkrete Fokus-Stile empfehlenswert, weil das ältere 2.4.7 (Stufe AA aus WCAG 2.1) bereits eine erkennbare Fokusanzeige verlangt. Themes, die pauschal `outline: none` setzen, verstoßen schon dagegen. Wie man Fokus-Stile selbst prüft, zeigt der Testleitfaden.
Touch und Zeigereingabe: Drag-Alternativen und Zielgrößen
Zwei der vier neuen AA-Kriterien betreffen direkt, wie Inhalte per Finger oder Maus bedienbar sein müssen.
2.5.7 Ziehbewegungen: Jede Funktion, die Drag-and-Drop voraussetzt, muss auch ohne Ziehgeste erreichbar sein, durch einfaches Antippen oder Klicken. Das trifft Schieberegler, sortierbare Listen, Kanban-Karten und Karusselle. Ein Slider braucht also zusätzlich Pfeiltasten oder klickbare Punkte auf der Leiste, damit er auch von jemandem bedienbar ist, der keine Ziehbewegung präzise ausführen kann. Ausgenommen ist, was der Browser selbst steuert (natives Scrollen per Scrollbar) und was seiner Natur nach unersetzbar per Drag ist.
2.5.8 Zielgröße (Minimum): Klickziele müssen mindestens 24×24 CSS-Pixel messen. Alternativ genügt ausreichender Freiraum: Wenn um ein kleineres Element herum so viel Luft liegt, dass ein gedachter Kreis von 24 Pixeln Durchmesser kein benachbartes Klickziel schneidet, ist die Anforderung ebenfalls erfüllt. Fließtext-Links, vom Browser kontrollierte Bedienelemente und Fälle, in denen eine bestimmte Anordnung sachlich nötig ist, sind ausgenommen.
Die strengere AAA-Variante mit 44×44 Pixeln (aus WCAG 2.1, Kriterium 2.5.5) bleibt ein guter Richtwert für gut bedienbare Oberflächen, ist aber für AA-Konformität nicht Pflicht.
Eingabehilfen: Gedächtnistests vermeiden, Wiederholungen sparen
Zwei neue Kriterien schützen Menschen, für die das Merken und Wiederholen von Informationen besonders aufwendig ist.
3.3.8 Zugängliche Authentifizierung (Minimum), Stufe AA: Wer sich anmeldet, darf nicht gezwungen werden, etwas zu tippen, zu merken oder zu verarbeiten, wenn ein Hilfsmittel das übernehmen kann. Das trifft klassische Texteingabe-CAPTCHAs ohne Audio-Alternative, aber auch technisch blockierte Passwort-Manager. Formulare, die das Einfügen von Zugangsdaten per JavaScript verhindern, verstoßen damit direkt gegen dieses Kriterium. Zulässig bleibt ein kognitiver Test nur dann, wenn ein alternativer Anmeldeweg ohne diesen Test existiert, oder wenn die Aufgabe reine Objekterkennung ist (z.B. „Klicken Sie auf alle Ampeln“) und kein Merken voraussetzt. Die schärfere AAA-Variante 3.3.9 schließt auch diese Ausnahme für Objekterkennung.
Für Login-Bereiche, Kundenportale oder Mitglieder-Downloads ist die Prüfung meist eine Konfigurationsfrage: Passwortfeld `autocomplete=“current-password“` setzen, Einfügen nicht per JavaScript sperren, CAPTCHA durch eine textlose Alternative oder Magic-Link-Login ergänzen.
3.3.7 Redundante Eingabe, Stufe A: Innerhalb desselben Prozesses einmal eingegebene Daten dürfen nicht ein zweites Mal von Hand eingetippt werden müssen. Sie werden entweder automatisch gefüllt oder zur Auswahl bereitgestellt. Das häufigste Beispiel aus der Praxis: Ein Checkout, der Rechnungs- und Lieferadresse als separate Felder führt, ohne eine Checkbox „Identisch mit Rechnungsadresse“ anzubieten. Ausnahmen: Sicherheitskritische Wiederholung (Passwort bestätigen), Gedächtnisspiele oder wenn die erste Eingabe ungültig war.
Konsistente Hilfe: immer an derselben Stelle
3.2.6 (Stufe A) verlangt nicht, dass eine Website überhaupt Hilfe anbietet. Wenn sie es aber auf mehreren Seiten tut, müssen Chat-Widget, Kontaktformular oder FAQ-Link an derselben Stelle im Seitenlayout erscheinen. Ein Chat, der auf der Startseite oben rechts sitzt und auf Unterseiten unten links, erfüllt das nicht. Das gilt für alle vier Hilfe-Typen: Kontaktangaben, Chat/Kontaktformular, Self-Service-Seiten und automatisierte Kontaktmechanismen wie Chatbots.
Für die meisten mittelständischen Sites ist das die einfachste der neuen Anforderungen: Wer seinen Chat im Header oder Footer fix verankert hat, erfüllt sie automatisch.
Praxisbeispiel: Target Size beim Button-Check
In einem Projekt prüften wir eine mobile Website, die eine Reihe kleiner Icon-Buttons für Social-Media-Links im Footer enthielt. Die Icons selbst waren 18×18 Pixel. Der Abstand zwischen ihnen betrug 4 Pixel. Per gedachtem 24-Pixel-Kreis: Jeder Kreis überlappte die Nachbarn, also war der Freiraum-Ausnahmeweg nicht nutzbar. Das Ergebnis war ein Verstoß gegen 2.5.8.
Die Lösung war ein Padding von 8 Pixeln ringsum im CSS, das das tatsächlich antippbare Gebiet auf 34×34 Pixel hob, ohne das Icon selbst größer wirken zu lassen:
.social-icon {
padding: 8px; /* Tipp-Fläche: 18 + 16 = 34px */
display: inline-flex;
align-items: center;
}Kein Redesign, keine neue Grafik, zwei Zeilen CSS. Das ist der typische Aufwand bei frühzeitiger Entdeckung. Wer die Icons erst in einer fertigen, gebrandeten App im Nachgang anpasst, hat deutlich mehr Aufwand, weil dann oft das gesamte Footer-Layout nachgezogen werden muss. Wie man solche Messpunkte schnell findet, zeigt der Artikel Barrierefreiheit selbst testen mit der Methode über die Entwickler-Tools des Browsers.
Auf die häufigsten Barrieren, die neben diesen neuen Kriterien in einem Mittelstands-Audit auftauchen, geht der Artikel Die 12 häufigsten Barrieren auf Mittelstands-Websites systematisch ein. Wer den Kontrast seiner Buttons korrekt messen möchte, findet das Verfahren bei Farbkontraste richtig prüfen.
Sofort-Checkliste für die 6 neuen AA- und A-Kriterien
- 2.4.11: Sticky-Elemente (Header, Cookie-Banner, Chat) verdecken tabbare Elemente nicht vollständig, mit Tab-Taste prüfen
- 2.5.7: Alle Drag-Funktionen (Schieberegler, Sortierung, Karussell) sind auch per Klick oder Pfeiltasten bedienbar
- 2.5.8: Klickziele mind. 24×24 px, besonders Icon-Buttons, Schließen-Symbole, kleine Navigation prüfen
- 3.2.6: Chat-Widget, Kontaktlink oder FAQ erscheinen auf jeder Seite an derselben Position im Layout
- 3.3.7: Checkout und mehrstufige Formulare füllen bereits eingegebene Daten automatisch vor, kein doppeltes Tippen
- 3.3.8: Login-Felder erlauben Einfügen per Passwortmanager, CAPTCHAs haben eine textlose Alternative
- WCAG 2.2 fügt 9 Kriterien hinzu und entfernt eines (4.1.1 Parsing). Wer 2.1 AA hatte, muss nur die neuen 6 AA/A-Punkte nachprüfen.
- Die vier neuen AA-Kriterien betreffen Fokus-Sichtbarkeit (2.4.11), Drag-Alternativen (2.5.7), Klickzielgrößen (2.5.8) und Anmelde-Zugänglichkeit (3.3.8).
- 2.4.13 (Fokus-Erscheinungsbild mit Pixelmaßen) und 3.3.9 (kein CAPTCHA jeder Art) liegen auf AAA und sind für AA-Konformität nicht Pflicht.
- Der häufigste unterschätzte Einzelpunkt in der Praxis: kleine Icon-Buttons unter 24 px ohne ausreichenden Freiraum.
Häufige Fragen
Gilt WCAG 2.2 Stufe AA jetzt als gesetzlicher Standard in Deutschland?
Nicht direkt, aber als maßgebliche technische Grundlage. Für öffentliche Stellen verlangt die BITV 2.0 Barrierefreiheit nach dem Stand der Technik. Die Verordnung nennt selbst keine WCAG-Version, sondern arbeitet mit einer Konformitätsvermutung über harmonisierte Normen (in der Praxis EN 301 549, die ihrerseits die WCAG referenziert). Für private Unternehmen verweist das BFSG auf EN 301 549, die ihrerseits die WCAG referenziert. WCAG 2.2 ist der aktuelle Stand, an dem sich eine Prüfung orientiert. In der Praxis ist die Ausrichtung an WCAG 2.2 AA der sichere Weg.
Muss ich meine Website neu aufbauen, wenn sie nach WCAG 2.1 AA konform war?
Nein. WCAG 2.2 ist eine Erweiterung, keine Neufassung. Wer 2.1 AA erfüllt, muss nur die 6 neuen AA- und A-Kriterien nachprüfen und bei Bedarf anpassen. Der größte praktische Handlungsbedarf liegt bei Fokus-Stilen und Sticky-Overlays, bei Klickzielgrößen auf mobilen Ansichten und bei Login-Seiten mit CAPTCHA oder gesperrten Paste-Feldern.
Welche neuen Kriterien aus WCAG 2.2 liegen auf Stufe AA?
Vier: 2.4.11 (Fokus nicht verdeckt, Minimum), 2.5.7 (Ziehbewegungen), 2.5.8 (Zielgröße, Minimum) und 3.3.8 (Zugängliche Authentifizierung, Minimum). Hinzu kommen mit 3.2.6 (Konsistente Hilfe) und 3.3.7 (Redundante Eingabe) zwei Stufe-A-Kriterien, die in einer AA-Konformität ohnehin enthalten sind. 2.4.12, 2.4.13 und 3.3.9 liegen auf AAA und sind für den üblichen Konformitätszielwert nicht verpflichtend.
Was ist mit 4.1.1 Parsing passiert?
Es wurde aus dem Standard entfernt und als obsolet markiert. Moderne Screenreader und Browser gleichen die technischen HTML-Fehler, die dieses Kriterium adressierte, zuverlässig selbst aus. Das bedeutet nicht, dass HTML-Fehler harmlos sind, aber sie begründen keinen eigenen WCAG-Verstoß mehr.
Was kostet ein WCAG-2.2-AA-Audit für eine mittelständische Website?
Das hängt stark vom Ausgangszustand ab. Eine priorisierte Erstprüfung der kaufkritischen Seitentypen ist deutlich günstiger als ein vollständiges dokumentiertes Audit mit Prüfbericht über die gesamte Seite. Eine belastbare Zahl ergibt sich erst nach einem kurzen Blick auf den konkreten Seitenumfang und die eingesetzten Systeme.
Sind Ausnahmen vom BFSG möglich?
Ja. Kleinstunternehmen nach EU-Empfehlung 2003/361/EG mit weniger als zehn Beschäftigten und einem Jahresumsatz oder einer Jahresbilanzsumme von jeweils höchstens 2 Millionen Euro sind bei der Erbringung von Dienstleistungen ausgenommen. Wer Waren verkauft, fällt unabhängig von der Größe unter das Gesetz. Darüber hinaus kann im Einzelfall eine unverhältnismäßige Belastung als Ausnahmegrund anerkannt werden, die Nachweispflicht liegt beim Unternehmen.