Dieser Blogpost befasst sich mit den WCAG (Web Content Accessibility Guidelines) in der Versionsnummer 3.0. Zum Zeitpunkt des Verfassens liegt diese in einer sehr frühen Vorabversion vor. Bis zur finalen Version wird sich noch viel ändern und konkretisieren. Dennoch schadet es nicht, sich damit zu befassen, wohin die Entwicklung geht. An dieser Stelle möchte ich einen ersten groben Überblick vermitteln.
Der Ist-Zustand
Derzeit gelten die WCAG in der Version 2.0. – wobei mit der Version 2.1 und 2.2 Erweiterungen vorgenommen wurden. In Deutschland sind sie die Grundlage der BITV (Barrierefreie Informationstechnik Verordnung). Die WCAG beschreiben drei Konformitätsstufen: A, AA und AAA. Die BITV legt die mittlere Stufe, also AA zu Grunde.
Was ändert sich?
In der WCAG 3.0 werden die Erfolgskriterien neu strukturiert und benannt. Mit Inkrafttreten gibt es Bronze, Silber und Gold. Bronze entspricht hierbei dem Zustand, der mit einer AA-Konformität vergleichbar wäre. Daran zeigt sich schon, dass die Anforderungen an die Barrierefreiheit potenziell steigen. Durch die neuen Konformitätsstufen soll ein Anreiz gegeben werden, für mehr Barrierefreiheit zu sorgen. Schließlich geben sich die Wenigsten mit einer Bronzemedaille zufrieden. Eine weitere Änderung ist, dass sowohl die ATAG (Authoring Tool Accessibility Guidelines) und die UAAG (User Agent Accessiblity Guidelines) in die WCAG integriert werden. Das schließt beispielsweise die Werkzeuge zum Erstellen von Blogposts wie diesen mit in die Barrierefreiheitsprüfung ein.
Testverfahren
Noch ist nicht ganz klar, wie zukünftige Testverfahren im Einzelnen ausgestaltet werden. Ein paar Erkenntnisse lassen sich aber bereits jetzt aus der Arbeitsvorlage ziehen. Es wird zwei Testverfahren geben. Atomic Testing und Holistic Testing. Vereinfacht gesagt bildet Atomic Testing das ab, was derzeit mit WCAG 2 abgeprüft wird. Grundsätzlich wird es einen Unterschied beim Testen zwischen Views und Processes geben. Ein View, also eine Ansicht, kann dabei eine einzelne Seite, oder beispielsweise eine Grafik sein. Diese Views sind voraussichtlich im Test selbst je nach Anforderung zu definieren. Processes sind spezifische Aufgaben, auf deren Erfüllung geprüft wird. So könnte so ein Prozess beispielsweise beinhalten, einen Artikel in einem Webshop zu suchen, ihn in den Warenkorb zu legen und die Bestellung abzuschließen. Innerhalb dieses Prozesses gibt es verschiedene Ansichten:
- Suchformular
- Suchergebnis-Übersicht
- Artikelseite
- Warenkorb
- Formular zur Eingabe von Adress- und Zahlungsdaten
Oder kurz zusammengefasst: Es wird auf typische Aktionen geprüft, die auf der Plattform durchgeführt werden. Und sowohl der Erfolg oder Misserfolg wird überprüft als auch die Zwischenschritte.
Holistic Testing
Jetzt könnte man meinen, dass damit doch alles abgegolten ist. Wozu also noch ein weiteres Testverfahren? Das Atomic Testing lässt sich zunehmend automatisieren, was klare Schwächen aufweist. Zudem lässt sich dadurch nur Bronze erreichen. Und wir wollen doch alle höher hinaus, nicht wahr? Testet das Atomic Testing vor allem, ob gut genug gearbeitet wurde, so dass von technischer Seite keine gravierenden Mängel auftreten, so nimmt Holistic Testing neben der formalen Barrierefreiheit auch die Nutzbarkeit unter die Lupe. Hier kommen Dinge zum Tragen wie:
- Ist der Text inhaltlich leicht verständlich?
- Ist die Benutzerführung logisch?
- Ist der Aufbau leicht verständlich?
- Ist klar, mit welcher Interaktion welches Ergebnis erzielt wird?
Man setzt hier gezielt auf Tests mit Hilfstechnologien wie z. B. Screenreader. Sowohl das Urteil mit Expertise-Hintergrund als auch das Urteil von "einfachen Nutzenden" findet hier Anwendung. Des Weiteren soll es möglich sein, deutlich mehr Technologien testen zu können. Als Beispiele werden Smart-Home-Produkte und Virtual Reality genannt. Bei diesen Tests kommen dann logischerweise andere Prozesse auf, die barrierefrei gestaltet werden müssen.
Persönliche Anmerkung
Mit den WCAG 3.0 wird eine deutlich breitere Grundlage geschaffen. Diese Grundlage erlaubt es, auch in Zukunft mit der technischen Entwicklung Schritt zu halten. Das bedeutet zumindest in der Theorie, dass es keine Ausrede mehr gibt, Produkte nicht barrierefrei zu gestalten. Zeitgleich wird aber unterschieden, ob es sich bei Fehlern um einen handelt, der den Hauptzweck der Plattform beeinträchtigt oder ob es beispielsweise ein Bild irgendwo im Footer der Plattform ist, das keinen Alternativtext hat. Letzteres beeinträchtigt die Nutzung nicht so sehr wie ein unbeschrifteter Link. Aus Sicht eines Usability-Testers und selbst Betroffenen begrüße ich diese Veränderung der Herangehensweise sehr.
Ausblick
Jetzt muss man aber nicht in Panik geraten. Die WCAG 3.0 sollen erst 2023 fertiggestellt werden. In dieser Zeit wird viel konkretisiert werden. Diese Zeit kann man bereits nutzen, um das Backend barrierefrei zu gestalten und Barrierefreiheit in neuen Projekten von Anfang an zu berücksichtigen. Bis zum 26.02.2021 kann man sich außerdem noch mit Feedback beteiligen. Um noch mehr zu erfahren, ist der Blogartikel beim W3C ein guter Startpunkt.
Über den Verfasser
Dennis Westphal ist Blogautor zu Barrierefreiheitsthemen und Qualitätssicherer bei der Gesellschaft zur Entwicklung von Dingen. Hilfreich bei seiner Arbeit: er ist blind und kann aus der Praxis heraus urteilen.
