Was ist neu in WCAG 2.2: Die 9 neuen Erfolgskriterien erklärt

Web-Accessibility-Standards stehen nicht still. Da sich das Surfverhalten zunehmend auf mobile Geräte verlagert, immer mehr Menschen auf Tastatur- und Sprachnavigation angewiesen sind und die Lücken älterer Richtlinien deutlicher werden, werden die Regeln für barrierefreie Websites aktualisiert, um Schritt zu halten. Die aktuellste dieser Aktualisierungen ist WCAG 2.2(opens in a new tab).

Ein wichtiger Unterschied: WCAG 2.2 ersetzt nicht WCAG 2.0 oder 2.1 – alle drei bleiben aktive Standards. Aber das World Wide Web Consortium (W3C) empfiehlt, auf die neueste Version hinzuarbeiten, da sie auf allem Vorherigen aufbaut.

Für die meisten Organisationen lautet die Frage eher „Was hat sich in WCAG 2.2 geändert und was muss ich tun?“ als „Was ist WCAG 2.2?“. Wenn Sie bereits WCAG 2.1 Level AA erfüllen, sind Sie fast am Ziel: WCAG 2.2 fügt neun neue Erfolgskriterien hinzu und entfernt eines, sodass die Lücke klein, aber spezifisch ist.

Im Folgenden erläutern wir alle neun neuen Kriterien, erklären die Änderungen gegenüber WCAG 2.1 und zeigen, wie Sie prüfen können, wo Ihre Website noch nicht konform ist.

Die Entwicklung der Web Content Accessibility Guidelines

WCAG hat sich seit der ersten Veröffentlichung durch das W3C im Jahr 1999 stetig weiterentwickelt. WCAG 2.0 (erstellt 2008) führte die vier Prinzipien der Web-Accessibility ein und erweiterte die Richtlinien auf alle digitalen Inhalte; WCAG 2.1 (erstellt 2018) ergänzte Kriterien für mobile Geräte und eine größere Bandbreite an Behinderungen; und WCAG 2.2, veröffentlicht im Oktober 2023, fügt die unten behandelten neun neuen Erfolgskriterien hinzu, die sich auf Nutzer mit Sehbehinderung, kognitiven oder Lernbehinderungen und eingeschränkten motorischen Fähigkeiten konzentrieren.

WCAG 2.2: Was ist neu und warum ist es wichtig

Die neun Ergänzungen verteilen sich auf drei Konformitätsstufen: A, AA und AAA, die angeben, wie weit eine Website gehen muss, um konform zu sein, wobei die meisten gesetzlichen und organisatorischen Ziele auf Level AA liegen. Die folgende Übersicht behandelt jedes neue Kriterium: was es verlangt, wem es hilft und warum es in der Praxis wichtig ist.

WCAG 2.4.11: Fokus nicht verdeckt (Minimum) (Level AA)

WCAG 2.4.11(opens in a new tab) verlangt, dass, wenn ein Element Tastaturfokus erhält, mindestens ein Teil davon sichtbar bleibt und nicht vollständig von anderen Inhalten wie Sticky Headers oder Pop-ups verdeckt wird. Für sehende Nutzer, die zur Navigation auf die Tastatur angewiesen sind, ist es entscheidend, den aktuellen Fokus zu erkennen. Allerdings können fokussierte Elemente gelegentlich von anderen Webelementen verdeckt werden.

Das Hinzufügen eines sichtbaren Fokus-Elements kann die Navigation für Nutzer mit kognitiven oder visuellen Einschränkungen verbessern; je sichtbarer der Fokus-Indikator ist, desto leichter können Nutzer beim Navigieren folgen.

WCAG 2.4.12: Fokus nicht verdeckt (Erweitert) (Level AAA)

