Was WCAG 2.2 für Ihre Website bedeutet

Nach zwei Jahren des Sammelns von Feedback hat das World Wide Web Consortium (W3C) die Web Content Accessibility Guidelines (WCAG) 2.2(opens in a new tab) als offizielle Empfehlung veröffentlicht – und damit neue Kriterien für Unternehmen geschaffen, die weiterhin gesetzeskonform bleiben möchten, etwa im Hinblick auf das Americans with Disabilities Act (ADA).

Bemerkenswert ist, dass Unternehmen, die bisher die WCAG 2.1 Level AA-Standards erfüllten, unter WCAG 2.2 möglicherweise nicht mehr konform sind – und es ist wahrscheinlich, dass sich diese Anforderungen in den kommenden Jahren erneut ändern werden. Das bedeutet, dass zusätzliche Tests und Einblicke von zertifizierten Barrierefreiheitsexperten erforderlich sind, um die Einhaltung sicherzustellen.

Im Folgenden geben wir einen Überblick über die neuen Kriterien und Tipps, wie Unternehmen feststellen können, wo ihre digitalen Inhalte nicht mehr konform sind. Außerdem zeigen wir, wie AudioEye diesen Prozess vereinfacht und es Organisationen leicht macht, die sich entwickelnden Barrierefreiheitsstandards zu erfüllen.

Die Entwicklung der Web Content Accessibility Guidelines

Ursprünglich 1999 eingeführt, war WCAG 1.0 der erste Schritt zur Festlegung von Barrierefreiheitsrichtlinien für das Web. Die ursprünglichen Richtlinien konzentrierten sich hauptsächlich auf HTML und umfassten 14 Leitlinien.

Die nächste Version, WCAG 2.0, wurde 2008 erstellt und erweiterte den Anwendungsbereich auf die vier Prinzipien der Web-Barrierefreiheit. WCAG 2.0 wurde nach erheblichen technologischen Veränderungen eingeführt und galt für alle digitalen Inhalte, einschließlich Dokumenten und mobilen Apps.

WCAG 2.1 wurde im Juni 2018 veröffentlicht und baut auf den Prinzipien von WCAG 2.0 auf. Es war ein willkommenes Update, da WCAG 2.0 neuere technologische Entwicklungen und Webnutzung nicht mehr abdecken konnte. Die neuen Richtlinien enthalten mehrere neue Erfolgskriterien zur Verbesserung der Barrierefreiheit auf mobilen Geräten.

Dies führt uns zum Oktober 2023, als die neueste Version von WCAG veröffentlicht wurde. Die Richtlinien umfassen neun neue Erfolgskriterien, die sich speziell auf die Unterstützung von Nutzern mit Sehbehinderung, kognitiven oder Lernbehinderungen und eingeschränkten motorischen Fähigkeiten konzentrieren.

Da WCAG als Goldstandard für Web-Barrierefreiheit gilt, verlangt Abschnitt 508 des Rehabilitation Act von Bundesbehörden die Einhaltung von WCAG 2.0 A/AA. Für private Unternehmen hat das Justizministerium (DOJ) erklärt, dass zur Einhaltung des Americans with Disabilities Act (ADA)(opens in a new tab) Organisationen den WCAG-Empfehlungen entsprechen müssen.

Ein Diagramm, das die drei Konformitätsstufen von WCAG zeigt: Level A, Level AA und Level AAA.

WCAG 2.2: Was ist neu und warum ist es wichtig?

Wie oben erwähnt, enthält WCAG 2.2 neun neue Erfolgskriterien, die auf den 78 Erfolgskriterien von WCAG 2.1 aufbauen. Jedes dieser Erfolgskriterien trägt dazu bei, die digitale Barrierefreiheit für drei Hauptgruppen zu verbessern: Nutzer mit kognitiven oder Lernbeeinträchtigungen, Nutzer mit Sehbehinderung und Nutzer mit Behinderungen auf mobilen Geräten.

Die neueste Version der Barrierefreiheitsrichtlinien hat auch ein älteres Kriterium entfernt, das nun veraltet ist: WCAG 4.1.1: Parsing. Dies ist das erste Mal, dass ein Erfolgskriterium aus den Richtlinien entfernt wurde – ein Beweis für die Anpassungsfähigkeit der Richtlinien an aktuelle digitale Trends.

Wie bei früheren Versionen sind die neuen Kriterien in drei Konformitätsstufen unterteilt: A, AA und AAA. Laut der kürzlich veröffentlichten Bekanntmachung des DOJ zum Thema Barrierefreiheit von Websites nach Titel II des ADA müssen Unternehmen die WCAG 2.X Level AA-Standards erfüllen.

