Neu in WCAG 2.2: die neun neuen Erfolgskriterien

WCAG 2.2 bringt neun neue Erfolgskriterien und streicht eines: Vier der neun liegen auf Stufe AA und sind damit für BFSG und BITV relevant, zwei auf Stufe A, drei auf AAA. Der rote Faden dahinter ist ungewöhnlich klar. Acht der neun zielen auf Tastatur, Fokus, Motorik und kognitive Last statt auf reine Wahrnehmung.

Das Wichtigste in Kürze

• Neun Kriterien kamen hinzu, eines wurde gestrichen. Für die gesetzliche Zielstufe AA sind davon vier relevant.
• Die vier auf AA: 2.4.11 Fokus nicht verdeckt, 2.5.7 Ziehbewegungen, 2.5.8 Zielgröße (24 × 24 CSS-Pixel), 3.3.8 Zugängliche Authentifizierung.
• Neu auf Stufe A: 3.2.6 Konsistente Hilfe und 3.3.7 Redundante Eingabe; die übrigen drei Neuzugänge liegen auf AAA.
• 4.1.1 Parsing ist ersatzlos gestrichen und gilt rückwirkend auch in WCAG 2.1 und 2.0 als erfüllt.
• Stand September 2026 rechtlich noch nicht verbindlich: Bezugspunkt bleibt die EN 301 549 V3.2.1 mit WCAG 2.1 AA. Die V4.1.1 mit WCAG 2.2 erschien am 2. September 2026.

Vergrößern: Nur die mittlere Spalte betrifft die gesetzliche Zielstufe AA. Die linke gilt…

Diese Seite behandelt ausschließlich die neun Neuzugänge, nicht die 77 Kriterien, die bereits in WCAG 2.1 standen. Wer den vollständigen Prüfkatalog braucht, findet alle 55 Kriterien der Zielstufe AA unter WCAG-2.2-Referenz: alle 55 Kriterien der Stufen A & AA. Was die WCAG insgesamt sind und wie sich die Versionen zueinander verhalten, klärt WCAG einfach erklärt: Aufbau, Versionen und Stufen.

Abgrenzung: nur die Neuzugänge. Diese Seite behandelt ausschließlich die neun Kriterien, die WCAG 2.2 hinzugefügt hat. Alle 55 Kriterien der Stufen A und AA stehen in der WCAG-2.2-Referenz, der Standard als Ganzes samt Versionsvergleich unter WCAG einfach erklärt.

Die vier AA-Neuzugänge

2.4.11 Fokus nicht verdeckt (Minimum)

Was verlangt wird: Wenn ein Bedienelement den Tastaturfokus erhält, darf es nicht vollständig durch von dir erzeugte Inhalte verdeckt sein. Der Klassiker ist ein Sticky-Header, unter dem das gerade fokussierte Element verschwindet, oder ein Cookie-Banner am unteren Rand.

Das Wort „vollständig“ ist wichtig: Teilweise Verdeckung ist auf AA erlaubt. Erst 2.4.12 auf Stufe AAA verlangt, dass gar nichts verdeckt wird.

Die Lösung ist meist eine CSS-Zeile. scroll-margin reserviert den Platz, den der Browser beim automatischen Scrollen freilassen soll:

/* Höhe des Sticky-Headers plus etwas Luft */
:root { --sticky-hoehe: 4.5rem; }

:target,
a:focus-visible,
button:focus-visible,
input:focus-visible,
[tabindex]:focus-visible {
  scroll-margin-block-start: calc(var(--sticky-hoehe) + 1rem);
}

So testest du es: Tab-Taste gedrückt halten und die Seite durchlaufen. Bei jedem Sprung prüfen, ob das fokussierte Element sichtbar bleibt. Besonders beim Wechsel von oben nach unten und beim Rücksprung mit Shift+Tab, weil dabei anders gescrollt wird. Details unter 2.4.11 Fokus nicht verdeckt.

2.5.7 Ziehbewegungen

Was verlangt wird: Jede Funktion, die über eine Ziehbewegung bedient wird, muss auch mit einem einzelnen Zeiger ohne Ziehen erreichbar sein. Also muss ein einfaches Tippen oder Klicken genügen. Ausgenommen ist nur, was ohne Ziehen seinen Sinn verliert (eine Signaturfläche, ein Zeichenwerkzeug) oder was der Browser selbst mitbringt.

Betroffen sind mehr Bauteile, als man zunächst denkt:

Wichtig ist die Abgrenzung zu 2.5.1 Zeigergesten: Das ältere Kriterium betrifft pfadabhängige Gesten und Mehrfingergesten, 2.5.7 speziell das Ziehen. Ein Drag-and-drop-Board verstößt gegen 2.5.7, eine Zwei-Finger-Zoomgeste ohne Alternative gegen 2.5.1. Die Umsetzung steht unter Karten & Drag-and-drop und 2.5.7 Ziehbewegungen.