WCAG 2.4.12(opens in a new tab) geht über 2.4.11 hinaus und verlangt, dass ein tastaturfokussiertes Element vollständig sichtbar ist, ohne dass ein Teil davon von anderen Inhalten auf der Seite verdeckt wird. Dies stellt sicher, dass das fokussierte Element für den Nutzer vollständig sichtbar ist, was die Navigation für Menschen mit eingeschränktem oder schwachem Sehvermögen verbessert. Nutzer mit Aufmerksamkeitsdefiziten (wie Kurzzeitgedächtnisproblemen) können sich ebenfalls besser orientieren, wenn der gesamte Fokus sichtbar ist.

WCAG 2.4.13: Fokus-Erscheinungsbild (Level AAA)

WCAG 2.4.13(opens in a new tab) verlangt, dass Fokus-Indikatoren groß genug sind und mindestens einen Farbkontrast von 3:1 zwischen fokussiertem und nicht fokussiertem Zustand aufweisen, sodass Nutzer klar erkennen können, welches Element im Fokus ist. Beispielsweise erscheint beim Fokussieren eines Links eine Umrandung. Die Farbe dieser Umrandung sollte ausreichend Kontrast zur Hintergrundfarbe der Seite haben.

Sicherzustellen, dass Fokus-Indikatoren ausreichend Farbkontrast haben, gewährleistet, dass Nutzer kleine Änderungen im Erscheinungsbild leicht erkennen können. Dies ist besonders für ältere Menschen oder Tastaturnutzer hilfreich, da sie ihre Position auf einer Seite beim Navigieren leicht verfolgen können.

WCAG 2.5.7: Ziehbewegungen (Level AA)

WCAG 2.5.7(opens in a new tab) verlangt, dass jede durch Ziehen ausgeführte Aktion auch eine Alternative mit einem einzelnen Zeiger hat, wie z. B. Tippen oder einen Bildschirm-Button, es sei denn, Ziehen ist wesentlich. Beispielsweise könnte eine Website ermöglichen, mit den Pfeiltasten der Tastatur oder mit Bildschirm-Buttons einen Schieberegler zu bewegen oder eine Liste zu sortieren. So wird sichergestellt, dass Nutzer, die Schwierigkeiten mit Ziehbewegungen haben oder diese nicht ausführen können, trotzdem mit Drag-and-Drop-Oberflächen arbeiten können.

WCAG 2.5.8: Zielgröße (Minimum) (Level AA)

WCAG 2.5.8(opens in a new tab) verlangt, dass klickbare Ziele mindestens 24x24 CSS-Pixel groß sind oder ausreichend Abstand zu anderen Elementen haben, um versehentliche Aktivierungen zu verhindern. Wenn Buttons und andere klickbare Elemente zu klein sind, fällt es Menschen mit Zittern oder anderen feinmotorischen Einschränkungen schwer, sie zu aktivieren, ohne versehentlich ein anderes Element zu treffen.

Diese neue Anforderung ermöglicht es Menschen mit feinmotorischen Einschränkungen, Buttons leichter zu klicken. Sie verbessert auch das mobile Nutzungserlebnis, da Nutzer genügend Abstand haben, um kleinere Buttons auszuwählen.

WCAG 3.2.6: Konsistente Hilfe (Level A)

WCAG 3.2.6(opens in a new tab) verlangt, dass Hilfemechanismen wie Kontaktdaten oder eine Chat-Option auf jeder Seite, auf der sie angeboten werden, in derselben relativen Reihenfolge erscheinen. Wenn eine Website beispielsweise eine „Chat“-Option hat, sollte diese in der rechten unteren Ecke jeder Seite erscheinen. Oder Kontaktdaten, einschließlich Telefonnummer, Öffnungszeiten oder E-Mail-Adresse, werden im Footer jeder Seite aufgeführt.

Durch die konsistente Platzierung hilfreicher Informationen am selben Ort können Menschen, die Schwierigkeiten haben, Hilfe zu finden oder sich zu merken, wo Informationen stehen, diese leichter auffinden.

