Die meisten Websites, die ich prüfe, wurden gegen WCAG 2.1 gebaut – und ihre Betreiber wissen oft nicht, dass seit Oktober 2023 eine neuere Fassung gilt. WCAG 2.2 hat neun zusätzliche Erfolgskriterien gebracht, und sechs davon zählen zur Konformitätsstufe AA, also genau zu dem Maßstab, den das deutsche Gesetz von Ihnen verlangt. Das Tückische daran: Es sind ausgerechnet jene Kriterien, die ein automatischer Test fast nicht erkennen kann. In diesem Leitfaden gehe ich jedes der neun neuen Kriterien durch – was es verlangt, warum es eingeführt wurde und wie Sie es in der Praxis erfüllen. Mit Code, mit Beispielen aus echten Audits und mit einer klaren Übersicht, was für Ihre Rechtssicherheit bindend ist und was nicht.

Was ist neu an WCAG 2.2?

WCAG 2.2 ist seit Oktober 2023 die offizielle Empfehlung des W3C und damit die aktuelle Fassung des Standards für digitale Barrierefreiheit. Sie baut vollständig auf WCAG 2.1 auf: Wer 2.2 erfüllt, erfüllt automatisch auch 2.1 und 2.0. Neu hinzugekommen sind neun Erfolgskriterien, die sich um die Schwachstellen heutiger Oberflächen drehen – Mobilbedienung, komplexe Formulare, überladene Layouts. Ein einziges altes Kriterium, 4.1.1 zum Parsing, wurde im Gegenzug gestrichen.

Entscheidend für Sie ist die Verteilung auf die Konformitätsstufen, denn nicht alle neun sind gleich verbindlich. Zwei der neuen Kriterien liegen auf Stufe A, vier auf Stufe AA und drei auf Stufe AAA. Da das Barrierefreiheitsstärkungsgesetz und der European Accessibility Act die Stufe AA verlangen, sind sechs der neun Kriterien für Ihre gesetzliche Pflicht relevant. Die folgende Tabelle ordnet alle neun nach Nummer, Name und Konformitätsstufe ein.

Fokus sichtbar halten: die drei Fokus-Kriterien

Drei der neun Neuerungen betreffen den Tastaturfokus – also die visuelle Markierung, die zeigt, wo sich ein Nutzer gerade befindet, der ohne Maus navigiert. Für sehende Tastaturnutzer ist diese Markierung die einzige Orientierung. Geht sie verloren oder ist sie verdeckt, ist die Seite praktisch unbedienbar. Mit dem Siegeszug klebriger Kopfzeilen, eingeblendeter Chat-Fenster und Cookie-Banner ist genau dieses Problem in den letzten Jahren regelrecht explodiert – kaum eine moderne Seite ist davon frei, und kaum jemand testet es.

Fokus nicht verdeckt (2.4.11, AA) ist davon das wichtigste, weil es auf Stufe AA bindend ist. Es verlangt, dass ein fokussiertes Element nicht vollständig von anderen Inhalten verdeckt wird. Der häufigste Verursacher sind klebrige Kopfzeilen und Cookie-Banner, die beim Tabben über das fokussierte Element rutschen. Die strengeren Varianten auf Stufe AAA gehen weiter: 2.4.12 verlangt, dass der Fokus gar nicht verdeckt wird, und 2.4.13 stellt konkrete Anforderungen an den Fokusrahmen selbst: Er muss mindestens die Fläche eines zwei Pixel dicken Rahmens um das Element abdecken und gegenüber dem nicht fokussierten Zustand einen Kontrast von mindestens 3:1 erreichen – ein dünner, blasser Standard-Outline des Browsers genügt dafür oft nicht.

In der Praxis lässt sich das Verdeckungsproblem oft mit wenigen Zeilen CSS entschärfen, indem man dem scrollenden Bereich genügend Abstand zur klebrigen Kopfzeile gibt:

/* Hält das fokussierte Element unter der Sticky-Header-Zone */
:target, :focus {
  scroll-margin-top: 6rem;
}

