Mit Interesse habe ich Erik Eggerts Beitrag Do we need WCAG 3 (now)? gelesen und möchte dafür argumentieren, die WCAG 2.x grundlegend zu überarbeiten.
Probleme der WCAG 2.x
Die WCAG 2.x hat mit aus meiner Sicht zahlreichen gravierenden Problemen zu kämpfen, die sie nicht wirklich zukunftsfest macht.
Die WCAG selbst soll technik-agnostisch sein. Allerdings nicht ganz konsequent, da der Begriff „Web“ im Namen steckt. Die WCAG selbst besteht aus etwas kryptischen Erfolgskriterien, die erst im Zusammenspiel mit den „Understanding“ und „How to meet“-Dokumenten wirklich verständlich werden. Ich empfehle meinen Schulungs-Teilnehmerinnen immer zuerst die „Understanding“-Dokumente zu konsultieren, die WCAG selbst ist IMO nur für Expertinnen geeignet. Auch das Zusammenspiel dieser Dokumente untereinander und mit den Techniques ist für Außenstehende nicht immer klar.
Auch das Konformitäts-Modell aus A, AA und AAA ist nicht immer verständlich. Es bleibt mir ohnehin ein Rätsel, warum die WAI nicht einfach einen Filter auf der WCAG-Seite anbietet, um die jeweiligen Erfolgskriterien herauszufiltern. Das müssen Andere machen. Die Begründung, warum bestimmte Kriterien als A, AA oder AAA eingestuft wurden sind nicht immer verständlich.
Auch das Prinzip der vollen Konformität ist überholt. Ich habe das Problem anhand der WebAIM-Analyse ausführlich erklärt. Wenn es fast kein komplexes Angebot gibt, welches vollständig konform ist, dann scheint da irgendwas nicht zu funktionieren. Entweder sind alle zu blöd oder der Aufwand zu Konformität steht in keinem gesunden Verhältnis zum Resultat. Tatsächlich halte ich das Prinzip der vollständigen Konformität für das größte Manko der WCAG, das eher heute als morgen abgeschafft werden sollte. Es ist einer der Gründe für den Erfolg der Accessibility Overlays und unsinniger automatischer Tests wie WAVE.
Die ganz großen wie Amazon, Microsoft, Apple und Google formulieren ohnehin ihre eigenen Standards. Amazon etwa hält sich für barrierefrei, obwohl die Cookie-Message seit Jahren nicht barrierefrei umgesetzt wird. Google macht viele seiner Business-relevanten Programme wie Analytics oder die Search Console nicht barrierefrei und schließt damit Blinde vom Arbeitsfeld SEO und Analytics aus. Microsoft Bing hat es nach X Jahren nicht geschafft, seine Standard-Cookie-Message barrierefrei zu machen.
Auch die Verteilung der Erfolgskriterien erschließt sich nicht unmittelbar. Es gibt zum Beispiel einen Prüfschritt Info and Relationsships, in welchem etwa geprüft wird, ob Überschriften und maschinenlesbare Beschriftungen vorhanden sind. In einem anderen Prüfschritt Headings and Labels wird geprüft, ob die Beschriftungen sinnvoll sind. Es gibt einen Prüfschritt, in welchem das Vorhandensein visueller Beschriftungen geprüft wird und einen weiteren Prüfschritt an einer ganz anderen Stelle, der prüft, ob der maschinen-lesbare Name Teil der visuellen Beschriftung ist. Aus der internen Logik ergibt das Sinn, weil diese Erfolgskriterien jeweils anderen Guidelines zugeordnet sind. Von der Systematik der Prüfung hingegen ist das nicht wirklich sinnvoll. Wenn man sich die Beschriftung anschaut, kann man in einem Schritt prüfen, ob sie sinnvoll, maschinenlesbar, visuell vorhanden, mit dem maschinenlesbaren Namen synonym ist und ob ein Auto Complete wenn nötig vorhanden ist.
Neben sinnvollen Kriterien steckt auch viel Unsinn in der WCAG wie das Language Attribut. Auch die AutoComplete-Anforderung halte ich nicht für sinnvoll: Das kann client-seitig besser gelöst werden.
Generell ein wichtiges Thema ist die Frage der Verständlichkeit: Die WCAG und ihre informativen Understanding, und How-to-meet-Dokumente ist alles Mögliche, aber für Außenstehende verständlich ist sie nicht. Es bleibt die Frage, ob sie ein Expertinnen-Dokument sein soll – was sie defacto heute ist – oder eine Hilfe für Personen, die nicht knietief in der Barrierefreiheit stecken und sie anwenden wollen – das ist sie heute nicht. Im Grunde muss man immer alle 60 AA-Kriterien kennen, um sie anwenden zu können. Aber nebenbei liest sich niemand in 60 Kriterien ein. D.h. im Grunde bräuchte jede Organisation mit einem digitalen Angebot einen Barrierefreiheits-Spezi – absolut illusorisch.
Es ist richtig, dass die WCAG sich bewährt hat. Im Großen und Ganzen dürfte sie die meisten Use Cases abdecken und braucht nicht so viele Updates. Das ist auch gut so, wenn man bedenkt, dass 10 Jahre zwischen 2.0 und 2.1 lagen und inzwischen fast fünf Jahre zwischen 2.1 und 2.2, obwohl es sich jeweils um relativ kleine Änderungen handelt. Viele konkrete Anforderungen werden auch eher in den nicht-normativen Dokumenten wie etwa den ARIA Authoring Practices behandelt, die so scheint es schneller aktualisiert werden.
Andererseits erscheint die WAI wie viele Standardisierungs-Institutionen zu einem bürokratischen Monster zu verkommen. Diese unendlichen Diskussionen sind einerseits erklärbar, wenn man den Impact der Regeln bedenkt – schließlich sind sie für fast jeden auf der Welt, der mit Technik zu tun hat irgendwie relevant. Andererseits kann man mit der Entwicklung nicht Schritt halten. Das ist auch daran erkennbar, dass die WAI wenig zu elektronischen Dokumenten (ausgenommen ePub), nativen Apps und Desktop-Software zu sagen hat und sich praktisch vollständig auf Websites und Web-Anwendungen konzentriert. Es ist richtig, dass Desktop-Software an Relevanz verliert, das gilt aber nicht für native Apps.
Meines Erachtens muss es auch möglich werden, über die WCAG hinauszugehen, ohne vom Kunden gefressen zu werden. Es ist zwar schön, dass die WAI Empfehlungen für die Gestaltung für kognitiv behinderte Menschen gibt, aber nicht so schön, dass Empfehlungen unverbindlich sind.
Das Problem der parallelen Existenz mehrerer Regelwerke lässt sich lösen. Die bisher geplanten Änderungen werden nicht alle alten Regeln über Bord werfen. Das heißt, was WCAG-2.x-AA-konform ist, wird wahrscheinlich auch 3.0-konform sein. Durch Übergangs-Fristen kann für alte Angebote sichergestellt werden, dass sie nach und nach die wenigen neuen Anforderungen erfüllen. Neue Angebote können nach einer gewissen Frist direkt mit 3.0 einsteigen. Auch heute schon existieren WCAG 2.0 und 2.1 parallel. Die 2.2 wird wahrscheinlich ebenfalls parallel zu den beiden anderen existieren, da einige Länder nach wie vor WCAG 2.0 als Standard festgeschrieben haben.
Ist WCAG 3 die Antwort
Aus vielen Erfahrungen haben wir gelernt, dass man die Erwartungen nicht zu hoch hängen sollte. Wir werden so oder so enttäuscht sein. Falls die WCAG 3 überhaupt kommt, woran ich aktuell eher zweifle, wird sie ein paar Probleme lösen und ein paar neue schaffen. Für mich steht allerdings fest, dass die WCAG 2.x aufgrund der oben genannten Probleme im Grunde nicht zukunftsfähig ist. Ich stimme Eggert allerdings zu, dass es schnellere Updates der Dokumente benötigt. Das aktuelle System der WAI zur Aushandlung scheint nicht so wirklich zu funktionieren, so dass man auf aktuelle Entwicklungen nicht gut reagieren kann.