2.5.8 Zielgröße (Minimum)

Was verlangt wird: Bedienelemente müssen mindestens 24 × 24 CSS-Pixel groß sein oder so viel Abstand halten, dass ein gedachter Kreis von 24 px Durchmesser, zentriert auf jedes zu kleine Ziel, kein anderes Ziel schneidet.

Vergrößern: Größe oder Abstand reicht aus. Die Symbole dürfen dabei optisch klein bleiben.

Die Umsetzung braucht die Fläche, nicht das Symbol:

.icon-button {
  /* Trefffläche wächst, Icon bleibt 20 px */
  min-inline-size: 24px;
  min-block-size: 24px;
  display: grid;
  place-items: center;
  padding: 0;
}

/* Reicht der Platz nicht, hilft ein unsichtbarer Puffer */
.icon-button::before {
  content: "";
  position: absolute;
  inset: -6px;
}

Fünf Ausnahmen nennt das Kriterium selbst: Inline-Links im Fließtext, ausreichender Abstand, eine gleichwertige Bedienmöglichkeit an anderer Stelle, vom Browser bestimmte Größen und Fälle, in denen die genaue Position wesentlich ist (Kartenmarker, Bildeditor-Anfasser).

Ich sag’s mal deutlich: Von allen vier AA-Neuzugängen ist das der, der in bestehenden Projekten die meiste Arbeit macht. Den Aufwand verursacht die Menge. Icon-Leisten, Tabellen-Aktionen, Kalender-Zellen und Schließen-Kreuze summieren sich. Mehr unter 2.5.8 Zielgröße.

3.3.8 Zugängliche Authentifizierung (Minimum)

Was verlangt wird: In keinem Schritt einer Anmeldung darf ein kognitiver Funktionstest verlangt werden. Es sei denn, es gibt einen alternativen Weg oder eine Hilfe, die den Test überflüssig macht.

Ein kognitiver Funktionstest ist alles, was Erinnern, Rechnen oder Rätseln verlangt: ein Passwort aus dem Gedächtnis abtippen, verzerrte Zeichen entziffern, eine Rechenaufgabe lösen, eine Sicherheitsfrage beantworten.

Vier Ausnahmen erlaubt das Kriterium:

• Alternative: Es gibt einen zweiten Weg ohne kognitiven Test (Magic Link, Passkey).
• Mechanismus: Eine Hilfe darf den Test übernehmen. Das gilt etwa für einen Passwort-Manager, der ausfüllt. Deshalb ist ein Kopier- oder Einfügeverbot im Passwortfeld ein direkter Verstoß.
• Objekterkennung: Objekte auf Bildern erkennen ist zulässig. Das gängige Bilder-CAPTCHA („alle Busse anklicken“) erfüllt damit auf AA das Kriterium.
• Persönlicher Inhalt: Inhalte wiedererkennen, die der Nutzer selbst hochgeladen hat.

Die letzten beiden Ausnahmen fallen auf Stufe AAA (3.3.9) weg. Dort sind auch Bilderrätsel unzulässig.

<!-- Falsch: sperrt Passwort-Manager aus, verhindert Einfügen -->
<input type="password" name="pw" onpaste="return false"
       autocomplete="off" />

<!-- Richtig: Passwort-Manager füllen aus, Einfügen erlaubt -->
<label for="pw">Passwort</label>
<input type="password" id="pw" name="pw"
       autocomplete="current-password" />

Der Wert von autocomplete ist dabei nicht kosmetisch. Er sagt Browsern und Passwort-Managern, welches Feld welchen Zweck hat, und hängt direkt mit 1.3.5 Eingabezweck bestimmen zusammen. Vertiefung unter 3.3.8 Zugängliche Authentifizierung.

Die beiden A-Neuzugänge

3.2.6 Konsistente Hilfe

Wenn eine Website Hilfsangebote anbietet (Telefonnummer, Kontaktformular, Chat, Suche oder eine Selbsthilfe-Seite) und diese auf mehreren Seiten wiederholt, dann müssen sie in derselben Reihenfolge relativ zum übrigen Seiteninhalt stehen. Gemeint ist die Stelle in der Abfolge der Inhalte. Die Position in Pixeln darf sich ändern.

Der praktische Fehler dahinter: Auf der Startseite steht die Servicenummer im Header, auf der Produktseite nur im Footer, im Checkout gar nicht. Wer sich einmal gemerkt hat, wo die Hilfe zu finden ist, sucht sie beim nächsten Mal vergeblich. Betroffen sind vor allem Menschen mit kognitiven Einschränkungen und alle, die eine Seite nicht visuell überfliegen können.

Wichtig: Das Kriterium verlangt nicht, dass es überhaupt Hilfe geben muss. Es verlangt nur Konsistenz, wenn es sie gibt. Details unter 3.2.6 Konsistente Hilfe.

