WCAG-2.2-Adoptionsrate: Wo die Empfehlung in Recht, Beschaffung und Audit-Praxis Eingang gefunden hat — und wo nicht. Eine Erhebung 2026
Das W3C veröffentlichte WCAG 2.2 am 5. Oktober 2023 als Empfehlung. Zweieinhalb Jahre später ist es die Version, gegen die jede seriöse Prüferin und jeder seriöse Prüfer bewertet, und die Version, die jedes wichtige Designsystem zumindest teilweise übernommen hat — aber noch nicht die Version, die das Barrierefreiheitsrecht des größten Teils der Welt tatsächlich zitiert. Die Verzögerung zeigt sich an neun bestimmten Stellen: den neun neuen Erfolgskriterien. Dieser Field Guide katalogisiert jedes von ihnen.
Die vorangegangenen Beiträge dieser Reihe haben das Bild der gesetzlichen Verweise von oben nach unten kartiert — Jurisdiktion für Jurisdiktion, Gesetz für Gesetz. Diese Perspektive ist für Compliance-Beauftrage und Beschaffungsverantwortliche nützlich. Für Entwicklende, Designer und Produktmanager, die die eigentliche Behebungsarbeit leisten müssen, ist sie weniger hilfreich. Dieser Leitfaden wählt die umgekehrte Perspektive: Er arbeitet vom Erfolgskriterium nach außen.
Jeder Eintrag unten ist eines der neun neuen WCAG-2.2-Erfolgskriterien — die genauen Änderungen, die die Arbeitsgruppe an der vorherigen Empfehlung vorgenommen hat. Für jedes beschreiben wir in verständlicher Sprache, was das Kriterium erfordert, wie häufig das Feld in Audits von 2026 tatsächlich das Versagen erkennt, den Produktionsmechanismus, der es auslöst, und die technische Behebung. Jeder Eintrag folgt derselben Struktur, in derselben Reihenfolge, sodass der Katalog von oben nach unten oder per Sprung gelesen werden kann.
9 neue Erfolgskriterien · gereiht nach Audit-Fehlerfrequenz 2026
| ID | Muster (SC + Titel) | Stufe | Audit-Fehlerrate |
|---|---|---|---|
| E·01 | 2.4.13 Fokusdarstellung | AAA | >70 % |
| E·02 | 2.5.8 Zielgröße (Minimum) | AA | Häufigster AA-Fehler |
| E·03 | 3.3.8 Barrierefreie Authentifizierung (Min.) | AA | Stärkster AA-Einfluss |
| E·04 | 2.4.11 Fokus nicht verdeckt (Min.) | AA | Top-5 AA |
| E·05 | 2.5.7 Ziehbewegungen | AA | Enge Anwendungsfläche |
| E·06 | 3.3.7 Redundante Eingabe | A | Serverseitige Behebung |
| E·07 | 3.2.6 Konsistente Hilfe | A | Redaktionell |
| E·08 | 2.4.12 Fokus nicht verdeckt (Erw.) | AAA | Strengere Variante von E·04 |
| E·09 | 3.3.9 Barrierefreie Authentifizierung (Erw.) | AAA | Strengere Variante von E·03 |
Fehlerraten-Deskriptoren aus unabhängigen Prüfberichten aggregiert, die bis einschließlich Q1 2026 veröffentlicht wurden; die Methoden unterscheiden sich zwischen den Firmen, sodass die Zahlen als Richtungsangaben und nicht als präzise Werte zu verstehen sind. Fünf der neun Kriterien liegen auf Stufe AA — der regulatorisch verbindlichen Tier — und sind die Zeilen, mit denen sich Beschaffungsklauseln zuerst auseinandersetzen müssen.
Wo die Verzögerung tatsächlich sichtbar wird
Die gesetzliche Einbindung von WCAG erfolgt durch Versionsfixierung. Eine Verordnung sagt nicht „aktuelles WCAG“; sie nennt WCAG 2.0 oder WCAG 2.1 mit einer Stufe und einem Datum. Die Aktualisierung der Fixierung ist ein Akt der gesetzlichen oder regulatorischen Änderung. Mitte 2026 sind die wichtigsten Barrierefreiheitsverordnungen der Welt noch auf drei Versionen verteilt: Section 508 der USA auf 2.0; die europäische EN 301 549 V3.2.1 auf 2.1; das britische PSBAR auf 2.1 (mit einer im Februar 2026 abgeschlossenen Konsultation, die noch aussteht). Der pragmatische Mittelweg des Jahrzehnts — „WCAG 2.1 AA als Mindestanforderung, mit VPAT-2.5-Berichterstattung gegen 2.2, soweit die Antwort des Anbieters dies erlaubt“ — ist zur gängigen Beschaffungssprache geworden.
Die Beschaffung bewegt sich schneller als das Recht. Die VPAT-2.5/ACR-Vorlage des ITI, veröffentlicht im Januar 2025, fügte Berichtsspalten für jedes der neun neuen Kriterien hinzu; jedes nach diesem Datum gegen die WCAG-Version der Vorlage ausgestellte VPAT berichtet gegen 2.2. Die Adoption durch die Designsysteme der großen Technologieunternehmen ist am schnellsten vorangeschritten — Microsoft, Apple HIG, Material 3, Adobe Spectrum und Meta haben sich alle bis 2024–25 an 2.2 ausgerichtet. Der folgende Katalog ist das technische Pendant: die neun konkreten Änderungen, die die Arbeitsgruppe vorgenommen hat, und was sie in der Produktion tatsächlich aufdecken.
Fünf der neun neuen Erfolgskriterien sind AA — das sind die regulatorisch verbindlichen, die Zeilen, die eine Beschaffungsklausel von 2026 nicht umgehen kann.
Fokusindikatoren waren das erste Anliegen der Arbeitsgruppe im WCAG-2.2-Auftrag. Zwei Kriterien befassen sich damit, ob der Fokusring jemals durch autorenseitige Inhalte verborgen wird; ein drittes spezifiziert den Indikator selbst. Zusammen erfassen sie die am häufigsten übersehene Teiloberfläche jeder Tastaturnavigation.
Fokusdarstellung — 2.4.13 AAA
Wenn eine Benutzeroberflächenkomponente den Tastaturfokus erhält, muss der Fokusindikator ein Mindestkontrastsverhältnis von 3:1 gegenüber angrenzenden Farben aufweisen und mindestens den Umfang einer 2-CSS-Pixel-Volllinie um das fokussierte Element abdecken oder eine äquivalente Indikatorfläche bieten. Das Kriterium ist eines der wenigen WCAG-Ergänzungen, die messbare Geometrie statt Verhalten spezifizieren.
Die Standard-Fokusringe des Browsers, die Designer fünfzehn Jahre lang aus ästhetischen Gründen überschrieben haben, scheitern an dieser Messung auf der Mehrheit der auditierten Produktionssites. Benutzerdefinierte Fokusstile verwenden in der Regel 1-Pixel-Outlines oder Akzentfarben mit geringem Kontrast, die in Design-Tools korrekt aussehen, aber gegen den Hintergrund des tatsächlich fokussierten Elements unter 3:1 liegen.
Die Zahl ist relevant, auch wenn das Kriterium AAA ist: Sie zeigt, was passieren würde, wenn ein künftiger Gesetzgeber auf WCAG 2.2 Stufe AAA verweist oder ein Beschaffungsvertrag dieses eine Kriterium anhebt.
Eine 2-CSS-Pixel-Outline in einer Farbe setzen, die mindestens 3:1 gegenüber dem Elementhintergrund erreicht; mit einem Kontrastprüfer verifizieren, nicht nach Augenmaß. Wo das Designsystem den Browser-Fokus überschreibt, ein Fokustil-Token bereitstellen, das Designer nicht versehentlich unter den Kontraststchwellenwert senken können.
Zielgröße (Minimum) — 2.5.8 AA
Das Trefferziel jeder Zeigereingabe muss mindestens 24 mal 24 CSS-Pixel groß sein, außer wenn das Ziel inline in einem Satz steht, wenn es vom User-Agent bemessen wird, wenn ein äquivalentes Ziel verfügbar ist oder wenn die Funktion des Ziels wesentlich ist. Das Kriterium misst das Trefferziel, nicht das sichtbare Symbol.
Das Kriterium erfasst ein spezifisches UI-Muster: dichte Symbol-Symbolleisten, insbesondere in Editoren, Dashboards und Datentabellenköpfen. Die meisten Symbol-Button-Bibliotheken verwenden standardmäßig 16×16- oder 20×20-Pixel-Symbolgrößen innerhalb eines geringfügig größeren Trefferziels. Wenn das Trefferziel ebenfalls unter 24×24 liegt, versagt das Kriterium — und Symbolleistendesigner reduzieren routinemäßig die Abstände, um mehr Symbole in begrenzte horizontale Fläche zu packen.
Ein Mindest-Trefferziel-Token von 24 mal 24 CSS-Pixeln im Designsystem festlegen, angewendet über Padding und nicht über die eigenen Abmessungen des Symbols. Wo Symbolleisten die Untergrenze nicht unterbringen können, ausreichend Abstand hinzufügen, damit benachbarte Ziele nicht innerhalb des Überlappungsausschlusses des Kriteriums liegen. Ein Einstellungs-Äquivalent (ein größeres Menü) für wirklich beengte Oberflächen bereitstellen.
Barrierefreie Authentifizierung (Minimum) — 3.3.8 AA
Der Authentifizierungsschritt einer Website oder App darf nicht auf einem kognitiven Funktionstest beruhen — Lösen eines Rätsels, Abschreiben eines verzerrten Bildes, Erkennen von Objekten in einem Raster —, es sei denn, eine alternative Authentifizierungsmethode wird bereitgestellt, ein Hilfsmechanismus ist verfügbar oder eine Ausnahme für Objekterkennung findet Anwendung. Das Auswendiglernen eines Passworts gilt als kognitiver Funktionstest, weshalb Passwort-Manager ausdrücklich berücksichtigt werden.
Die meisten bildbasierten CAPTCHAs versagen offensichtlich. Gleiches gilt für „Klicken Sie auf die Kacheln mit Ampeln“-Aufgaben, Transkriptionstests mit verzerrtem Text und jeden Flow, der einen Einmalcode in ein Feld einfügt, aber die Einfügeinteraktion deaktiviert. Das Muster konzentriert sich auf Login-, Passwort-Zurücksetzen- und Kontoerstellungsflows — genau die hochriskanten Punkte, an denen ein Ausschluss die größten Kosten verursacht.
Authentifizierungsflows sind auch der Bereich, in dem das Kriterium am schärfsten zubeißt, denn das Versagen verschlechtert die Erfahrung nicht — es beendet sie.
Kognitive CAPTCHAs durch eine nicht-kognitive Alternative ersetzen — gerätebasierte Attestierung, Magic Links, Passkeys oder unsichtbare Risikobewertung. Passwort-Manager-Autofill ermöglichen. Sicherstellen, dass Einfügen in Einmalcode-Feldern funktioniert. Wenn ein CAPTCHA bestehen bleiben muss, eine Audio-Alternative bereitstellen, die ihrerseits keine Transkription von verzerrter Sprache erfordert.
Die AA-Tier ist der Dreh- und Angelpunkt
Fünf der neun neuen Kriterien liegen auf Stufe AA: 2.4.11 Fokus nicht verdeckt (Min.), 2.5.7 Ziehbewegungen, 2.5.8 Zielgröße (Min.), 3.3.8 Barrierefreie Authentifizierung (Min.) und (im Paar mit 3.3.8 auf AAA) 3.3.9. Das sind die Kriterien, die eine Beschaffungsklausel nicht umgehen kann, und die Zeilen, an denen der Unterschied zwischen WCAG-2.1-AA-Konformität und WCAG-2.2-AA-Konformität am deutlichsten messbar ist. Die beiden Ergänzungen auf Stufe A (3.2.6 Konsistente Hilfe, 3.3.7 Redundante Eingabe) sind einfachere Gewinne. Die beiden AAA-Ergänzungen (2.4.12 und 3.3.9) sind aspirative Verschärfungen der AA-Paare.
Fokus nicht verdeckt (Minimum) — 2.4.11 AA
Wenn eine Benutzeroberflächenkomponente den Tastaturfokus erhält, darf das fokussierte Element nicht vollständig durch autorenseitige Inhalte verborgen sein. Teilweise Überlappung ist auf dieser Stufe erlaubt (ein Sticky-Header, der die obere Hälfte eines fokussierten Feldes überdeckt, ist zulässig); vollständige Verdeckung ist es nicht.
Die häufigste Kollision ist ein Sticky-Header — manchmal ein Cookie-Banner oder ein schwebendes Chat-Widget —, der das fokussierte Formularfeld überlagert, wenn ein Tastaturnutzender hineintabt. Produktionssites, die während der Redesign-Ära 2020–22 einen Sticky-Header über ein vorhandenes Formular gelegt haben, haben das Fokus-und-Scroll-Verhalten routinemäßig übersehen, weil das ursprüngliche Formular erstellt wurde, bevor Sticky-Elemente existierten.
scroll-margin-top (oder scroll-padding-top auf dem Scroll-Container) gleich der Höhe jedes Sticky-Overlays setzen. Testen, dass das Tabben durch ein langes Formular das fokussierte Element vollständig unterhalb eines Headers scrollt. Mit sichtbaren Fokus-Stilen kombinieren, damit Nutzende sehen können, wo der Fokus tatsächlich gelandet ist.
Der motorische Barrierefreiheits-Auftrag in WCAG 2.2 reduzierte sich auf zwei Kriterien, beide AA. Das eine erfasst Listenreihenfolge-Benutzeroberflächen, die ein anhaltend gedrücktes Ziehen erfordern; das andere (E·02 oben) erfasst dichte Symbol-Symbolleisten. Sie teilen eine gemeinsame Ursache — Designsysteme, die einen präzisen Zeiger voraussetzen.
Ziehbewegungen — 2.5.7 AA
Funktionen, die eine Ziehbewegung verwenden, müssen auch über eine Einzelzeiger-Aktion bedienbar sein — ein Tipper, ein Klick oder ein Äquivalent, das keine anhaltende Zeigerbewegung erfordert. Drag-and-Drop-Interaktionen sind nicht verboten; sie dürfen lediglich nicht der einzige verfügbare Weg zur Funktion sein.
Listen-Reihenfolge- und Kanban-ähnliche Benutzeroberflächen werden häufig nur mit Drag-Umsortierung ausgeliefert. Dasselbe gilt für Slider-Steuerelemente, die als ziehbare Thumbs ohne entsprechenden Spinbutton oder Texteingabe implementiert sind, sowie für Bild-Zuschnitt-UIs, die ein Ziehen zum Setzen der Grenzen erfordern. Das Kriterium erfasst diese jedes Mal.
Für jede Ziehinteraktion eine äquivalente Tipper/Klick-Alternative bereitstellen — „nach oben verschieben“- und „nach unten verschieben“-Schaltflächen neben ziehbaren Listenelementen, eine numerische Eingabe neben einem Slider, einen Klick-zum-Setzen-der-Grenzen-Modus im Zuschneidewerkzeug. Wenn die Alternative in einem Kontextmenü versteckt ist, sicherstellen, dass sie per Tastatur erreichbar ist.
Die verbleibenden vier Kriterien fallen in zwei Paare: die beiden redaktionellen Ergänzungen auf Stufe A (Redundante Eingabe und Konsistente Hilfe) und die beiden AAA-Verschärfungen (Fokus nicht verdeckt (Erweitert), Barrierefreie Authentifizierung (Erweitert)). Zusammen runden sie den WCAG-2.2-Auftrag zur kognitiven Barrierefreiheit ab.
Redundante Eingabe — 3.3.7 A
Innerhalb desselben authentifizierten Prozesses darf die Nutzerin oder der Nutzer nicht aufgefordert werden, dieselbe Information zweimal einzugeben — es sei denn, die erneute Eingabe ist wesentlich, der vorherige Eintrag ist nicht mehr gültig oder die Information betrifft die Sicherheit (ein Passwort-Rückgabe bei der Kontoerstellung ist das kanonische Gegenbeispiel). Automatisches Ausfüllen oder Auswählen aus zuvor eingegebenen Werten erfüllt das Kriterium.
Mehrstufige Checkout-Flows, mehrseitige Antragsformulare und Visa/Genehmigungsanträge fragen routinemäßig nach derselben Adresse, demselben Namen oder denselben Kontaktinformationen in zwei separaten Schritten, weil die Schritte von verschiedenen Teams erstellt und nie abgestimmt wurden. Die zuvor eingegebenen Werte der Nutzerin oder des Nutzers werden nicht in einer sitzungsübergreifenden Session zwischen den Schritten gespeichert.
Nutzerseitig eingegebene Werte über die Schritte eines einzelnen Prozesses hinweg speichern; passende Felder in nachfolgenden Schritten vorausfüllen; oder eine Ein-Klick-„Dieselbe Adresse verwenden“-Schaltfläche anbieten. Das Muster zeigt sich typischerweise bei der Prozessanalyse und nicht beim Frontend-Audit, sodass eine teamübergreifende Flow-Überprüfung der praktische Behebungsschritt ist.
Konsistente Hilfe — 3.2.6 A
Wenn ein Hilfsmechanismus bereitgestellt wird — ein Kontakt-Link, ein Hilfe-Link, ein Chat-Widget, eine Support-Telefonnummer, ein Selbsthilfe-Link —, muss er an derselben relativen Position auf den Seiten erscheinen, auf denen er bereitgestellt wird. Das Kriterium erfordert keine Hilfe; nur dass sie, wo sie vorhanden ist, konsistent platziert wird.
Das Kriterium ist im Prinzip unkompliziert und erfasst eine enge Gruppe von Sites, die auf einigen Seiten einen „Kontakt“-Link in der Kopfzeile, auf anderen in der Fußzeile und auf einer dritten Gruppe von Seiten in einem schwebenden Chat-Widget haben — häufig das Ergebnis mehrerer Site-Bereiche, die verschiedenen Teams mit separaten Vorlagen gehören.
Platzierung von Hilfsmechanismen über Vorlagen hinweg prüfen; einen einzigen kanonischen Ort festlegen (Kopfzeile, dauerhafter Footer oder schwebendes Widget) und alle Abweichungen angleichen. Die Behebung ist selten technisch; es ist ein Governance-Schritt für Inhalte und Vorlagen.
Fokus nicht verdeckt (Erweitert) — 2.4.12 AAA
Das AAA-Pendant zu 2.4.11: Wenn eine Benutzeroberflächenkomponente den Tastaturfokus erhält, darf das fokussierte Element durch autorenseitige Inhalte überhaupt nicht verdeckt sein. Teilweise Überlappung ist auf dieser Stufe verboten — ein Sticky-Header, der einen Teil des fokussierten Feldes überdeckt, versagt.
Dieselben Sticky-Overlay-Kollisionen, die 2.4.11-Fehler verursachen, bestehen bei 2.4.12 fort. Sites, die scroll-margin-top zur Erfüllung des Minimumkriteriums eingesetzt haben, hinterlassen bei Edge-Case-Viewport-Höhen tendenziell noch einige CSS-Pixel Überlappung. Auf AAA-Stufe ist diese Überlappung bereits das Versagen.
scroll-margin-top so anpassen, dass es die Höhe jedes autorenseitigen Overlays komfortabel überschreitet, einschließlich dynamischer (Cookie-Banner beim ersten Besuch, Chat-Widgets, die beim Hover erweitern). Explizite Regressionstests für das Tabbing-in-Formular-Verhalten bei gängigen Viewport-Größen hinzufügen.
Barrierefreie Authentifizierung (Erweitert) — 3.3.9 AAA
Das AAA-Pendant zu 3.3.8: Die Authentifizierung darf sich grundsätzlich nicht auf einen kognitiven Funktionstest stützen. Die Ausnahmen für Objekterkennung und persönliche Inhalte, die auf AA-Stufe gelten, finden hier keine Anwendung. Gedächtnistests, Transkriptionstests und Bilderkennungsaufgaben scheitern auf dieser Stufe.
Selbst Sites, die traditionelle CAPTCHAs durch Objekterkennungsaufgaben ersetzt haben (die AA-Ausnahme), scheitern an 3.3.9. Das Kriterium ist das Signal der Arbeitsgruppe, in welche Richtung sich die Authentifizierung entwickeln sollte: weg von kognitiven Aufgaben, hin zu Geräteattestation oder biometrischer Verifizierung.
Passkeys (WebAuthn) als primären Authentifizierungsmechanismus einführen; Passwort plus Passkey als Übergangszustand und nicht als Ziel behandeln. Wo Bilderkennung für die Risikobewertung beibehalten wurde, diese serverseitig aus Verhaltenssignalen ausführen und nicht als nutzerseitige Aufgabe.
Die 2.2-Ergänzungen sind nicht dort, wo die schwersten Probleme der Barrierefreiheit liegen. Sie sind dort, wo die häufigsten, messbarsten Produktionsversagen liegen — was genau der Grund ist, weshalb sie ausgewählt wurden.
Was die neun gemeinsam haben
Als Katalog gelesen, teilen die neun neuen Kriterien eine gemeinsame redaktionelle Haltung. Es sind keine neuen Fehlermodi, die die Arbeitsgruppe erfunden hat; es sind die Fehlermodi, die seit der Veröffentlichung von WCAG 2.1 am konsistentesten aufgetreten sind. Die Arbeitsgruppe behandelte sie als zu schließende Lücken: dichte Symbolleisten (2.5.8), Sticky-Overlays (2.4.11 / 2.4.12), CAPTCHA-artige Authentifizierung (3.3.8 / 3.3.9), Standard-Fokusringe (2.4.13), Adresse-erneut-eingeben-Checkout-Muster (3.3.7), reine Drag-Listenreihenfolgen (2.5.7) und die inkonsistente Platzierung von Hilfe-Links, die Barrierefreiheits-Befürworter mit kognitiven Einschränkungen frustriert hat (3.2.6).
Das Bild der gesetzlichen Verweise hinkt hinterher, weil der Versionsfixierungsmechanismus langsam ist. EN 301 549 V4 — das einzige größte ausstehende Ereignis — würde WCAG 2.2 durch die EU-Web-Zugänglichkeitsrichtlinie, die Konformitätsreferenz des European Accessibility Act (Europäischer Rechtsakt zur Barrierefreiheit) und jedes nationale Web-Zugänglichkeitsgesetz, das auf den harmonisierten europäischen Standard verweist, kaskadieren lassen. Eine Veröffentlichung 2026 ist die Arbeitshypothese innerhalb von ETSI JTC HF; ein Rutsch auf 2027 ist die vorsichtigere Annahme. Die britische PSBAR-Änderung, die aus der im Februar 2026 abgeschlossenen Konsultation folgt, wird vor Jahresende erwartet. Das US-Section-508-Update bleibt das am langsamsten voranschreitende große Stück — selbst das 2.1-Update steht 2026 noch aus; ein 2.2-Update ist realistisch ein Instrument der späten 2020er Jahre.
Für die Planung 2026 gilt: WCAG 2.2 ist der Standard, der für den Rest des Jahrzehnts in Recht und Beschaffung zitiert werden wird. WCAG 3 (Silver) befindet sich weiterhin als Working Draft und ist nicht auf einem kurzfristigen Empfehlungstrack; der jüngste öffentliche Entwurf aus 2025 machte deutlich, dass eine Veröffentlichung auf Empfehlungsebene nicht vor 2028 erwartet wird. Die Versionsfixierungspraxis in Verordnungen bedeutet, dass 2.2 noch Jahre nach der Veröffentlichung von 3.0 referenziert werden wird. Die pragmatische Beschaffungsklausel — WCAG 2.2 auf Stufe AA als Konformitätsziel fordern, ein VPAT 2.5 ACR aus den letzten 12 Monaten fordern, vom Anbieter die Identifikation aller neun neuen Kriterien fordern, bei denen die Konformität noch nicht erreicht ist — funktioniert unter jeder Jurisdiktion, deren zugrundeliegendes Recht weiterhin auf 2.0 oder 2.1 verweist, weil nichts in diesen Gesetzen einen Auftraggeber daran hindert, mehr zu verlangen.
Checkliste zur WCAG-2.2-Bereitschaft
Beschaffungssprache (sofort umsetzen)
- WCAG 2.2 auf Stufe AA als Konformitätsziel in neuen Verträgen fordern
- Ein VPAT 2.5 ACR aus den letzten 12 Monaten von jedem Anbieter fordern
- Von Anbietern die Identifikation aller neun neuen Kriterien fordern, bei denen die Konformität noch nicht erreicht ist, sowie einen dokumentierten Behebungsfahrplan
- „WCAG 2.1 AA als Mindestanforderung, mit Berichterstattung gegen 2.2, soweit die Antwort des Anbieters dies erlaubt“ als Untergrenze — nicht als Obergrenze — behandeln
Engineering-Regressionstests (die fünf AA-Kriterien vor dem Audit erkennen)
- Tabbing-in-Formular-Verhalten bei gängigen Viewport-Größen, mit jedem geöffneten Overlay (2.4.11)
- Trefferziel-Abmessungen in Symbol-Symbolleisten, Dashboards und Datentabellenköpfen (2.5.8)
- Einzelzeiger-Alternativen für jede Ziehinteraktion — Listenreihenfolge, Slider, Zuschneidewerkzeuge (2.5.7)
- Login-, Registrierungs- und Passwort-Zurücksetzen-Flows frei von kognitiven Funktionstests; Einfügen in OTP-Felder aktiviert (3.3.8)
- Schrittübergreifende Persistenz: kein Feld zweimal im selben authentifizierten Prozess abgefragt (3.3.7)
Redaktionelle / IA-Überprüfung (die beiden Ergänzungen auf Stufe A)
- Einziger kanonischer Ort für Hilfsmechanismen über Vorlagen hinweg (3.2.6)
- Teamübergreifende Flow-Überprüfung für jeden mehrstufigen Prozess, der mehr als einem Team gehört (3.3.7)
Beobachtungspunkte für den Ausblick 2026
- Veröffentlichung von EN 301 549 V4 — löst WCAG 2.2 im EU-Web-Zugänglichkeitsrecht aus
- UK-PSBAR-Änderung — erste große englischsprachige Jurisdiktion, die auf 2.2 verweist
- US-Section-508-IKT-Update — 2.1 steht noch aus; 2.2 ist ein Instrument der späten 2020er Jahre
- VPAT-2.5-Zyklus — jedes ACR aus 2025 oder später sollte gegen 2.2 berichten
Der WCAG-2.2-Übergang ist strukturell zwei Übergänge, die auf verschiedenen Uhren laufen. Der Rechtsübergang ist langsam, abhängig von einer kleinen Anzahl von Standardisierungsgremien — ETSI JTC HF vor allem — und wird sich durch 2026–27 fortsetzen. Der Praktiker-Übergang ist weitgehend bereits vollzogen: Prüfende bewerten gegen 2.2, Designsysteme richten sich danach aus, Anbieter reichen VPAT-2.5-ACRs ein, die dagegen berichten, und die neun neuen Kriterien sind nun das etablierte Vokabular von Barrierefreiheits-Audits. Die interessante analytische Frage ist nicht mehr, ob WCAG 2.2 der Arbeitsstandard ist — das ist er —, sondern ob die regulatorischen Verweise aufholen werden, bevor WCAG 3 die Aufmerksamkeit nach vorne zieht.
MethodikFehlerraten-Deskriptoren aus unabhängigen Prüfberichten aggregiert, die bis Q1 2026 über SaaS-, E-Commerce- und öffentliche Sektor-Audit-Zyklen veröffentlicht wurden. Qualitative Deskriptoren werden verwendet, wo Firmen ordinale statt präziser Raten veröffentlichen.
UmfangAusschließlich die neun neuen WCAG-2.2-Erfolgskriterien. SC 4.1.1 Syntaxanalyse, in WCAG 2.2 zurückgezogen, ist außerhalb des Umfangs. In WCAG 2.1 weitergeführte Kriterien sind außerhalb des Umfangs.
QuellenW3C, Web Content Accessibility Guidelines (WCAG) 2.2, Empfehlung 5. Oktober 2023 — w3.org/TR/WCAG22; W3C AG WG, What’s New in WCAG 2.2 — w3.org/WAI/standards-guidelines/wcag/new-in-22; ETSI, EN 301 549 V3.2.1 (2021) und JTC-HF-V4-Entwürfe; US Access Board IKT-Standards (Section-508-Refresh, 2017); US DOJ, Final Rule — Title II web accessibility, 28 C.F.R. Part 35 (April 2024); UK Cabinet Office, PSBAR 2018 und Konsultation 2025–26; ITI, VPAT 2.5 / ACR, Januar 2025 — itic.org/policy/accessibility/vpat; EU-Richtlinien 2016/2102 und 2019/882; W3C, WCAG 3.0 Working Draft — w3.org/TR/wcag-3.0. Weitere Informationen zu nationalen Barrierefreiheitsvorschriften, dem Praktiker-Toolkit, der vollständigen WCAG-2.2-Erfolgskriterien-Referenz, dem Erläuterer zu Compliance, Konformität und Barrierefreiheit, dem Monitoring-Einkaufsführer, einem kostenlosen WCAG-2.2-Basis-Scan und dem weiteren Bericht von 2026.