Aus der Praxis: Bei einem Versicherungsportal verschwand jedes fokussierte Formularfeld der oberen Bildschirmhälfte hinter einer eingeblendeten Navigationsleiste, sobald man sich per Tastatur nach oben bewegte. Sehende Mausnutzer bemerkten nichts. Ein Tastaturnutzer aber tippte blind, weil er nicht sehen konnte, in welchem Feld er gerade schrieb. Das Kriterium 2.4.11 war damit klar verletzt – und die Lösung kostete eine Handvoll CSS-Regeln, kein Redesign.

Bedienung für Hände und Finger: Ziehbewegungen und Zielgröße

Zwei neue AA-Kriterien adressieren Menschen mit motorischen Einschränkungen – und nebenbei jeden, der ein Smartphone mit dem Daumen bedient. Sie gehören zu den am leichtesten nachvollziehbaren Neuerungen, werden aber überraschend oft gerissen.

Ziehbewegungen (2.5.7, AA) verlangt, dass jede Funktion, die eine Ziehbewegung erfordert, auch mit einem einfachen Tippen oder Klicken bedienbar ist. Schieberegler, Drag-and-drop-Listen oder Karten, die man verschieben muss, brauchen also eine Alternative – etwa Plus- und Minus-Schaltflächen neben einem Slider. Ausgenommen sind nur Fälle, in denen das Ziehen für die Funktion wesentlich ist.

Zielgröße (2.5.8, AA) ist das konkreteste der neun Kriterien: Interaktive Elemente müssen mindestens 24 mal 24 CSS-Pixel groß sein, oder durch ausreichenden Abstand zu Nachbarelementen entsprechend Platz bieten. Damit fallen winzige Icon-Buttons, eng gesetzte Pfeile in Kalendern und zu kleine Schließen-Kreuze durch. Im Code ist die Vorgabe trivial umzusetzen:

/* Falsch: zu kleines Touch-Ziel */
.icon-btn { width: 16px; height: 16px; }

/* Richtig: erfüllt die Mindestgröße nach 2.5.8 */
.icon-btn { min-width: 24px; min-height: 24px; }

Zwei Ausnahmen sollten Sie kennen, weil sie regelmäßig falsch interpretiert werden. Erstens gilt die Mindestgröße als erfüllt, wenn um ein kleineres Element herum genug ungenutzter Abstand liegt – konkret, wenn sich um seinen Mittelpunkt ein Kreis von 24 Pixeln Durchmesser legen lässt, ohne ein anderes Ziel zu berühren. Zweitens sind Links mitten im Fließtext ausgenommen, weil sie an die Zeilenhöhe gebunden sind. Aufschlussreich ist außerdem, dass ein einziges Bauteil oft mehrere der neuen Kriterien gleichzeitig betrifft: Ein selbstgebauter Schieberegler muss eine Tipp-Alternative bieten (2.5.7), die Mindestgröße seiner Bedienpunkte einhalten (2.5.8) und per Tastatur bedienbar bleiben – drei Anforderungen, die erst zusammen echte Bedienbarkeit ergeben.

Aus der Praxis: Ein Online-Shop hatte auf dem Smartphone seine Mengen-Auswahl mit Plus- und Minus-Buttons von 18 Pixeln Kantenlänge gestaltet – schick, aber unter der Schwelle von 2.5.8. Im Test trafen Nutzer mit motorischen Einschränkungen regelmäßig daneben und änderten ungewollt die Bestellmenge. Solche Verstöße entstehen fast immer, weil das neue Kriterium im Design-System schlicht noch nicht hinterlegt ist.

Formulare und Anmeldung: die drei Kriterien, die Conversion kosten

Die letzte Gruppe betrifft Formulare und Anmeldeprozesse – also genau die Stellen, an denen ein Mensch zum Kunden wird. Hier entscheidet Barrierefreiheit unmittelbar über Abschluss oder Abbruch.