Mit diesem Wissen wollen wir uns die neuen Kriterien ansehen und wie jedes einzelne dazu beiträgt, Barrierefreiheitsprobleme zu adressieren.

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

Für sehende Nutzer, die zur Navigation auf Websites auf die Tastatur angewiesen sind, ist es entscheidend zu wissen, welches Element gerade im Fokus ist. Allerdings können fokussierte Elemente gelegentlich von Sticky-Headern, Pop-ups und anderen Inhalten auf dem Bildschirm verdeckt werden.

Wenn eine Benutzeroberflächenkomponente den Tastaturfokus erhält, schreibt WCAG 2.4.11(opens in a new tab) vor, dass ein Teil davon sichtbar bleiben und nicht von anderen Inhalten auf dem Bildschirm verdeckt werden darf. Dies kann die Navigation und den Fokus für Nutzer mit kognitiven oder visuellen Beeinträchtigungen verbessern; je sichtbarer der Fokusindikator ist, desto leichter können Nutzer beim Navigieren auf Webseiten folgen.

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

WCAG 2.4.12(opens in a new tab) folgt denselben Richtlinien wie das vorherige Kriterium; der entscheidende Unterschied ist jedoch, dass kein Teil des Fokusindikators von anderen Inhalten auf der Seite verdeckt werden darf. So ist das fokussierte Element vollständig sichtbar, was die Navigation für Menschen mit eingeschränktem oder schwachem Sehvermögen verbessert. Auch Nutzer mit Aufmerksamkeitsdefiziten (wie z. B. Kurzzeitgedächtnisproblemen) können sich leichter orientieren, wenn der gesamte Fokus sichtbar ist.

WCAG 2.4.13: Fokus-Erscheinungsbild (Level AAA)

Fokusindikatoren heben das Element auf einer Webseite hervor, das aktuell im Fokus steht. WCAG 2.4.13(opens in a new tab) verlangt, dass Fokusindikatoren einen ausreichenden Farbkontrast aufweisen (mindestens 3:1 zwischen denselben Pixeln im fokussierten und nicht fokussierten Zustand) und groß genug sind, um klar sichtbar zu sein. Beispielsweise wird beim Fokussieren eines Links eine Umrandung um den Link angezeigt. Die Farbe dieser Umrandung sollte einen ausreichenden Kontrast zur Hintergrundfarbe der Seite haben.

Ein ausreichender Farbkontrast der Fokusindikatoren stellt sicher, dass Nutzer kleine Änderungen im Erscheinungsbild leicht erkennen können. Dies ist besonders für ältere Menschen oder Tastaturnutzer hilfreich, da sie so leichter verfolgen können, wo sie sich auf einer Seite befinden.

WCAG 2.5.7: Ziehbewegungen (Level AA)

Drag-and-Drop kann für viele Menschen umständlich und fehleranfällig sein, egal ob sie eine Tastatur verwenden, eine Mobilitätseinschränkung haben oder auf angepasste Eingabegeräte wie Kopfzeiger oder sprachgesteuerte Maus-Emulatoren angewiesen sind.

WCAG 2.5.7(opens in a new tab) verlangt, dass Ziehbewegungen nicht die einzige Möglichkeit sind, wesentliche Aktionen auf einer Seite auszuführen – egal, ob es um das Bedienen eines Sliders oder das Umordnen von Komponenten in einer Drag-and-Drop-Oberfläche geht.

Eine Website könnte beispielsweise die Bedienung per Tastatur mit den Pfeiltasten ermöglichen oder Bildschirmtasten bereitstellen, mit denen Nutzer einen Slider bewegen oder eine Liste sortieren können. So können auch Menschen, die Schwierigkeiten mit Ziehbewegungen haben oder diese nicht ausführen können, die Drag-and-Drop-Oberfläche nutzen.

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

Wenn Schaltflächen und andere anklickbare Elemente zu klein sind, ist es für Menschen mit Zittern oder anderen feinmotorischen Einschränkungen schwierig, sie zu aktivieren, ohne versehentlich ein anderes Element auszulösen.

WCAG 2.5.8(opens in a new tab) verlangt, dass alle anklickbaren Elemente (wie Call-to-Action-Buttons) mindestens 24 x 24 CSS-Pixel groß sind. Außerdem müssen Websites mindestens 24 CSS-Pixel Abstand zwischen benachbarten Zielen einhalten.