WCAG 3.3.7: Doppelte Eingabe (Level A)

WCAG 3.3.7(opens in a new tab) verlangt, dass Informationen, die ein Nutzer in einem Prozess bereits eingegeben hat, automatisch ausgefüllt oder zur Auswahl angeboten werden, anstatt erneut abgefragt zu werden. Das erspart Nutzern wiederholte Eingaben, verringert die Fehlerwahrscheinlichkeit und reduziert den Bedarf an Texteingaben.

WCAG 3.3.8: Barrierefreie Authentifizierung (Minimum) (Level AA)

WCAG 3.3.8(opens in a new tab) verlangt, dass Logins nicht von einem kognitiven Funktionstest(opens in a new tab) abhängen, wie z. B. das Merken eines Passworts oder das Lösen eines Rätsels, es sei denn, es gibt eine alternative Methode oder Unterstützung. Dies vereinfacht den Authentifizierungsprozess für Menschen mit kognitiven Einschränkungen und ermöglicht ihnen eine Authentifizierung auf eine für sie passende Weise. Ein Mechanismus, der dabei helfen kann, ist die Nutzung von Passwortmanagern. Diese können den Erinnerungsaufwand und das erneute Eintippen von Informationen verringern.

WCAG 3.3.9: Barrierefreie Authentifizierung (Erweitert) (Level AAA)

WCAG 3.3.9(opens in a new tab) wendet dieselbe Regel wie 3.3.8 an, aber strenger, indem Objekterkennung oder vom Nutzer bereitgestellte Inhalte (wie ein hochgeladenes Bild) als Authentifizierungsmodelle ausgeschlossen werden. So wird sichergestellt, dass Nutzer mit kognitiven Problemen im Zusammenhang mit Gedächtnis, Lesen (z. B. Legasthenie), Zahlen oder Wahrnehmungsverarbeitung sich einfach anmelden oder authentifizieren können.

Was entfernt wurde: 4.1.1 Parsing

WCAG 2.2 hat ein Kriterium entfernt, 4.1.1 Parsing, und damit erstmals ein Erfolgskriterium aus den Richtlinien gestrichen. Das Kriterium verlangte ursprünglich sauberes, wohlgeformtes HTML-Markup, aber das W3C stellte fest, dass es überholt ist, da moderne Browser und Hilfstechnologien die damit verbundenen Fehler inzwischen problemlos verarbeiten.

Das Entfernen bedeutet nicht, dass gültiges HTML keine Rolle mehr spielt; gut strukturierter Code bleibt für Barrierefreiheit wichtig und ist weiterhin gute Praxis. Die praktische Auswirkung ist gering: Wenn Ihr automatisierter Test zuvor Parsing-Fehler als WCAG-Verstoß markiert hat, zählen diese spezifischen Fehler nicht mehr gegen die 2.2-Konformität.

WCAG 2.2 vs. WCAG 2.1: Was hat sich wirklich geändert

WCAG 2.2 ist eine Obermenge von WCAG 2.1: Es behält jedes Erfolgskriterium aus 2.1 bei, außer dem entfernten 4.1.1 Parsing, und fügt neun neue hinzu. Die praktische Konsequenz ist entscheidend: Wer WCAG 2.2 erfüllt, erfüllt auch 2.1 – es gibt also keinen Nachteil, auf die neuere Version zu setzen. Wenn Sie bereits WCAG 2.1 Level AA erfüllen, besteht die eigentliche Lücke nur in den sechs neuen Kriterien der Level A und AA; die drei Level-AAA-Ergänzungen sind optional. Kurz gesagt, der Wechsel von 2.1 zu 2.2 ist kein kompletter Umbau – sondern eine kurze, klar definierte To-do-Liste.

WCAG 2.2 Checkliste (Level AA)

