Was ist neu in WCAG 2.2: Änderungen und Updates gegenüber WCAG 2.1

Die Web Content Accessibility Guidelines(opens in a new tab) (WCAG) bieten einen Rahmen für die Erstellung digitaler Inhalte, die für alle Nutzer zugänglich und mit wichtigen Gesetzen zur Barrierefreiheit konform sind. Die Einhaltung der WCAG stellt sicher, dass jeder Ihre digitalen Inhalte nutzen kann, erweitert Ihre Zielgruppe und reduziert rechtliche Risiken.

Da sich die Barrierefreiheitsbranche und die Technologie ständig weiterentwickeln, werden auch die WCAG-Richtlinien regelmäßig angepasst. Die neueste Version, veröffentlicht im Oktober 2023, fördert die Standards für digitale Barrierefreiheit. Im Folgenden erläutern wir, was neu ist in WCAG 2.2 und wie Sie diese Updates auf Ihre digitalen Inhalte anwenden können.

Eine Reihe von vier Barrierefreiheitssymbolen, die in die Ferne verlaufen, vor einem Regenbogen-Farbverlauf.

Was ist WCAG 2.2?

Herausgegeben vom World Wide Web Consortium(opens in a new tab) (W3C), sind die WCAG internationale Standards, die erklären, wie Websites und digitale Inhalte für Menschen mit Behinderungen zugänglich gemacht werden können. Das W3C veröffentlichte die WCAG-Standards erstmals am 5. Mai 1999. Mit der Weiterentwicklung digitaler Erlebnisse aktualisiert das W3C die Richtlinien auf Basis gründlicher Überprüfungen, zahlreicher Überarbeitungen und öffentlicher Rückmeldungen(opens in a new tab). Seit der Veröffentlichung hat das W3C drei Versionen der Richtlinien angekündigt, die jeweils auf der vorherigen Version aufbauen.

Jede Version der WCAG enthält Erfolgskriterien, die in drei Konformitätsstufen:

• Stufe A: Die Mindestanforderung an die Konformität, Stufe A, enthält grundlegende Erfolgskriterien zur Beseitigung schwerwiegender Barrieren, die eine breite Nutzergruppe betreffen.

• Stufe AA: Die Erfolgskriterien der Stufe AA beseitigen zusätzliche Barrieren und stellen ein Maß an Barrierefreiheit her, das für die meisten Nutzer mit Behinderungen und unterstützenden Technologien, einschließlich Screenreadern, funktioniert.

• Stufe AAA: Die strengste Konformitätsstufe, Stufe AAA, enthält zusätzliche Erfolgskriterien für das höchstmögliche Maß an Barrierefreiheit. Die Konformität mit Stufe AAA bedeutet, dass Ihre Website alle WCAG-Erfolgskriterien erfüllt.

Barrierefreiheitssymbol mit der Beschriftung 2.1 neben einem Barrierefreiheitssymbol mit der Beschriftung 2.2

Was ist der Unterschied zwischen WCAG 2.1 und 2.2?

Der Hauptunterschied zwischen WCAG 2.1 und WCAG 2.2 liegt im Fokus. Ab Oktober 2025 ist WCAG 2.2 der aktuelle W3C-Standard für Barrierefreiheit(opens in a new tab), und legt mehr Wert auf Nutzbarkeit – insbesondere für Tastaturnavigation, Touch-Interaktionen und kognitive Barrierefreiheit – während die bestehenden Anforderungen aus WCAG 2.1 erhalten bleiben.

Die neuen Erfolgskriterien von WCAG 2.2 adressieren häufige Barrieren, denen Nutzer in digitalen Erlebnissen begegnen, darunter verdeckte Fokusindikatoren, ausschließliches Drag-and-Drop, kleine Touch-Ziele, inkonsistente Hilfeplatzierung und nicht barrierefreie Authentifizierungsprozesse.

Diese Updates verbessern die Barrierefreiheit auf Websites, in mobilen Apps, Online-Dokumenten und anderen digitalen Inhalten, während sie weiterhin mit den vier Prinzipien der WCAG übereinstimmen: Inhalte müssen wahrnehmbar, bedienbar, verständlich und robust sein.

