WCAG 2.2: Neue Erfolgskriterien verstehen und umsetzen

WCAG 2.2 baut auf dem Fundament von WCAG 2.1 auf und fügt neun neue Erfolgskriterien hinzu, während ein bestehendes Kriterium (4.1.1 Parsing) als veraltet markiert wurde. Die neuen Kriterien verteilen sich auf drei Konformitätsstufen: ein Kriterium auf Level A, sechs auf Level AA und zwei auf Level AAA. Da das BFSG und der European Accessibility Act Level AA als Mindestanforderung definieren, sind sieben der neun neuen Kriterien direkt compliance-relevant.

Die inhaltlichen Schwerpunkte der neuen Kriterien liegen in drei Bereichen: Fokus-Management (Focus Not Obscured, Focus Appearance), motorische Zugänglichkeit (Dragging Movements, Target Size) und kognitive Zugänglichkeit (Redundant Entry, Consistent Help, Accessible Authentication). Diese Schwerpunkte spiegeln die Erkenntnis wider, dass bisherige WCAG-Versionen vor allem visuelle und auditive Barrieren adressierten, während kognitive und motorische Einschränkungen unterrepräsentiert waren.

Für Unternehmen, die bereits WCAG 2.1 AA-konform sind, ist der Aufwand für die Migration auf WCAG 2.2 überschaubar. Die neuen Kriterien betreffen spezifische Interaktionsmuster, die in einem gezielten WCAG-Audit effizient geprüft werden können. Wer allerdings noch grundlegende 2.1-Anforderungen nicht erfüllt, sollte diese zuerst adressieren.

Das Kriterium 2.4.11 Focus Not Obscured (Minimum) auf Level AA verlangt, dass der Tastaturfokus nicht vollständig von anderen Seitenelementen verdeckt wird. In der Praxis bedeutet das: Wenn ein Nutzer per Tab-Taste durch die Seite navigiert und ein Element den Fokus erhält, darf dieses Element nicht hinter einem Sticky Header, einem Cookie-Banner, einem Chat-Widget oder einem anderen überlagernden Element verschwinden.

Dieses Kriterium adressiert ein häufiges Problem moderner Webseiten. Sticky Header mit einer Höhe von 60 bis 80 Pixeln verdecken regelmäßig fokussierte Elemente am oberen Seitenrand. Cookie-Banner am unteren Bildschirmrand überlagern Footer-Links. Chat-Widgets in der unteren rechten Ecke verdecken Formularfelder. Für Tastaturnutzer, die den Fokus nicht visuell verfolgen können, werden diese Elemente unsichtbar und damit unbenutzbar.

Die technische Umsetzung erfordert eine sorgfältige Koordination von z-index-Werten, scroll-padding-Regeln und Fokus-Management. Sticky Header benötigen ein entsprechendes scroll-padding-top auf dem HTML-Element, sodass fokussierte Elemente unterhalb des Headers einrollen. Cookie-Banner sollten nach Interaktion minimiert werden und nicht dauerhaft den unteren Bereich blockieren. Die strengere AAA-Variante (2.4.12) verlangt, dass das fokussierte Element vollständig sichtbar ist, nicht nur teilweise.

Das Kriterium 2.5.7 Dragging Movements auf Level AA fordert, dass jede Funktion, die Drag-and-Drop erfordert, auch über eine Single-Pointer-Alternative ausführbar ist. Das bedeutet: Jede Interaktion, die eine Ziehbewegung erfordert, muss auch durch einfaches Tippen oder Klicken erreichbar sein. Dieses Kriterium ist besonders relevant für Nutzer mit motorischen Einschränkungen, die keine präzisen Ziehbewegungen ausführen können.

In der Praxis betrifft dieses Kriterium zahlreiche gängige UI-Patterns: Slider und Range-Inputs, die per Ziehen bedient werden, Drag-and-Drop-Sortierungen in Listen und Kanban-Boards, Datei-Uploads per Drag-and-Drop, Karussells mit Swipe-Gesten und Kartenanwendungen mit Panning-Interaktion. Für jedes dieser Patterns muss eine alternative Bedienungsmöglichkeit existieren.

Für Slider bietet sich eine numerische Eingabe oder Plus/Minus-Buttons als Alternative an. Sortierbare Listen können zusätzliche Buttons für Hoch/Runter erhalten. Datei-Uploads benötigen neben dem Drop-Bereich einen klassischen Datei-Auswahl-Button. Karussells brauchen Vor/Zurück-Schaltflächen. Diese Alternativen verbessern nicht nur die Barrierefreiheit, sondern oft auch die allgemeine Usability, da nicht alle Nutzer Drag-Interaktionen intuitiv finden. Die barrierefreie Webentwicklung berücksichtigt diese Patterns von Anfang an.