3.3.7 Redundante Eingabe

Angaben, die im selben Vorgang bereits gemacht wurden, dürfen nicht erneut abgefragt werden. Sie sind entweder vorausgefüllt oder zur Auswahl anzubieten. Ausgenommen sind Fälle, in denen die Wiederholung wesentlich ist (Passwortbestätigung), der Sicherheit dient oder die alte Angabe nicht mehr gültig ist.

<!-- Richtig: Lieferadresse übernehmen statt neu eingeben -->
<fieldset>
  <legend>Lieferadresse</legend>
  <label>
    <input type="checkbox" name="gleiche_adresse" checked />
    Entspricht der Rechnungsadresse
  </label>
</fieldset>

Das klingt nach Komfort, ist aber für Menschen mit motorischen Einschränkungen oder Gedächtnisproblemen der Unterschied zwischen „machbar“ und „abgebrochen“. Am häufigsten verstoßen mehrstufige Formulare und Checkout-Strecken dagegen. Mehr dazu unter 3.3.7 Redundante Eingabe.

Die drei AAA-Kriterien

Sie sind nicht Teil der gesetzlichen Zielstufe, aber zwei davon lohnen einen Blick:

• 2.4.12 Fokus nicht verdeckt (Erweitert): Wie 2.4.11, nur ohne jede Teilverdeckung. Wer scroll-margin ohnehin sauber gesetzt hat, erfüllt es oft nebenbei.
• 2.4.13 Fokus-Aussehen: Der Fokusindikator muss mindestens so groß sein wie ein 2 px starker Rahmen um das Element und einen Kontrast von 3:1 zwischen fokussiertem und nicht fokussiertem Zustand haben. Das ist die konkrete Zahl, die 2.4.7 Fokus sichtbar auf AA schuldig bleibt und deshalb ein guter Maßstab, auch wenn man AAA nicht anstrebt.
• 3.3.9 Zugängliche Authentifizierung (Erweitert): Wie 3.3.8, aber ohne die Ausnahmen Objekterkennung und persönlicher Inhalt.

Was WCAG 2.2 weggenommen hat

4.1.1 Parsing ist gestrichen. Das Kriterium verlangte, dass Markup korrekt verschachtelt ist, Elemente vollständige Start- und End-Tags haben und id-Werte eindeutig sind. Der Grund für die Streichung: Moderne Browser gehen mit solchen Fehlern einheitlich um, und Hilfsmittel bauen ihren Baum aus dem geparsten DOM. Der Fehler ist zu diesem Zeitpunkt längst repariert.

Das W3C hat 4.1.1 zugleich in WCAG 2.1 als überholt gekennzeichnet; dort gilt es bei HTML- und XML-Inhalten seither als immer erfüllt. Wer also einen alten Prüfbericht mit 4.1.1-Befunden vor sich hat, kann diese Zeilen streichen.

Verschwunden ist das Problem damit nicht. Doppelte id-Werte zerstören weiterhin die Verknüpfung über aria-labelledby, aria-describedby und <label for>. Sie fallen jetzt nur unter 4.1.2 Name, Rolle, Wert statt unter ein eigenes Kriterium. Der HTML-Validator bleibt deshalb ein sinnvolles Werkzeug, auch wenn er kein WCAG-Kriterium mehr bedient.

Was das rechtlich bedeutet

Im EU-Amtsblatt genannt ist Stand September 2026 die Fassung EN 301 549 V3.2.1 mit WCAG 2.1 AA, und zwar über den Durchführungsbeschluss (EU) 2021/1339 für die Richtlinie (EU) 2016/2102 der öffentlichen Stellen. Für den European Accessibility Act und damit das BFSG ist noch keine Fassung genannt. Die neun Kriterien dieser Seite sind damit noch nicht gesetzlich verbindlich. Das gilt für das BFSG ebenso wie für die BITV 2.0.

ETSI hat am 2. September 2026 die Fassung V4.1.1 veröffentlicht. Sie verweist für das Web auf WCAG 2.2 AA und umfasst damit die sechs Kriterien der Stufen A und AA von dieser Seite. Die Vermutungswirkung entsteht erst mit der Nennung im Amtsblatt. Den aktuellen Stand pflege ich unter Aktuelles zum BFSG.

Fachlich würde ich trotzdem bereits heute auf 2.2 AA prüfen. Der Mehraufwand liegt bei sechs Kriterien, von denen vier mit CSS und HTML zu lösen sind. Ein zweites vollständiges Audit nach der Normrevision kostet dagegen ein Vielfaches davon.

Kein Rechtsrat. Diese Seite ordnet Normen und Fristen aus der Praxis ein und ersetzt keine juristische Beratung.

Häufiger Fehler in der Praxis