Konsistente Hilfe (3.2.6, A) verlangt, dass Hilfe-Mechanismen wie ein Kontaktlink, eine Telefonnummer oder ein Chat über mehrere Seiten hinweg an derselben relativen Stelle erscheinen. Wer Hilfe sucht, soll sie nicht auf jeder Seite neu suchen müssen. Redundante Eingabe (3.3.7, A) untersagt, bereits erfasste Informationen im selben Prozess erneut manuell abzufragen – etwa die Lieferadresse, die schon als Rechnungsadresse eingegeben wurde. Die saubere Lösung ist, solche Felder vorzubefüllen oder zur Übernahme anzubieten; technisch hilft auch das korrekte autocomplete-Attribut.

<!-- Browser und Passwortmanager füllen diese Felder automatisch -->
<input name="email" autocomplete="email">
<input name="strasse" autocomplete="street-address">

Beide A-Kriterien haben praktische Feinheiten, die in Audits immer wieder auftauchen. Bei der redundanten Eingabe (3.3.7) ist eine erneute Abfrage ausdrücklich erlaubt, wenn sie wesentlich ist – etwa die Bestätigung eines Passworts, eine echte Sicherheitsprüfung oder Fälle, in denen die früher eingegebene Information nicht mehr gültig ist. Sie dürfen also weiterhin sicher arbeiten, müssen aber alles, was Sie bereits kennen, zur Übernahme anbieten statt es erneut zu verlangen. Konsistente Hilfe (3.2.6) wiederum verlangt keine pixelgenaue Position, sondern dieselbe relative Reihenfolge im Seitenaufbau: Steht der Hilfe-Link einmal als letzter Eintrag der Kopfnavigation, muss er das auf jeder Seite tun, auf der er überhaupt erscheint.

Das folgenreichste Kriterium dieser Gruppe ist Zugängliche Authentifizierung (3.3.8, AA). Es besagt, dass ein Anmeldevorgang nicht allein an einem kognitiven Funktionstest hängen darf – also an einer Aufgabe, die Erinnern, Abtippen oder das Lösen eines Rätsels verlangt. Captchas, bei denen verzerrte Zeichen entziffert werden müssen, Rechenaufgaben oder das fehlerfreie Übertragen eines Codes innerhalb weniger Sekunden fallen damit durch, sofern es keine zugängliche Alternative gibt. Erlaubt bleiben Verfahren, die der Browser oder ein Passwortmanager übernehmen können, sowie Alternativen wie die Anmeldung per Bestätigungslink. Besonders elegant lösen das passwortlose Verfahren wie Passkeys (WebAuthn) per Fingerabdruck oder Gesichtserkennung – sie erfüllen das Kriterium von vornherein, weil sie keinerlei Erinnerung verlangen. Ein simpler, aber häufig übersehener Punkt: Erlauben Sie in Passwort- und Code-Feldern ausdrücklich das Einfügen aus der Zwischenablage. Ein onpaste-Blocker, der das aus vermeintlichen Sicherheitsgründen unterbindet, zwingt zum fehlerfreien Abtippen und verstößt damit direkt gegen den Geist von 3.3.8.

Die wirtschaftliche Tragweite dieses Kriteriums wird regelmäßig unterschätzt. Der Anmelde- und Bezahlvorgang ist der Engpass, durch den jeder Kunde muss – scheitert hier ein Nutzer, ist nicht nur die Barrierefreiheit verletzt, sondern unmittelbar ein Geschäft verloren. Und betroffen sind weit mehr Menschen als jene mit einer dauerhaften Behinderung: Auch wer unter Stress steht, abgelenkt ist oder eine schlechte Verbindung hat, profitiert von einem Login, der nicht auf fehlerfreiem Abtippen unter Zeitdruck beruht. Ein zugänglicher Anmeldeprozess ist deshalb keine Nischenanforderung, sondern eine Frage der Abschlussrate für Ihre gesamte Kundschaft.

Aus der Praxis: Ein Finanzdienstleister sicherte seinen Login mit einem Code ab, der innerhalb von 30 Sekunden aus einer Grafik abgetippt werden musste. Für einen blinden Kunden war das eine unüberwindbare Hürde: Der Code ließ sich weder vorlesen noch in der knappen Zeit erfassen. Genau hier greift 3.3.8. Die Lösung war keine Aufweichung der Sicherheit, sondern eine zweite, gleichwertige und zugängliche Methode – ein Muster, das auch Screenreader-Nutzern den Zugang öffnete.