Es ist auch wichtig zu beachten, dass WCAG 2.2 nicht frühere Versionen der Richtlinien ersetzt. Alle Erfolgskriterien aus WCAG 2.1 (und WCAG 2.0) bleiben unverändert und voll anwendbar, WCAG 2.2 baut lediglich darauf auf.

Neue Erfolgskriterien in WCAG 2.2 erklärt

Mit einem besseren Verständnis der Unterschiede von WCAG 2.2 zu früheren Versionen betrachten wir nun die neuen Kriterien in WCAG 2.2(opens in a new tab).

2.4.11 Fokus nicht verdeckt (Minimum)

Dieses Kriterium(opens in a new tab) stellt sicher, dass ein visueller Tastaturfokus-Indikator (wie ein Rahmen oder eine Hervorhebung) für Nutzer teilweise sichtbar ist. Ein Fokusindikator sorgt dafür, dass Nutzer das fokussierte Element, wie Buttons oder Links, finden und bedienen können.

Beim Design mit festen Kopfzeilen, Sticky-Elementen oder Modalen muss sichergestellt werden, dass der Tastaturfokus nicht hinter überlagernden UI-Elementen verschwindet. Entwickler können JavaScript verwenden, um Elemente mit ‘.scrollIntoView({block:"nearest"})’ oder ähnlichen Methoden in den sichtbaren Bereich zu scrollen. CSS sollte ebenfalls vermeiden, feste Layouts zu verwenden, die interaktive Elemente überdecken, ohne sie dynamisch neu zu positionieren.

2.4.12 Fokus nicht verdeckt (Erweitert)

Aufbauend auf der Mindestanforderung verlangt das erweiterte Kriterium(opens in a new tab) noch robustere visuelle Indikatoren für Fokuszustände. Das gesamte fokussierte Element muss vollständig sichtbar sein und darf in keiner Weise verdeckt werden. Dies ermutigt Designer, deutlich hervorgehobene Elemente zu verwenden, um die Sichtbarkeit und Klarheit fokussierter Elemente zu verbessern.

Um diese Anforderung zu erfüllen, sollten Entwickler Oberflächen gestalten, die das fokussierte Element immer vollständig in den sichtbaren Bereich scrollen. Vermeiden Sie teilweise Sichtbarkeit oder überlappende UI-Komponenten. Verwenden Sie JavaScript wie ‘.scrollIntoView({block:"center"})’ oder implementieren Sie eigene Scroll-Logik, die ein vollständig sichtbares Fokusziel in allen Ansichten und Ausrichtungen sicherstellt.

2.4.13 Fokus-Erscheinungsbild

Das Kriterium 2.4.13(opens in a new tab) verlangt, dass der sichtbare Indikator für jedes UI-Element Mindestanforderungen an Größe und Kontrast erfüllt. Indikatoren müssen mindestens so groß sein wie ein 2 Pixel breiter Rahmen um das Element und müssen einen Kontrast von mindestens 3:1 zu angrenzenden Farben aufweisen.

Beim Erstellen von Fokusindikatoren sollten sichtbare Fokus-Stile verwendet werden, die sich nicht nur auf dezente Umrandungen oder Schatten verlassen. Beispielsweise erfüllt eine 2-Pixel-dicke, durchgehende Umrandung mit ausreichendem Farbkontrast oder eine Hintergrundhervorhebung die Konformitätsstandards. Vermeiden Sie außerdem das Entfernen von Fokus-Umrandungen mit ‘outline: none’, es sei denn, es wird eine zugänglichere Alternative eingesetzt.

2.5.7 Ziehbewegungen

Das Kriterium 2.5.7(opens in a new tab) verlangt, dass Ziehbewegungen, die von Nutzern ausgeführt werden, barrierefrei gestaltet sind. Wenn ein Nutzer beispielsweise ein Element zieht, um es neu anzuordnen, oder mit einem Schieberegler interagiert, sollten alternative Methoden (wie Buttons) für diejenigen bereitgestellt werden, die diese Aktion nicht ausführen können.

