Artikel Wissenswertes über kommende WCAG-Änderungen

Im September 2022 gab das W3C bekannt, dass die nächste Version der WCAG den Kandidatenempfehlungsstatus erreicht hat. Abgesehen von Änderungen in der elften Stunde sollte Version 2.2 des Standards bald ratifiziert werden. Die Änderungen sind relativ geringfügig, aber jeder, der für den Aufbau oder die Wartung einer Website verantwortlich ist, sollte wissen, was kommt.

Wenn Sie bereits mit den WCAG vertraut sind, können Sie die Übersicht überspringen und direkt zu den nerdigen Details springen, andernfalls lesen Sie weiter.

Was sind die WCAG und warum sind sie wichtig?

Die Richtlinien für barrierefreie Webinhalte (WCAG) umfassen eine Reihe von Kriterien, die Webentwicklern, Designern und Inhaltsadministratoren helfen sollen, sicherzustellen, dass ihre Websites für Menschen mit einer Vielzahl von Behinderungen zugänglich sind. Verantwortlich für den Standard ist das Team der Web Accessibility Initiative des W3C. Das W3C und WAI bilden ein Konsortium aus Branchenführern und Fachexperten, die sich darauf konzentrieren, das Internet barrierefreier zu machen.

Die WCAG ist nach vier Zugänglichkeitsprinzipien organisiert. Diese Prinzipien besagen, dass eine Website wahrnehmbar, bedienbar, verständlich und robust sein muss. Innerhalb jedes dieser Prinzipien gibt es Richtlinien, die grundlegende Ziele beschreiben. Innerhalb jeder Richtlinie gibt es Erfolgskriterien, die ein bestimmtes, messbares Ziel beschreiben, das Website-Entwickler erfüllen sollten, um WCAG-konform zu sein.

Die Erfolgskriterien haben jeweils einen Konformitätsgradindikator von A, AA oder AAA. Die Kriterien der Stufe A werden leichter erfüllt, während AAA am strengsten ist.

Werde ich verklagt, wenn meine Website nicht WCAG 2.2 AA-konform ist?

Die endgültige Antwort ist "vielleicht".

In den USA sind die Gesetze mehrdeutig und die ADA geht nicht ausdrücklich auf Websites ein. Während es sehr spezifische Gesetze über die Vorkehrungen gibt, die in einem physischen Raum vorgenommen werden müssen, sagt die ADA, dass das einzige, was direkt auf Websites angewendet werden kann, ist, dass die „Einrichtungen eines Unternehmens zugänglich sein müssen“. Selbst dann sind sich nicht alle Gerichte darüber einig, ob eine Website als Einrichtung eines Unternehmens gilt, und nirgendwo gibt es eine klare Definition von „zugänglich“. Beachten Sie, dass wir über die Websites privater Unternehmen und Bundesgesetze sprechen. Für Websites von Bundes- und einigen Landesregierungen gelten Gesetze.

Da es keine klare Definition von „zugänglich“ gibt, wenden wir uns an die WCAG, um uns zu sagen, was zu tun ist, wenn eine Website erstellt oder gepflegt wird. Keine US-Gesetze empfehlen ausdrücklich eine Version der WCAG (oder eines anderen Standards) für öffentliche Websites. Es ist jedoch ein gutes Ziel, danach zu streben, jede Version der WCAG-Erfolgskriterien zu erfüllen. Es sollte zu einer Website führen, die für alle angemessen zugänglich ist.

Wie werden Standards entwickelt?

Entgegen der landläufigen Meinung wird die Entwicklung von Standards nicht in einem Elfenbeinturm von einer ausgewählten Handvoll von Teilnehmern durchgeführt. Während ein Großteil der Arbeit von Mitarbeitern der Mitgliedsorganisationen geleistet wird, kommt ein großer Teil der Arbeit von eingeladenen Experten und anderen Personen, die sich für das Thema begeistern und bereit sind, Zeit zu investieren. Darüber hinaus haben viele Standardisierungsteams offene öffentliche Foren, in denen Mitglieder der gesamten Community ermutigt werden, sich zu beteiligen, indem sie Fragen stellen oder neue Probleme ansprechen.

Für die WCAG kann die Öffentlichkeit Standards lesen und kommentieren, indem sie ein neues Problem oder eine Pull-Anfrage öffnet oder einfach an den bestehenden Diskussionen im WCAG-Repository auf Github teilnimmt. Wenn Sie mit einer Idee zur Gruppe kommen, ist es immer ratsam, alle vorhandenen Probleme und Pull-Requests zu durchsuchen, um sicherzustellen, dass Ihre Idee nicht bereits auf den Tisch gebracht wurde. Wenn Sie daran denken, mit einem Pull-Request zu den WCAG beizutragen, nehmen Sie sich immer die Zeit, ein Issue zu eröffnen und zuerst Ihre Idee zu diskutieren. Es besteht eine sehr gute Chance, dass Sie sich unnötige Arbeit ersparen.