Was für die gesetzliche AA-Konformität bindend ist

Nicht jedes neue Kriterium müssen Sie umsetzen, um rechtssicher zu sein – aber Sie sollten genau wissen, welche. Diese Priorisierung nutze ich, um Teams den Pflichtteil von der Kür zu trennen.

Konzentrieren Sie Ihre Ressourcen also zuerst auf die sechs Pflicht-Kriterien. Die drei AAA-Varianten sind sinnvoll, wo Sicherheit und Zugänglichkeit besonders kritisch sind – etwa im Banking –, aber niemand kann sie rechtlich von Ihnen einfordern.

So bringen Sie Ihre Website von 2.1 auf 2.2

Wenn Ihre Seite bereits WCAG 2.1 auf Stufe AA erfüllt, ist der Weg zu 2.2 überschaubar – Sie müssen gezielt die sechs neuen Pflicht-Kriterien nachrüsten. Ein pragmatischer Ablauf hat sich in unseren Projekten bewährt.

Beginnen Sie mit den beiden mechanisch greifbarsten Punkten: Prüfen Sie alle interaktiven Elemente auf die Mindestgröße von 24 Pixeln (2.5.8) und ergänzen Sie für jede Ziehfunktion eine Tipp-Alternative (2.5.7). Beides lässt sich systematisch im Design-System verankern, sodass künftige Komponenten die Vorgaben von selbst erfüllen. Nehmen Sie sich anschließend den Tastaturfokus vor (2.4.11) – tabben Sie durch jede Schlüsselseite und achten Sie darauf, dass weder Cookie-Banner noch Kopfzeile das fokussierte Element verdecken. Der aufwendigste Schritt ist die Authentifizierung (3.3.8): Hier prüfen Sie, ob jeder Anmelde- und Verifizierungsweg eine zugängliche Alternative bietet. Die beiden A-Kriterien zur konsistenten Hilfe (3.2.6) und redundanten Eingabe (3.3.7) erledigen sich meist schnell durch eine einheitliche Platzierung und das Vorbefüllen von Feldern. Wichtig zum Schluss: Verlassen Sie sich bei der Abnahme nicht auf einen automatischen Scan, denn der erfasst – wie Sie gleich sehen – fast keines dieser Kriterien.

Warum 4.1.1 Parsing gestrichen wurde

Eine Neuerung von WCAG 2.2 ist eine Streichung. Das frühere Kriterium 4.1.1, das sauberes, fehlerfreies HTML-Markup verlangte, wurde entfernt. Der Grund ist erfreulich: Moderne Browser und assistive Technologien gehen mit kleineren Markup-Fehlern heute so robust um, dass die ursprünglich dahinterstehende Barriere praktisch verschwunden ist. Für Sie bedeutet das keine neue Aufgabe – sauberes HTML bleibt selbstverständlich gute Praxis, ist aber kein eigener Prüfpunkt mehr.

Und danach? Ein Blick auf WCAG 3.0

Über die nächste Generation kursieren viele Halbwahrheiten, deshalb der Stand der Dinge konkret: WCAG 3.0 ist weiterhin ein Arbeitsentwurf – der jüngste wurde im März 2026 veröffentlicht und führt rund 174 sogenannte Outcomes als Nachfolger der heutigen Erfolgskriterien ein. Das starre Bestehen-oder-Durchfallen der Stufen A, AA und AAA weicht dabei einem abgestuften Bewertungsmodell mit den Niveaus Bronze, Silber und Gold. Bis zur offiziellen W3C-Empfehlung ist es allerdings weit: Eine Candidate Recommendation wird frühestens für Ende 2027 erwartet, die finale Empfehlung nicht vor 2028 – und auch dann löst WCAG 3.0 die Version 2.2 nicht ab, sondern besteht zunächst neben ihr. Für Ihre heutige Planung heißt das unmissverständlich: WCAG 2.2 auf Stufe AA ist und bleibt auf absehbare Zeit der maßgebliche Standard. Wer auf 3.0 wartet, um „es dann gleich richtig zu machen“, verschenkt Jahre – und bleibt in dieser Zeit angreifbar.