Das Kriterium 3.3.7 Redundant Entry auf Level A ist eines der praxisrelevantesten neuen Kriterien. Es verlangt, dass Informationen, die der Nutzer in einem Prozess bereits eingegeben hat, nicht erneut abgefragt werden, sofern die erneute Eingabe nicht wesentlich für die Funktion ist. Das klassische Beispiel: Wenn ein Nutzer im Checkout seine Rechnungsadresse eingibt, sollte das Feld für die Lieferadresse diese Daten automatisch übernehmen können.

Dieses Kriterium zielt vor allem auf Menschen mit kognitiven Einschränkungen, für die wiederholte Dateneingabe eine erhebliche Belastung darstellt. Aber auch für alle anderen Nutzer ist das Prinzip sinnvoll: Weniger Eingaben bedeuten weniger Fehler, schnellere Prozesse und höhere Conversion-Raten. Laut Baymard Institute (2024) führen 12% (Projekterfahrung) aller Checkout-Abbrüche auf zu lange oder komplizierte Formulare zurück.

Die Umsetzung erfordert eine durchdachte Formulararchitektur. Multi-Step-Formulare müssen eine Datenübernahme zwischen Schritten ermöglichen. Checkout-Prozesse benötigen eine Option zur Übernahme der Rechnungsadresse als Lieferadresse. Registrierungsformulare sollten Daten aus dem Bestellprozess übernehmen. Autocomplete-Attribute nach dem HTML-Standard erleichtern die automatische Befüllung durch den Browser. All diese Maßnahmen sind Teil einer barrierefreien Shop-Entwicklung.

Das Kriterium 2.5.8 Target Size (Minimum) auf Level AA definiert, dass interaktive Elemente mindestens 24x24 CSS-Pixel groß sein müssen. Alternativ darf ein Element kleiner sein, wenn der Abstand zu benachbarten interaktiven Elementen groß genug ist, um versehentliches Aktivieren zu verhindern. Dieses Kriterium betrifft vor allem mobile Interfaces, wo kleine Touch-Ziele ein häufiges Problem darstellen.

In der Praxis verstoßen viele Websites gegen dieses Kriterium, ohne es zu wissen. Icons in Navigationsleisten, die nur 16x16 Pixel messen, Social-Media-Links mit 20x20 Pixeln, eng nebeneinander liegende Checkbox-Gruppen und kleine Schließen-Buttons in Modals fallen regelmäßig unter die Mindestgröße. Die AAA-Variante (Kriterium 2.5.5 aus WCAG 2.1) empfiehlt sogar 44x44 CSS-Pixel als Zielgröße.

Die Umsetzung ist technisch unkompliziert: CSS-Regeln stellen sicher, dass alle interaktiven Elemente die Mindestgröße erreichen. Für Icons, die visuell kleiner erscheinen sollen, kann der klickbare Bereich über Padding vergrößert werden, ohne das visuelle Design zu verändern. Die Überprüfung kann automatisiert erfolgen, etwa durch Tools, die die Bounding Box aller interaktiven Elemente messen und gegen den Schwellenwert prüfen.

Das Kriterium 3.3.8 Accessible Authentication (Minimum) auf Level AA verlangt, dass Authentifizierungsprozesse keine kognitiven Funktionstests erfordern, es sei denn, eine Alternative steht zur Verfügung. Konkret bedeutet das: Wenn ein Login-Prozess ein CAPTCHA enthält, das Buchstaben erkennen, Bilder zuordnen oder Rechenaufgaben lösen erfordert, muss eine alternative Methode angeboten werden.

Akzeptable Alternativen sind unter anderem Passwort-Manager-Unterstützung durch korrekte Autocomplete-Attribute, Copy-and-Paste-Möglichkeit für Verifizierungscodes, biometrische Authentifizierung wie Fingerabdruck oder Gesichtserkennung, und objektorientierte CAPTCHAs, die keine kognitive Leistung erfordern. Das Ziel ist, dass Menschen mit kognitiven Einschränkungen nicht durch den Authentifizierungsprozess ausgesperrt werden.

Für E-Commerce-Websites hat dieses Kriterium direkte Auswirkungen auf den Login, die Registrierung und den Checkout-Prozess. Kontaktformulare mit CAPTCHAs benötigen alternative Spam-Schutz-Mechanismen wie Honeypot-Felder oder serverseitige Zeitprüfungen. Die Implementierung barrierefreier Authentifizierung verbessert gleichzeitig die Conversion-Rate, da CAPTCHAs ein bekannter Abbruchgrund sind.

