Allgemein

Wai und WCAG brauchen eine Revolution


Die Web Accessibility Initiative WAI und die WCAG sind die Säulen der digitalen Barrierefreiheit. Leider sind sie auch ähnlich flexibel wie Säulen, wie ich in diesem Beitrag zeigen möchte.
Eine Warnung vorweg: Dieser Artikel dürfte für Leute nicht interessant sein, die sich nur am Rande mit Barrierefreiheit beschäftigen. Ich kann nicht alle Kontext-Infos einbauen, die zum Verständnis relevant wären. Ansonsten wäre der Artikel noch viel länger geworden.

Einige 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. Ich greife die hier aus meiner Sicht wichtigsten auf.
Bisher war die WCAG recht robust. Allerdings kommt sie aus einem Zeitalter statischer Webseiten und ist für dynamische Anwendungen nicht gerüstet. Zahlreiche Anforderungen wie die von Sehbehinderten, kognitiv Behinderten oder neuro-diversen Personen werden unzureichend abgedeckt. Gleichzeitig erscheint es nicht wünschenswert, die jetzt schon sehr unübersichtlichen Kriterien noch weiter aufzublähen. Wichtige Themen sind zum Beispiel dynamisch generierte Meldungen, Tastenkombinationen (die im Web zu kompliziert sind), mehr Fokus auf Anpassbarkeit und vieles mehr.
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. Das ist informativ, jenes normativ, das gilt für Version X, jenes für Version Y, wer blickt da noch durch.
Auch das Konformitäts-Modell aus A, AA und AAA ist nicht immer verständlich. Die Begründung, warum bestimmte Kriterien als A, AA oder AAA eingestuft wurden sind nicht transparent. Warum ist das wichtige Thema Kontraste erst ab AA verpflichtend?
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. Die volle Konformität ist der Elefant im Raum, über den keine der Expertinnen spricht.
Das Problem ist nicht die Konformität an sich, sondern die unterschiedliche Interpretation durch Expertinnen. Es reicht schon eine Expertin, die sagt, das Kriterium X sei nicht konform, schon ist der ganze Web-Auftritt nicht barrierefrei. Auf Seite X fehlt ein Alternativtext für ein rirrelevantes Bild – der Webauftritt ist nicht konform. Wie soll man das als Dienstleister einem Kunden empfehlen? Es führt zu unzähligen Mikro-Optimierungen mit geringem bis keinem Wert für behinderte Menschen. Aber es ist eine der Haupt-Einnahmequellen für Barrierefreiheits-Experten. Und eine der Gründe, warum viele Developer uns hassen, weil viele Dinge nicht plausibel begründet werden können. Volle Konformität bedeutet nicht, dass eine Web-Anwendung vollständig durch behinderte Menschen bedienbar ist. Halbe Konformität macht eine Anwendung nicht vollständig unbedienbar.
Oft genug sagen wir, dass die WCAG Richtlinien und keine Regeln sind. Dennoch bestehen viele von uns dogmatisch darauf, dass genau unere Interpretation der Richtlinien beim Kunden eingehalten wird. Es ist zu viel Subjektivität und persönlicher Geschmack in den Interpretationen.
Immerhin wurde mit der WCAG 2.2 das Kriterium 4.1.1 Parsing abgeschafft, einer der weniger sinnvollen Kriterien. Leider geht das nur mit Zeitverzögerung in die nationalen Verordnungen ein.
Die ganz großen wie Amazon, Microsoft, Apple und Google formulieren ohnehin ihre eigenen Standards. Amazon Deutschland 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. Und alle feiern sich selbst für ihre Anstrengungen in Sachen Barrierefreiheit.
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 (1.3.5: Identify Input Purpose ) halte ich nicht für sinnvoll: Das kann client-seitig besser gelöst werden. 1.4.10: Reflow fordert, das Inhalt bei 320 Pixel nutzbar ist, eine Breite, die kein aktuelles Smartphone mehr besitzt.
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 A- und 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.
Ein weiteres Beispiel ist die komplizierte Übersetzungs-Politik. Ich war ganz am Rande an der offiziellen deutschen Übersetzung der WCAG 2.1 beteiligt, die es bis heute nicht gibt. Die Übersetzung wurde von kompetenten Leuten kompetent durchgeführt. Bis heute ist mir nicht klar, warum sie abgelehnt wurde, aber das war auch das Ende der Bemühungen der Übersetzung ins Deutsche. So schnell wird es keine neue Übersetzung mehr geben.
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.

Die Web Accessibility Initiative braucht eine Reform

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.
Die 10 Jahre von WCAG 1.0 zu 2.0 waren noch erklärbar. Nicht aber die zehn Jahre von 2.0 zu 2.1 und fünf Jahre von 2.1 zu 2.2. Bedenkt man, dass Behörden mindestens noch einmal fünf Jahre brauchen, um diese Verordnungen in nationales Recht umzusetzen, muss man einfach feststellen, das wir hoffnungslos hinterherhängen.
Die WCAG sollte sich ähnlich dynamisch entwickeln können wie HTML5, um neuen Entwicklungen nicht mehr hinterherzulaufen. Für die lahmen Behörden und alle Anderen könnte man, wie es bei Browsern heute üblich ist, eine stabile Version der Richtlinien anbieten, für die Anderen die WCAG dynamisch weiterentwickeln.
Die Prozesse der WCAG sind pseudo-demokratisch. Ja, jede Person kann sich beteiligen – theoretisch. Praktisch muss man viel Zeit, tiefe technische Kenntnisse, perfektes technisches Englisch und einige weitere eigenschaften haben. Auch der Umgangston in den Mailinglisten ist teils rauh, wenn man nicht Teil der Clique oder wirklich viel Ahnung hat, also nichts für sanfte Gemüter. Ich zweifle nicht daran, dass alle Beteiligten sich viel Mühe geben. Aber jede kann sich beteiligen und einbringen ist etwas Anderes als die Leute offen dazu einzuladen. Im Augenblick ist die WAI kein gutes Beispiel für Inklusion. Sie erinnert an andere ehrwürdige Einrichtungen wie die Wikipedia, wo man erst mal seine Sporen verdienen muss, um überhaupt ernst genommen zu werden. Das Gremium ist für junge Menschen nicht interessant.
In heutigen Zeiten braucht man andere Möglichkeiten der Mitbestimmung, die einerseits diversere Gruppen einbinden, andererseits auch schnellere Entscheidungen ermöglichen. Warum gibt es zum Beispiel kein Wiki, welches die Diskussion niedrig-schwelliger als GitHub machen würde?
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.

Ist WCAG 3 die Antwort

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.
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. Schnellere Updates der Dokumente sind nötig. Das aktuelle System der WAI zur Aushandlung scheint nicht so wirklich zu funktionieren, so dass man auf aktuelle Entwicklungen nicht gut reagieren kann.
Aktuell würde ich keine Wette darauf annehmen, dass es überhaupt eine WCAG 3 gegen wird, eher glaube ich daran, dass George Martin das Lied von Eis und Feuer bis 2030 fertig bekommt.

Zum Weiterlesen