Wenn Sie bereits WCAG 2.1 Level AA erfüllen, sind dies die sechs neuen Kriterien, die Sie für WCAG 2.2 Level AA umsetzen müssen. Die drei Level-AAA-Ergänzungen (2.4.12, 2.4.13 und 3.3.9) sind optional.

• Tastaturfokus bleibt sichtbar (2.4.11): Tabben Sie durch jede Seite und stellen Sie sicher, dass das fokussierte Element nie vollständig hinter Sticky Headers, Cookie-Bannern oder Pop-ups verborgen ist.

• Ziehen hat eine Alternative (2.5.7): Bieten Sie für jede Drag-and-Drop-Aktion (Schieberegler, Sortierung, Kartensteuerung) eine Option mit einem einzelnen Zeiger an, z. B. Tippen oder Bildschirm-Buttons.

• Ziele sind groß genug (2.5.8): Stellen Sie sicher, dass klickbare Elemente mindestens 24×24 CSS-Pixel groß sind oder genügend Abstand haben, damit benachbarte Ziele nicht versehentlich getroffen werden.

• Hilfe ist konsistent (3.2.6): Platzieren Sie Hilfemechanismen (z. B. Kontaktlinks, Chat, Supportinfos usw.) an derselben relativen Stelle auf jeder Seite, auf der sie angeboten werden.

• Nicht nach denselben Infos fragen (3.3.7): Füllen Sie Informationen automatisch aus oder lassen Sie Nutzer Daten wiederverwenden, die sie bereits im selben Prozess eingegeben haben, außer eine erneute Eingabe ist zwingend erforderlich.

• Logins erfordern kein Gedächtnis oder Rätsel (3.3.8): Bieten Sie eine barrierefreie Alternative, wenn für die Authentifizierung ein kognitiver Funktionstest wie das Merken eines Passworts oder das Lösen eines CAPTCHAs erforderlich ist.

Mehrere dieser Kriterien – Fokus-Sichtbarkeit, konsistente Hilfe und barrierefreie Authentifizierung – können nicht vollständig durch automatisierte Tools geprüft werden. Ein kostenloser Accessibility-Scan ist ein schneller Weg, um zu sehen, wo Ihre Website aktuell steht.

Wie AudioEye die WCAG 2.2-Konformität vereinfacht

WCAG 2.2 hat die Barrierefreiheit geschärft, statt sie neu zu erfinden, und neun gezielte Kriterien hinzugefügt, die echte Lücken für Nutzer schließen, die mit Tastatur navigieren, sich einloggen oder mobile Geräte nutzen. Die Herausforderung für die meisten Organisationen ist es, zu überprüfen, ob die eigene Website tatsächlich konform ist – und sie es bleibt, während sich die Standards weiterentwickeln.

Hier kommt der richtige Ansatz ins Spiel: Mehrere WCAG 2.2-Kriterien, darunter Fokus-Sichtbarkeit, konsistente Hilfe und barrierefreie Authentifizierung, können nicht allein durch Automatisierung bestätigt werden.

Die AudioEye-Plattform ist genau für diese Kombination gebaut. AudioEye hilft Organisationen, WCAG 2.2 Level AA zu erfüllen, indem automatisierte Korrekturen im großen Maßstab mit zertifizierten Experten und Tests durch die Behinderten-Community kombiniert werden, um die Kriterien zu prüfen, die die Automatisierung allein nicht bestätigen kann. Und mit kontinuierlichem Monitoring wird Ihre Website bei jeder Änderung geprüft und Probleme werden schneller behoben – so bleiben Sie mit WCAG auf dem neuesten Stand, nicht nur dort, wo Sie heute stehen.

Bereit herauszufinden, wie Ihre Website im Vergleich zu WCAG 2.2 abschneidet? Nutzen Sie den free Website Accessibility Checker. Oder vereinbaren Sie eine Demo, und wir zeigen Ihnen, wie AudioEye Ihnen hilft, Barrierefreiheitsstandards zu erfüllen und diese langfristig einzuhalten.