Entwickler sollten sicherstellen, dass diese Bewegungen alternative Eingabemethoden wie Tastaturinteraktion (z. B. Pfeiltasten oder Buttons zum Verschieben von Elementen) oder Texteingabe unterstützen. Nutzer können beispielsweise Pfeile anklicken, um ein Listenelement nach oben oder unten zu verschieben, anstatt Drag-and-Drop zu benötigen. Dies unterstützt Menschen mit eingeschränkter Motorik, die Schwierigkeiten mit präzisen Zeigerbewegungen haben.

2.5.8 Zielgröße (Minimum)

Interaktive Elemente wie Buttons und Links müssen eine Mindestzielgröße(opens in a new tab) haben, damit sie leicht angetippt oder angeklickt werden können. Größere Ziele verringern die Fehlerwahrscheinlichkeit und verbessern das Erlebnis für Nutzer unterstützender Technologien. Das Erfolgskriterium empfiehlt, dass interaktive Ziele mindestens 24 x 24 CSS-Pixel groß sind, sofern nicht ausreichend Abstand oder bestimmte Ausnahmen vorliegen.

Um diese Anforderung zu erfüllen, stellen Sie sicher, dass Tipp- und Klickziele entweder direkt oder durch Polsterung die Mindestgröße erreichen. Sind Ziele kleiner, sollte ein Mindestabstand von 24 Pixeln zwischen ihnen bestehen, um versehentliche Aktivierung zu vermeiden. Verwenden Sie Media Queries und CSS, um Zielgrößen für mobile und Touch-Oberflächen anzupassen, ohne das Layout zu stören.

3.2.6 Konsistente Hilfe

Konsistente Hilfe(opens in a new tab) bezieht sich auf die Notwendigkeit, Hilfs- und Unterstützungsfunktionen wie Hilfemechanismen oder FAQ-Bereiche an vorhersehbaren Stellen auf Ihrer Website bereitzustellen (sofern der Nutzer die Platzierung nicht selbst ändert). Diese Konsistenz hilft Nutzern, Hilfeoptionen schnell zu finden und sich leichter zurechtzufinden – besonders für Menschen mit kognitiven Einschränkungen.

Um konform zu sein, stellen Sie sicher, dass Hilfemechanismen wie Live-Chat-Buttons, Support-Kontaktlinks oder FAQ-Zugänge auf allen relevanten Seiten konsistent platziert sind – sowohl visuell als auch programmatisch. Reihenfolge und Position sollten innerhalb von Navigationsbereichen statisch bleiben, es sei denn, der Nutzer passt sie an. Konsistenz in Beschriftung und Positionierung ermöglicht es insbesondere Menschen mit kognitiven Einschränkungen, vorherzusehen, wo Hilfe verfügbar ist.

3.3.7 Doppelteingabe vermeiden

Wenn Nutzer Informationen in mehreren Feldern eingeben müssen, verlangt das Erfolgskriterium 3.3.7(opens in a new tab) mehrere Mechanismen zur Minimierung von Doppeleingaben. Informationen, die der Nutzer bereits in derselben Sitzung eingegeben hat, sollten nicht erneut eingegeben werden müssen, es sei denn, dies ist aus Sicherheitsgründen erforderlich, die erneute Eingabe ist vom Nutzer gewünscht oder die Information ist nicht mehr gültig.

Zur Einhaltung müssen Techniken wie Session Storage oder clientseitiger Speicher eingesetzt werden, um Nutzereingaben über einen mehrstufigen Prozess hinweg zu erhalten. Gibt ein Nutzer beispielsweise seine Adresse auf einer Seite eines Bestellformulars ein, sollten diese Daten auf Folgeseiten automatisch ausgefüllt werden. Das reduziert unnötige Wiederholungen, was besonders für Menschen mit Gedächtnis- oder Mobilitätseinschränkungen hilfreich ist.

3.3.8 Barrierefreie Authentifizierung (Minimum)

Barrierefreie Authentifizierung(opens in a new tab) verlangt, dass alle Formen der Nutzer-Authentifizierung (wie Login-Felder) so gestaltet sind, dass sie Menschen mit Behinderungen berücksichtigen. Dazu gehören verschiedene Eingabemethoden, klare Fehlermeldungen, Authentifizierungsprozesse und Unterstützung bei der Passwortwiederherstellung, damit Nutzer ohne Barrieren auf ihre Konten zugreifen können.