Das Kriterium 3.2.6 Consistent Help auf Level A fordert, dass Hilfe-Mechanismen auf allen Seiten einer Website an der gleichen relativen Position erscheinen. Wenn auf der Startseite ein Chat-Icon in der unteren rechten Ecke steht, muss es auf allen anderen Seiten ebenfalls dort stehen. Wenn die Telefonnummer im Header erscheint, muss sie auf jeder Seite im Header zu finden sein.

Dieses Kriterium adressiert die Bedürfnisse von Menschen mit kognitiven Einschränkungen, die auf vorhersagbare Layouts angewiesen sind. Das Suchen und Wiederfinden von Hilfe-Elementen auf unterschiedlichen Positionen stellt für diese Nutzergruppe eine erhebliche kognitive Belastung dar. Die Lösung ist einfach: Hilfe-Elemente werden als Teil des globalen Layouts implementiert, nicht als seitenspezifische Komponenten.

Zu den betroffenen Hilfe-Mechanismen zählen Live-Chat-Widgets, Telefonnummern und E-Mail-Adressen im Kontextbereich, FAQ-Links oder Hilfe-Buttons, Kontaktformular-Links und Self-Service-Portale. Alle diese Elemente sollten in einer konsistenten Header- oder Footer-Struktur verankert sein, die sich über die gesamte Website nicht verändert. Die barrierefreie Webentwicklung implementiert diese Konsistenz als architektonisches Grundprinzip.

Das Kriterium 2.4.13 Focus Appearance auf Level AAA definiert strenge Anforderungen an die Sichtbarkeit von Fokusindikatoren. Der Fokusring muss einen Mindestkontrast von 3:1 zum umgebenden Hintergrund aufweisen und eine Mindestfläche von zwei CSS-Pixeln Umrissstärke haben. Obwohl dieses Kriterium auf AAA-Level liegt und damit nicht direkt BFSG-pflichtig ist, empfehlen wir die Umsetzung, da sichtbare Fokusindikatoren fundamental für die Tastaturnavigation sind.

Viele Websites setzen outline: none in ihrem CSS ein und entfernen damit den Standard-Fokusindikator des Browsers. Das sieht visuell sauberer aus, macht die Seite aber für Tastaturnutzer unbenutzbar. Die bessere Lösung: einen eigenen, zum Design passenden Fokusindikator mit ausreichendem Kontrast implementieren. Die CSS-Eigenschaft :focus-visible ermöglicht es, den Fokusring nur bei Tastaturnavigation anzuzeigen, nicht bei Mausklicks.

Ein gut gestalteter Fokusindikator nutzt eine Kombination aus Outline und Offset, um sicherzustellen, dass der Ring nicht vom Element selbst verdeckt wird. Farblich sollte er sich deutlich vom Hintergrund abheben. Auf dunklem Hintergrund empfiehlt sich ein heller Fokusring, auf hellem Hintergrund ein dunkler. Eine einheitliche Fokus-Strategie über die gesamte Website stärkt die Vorhersagbarkeit und verbessert die Nutzererfahrung für alle Tastaturnutzer.

Die Umsetzung der WCAG 2.2 Kriterien sollte systematisch erfolgen. In einem ersten Schritt empfiehlt sich ein umfassendes Audit, das den aktuellen Stand gegen alle 2.2-Kriterien prüft. Die Ergebnisse werden in einem priorisierten Maßnahmenplan zusammengefasst, der die kritischsten Probleme zuerst adressiert.

Für die technische Umsetzung empfehlen wir einen komponentenbasierten Ansatz: Jede UI-Komponente wird einzeln gegen die relevanten Kriterien geprüft und bei Bedarf angepasst. Buttons und Links werden auf Target Size geprüft. Formulare werden auf Redundant Entry und Accessible Authentication getestet. Die Navigation wird auf Consistent Help und Focus Not Obscured validiert. Dieser modulare Ansatz ermöglicht eine schrittweise Migration, ohne den laufenden Betrieb zu unterbrechen.

Besonders wichtig ist die Integration der WCAG-Anforderungen in den Entwicklungsprozess. Neue Features sollten von Beginn an gegen WCAG 2.2 entwickelt werden. Code-Reviews sollten Barrierefreiheit als festes Prüfkriterium enthalten. Automatisierte Tests fangen einen Teil der Probleme ab, ersetzen aber nicht die manuelle Prüfung durch geschulte Tester. Unsere Schulungen vermitteln Entwicklern und Designern die notwendigen Kompetenzen für barrierefreie Entwicklung im Alltag.