Dieses Kriterium bietet eine Level-AA-Alternative zu WCAG 2.5.5: Zielgröße(opens in a new tab), einer Level-AAA-Anforderung, die mit WCAG 2.1 eingeführt wurde und eine Zielgröße von mindestens 44 x 44 CSS-Pixeln für alle anklickbaren Elemente verlangt.

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

WCAG 3.2.6: Konsistente Hilfe (Level A)

Wenn Hilfefunktionen oder Hilfemechanismen – wie die Kontaktdaten einer Website oder ein Self-Service-Chatbot – auf mehreren Seiten einer Website verfügbar sind, verlangt WCAG 3.2.6(opens in a new tab) deren Platzierung an derselben relativen Stelle und in derselben Reihenfolge auf jeder Seite, auf der sie erscheinen.

Wenn eine Website beispielsweise eine ‚Chat‘-Option hat, sollte diese in der rechten unteren Ecke jeder Seite erscheinen. Oder Kontaktdaten wie Telefonnummer, Öffnungszeiten oder E-Mail-Adresse werden im Footer jeder Seite aufgeführt.

Durch die konsistente Platzierung hilfreicher Informationen an derselben Stelle finden Menschen, die Schwierigkeiten haben, Hilfe zu finden oder sich zu merken, wo Informationen stehen, diese leichter.

WCAG 3.3.7: Doppelte Eingabe (Level A)

Manche Formulare verlangen von Nutzern, dieselben Informationen mehrmals einzugeben, was für Menschen mit motorischen Einschränkungen belastend sein kann. Auch für Menschen mit kognitiven Beeinträchtigungen kann es schwierig sein, sich zu merken, welche Informationen sie bereits eingegeben haben.

WCAG 3.3.7(opens in a new tab) verlangt, dass Websites Felder automatisch ausfüllen oder Nutzern erlauben, bereits eingegebene Daten wiederzuverwenden. Das erspart wiederholte Eingaben, senkt die Fehlerwahrscheinlichkeit und reduziert den Bedarf an Texteingaben.

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

Das Ziel von WCAG 3.3.8(opens in a new tab) ist es, Menschen mit kognitiven Beeinträchtigungen eine einfache, barrierefreie Möglichkeit zu bieten, sich auf Websites und in Apps anzumelden. Wird ein kognitiver Funktionstest(opens in a new tab) – wie das Merken eines Passworts oder das Erkennen von Bildern oder Zeichen – eingesetzt, muss die Website mindestens eine weitere Authentifizierungsmethode anbieten.

Dadurch wird der Authentifizierungsprozess für Menschen mit kognitiven Einschränkungen vereinfacht und sie können sich entsprechend ihrer individuellen Bedürfnisse anmelden. Ein Mechanismus, der dabei helfen kann, ist die Nutzung von Passwort-Managern. Diese reduzieren den Erinnerungsaufwand und die Belastung durch wiederholtes Eintippen.

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

Ähnlich wie das vorherige Kriterium ist WCAG 3.3.9(opens in a new tab) darauf ausgelegt, den Login-Prozess für Menschen mit kognitiven Einschränkungen zu vereinfachen. Dieses Kriterium geht jedoch noch einen Schritt weiter und erlaubt keine Authentifizierung mittels Objekterkennung oder nutzereigener Inhalte, wie z. B. ein vom Nutzer hochgeladenes Bild. So wird sichergestellt, dass Nutzer mit Gedächtnis-, Lese- (z. B. Legasthenie), Zahlen- oder Wahrnehmungsproblemen sich einfach anmelden oder authentifizieren können.

Ist WCAG eine gesetzliche Anforderung?

Bemerkenswert ist, dass mehrere neue Erfolgskriterien von WCAG 2.2 manuelle Tests erfordern, um sie zuverlässig zu identifizieren – was unterstreicht, dass Unternehmen automatisierte Tests durch manuelle Prüfungen von zertifizierten Barrierefreiheitsexperten und Nutzern assistiver Technologien ergänzen sollten.

Bei AudioEye arbeiten wir mit über 80 Mitgliedern der Community von Menschen mit Behinderungen (bekannt als AudioEye A11iance) zusammen, um Kundenwebsites auf WCAG-Probleme zu prüfen. Zur Vorbereitung auf die Veröffentlichung von WCAG 2.2 haben unsere Tester mit den neuesten WCAG-Kriterien und Behebungsstrategien trainiert.