Zur Erfüllung dieser Anforderung sollten Authentifizierungsmethoden entwickelt werden, die die kognitive Belastung reduzieren, z. B. durch Zulassen von Kopieren und Einfügen in Passwortfeldern, Integration von Passwortmanagern und Passwort-lose Login-Optionen (z. B. einmalige Passcodes per E-Mail). Wird ein CAPTCHA verwendet, muss eine alternative Verifizierungsmethode angeboten werden, die keine Aufgabe erfordert, die auf Gedächtnis, Mustererkennung oder Interpretation basiert.

3.3.9 Barrierefreie Authentifizierung (Erweitert)

Der erweiterte Standard für barrierefreie Authentifizierung(opens in a new tab) baut auf den Basisanforderungen auf und verlangt, dass keine kognitiven Funktionstests für Authentifizierungsschritte erforderlich sind, es sei denn, es gibt eine Alternative, die keine kognitiven Fähigkeiten voraussetzt.

Um diese Anforderung vollständig zu erfüllen, verzichten Sie möglichst auf klassische Passwörter und Sicherheitsfragen. Bieten Sie stattdessen Alternativen wie biometrische Logins, sichere Authentifizierungslinks per E-Mail oder SMS oder die Erkennung vertrauenswürdiger Geräte. So können Menschen mit kognitiven Einschränkungen sich selbstständig authentifizieren, ohne Informationen erinnern oder entschlüsseln zu müssen.

Justizwaage mit WCAG 2.2 und WCAG 2.1 Symbolen

Welche WCAG-Version sollten Sie befolgen?

Zum Zeitpunkt dieses Artikels sollten Organisationen die Standards aus WCAG 2.2 Stufe AA einhalten, um Gesetze wie das Americans with Disabilities Act(opens in a new tab) (ADA), Section 508 oder das Accessibility for Ontarians with Disabilities Act(opens in a new tab) (AODA) zu erfüllen. Diese Richtlinien adressieren viele der frustrierendsten Barrieren, darunter:

• Fehlende Alternativtexte (oder Alt-Texte) bei Bildern oder anderen nicht-textlichen Inhalten, was Menschen mit Sehbehinderungen wie Blindheit oder Sehschwäche betrifft.

• Fehlende Videountertitel, Audiodeskriptionen oder Transkripte, was Menschen mit Hörbehinderungen, Lernbehinderungen und neurokognitiven Einschränkungen betreffen kann.

• Fehlende Überschriften, Unterüberschriften und Title-Tags, was das Surfen für Screenreader-Nutzer erschwert.

• "Tastaturfallen", die Inhalte für Menschen, die keine Maus zur Navigation verwenden, unbenutzbar machen können.

Die Einhaltung der WCAG 2.2-Standards ermöglicht es Ihnen, mit wichtigen Gesetzen zur Barrierefreiheit konform zu bleiben und sich auf zukünftige Versionen wie WCAG 3.0 vorzubereiten.

Der erste Schritt zur WCAG-Konformität: Testen Sie Ihre Inhalte

Da sich die Standards für Barrierefreiheit weiterentwickeln, hilft frühzeitiges Handeln, Risiken zu minimieren und bessere Erlebnisse für alle zu schaffen. Die oben genannten Hinweise bringen Sie in eine hervorragende Position, um die WCAG 2.2-Standards zu erfüllen.

AudioEye macht den nächsten Schritt einfacher. Unsere Accessibility Platform kombiniert automatisierte Tests mit Expert Audits und findet sowie behebt Barrierefreiheitsprobleme, damit Sie ein zugänglicheres und konformes Online-Erlebnis schaffen. Der Prozess beginnt mit unserem kostenlosen Web Accessibility Checker, der auf 32 WCAG-Verstöße prüft (mehr als jedes andere Tool auf dem Markt). Diese Probleme werden automatisch durch unsere automatisierten Korrekturen behoben und ebnen so den Weg zu mehr Barrierefreiheit.

Bereit für den nächsten Schritt? Scannen Sie jetzt Ihre Inhalte oder vereinbaren Sie eine Demo und sehen Sie, wie AudioEye die WCAG-Konformität schneller und effizienter unterstützt.