Barrierefreiheit: Über WCAG Level, Scores und Panikmache

Meiner Meinung nach bist du mit dem WCAG Level AA schon ganz gut dabei. Tatsächlich bezieht sich die EN 301 549 größtenteils auch „nur“ auf die WCAG. Allgemeine Best Practices zu berücksichtigen ist natürlich immer gut. 

Ich vergleiche das gerne mit dem Thema Test-Coverage. Ein anderes Ziel als 100 % Test-Coverage ergibt keinen Sinn. Sagen wir 80 % oder doch 90 %? Damit trifft man dann aber auch umgekehrt die Aussage, dass es in Ordnung ist, wenn 10 oder 20 % des Codes nicht funktionieren. Weil, das ist ja das, was Tests aussagen. Und das ist eine Aussage, die vernünftigerweise niemand unterschreiben würde. Gleichzeitig ist aber auch klar, dass 100 % Test-Coverage nie erreicht werden können. Der Aufwand und auch die Laufzeit der Tests wäre enorm. Ich nenne das gerne ein „asymtotisches Ziel“, also ein Ziel, dem wir versuchen uns anzunähern, es aber nicht erreichen werden. 

Beim Thema Barrierefreiheit wird man realistisch gesehen auch nie 100%ig perfekt sein. Trotzdem sollten wir versuchen, jeden Tag besser zu werden. 

Wenn einem bewusst ist, dass man nie 100 % echte Barrierefreiheit erreichen wird, ist Barrierearmut eigentlich das bessere Wort. Der Einfachheit halber sprechen wir im Deutschen trotzdem meistens von Barrierefreiheit. Tatsächlich finde ich den englischen Begriff Accessibility (abgekürzt A11y) hier etwas besser; die wörtliche deutsche Übersetzung Zugänglichkeit fühlt sich aber etwas sperrig an, macht jedoch klar, dass es sich eher um eine Skala als um ein absolutes Ziel bzw. einen erfüllt- / nicht-erfüllt-Wert handelt. 

Eine 100%ige Barrierefreiheit ist tatsächlich auch nicht vorgeschrieben. Deswegen gibt es unter anderem die Barrierefreiheitserklärung und die Konformitätsstufen der WCAG; die gesetzlichen Richtlinien beziehen sich auf Stufe AA (nicht AAA). Für Unternehmen oder Vereine mit bestimmten Zielgruppen ist es natürlich trotzdem sinnvoll, sich auch die Stufe AAA anzuschauen, das sind aber Ausnahmen. 

Zum Thema Kompromisse beim Design: Ich habe im Herbst auf dem WP Accessibility Day einen sehr guten Talk »Accessible Firebrand« (englisch) dazu gesehen. Auch die anderen Talks vom WP Accessibility Day lohnen sich (nicht abschrecken lassen von WP, die Talks sind alle recht allgemein gehalten). 

Diese Antworten waren bis jetzt alle recht unkonkret und irgendwie unbefriedigend, das ist mir bewusst. Versuchen wir mal, das in den Alltag zu übersetzen. Eigentlich geht es hier ja nicht um Gesetze, sondern um Menschen und darum, Menschen mit Einschränkungen den Zugang zu Produkten und Dienstleistungen zu ermöglichen – Zugänglichkeit eben. Also … 

Zunächst würde ich darauf achten, dass die Website grundsätzlich nutzbar und keine totale Katastrophe ist. In kurz: Fehler und Warnung nach WCAG Level A sollte es nicht geben! Ganz wichtig an der Stelle ist aber auch: automatisierte Tests können nicht alles erkennen. Es ist daher immer wichtig auch manuell zu testen: Funktioniert die Website auch nur über die Tastatur? Was macht ein Screenreader aus der Website? Das ist aus meiner Sicht das Must-Have für alle Websites. 

Und dann ist es wichtig, dass die Haupt-Use-Cases und User-Flows für die Website funktionieren, also z. B. die Kontaktaufnahme oder Bestellung oder das Einsehen der Öffnungszeiten beim lokalen Bäcker. Ob die dritte Unterseite der Firmengeschichte auch perfekt ist, ist dann zwar wünschenswert, aber nicht kritisch. Da gilt es also „die Kirche im Dorf“ zu lassen und ein Gefühl zu entwickeln. Ich definiere mit meinen Kunden etwa 3 bis 5 Flows, die optimiert werden sollen und schaue mir diese dann fokussiert an. Dabei fixed man oft „aus Versehen“ auch andere Issues. 

Mit der Kombination aus einem automatischen Scan, wie ihn der Barriere-Checker macht, und manuellem Testen mit Tastatur und Screen-Reader erreicht man schon sehr viel. Mein Tipp: Klein Anfangen und nicht vor dem großen Berg in Panik geraten. Jeder kleine Schritt hilft! Ja, es sind gerade viele Unsicherheiten und Panikmache in der Branche. Ich finde das sehr schade, weil dabei der eigentlich gute Gedanke hinter dem Thema oft untergeht. 

Und: Awareness schaffen bei den Redakteuren im CMS. Auch diese haben einen großen Einfluss. 

Übrigens: Warum von besserer Barrierefreiheit alle profitieren, habe ich bereits in einem weiteren Artikel im Blog dargestellt. Vielleicht hilft das auch in der Kommunikation mit Kunden. Denn bei allen technischen Details ist es vor allen Dingen wichtig, dass das Verständnis wächst und alle zur Erkenntnis kommen, dass barrierefreie Websites einfach für alle User Vorteile bieten.