Der blinde Fleck: Warum ein automatischer Test WCAG 2.2 kaum sieht

Jetzt kommt der Punkt, der WCAG 2.2 für Ihre Teststrategie so heikel macht. Von den neun neuen Kriterien lässt sich nur ein einziges zuverlässig automatisch prüfen: die Zielgröße (2.5.8). Alle anderen – ob der Fokus verdeckt wird, ob eine Authentifizierung zugänglich ist, ob Hilfe konsistent platziert ist, ob eine Ziehalternative existiert – erfordern menschliches Urteil. Der Hersteller der verbreiteten axe-Engine hat offen erklärt, dass voraussichtlich nur die Zielgröße in die automatische Prüfung aufgenommen wird, weil der Rest ohne menschliche Kontrolle zu viele Fehlalarme erzeugt.

Das hat eine unbequeme Konsequenz: Ein grünes Häkchen aus einem automatischen Test-Tool sagt über Ihre WCAG-2.2-Konformität noch weniger aus als über ältere Kriterien. Wer seine Seite nur scannen lässt, prüft ausgerechnet die neuesten und praxisrelevantesten Anforderungen überhaupt nicht. Genau diese Lücke schließt unser Anker-Audit Access Ready: ein menschliches Tiefen-Audit mit JAWS, NVDA und VoiceOver, kombiniert mit einem Panel echter Nutzer assistiver Technologien. Es prüft genau die Kriterien, an denen Scanner blind sind – die verdeckten Fokuszustände, die unzugänglichen Logins, die fehlenden Ziehalternativen –, und deckt damit jenen Anteil der WCAG 2.2 ab, den keine Maschine erreicht.

Das ist der Unterschied, auf den es ankommt: Ein reiner Scan-Anbieter liefert Ihnen eine Fehlerliste und überlässt Ihnen die Deutung. Access Ready prüft die kritischen Kriterien mit echten Nutzern, zeigt Ihnen die konkrete Behebung und führt Sie bis zum belastbaren Nachweis. Sie bekommen keinen Report, der im Nichts endet, sondern einen begleiteten Weg, der bei der Rechtssicherheit ankommt – und damit genau dort, wo ein automatisches Häkchen Sie alleinlässt.

Von WCAG 2.2 zum belastbaren Nachweis

WCAG 2.2 verschiebt die Messlatte genau dorthin, wo Automatisierung endet. Sechs neue Pflicht-Kriterien auf Stufe AA, von denen fünf nur ein Mensch verlässlich beurteilen kann – das ist die Realität, mit der Ihre Konformität heute steht oder fällt. Andere Werkzeuge zeigen Ihnen bestenfalls die eine automatisch prüfbare Vorgabe und lassen Sie mit dem Rest allein.

Access Ready geht den umgekehrten Weg. Wir prüfen jedes relevante Erfolgskriterium der WCAG 2.2 auf Stufe AA – auch und gerade die manuell prüfbaren – und Sie erhalten nach Behebung der Mängel ein rechtlich belastbares Zertifikat, das Ihre Konformität dokumentiert und im Streitfall als Nachweis Ihrer Sorgfaltspflicht dient. Ich verspreche Ihnen keine perfekte Punktzahl, sondern etwas Belastbareres: die dokumentierte Gewissheit, auch die neuen Kriterien erfüllt zu haben, mit denen die meisten Wettbewerber noch ringen. Wenn Sie wissen wollen, wo Ihre Website gegenüber WCAG 2.2 wirklich steht, ist ein zertifiziertes Tiefen-Audit nach WCAG 2.2 der direkte und einzige belastbare Weg dorthin. Den schnellen, kostenlosen Ausgangspunkt liefert vorab unser Access Score: Er erfasst die maschinell prüfbaren Punkte – bei den 2.2-Neuerungen vor allem die Zielgröße (2.5.8) – und macht in Minuten sichtbar, wo genau das menschliche Tiefen-Audit ansetzen muss.