Möchten Sie wissen, wo Ihr Unternehmen möglicherweise nicht den neuesten WCAG-Standards entspricht? Vereinbaren Sie eine kostenlose Beratung und besprechen Sie die Barrierefreiheit Ihrer Website sowie wie AudioEye Ihnen helfen kann, Barrierefreiheitsprobleme an der Quelle zu erkennen und zu beheben.

Schritte, um sicherzustellen, dass Ihre Website den WCAG 2.2-Standards entspricht

Auch wenn Ihre Organisation verpflichtet ist, die Standards von WCAG 2.0 oder 2.1 zu erfüllen, wird empfohlen, sich an die neuen WCAG-Standards zu halten. So verbessern Sie die Barrierefreiheit Ihrer Website und zeigen Ihr Engagement für ein zugängliches, inklusives Erlebnis.

Nachfolgend finden Sie drei Möglichkeiten, wie Sie die WCAG 2.2-Standards auf Ihrer Website umsetzen können.

Führen Sie ein Barrierefreiheitsaudit durch

Der erste Schritt zur Integration der WCAG 2.2-Kriterien ist ein Audit Ihres aktuellen Systems. So erkennen Sie bestehende Barrierefreiheitsprobleme und erhalten eine Ausgangsbasis für die Umsetzung von WCAG 2.2. Ein Accessibility Checker wie AudioEye kann Sie dabei unterstützen.

Setzen Sie Änderungen basierend auf den Audit-Ergebnissen um

Sobald Sie die Ergebnisse des Audits erhalten haben, beginnen Sie mit der Umsetzung der Änderungen. Wir empfehlen, mit kleineren Problemen zu starten – wie das Beheben defekter Links oder das Hinzufügen von Alternativtexten zu Bildern – bevor Sie größere Themen angehen.

Beziehen Sie zertifizierte Barrierefreiheitsexperten für manuelle Tests ein

Automatisierte Barrierefreiheitsplattformen können nur gängige Barrierefreiheitsprobleme erkennen. Komplexere Probleme wie schlecht formulierte Alternativtexte oder geringe Kompatibilität mit Tastatur- oder assistiven Technologien werden nicht erkannt. Manuelle Tests können diese Probleme nicht nur aufdecken, sondern auch Empfehlungen zur Behebung geben.

Beispielsweise nutzt die Digital Accessibility Plattform von AudioEye automatisierte Tests, um gängige Barrierefreiheitsprobleme zu erkennen und bietet automatische Korrekturen an. Alles, was nicht durch unsere automatisierte Lösung behoben werden kann, wird von unserem Team aus menschlichen Testern durch individuelle Anpassungen gelöst.

Ein hybrider Ansatz beim Barrierefreiheitstest verbessert die Gesamtbarrierefreiheit Ihrer Website und sorgt für ein besseres, inklusiveres Erlebnis.

Eine stilisierte Webseite mit mehreren Barrierefreiheitsfehlern, markiert durch Ausrufezeichen, neben einem grünen Barrierefreiheitssymbol.

Wie AudioEye die WCAG 2.2-Konformität vereinfacht

Da sich die WCAG-Standards ständig weiterentwickeln, müssen Organisationen ihre Websites kontinuierlich auf Barrierefreiheitsfehler oder WCAG-Verstöße überwachen und testen. So wird die Barrierefreiheit der Website verbessert und die Einhaltung gesetzlicher Anforderungen unterstützt.

Bei AudioEye stellen wir sicher, dass Ihre Website die neuesten WCAG-Standards sowohl durch automatisierte als auch durch Experten-Tests eines Teams von Barrierefreiheitsexperten erfüllt. Wir arbeiten außerdem mit über 80 Mitgliedern der Community von Menschen mit Behinderungen (AudioEye A11iance) zusammen, um individuelle Expertentests von Websites durchzuführen. Jeder unserer Tester wurde auf die neueste Version der WCAG-Standards geschult, um sicherzustellen, dass Websites die aktuellen Erfolgskriterien erfüllen.

Das Beste an der Zusammenarbeit mit AudioEye? Sie müssen Änderungen nicht selbst nachverfolgen – wir übernehmen das für Sie! Unsere Expert Audits testen Ihre Website regelmäßig, um Barrierefreiheitsprobleme zu finden und zu beheben, bevor sie Ihre Kunden beeinträchtigen.

Bereit, zu sehen, wie konform Ihre Website ist mit den WCAG 2.2-Standards? Vereinbaren Sie eine kostenlose Demo mit AudioEye und sehen Sie, wie wir Ihren Weg zur Barrierefreiheit vereinfachen können.