Zu Standards beizutragen kann frustrierend und schwierig sein, aber es ist auch sehr lohnend. Die meisten Teilnehmer sind sehr freundlich und geduldig. Wenn Sie sich die Zeit nehmen, Ihre Ideen zu recherchieren, Ihre Sorgfalt walten zu lassen und höflich und respektvoll mit anderen umzugehen, dann sind Ihre Beiträge willkommen. Das schlimmste Ergebnis ist, dass Sie sich mit der Materie vertrauter machen, als Sie es jemals für möglich gehalten hätten.

Was ändert sich?

Ein bestehendes Erfolgskriterium wurde in WCAG 2.2 geändert und neun brandneue Erfolgskriterien wurden hinzugefügt. Hier beschränken wir uns auf die Stufen A und AA, da wir selten auf AAA abzielen. Um alle neuen Kriterien zu sehen, lesen Sie den vollständigen Artikel des W3C,

2.4.7 Fokus sichtbar (A)

Dieses Kriterium wurde von Stufe AA auf A geändert, was die niedrigste Messlatte für die WCAG-Konformität darstellt. Ein Teil des Grundes, warum es existiert, ist, dass es in der nicht allzu fernen Vergangenheit eine gängige Praxis für Leute war, die Websites erstellten, um Fokusringe zu entfernen. Schließlich waren sie nicht Teil des Designs. Dies bedeutete, dass Benutzer, die mit ihrer Tastatur auf einer Webseite navigierten, nicht sehen konnten, wo sie sich auf einer Seite befanden. Es ist sinnvoll, dieses Kriterium auf Single-A zu verschieben, da so viele Benutzer auf die Tastaturnavigation angewiesen sind, auch solche ohne jegliche Form von Beeinträchtigung.

Alle gängigen Webbrowser zeigen standardmäßig Fokusringe an. Die wichtigste Anforderung dabei ist, die eingebaute Funktionalität nicht zu unterbrechen.

W3C – Focus Visible verstehen

2.4.11 Fokus-Erscheinungsbild (AA)

Dieses neue Kriterium definiert einige klarstellende Regeln zur Sichtbarkeit von Fokusringen. Sie müssen ein Kontrastverhältnis von 3:1 zu den umgebenden Pixeln und den Pixeln haben, die sie ersetzen. Außerdem müssen sie entweder das fokussierte Element oder die Unterkomponente umschließen oder so groß wie eine 4 Pixel dicke Linie entlang der kürzesten Kante des Elements sein.

Auch hier erfüllen die Standard-Fokusringe des Browsers normalerweise dieses Kriterium. Da Benutzer an die Standardeinstellungen gewöhnt sind, sollten Sie diese nur bei Bedarf überschreiben. Ein Beispiel könnte sein, wenn der Farbkontrast zwischen dem Standard-Fokusring und der Primärfarbe Ihrer Marke unzureichend ist. Browser verwenden normalerweise standardmäßig blaue Fokusringe. Wenn Sie also Blau in der Palette Ihrer Marke haben, kann es zu einem Konflikt kommen.

W3C – Focus Appearance verstehen

2.4.12 Fokus nicht verdeckt (Minimum) (AA)

Dieses Kriterium besagt, dass der Fokus nicht vollständig von nutzergenerierten Inhalten verdeckt werden darf. Dies soll verhindern, dass mehrschichtige Inhalte, wie z. B. eine klebrige Navigation (eine Menüleiste, die beim Scrollen des Benutzers am oberen Rand des Fensters bleibt), Fokusindikatoren verdecken.

Die einfachste Lösung hier ist, einfach keine klebrigen Elemente zu haben. Moderne Websites verwenden jedoch großzügig Sticky-Navigation und Floating-CTAs, sodass dies wahrscheinlich keine Option ist. Es besteht die Erwartung, dass die CSS-Eigenschaften scroll-padding und scroll-margin es uns eines Tages ermöglichen werden, einen Offset zu definieren, der Sticky Nav unterstützt. Derzeit werden diese Eigenschaften ausschließlich für Elemente verwendet, die Scroll-Snap nutzen.

Damit bleiben wir bei JavaScript. Generell ist es unser Ziel, JavaScript im Browser nur bei Bedarf einzusetzen. Diese StickyFix-Funktion überwacht fokussierbare Elemente innerhalb des Hauptelements, und wenn sie durch die Sticky-Navigation verdeckt werden, wenn sie den Fokus erhalten, werden sie in die Ansicht gescrollt.