24 px am Icon statt an der Trefffläche. Das Symbol wird auf 24 px vergrößert, das Layout wirkt plump. Dabei hätte ein min-block-size an der Schaltfläche gereicht, das Symbol bleibt klein.

scroll-margin nur an :target. Deckt Sprungmarken ab, nicht aber die Tab-Navigation. :focus-visible gehört dazu, sonst verdeckt der Sticky-Header weiterhin jedes zweite fokussierte Element.

Drag-and-drop mit Tastaturunterstützung verwechseln. Eine Sortierliste, die per Tastatur bedienbar ist, erfüllt 2.1.1. 2.5.7 erfüllt sie aber nicht zwingend. Das Kriterium verlangt eine Alternative mit einem einzelnen Zeiger, also für Menschen, die eine Maus oder einen Finger benutzen, aber nicht ziehen können.

CAPTCHAs pauschal für verboten halten. Objekterkennung ist auf AA ausdrücklich zugelassen. Verboten sind Texträtsel, Rechenaufgaben und Gedächtnisabfragen ohne Alternative.

autocomplete="off" aus Sicherheitsgründen setzen. Das war vor fünfzehn Jahren gute Praxis und ist heute ein Verstoß gegen 3.3.8, weil es Passwort-Manager aussperrt. Alle großen Sicherheitsleitfäden empfehlen inzwischen das Gegenteil.

Häufige Fragen

Muss ich für BFSG oder BITV schon WCAG 2.2 erfüllen?

Stand September 2026 verlangen beide das noch nicht. Bezugspunkt bleibt bis zur Nennung der neuen Fassung im EU-Amtsblatt die EN 301 549 V3.2.1 mit WCAG 2.1 AA. Fachlich ist 2.2 AA trotzdem der sinnvollere Zielwert: Die sechs zusätzlichen Kriterien der Stufen A und AA sind günstig umzusetzen, und die am 2. September 2026 veröffentlichte Fassung V4.1.1 nimmt sie auf.

Sind alle neun Kriterien Pflicht für AA?

Nein. Auf AA kommen vier hinzu (2.4.11, 2.5.7, 2.5.8, 3.3.8), auf A zwei (3.2.6, 3.3.7) und weil AA immer A einschließt, sind das zusammen sechs. Die übrigen drei sind AAA und gehören nicht zur üblichen Zielstufe.

Gilt die 24-px-Regel auch für Links im Fließtext?

Nein, Inline-Links sind ausdrücklich ausgenommen. Ihre Größe folgt der Zeilenhöhe und liegt nicht in der Hand des Entwicklers. Gemeint sind eigenständige Bedienelemente: Buttons, Icons, Kalenderzellen, Tabellen-Aktionen, Schließen-Kreuze.

Wie viele Erfolgskriterien hat WCAG 2.2 insgesamt?

86: 31 auf Stufe A, 24 auf AA und 31 auf AAA. Für eine AA-Konformität zählen A und AA zusammen, also 55 Kriterien. Genau diese sind in der Kriterien-Referenz einzeln aufbereitet.

Ändert sich durch den Wegfall von 4.1.1 etwas an meinem Code?

Nein. Validität bleibt sinnvoll, sie ist nur kein eigenes Erfolgskriterium mehr. Alles, was sich auf Name, Rolle oder Zustand auswirkt (doppelte id, kaputte label-Verknüpfungen, verwaiste aria-labelledby), fällt weiterhin unter 4.1.2 und bleibt ein Befund.

Verwandte Themen

• WCAG 2.1 & 2.2 erklärt: Aufbau, Versionen und Konformitätsstufen im Überblick
• Kriterien-Referenz: alle 55 A- und AA-Kriterien mit Code und Testanleitung
• Tastaturbedienung & sichtbarer Fokus: das Thema hinter der Hälfte der Neuzugänge
• Karten & Drag-and-drop: die Umsetzung von 2.5.7 an einem konkreten Bauteil
• Kognitive Barrierefreiheit: wen 3.2.6, 3.3.7 und 3.3.8 gemeinsam betreffen
• Aktuelles zum BFSG: der laufende Stand zur EN 301 549

Quellen

• Web Content Accessibility Guidelines (WCAG) 2.2 (W3C-Empfehlung: Normtext aller neun Kriterien)
• What's New in WCAG 2.2 (W3C WAI: Übersicht der Änderungen gegenüber 2.1)
• Understanding SC 2.5.8 Target Size (Minimum) (W3C: Kreis-Test und Ausnahmen)
• Understanding SC 3.3.8 Accessible Authentication (W3C: kognitive Funktionstests und Ausnahmen)
• EN 301 549 V3.2.1 (im EU-Amtsblatt genannte Fassung als PDF)
• EN 301 549 V4.1.1 (Fassung vom 2. September 2026 mit WCAG 2.2 als PDF)