80/20-Barrierefreiheit

Viele sind durch das BFSG (Barrierefreiheitsstärkungsgesetz) das erste Mal mit dem Thema Web-Zugänglichkeit konfrontiert ¹ und haben regelrecht Angst vor dem Thema, seiner Komplexität und „Konformität“ an sich. Dabei finde ich, dass diese Angststarre gar nicht nötig ist, und das Thema Barrierefreiheit wie so viele Dinge dem Pareto-Prinzip folgt, in seiner großen Mehrheit ein niedrigschwelliges und aktionierbares Thema ist, vor dem man insgesamt keinen lähmenden Respekt haben muss.

Par-was?

Das Pareto-Prinzip ist auch unter dem Namen "80-zu-20-Regel" bekannt und stellt allgemein fest, dass 80% der Ergebnisse häufig mit 20% des Gesamtaufwandes erreicht werden können (mehr zum Prinzip auf Wikipedia). Die verbleibenden 20 % der Ergebnisse würden mit 80 % des Gesamtaufwandes die meiste Arbeit erfordern. Aber auch wenn man das von Vilfredo Pareto etablierte Prinzip auf eine 80-20-Verteilung vereinfacht, bleiben meiner Meinung nach dennoch viele auffällige Parallelen zur Barrierefreiheit übrig.

In meiner Beratungs- und Prüfpraxis laufen mir alle Arten von Barrieren über den Weg und sie lassen sich durchaus in diese beiden Töpfe einordnen. Meine Beobachtung ist also, dass 80% des Themas Barrierefreiheit aus recht einfachen Grundlagen besteht, die man wahrscheinlich in 20% der zur Verfügung stehenden Zeit erlernen kann. Die verbleibenden 20% sind die schwierigen Situationen, Edge Cases, Hilfsmittel-Unterstützungslücken und Ecken des Spezialwissens, die aber auf 100% des Themas hochgerechnet werden und ihm insgesamt einen schlechten, angstauslösenden und schwierigen Ruf verpassen.

Achtzig

Konkret empfinde ich 80% der gefundenen Barrieren in z. B. einem Audit als Aspekte, die einerseits auf einigen wenigen Grundlagen beruhen, andererseits auch einfach zu beheben sind. Einige Beispiele:

• alt-Texte oder -Attribute für Bilder fehlen. Dass man für Nicht-Text-Inhalte eine angemessene textliche Alternativfassung bereithalten muss, ist einerseits das allererste Erfolgskriterium der WCAG, andererseits ein meiner Meinung nach recht einfach zu verstehendes Grundprinzip.
• Kontraste erfüllen nicht die Mindestvorgaben und erschweren deswegen die Wahrnehmbarkeit einer Benutzerschnittstelle. Während automatische Checker nicht alle Fälle erkennen können (z. B. Texte auf Bildern) und in wenigen Fällen auch Dinge falsch einschätzen (false negatives, false positives), sind sie jedoch ein niedrigschwelliger Weg, um mögliche Zugänglichkeits-Probleme schnell zu identifizieren und sich generell mit dem Thema und den Anforderungen vertraut zu machen. Wahrscheinlich ist insgesamt auch hier eine 80-20-Verteilung zu finden.
• An das einfach zu erlernende Grundprinzip „Alles was mit z. B. der Maus bedienbar ist muss auch per Tastatur bedienbar sein“ ist wie ich finde leicht zu verstehen und in der absoluten Mehrheit der Fälle gut umzusetzen. Aus dieser Anforderung erwächst, dass der oder die Tastaturnutzende auch immer wissen muss, wo im Interface man gerade ist (Stichwort: Fokushervorhebung). Sicher, auch hier gibt es eigene 20%, die mit Spezialfällen wie „Drag and Drop“ gespickt sind, aber wenn man das folgende Prinzip verinnerlicht, hat man in der absoluten Mehrheit der Fälle alles richtig und - ohne es zu merken - tastaturbedienbar gemacht:
• Ein weiterer Grundpfeiler von digitalen Dokumenten aller art ist: Verteile auch Metainfos über ein Element, und verlasse dich nicht allein auf seine Optik. Erkläre, was ein Element ist, damit seine Rolle im Kontext eines Gesamtdokumentes klar wird. Wenn das Element interaktiv ist, erkläre, was es bei Interaktion tut und in welchem Zustand es ist. Und dann gestalte es (im Rahmen von Kontrastvorgaben und Konventionen). Dieser Ansatz wird semantisches HTML genannt und hat fast immer² auch eine solide Tastaturbedienung „ab Werk“ eingebaut.

Zwanzig

Aber auch für die herausfordernden 20% will ich Beispiele bringen:

• Manchmal sind ARIA oder ARIA-Muster im Spiel und es ist nicht immer offensichtlich, was genau der richtige Ansatz ist oder wie eine bestimmte Technologie vom assistiven Technologien wie Screenreadern unterstützt wird. Um hier Unterstützung zu erfahren, kann ich das ergiebige Blog von Adrian Rosselli (englisch) empfehlen. Dieser hat einen reichen, testgestützten Fundus an vielen unterschiedlichen Artikeln über Interfaceelemente und Situationen aller Art, und klärt unter anderem auch darüber auf, wie man ARIA verantwortlich nutzt. Die Suchfunktion des Blogs ist hier das A und O.
• Wenn es um die konkrete technische Unterstützung von ARIA-Sonderfällen, -rollen und -eigenschaften geht, bietet a11ysupport.io einen ersten Startpunkt. Es ist nicht ganz mit CanIUse (englisch) zu vergleichen, aber die beste Übersicht von z. B. Screenreader-Unterstützung, die wir aktuell haben.

Ein weitere Idee für die „problematischen 20%“ wäre es, sich hier (bezahlte) Hilfe von Betroffenen und/oder Fachpersonal zu holen. Aber beide Gruppen wären froh, wenn die Organisation, die sie bucht, bereits die Grundlagen kennt, zumeist 80% des Weges zur Zugänglichkeit zurückgelegt haben und somit als Spezialkräfte für die verbleibenden, schwierigeren Barrierefreiheits- oder UX-Kopfnüsse in das Projekt kommen.

Fazit

Es ist nicht wert, nicht die problematischen, etwa 20% der Barrierefreiheit als 100% anzusehen. Dagegen erscheint es mir sinnvoll, die mehrheitlich einfachen Grundprinzipien nachhaltig zu meistern und anzugehen, um damit 80% der Barrieren in seiner eigenen digitalen Oberfläche den Garaus zu machen. Die 20% mögen in vielen Fällen existieren, sollten aber nicht dem Hemmschuh bilden, um das Thema aus einer Angst heraus gar nicht anzugehen oder auf Schlangenöl-Dienstleistungen (englisch) hereinzufallen, die einem das blaue vom Himmel versprechen.