Barrierefreiheit ist kein Feature

Der jährliche Global Accessibility Awareness Day ist erst in ein paar Wochen – dieses Jahr feiern wir ihn am 20. Mai 2021 – aber einige neuerliche Diskussionen haben mich dazu gebracht heute zu diesem Thema zu schreiben.

Es ist nicht nur eine Zahl, es sind Menschen!

In einer Diskussion ging es vor Kurzem um die Luca App zur Corona-Kontaktnachverfolgung und mal wieder darum wie wichtig es ist, dass eine solche App barrierefrei sein muss. Ich kann euch gar nicht sagen, wie oft ich Aussagen wie diese schon lesen musste:

  • Nicht unsere Zielgruppe
  • Wir haben kein Budget um die App barrierefrei zu machen
  • Wir machen sie später barrierefrei
  • Für 80% der Menschen ist sie nutzbar
  • Diese 80% sind Beta-Tester der App, danach machen wir sie perfekt
  • Fertig ist besser als perfekt

Einer behauptete sogar, dass die 20%, die die App nicht nutzen können ja einfach jemanden der 80% fragen könne zu helfen und schon wären wir bei 100% Nutzbarkeit für alle. Das ist einfach nicht wahr! Keines dieser Aussagen … nicht einmal das zum Budget!

Wenn ihr über diese 20% sprecht, dann denkt nicht einfach nur an einer Zahl, sondern an die Menschen dahinter. Ihr kennt sicher auch Menschen aus dieser 20% Gruppe, die Probleme haben bestimmte Technologien zu nutzt. Hey, vielleicht gehört ihr in manchen Fällen ja sogar selbst zu dieser Gruppe. Wenn wenn ihr auch nicht als „beeinträchtigt“ anseht, dann stellt euch mal vor ihr müsst eine App nutzen, die es nicht in eurer Sprache gibt und die vielleicht auch noch Zeichen verwendet, die ihr nicht einmal kennt. Aber das ist ja kein Problem, richtig? Ihr kennt ja sicher mindestens eine Person, die diese Sprache kennt und die euch gerne rund um die Uhr für Fragen zur Verfügung steht. Ihr müsst sie dann nur anrufen und den Bildschirm eures Smartphones teilen. Das ist ja auch super einfach, das kann ja wirklich jeder Mensch, und somit kann euch diese eine Person dann sofort helfen. Keine große Sache also, richtig?

Wieso es kein Feature, sondern ein Mindset ist!

Falls ihr zufällig beruflich Apps oder Websites programmiert, dann würdet ihr doch sicher niemals auf die Idee kommen bewusst ein Stück Software zu schreiben, welches unsicher ist, oder? Oder wie wäre es mit einer Website die nicht responsive ist und schlechtes SEO hat? So etwas würdet ihr nie tun, richtig? Aber wie rechtfertigt ihr es dann, dass ihr Software schreibt, die nicht für fast 100% aller Menschen, die darauf angewiesen sind, nutzbar ist? Ist es euch schlichtweg egal? Oder wisst ihr einfach nicht, wie es geht?

Ihr wusstet sicher nicht alles über responsive Websites, als ihr angefangen habt. Vielleicht programmiert ihr ja auch schon so lange Website wie ich, als es eigentlich nur drei Desktop-Auflösungen gab und auch nicht wirklich Elemente auf einer Website, die nicht gepasst hätten. Aber ihr habt euch die Zeit genommen und gelernt, wie man eine Website responsive macht, da ihr euch wohl auch selbst jedes Mal aufgeregt habt, wenn ihr eine Seite besucht habt, die nicht responsive war. Und wisst ihr was? Für diese 20% ist das noch immer bei den allermeisten Seiten so, die sie täglich besuchen. Ihr habt auch vermutlich nur sehr selten bei Budgetverhandlungen argumentieren müssen, dass eine Website responsive sein muss und es wurde eher erwartet, dass diese standardmäßig responsive ist.

Wenn ihr erst einmal ein wenig über barrierefreie Websites (oder Software im Allgemeinen) gelernt habt, dann werdet ihr feststellen, dass es gar nicht so viel mehr Zeit kostet, wenn man es von Anfang an richtig macht. Genau wie bei Sicherheit und Responsiveness muss man einfach von Beginn an ein paar Dinge beachten. Ansonsten wird es sehr schwer und teuer es nachträglich zu verbessern. Und wenn ihr einmal ein Mindest für Barrierefreiheit entwickelt habt, dann macht ihr das fast automatisch … und ihr werdet Gefallen daran finden eine Website oder Software barrierefrei zu machen. Denn eine schlechte, unsichere, unresponsive und nicht barrierefreie Seite können viele erstellen, aber ihr könnt es besser, richtig?

Seid empathisch, seid inklusiv!

Es wird Zeiten geben, in denen ihr selbst zu der 20% Gruppe gehört und dann werdet ihr sehr dankbar dafür sein, dass andere ein klein wenig mehr getan haben, damit das Produkt barrierefreier ist. Ich weiß, dass es einige Dinge gibt, die wirklich schwer barrierefrei umsetzbar sind. Aber vielleicht ist das auch ein gutes Zeichen dafür sich mal zu überlegen, ob es diese Dinge überhaupt braucht. Oder mögt ihr es selbst wirklich, euch auch einer Seite durch unzählige Slider, Akkordeons und Tabs durchzuklicken, statt einfach schnell durch eine etwas längere Seite scrollen und den Inhalt überfliegen zu können, statt ständig hier und da klicken zu müssen? Jedes Mal, wenn ihr also auf etwas stoßt, dass nicht barrierefrei ist und nur schwer verbessert werden kann, dann fragt euch, ob ihr es wirklich braucht. Ich weiß, dass ihr häufig mit solchen „Wünschen“ anderer konfrontriert seid. Aber statt die Zeit zu investieren dafür eine Lösung zu finden ist die Zeit vielleicht besser darin investiert gute Argumente dagegen zu finden. Im schlimmsten Fall könnt ihr mit schlechterer Performance, Sicherheit oder SEO argumentieren. Leider ist das für viele ein wichtigeres Argument als eine bessere Barrierefreiheit. Ich hoffe aber, dass wir alle noch die Zeiten erleben werden, in denen Barrierefreiheit genau so ein „Standard“ wird, wie es die Responsiveness in den letzten Jahren geworden ist. Bis dahin ist es eure Aufgabe die Software einfach dennoch barrierefreier zu machen, ohne es unbedingt zu erwähnen. Nehmt es einfach in einer Entwicklungs-Mindset mit, auch um die Welt für manche Menschen ein wenig besser zu machen. ❤️

Veröffentlicht von

Bernhard ist fest angestellter Webentwickler, entwickelt in seiner Freizeit Plugin, schreibt in seinem Blog über WordPress und andere Themen, treibt sich gerne bei den WP Meetups in Berlin und Potsdam herum und läuft nach Feierabend den ein oder anderen Halbmarathon.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.