Die WCAG 2.2 kommen – Neuerungen und Änderungen

Die Veröffentlichung der Version 2.1 der Web Content Accessibility Guidelines (WCAG) liegt bald drei Jahre zurück. Tatenlos war die Web Accessibility Initiative (WAI) im World Wide Web Consortiums (W3C) aber nicht – so stehen die WCAG 2.2 gerade in den Startlöchern.

Entsprechend der Versionsnummer sind keine großen Sprünge zu erwarten. Die WCAG behalten mit der Version 2.2 ihre Struktur und das Konformitätsmodell mit den Stufen A (niedrigstes Level), AA und AAA (höchstes Level). Diese konsistente Struktur erlaubt auch, dass die Guidelines damit rückwärtskompatibel sind: Webseiten, die konform mit den WCAG 2.2 sein werden, sind es auch in den Versionen 2.1 oder 2.0. Das ist für Webseiten öffentlicher Stellen bedeutsam, die zur Konformität verpflichtet sind. Mit der Version 2.2 werden die WCAG um neue Richtlinien und Erfolgskriterien ergänzt.

Die Entwürfe der WCAG 2.2 zeigen, was sich ändern wird:

Diese Richtlinie ist nicht neu, sondern verschiebt nur das Erfolgskriterium für einen sichtbaren Tastaturfokus vom Level AA runter zu Level A. Für die Bedienung mit der Tastatur ist es unerlässlich, dass fokussierte Elemente hervorgehoben werden. Praktisch ändert sich in Deutschland aber nicht so viel, weil die BITV ohne das Level AA voraussetzt.

Wie ein sichtbarer Fokus eines Elements genau aussieht, war bislang nicht eindeutig definiert. Mit dieser Änderung wird die WCAG um einen eindeutigen Prüfschritt ergänzt:

• Kontraste für den Farbwechsel: Die Farben zwischen dem fokussierten und nicht fokussierten Zustand sollten ein Kontrastverhältnis von mindestens 3:1 aufweisen.
• Mindestbereiche:
  • Ein Rand um Fokusanzeige muss mindestens einen CSS-Pixel breit sein oder
  • Eine Form entlang der kürzesten Seite muss mindestens acht CSS-Pixel breit sein.
• Kontraste für die angrenzenden Farben: Der Fokus hat ein Mindestkontrastverhältnis von 3:1 zu angrenzenden Farben oder einen Kontrastbereich, der mindestens zwei CSS-Pixel breit ist.
• Sichtbarkeit: Das fokussierte Element ist nicht vollständig hinter von Autor*innen erstellter Inhalte verdeckt.

Auf Webseiten mit Seitenumbrüchen müssen selbige ansteuerbar sein, um beispielsweise die Navigation mit dem Screenreader zu erleichtern.

Neben dem Klicken und Scrollen wurden auch andere Maus- und Touchbewegungen in den letzten Jahren häufiger in Bedienkonzepten vorgesehen. Der Prüfschritt 2.5.7 sieht vor, dass es für die Zieh-Bewegung wie in Slidern, Schiebereglern et cetera aber Alternativen geben muss, wenn die Zieh-Bewegung nicht essentiell ist. Bei Slidern könnte mit einer Paginierung gearbeitet werden, bei Schiebereglern mit nebenstehenden Buttons.

Dieser Prüfschritt hat Auswirkungen auf das UX-Design, denn er schreibt eine Zielgröße von mindestens 24 × 24 CSS-Pixel für Ziele wie Schaltflächen, Links, Eingabefelder und Buttons vor. Davon ausgenommen sind

• Ziele innerhalb eines Textblocks,
• Ziele, die mindestens 24 CSS-Pixel von benachbarten Elementen entfernt und
• Ziele, für welche die Darstellung zum Verständnis einer Information essentiell ist.

Webseiten, die auf mehreren Unterseiten Kontaktangaben oder Hilfestellungen angeben, sollten sie stets auf der gleichen Stelle positionieren – sowohl visuell, als auch im Quelltext der Webseite. Das erleichtert das Zurechtfinden auf der Webseite mit einer kognitiven Einschränkung und macht die Orientierung mittels Screenreader verständlicher.

Für kognitive Funktiontests, wie beispielsweise Rechenaufgaben, muss es in Authentifizierungsverfahren mindestens eine Alternative geben.

Informationen, die zuvor eingegeben oder bereitgestellt wurden, sollten nicht mehrfach von den Anwender*innen eingegeben werden müssen. Ausgenommen sind Prozesse, in denen die erneute Eingabe der Information essentiell ist oder die Sicherheit des Inhalts gewährleistet. Eine weitere Ausnahme gibt es natürlich bei zuvor eingebenen Informationen, die nicht mehr valide sind.

Als Umsetzung der europäischen Norm EN 301 549 sieht Barrierefreie-Informationstechnik-Verordnung (BITV 2.0) hierzulande eine Konformität mit den WCAG 2.1 in der Stufe AA vor. Es bleibt abzuwarten, ob die europäische Norm aktualisiert und die WCAG 2.2 zum neuen Standard erklärt werden.

Die nächste große Aktualisierung der WCAG wird mit der Version 3.0, auch Projekt »Silver«, kommen. Das wird schon oberflächlich deutlich: Das Akronym »WCAG« bleibt, aber wird zukünftig für »W3C Accessibility Guidelines« statt »Web Content Accessibility Guidelines« stehen. Sie werden also nicht mehr explizit auf Internetinhalte beziehen, sondern auch andere Anwendungen. Mit der Beibehaltung der Abkürzung will man den thematischen Bezug und eine Wiedererkennbarkeit behalten. Auch inhaltlich wird man sicher an die vorhergegangenen Versionen anknüpfen, aber eine Rückwärtskompatibilität wird es nicht mehr geben.

Angenommen wird auch, dass die WCAG nach häufiger Kritik verständlicher werden. Ebenfalls wird schon länger kritisiert, dass die WCAG für manche Unternehmen nicht attraktiv genug scheinen, obwohl es auch aus dieser Perspektive gute Gründe gibt, auf die WCAG zu setzen.

Einen ersten Entwurf gibt es bereits seit Anfang 2021, aber mit der Veröffentlichung der finalen WCAG 3.0 ist frühestens Ende 2022 zu rechnen.

Die neuen Prüfschritte sind erwartungsgemäß überschaubar, was den Wert dieser Neuerungen aber keineswegs schmälert. Das Augenmerk der neuen Prüfschritte liegt auf Bedienbarkeit.