Muss das wirklich sein? Warum Barrierefreiheit bei Software allen nutzen kann

Jeder, der bereits an (Web-)Projekten mitgearbeitet hat, wird die folgende Diskussion kennen:

„Muss die Anwendung accessible sein?“ „Nein, zum Glück nicht!“

Accessibility im Web – was heißt das?

„Das Web ist an seiner Basis so gestaltet, dass es für alle Menschen nutzbar ist, unabhängig von ihrer Hardware, Software, Sprache, Kultur, Ort, physischen oder kognitiven Fähigkeiten. Wenn eine Website dieses Ziel erfüllt, dann ist sie zugänglich für ein breitestmögliches Spektrum an Menschen mit unterschiedlichsten Fähigkeiten zu hören, zu sehen, zu verstehen oder sich zu bewegen.“

Aktion Mensch [https://www.einfach-fuer-alle.de/artikel/einfuehrung-barrierefreiheit/]

Was heißt das konkret? Menschen können technisch, geistig oder körperlich eingeschränkt sein. Wenn für sie digitale Informationen genauso leicht zugänglich sind, wie für Menschen ohne diese Einschränkungen, sprechen wir von Barrierefreiheit – oder Accessibility.

Theorie versus Praxis: Beispiele aus dem Projektalltag

In der Praxis gibt es einige Argumente, mit denen das Ignorieren von Accessibility gerechtfertigt wird:

  • „Wir kennen die Endgeräte unserer User*innen.“
  • „Wir kennen unsere User*innen. Die haben Accessibility nicht nötig.“
  • „Accessibility ist zu teuer.“
  • „Wir bauen das später ein.“

Diese Aussagen ergeben in der Regel keinen Sinn. Warum, erläutere ich im Folgenden.

Argument gegen Accessibility 1: Wir kennen die Endgeräte unserer User*innen.

Dieses Argument wird insbesondere gerne bei internen Unternehmensanwendungen angeführt. Die Theorie dahinter klingt zunächst einmal einleuchtend: Das Unternehmen stattet die Arbeitsplätze der Angestellten mit Hard- und Software aus und kann so vorgeben, welches Betriebssystem, welcher Browser, welche Bildschirmauflösung und so weiter, verwendet werden.

Was ist aber, wenn plötzlich besondere Umstände eintreten, die diese Kontrollmöglichkeit verhindern? Mir fiele da zum Beispiel spontan eine Pandemie ein, die dafür sorgt, dass von heute auf morgen alle Leute im Homeoffice arbeiten müssen! Plötzlich werden die unterschiedlichsten Geräte, Betriebssysteme, Bildschirmauflösungen et cetera genutzt. Es wäre doch äußerst praktisch, wenn die Mitarbeiter*innen weiterhin arbeitsfähig blieben. Auch wenn sie zuhause ein Macbook mit dem Safari-Browser nutzen, statt eines Windows-Rechners mit Edge-Browser.

Argument gegen Accessibility 2: Wir kennen unsere User*innen. Die haben Barrierefreiheit nicht nötig.

Das Problem bei dieser Aussage ist, dass es nicht DEN User oder DIE Userin gibt. Insbesondere ist das bei externen Anwendungen der Fall, die potenziell von jedem beliebigen Menschen auf der Welt verwendet werden können. Aber auch bei internen Anwendungen ist die Frage, wer denn der Beispiel-User oder die Beispiel-Userin ist? Ist es der 60-jährige Mitarbeiter oder seine 25-jährige Kollegin? Welche Einschränkungen und Voraussetzungen haben die beiden? Während der Kollege eine Brille trägt und somit offensichtlich ein eingeschränktes Sehvermögen besitzt, ist die Kollegin dem Anschein nach kerngesund. In Wahrheit ist sie aber farbenblind – das ist für den Arbeitgeber ohne weiteres schwer erkennbar.

Selbst wenn es hypothetisch betrachtet, Pauschal-Benutzer*innen gäbe, wäre dies nur eine Momentaufnahme. Wie entscheiden Unternehmen, die neues Personal einstellen möchten, wenn die geeignete Bewerberin eine Einschränkung hat und somit auf Accessibility angewiesen ist? Wird sie nicht eingestellt, weil sie die Anwendung nicht benutzen kann?

Nicht der Mensch muss sich den Gegebenheiten anpassen – die Gegebenheiten müssen sich dem Menschen anpassen: Inklusion ist das Mittel der Wahl.

Argument gegen Accessibility 3: Barrierefreiheit ist zu teuer.

Semantisch korrektes HTML zu verwenden, erzeugt keinen Mehraufwand. Wenn beispielsweise eine Navigation benötigt wird, empfiehlt sich ein nav-Element statt eines div-Elements. Technisch macht das keinen Unterschied, semantisch jedoch schon, sodass nun auch Screenreader den Quellcode entsprechend interpretieren können. Für jedes Element ist genau definiert, wie es zu verwenden ist. Technisch kann man viel Schindluder treiben und beispielsweise ausschließlich div-Elemente verwenden. Allerdings ergibt das keinen Sinn, es sei denn, es sollen möglichst viele Leute von der Nutzung der Anwendung ausgeschlossen werden.

Nicht bei jeder Entwicklung muss das Rad neu erfunden werden. So gibt es beispielsweise (CSS-)Bibliotheken, die dazu beitragen können, dass viele Accessibility-Standards von Grund auf eingehalten werden (Elemente funktionieren auch bei 200-Prozent-Zoom, es gibt passende Farbkontraste, passende Schriftgrößen und -arten, vernünftige Abstände usw.).
Daneben gibt es auch Test-Tools, um sicherzustellen, dass möglichst viele der Standards eingehalten werden. Natürlich können diese Tools im Rahmen ihrer Möglichkeiten nur „harte“ messbare Standards, wie etwa den Farbkontrast, prüfen. Bei den „weicheren“ Kriterien, wie sinnvoller Gruppierung von zueinander gehörigen Informationen, stoßen diese Tools in der Regel an ihre Grenzen, da sie dafür den Kontext verstehen müssten.
Aber wenn alle Softwareentwickler*innen allein die harten Standards einhalten würden, wären wahrscheinlich schon die Hälfte aller Accessibility-Probleme gelöst. Für den Rest reicht dann gesunder Menschenverstand.

Im Übrigen kommen auch nicht eingeschränkten User*innen Entscheidungen für Barrierefreiheit bei Anwendungen zugute. So hilft es wohl jedem Menschen, wenn Informationen auf einer Seite strukturiert, sinnvoll gruppiert und ohne viel „Schnickschnack“ angezeigt werden. Anstatt, dass sich Nutzer*innen diese Informationen selbst mühevoll auf diversen Unterseiten nach aufwendigen Ladeanimationen zusammensuchen müssen.

Selbst wenn Accessibility teurer wäre als das Verzichten auf Barrierefreiheit, würde der Nutzen die Kosten eindeutig überwiegen.

Argument gegen Accessibility 4: Wir bauen das später ein.

Leute, die sagen, dass Accessibility später eingebaut wird, sagen auch:

  • „Security bauen wir später ein“
  • „(Automatisierte) Tests schreiben wir später“
  • „Das Versions-Upgrade machen wir später“

Was haben diese Aussagen gemein? Meist wird es eben später doch nicht gemacht, weil es ja auch ohne funktioniert.

Eine Analogie aus dem Hausbau: Nehmen wir an, dass wir ein Haus bauen wollen, in dem in erster Linie Senioren leben werden. Wir wissen, dass viele Menschen im Alter, früher oder später, motorisch eingeschränkt sind und dann beispielsweise auf einen Rollstuhl angewiesen sind. Wie würden wir das Haus bauen?
Es wäre ratsam, bereits bei der Planung darauf zu achten, dass breite Türen verwendet werden, die Dusche ebenerdig erreichbar ist, eventuell Platz für einen Treppenlift vorhanden ist, das Haus mittels einer Rampe erreichbar ist und so weiter und so fort.
Natürlich kann das Haus zunächst gebaut werden, ohne diese Besonderheiten zu beachten. Erst, wenn es nötig ist, wird es entsprechend umgebaut. Dadurch wird der Bau aber deutlich komplexer, umständlicher und teurer, als wenn die Gegebenheiten von Anfang an eingeplant werden.

Diese Analogie lässt sich fast eins zu eins auf die Softwareentwicklung übertragen: Bei einer Anwendung, die, ohne auf Accessibility zu achten, entwickelt wird, kommt der nachträgliche Einbau im schlimmsten Fall einer Neuentwicklung gleich, da zu viele Anpassungen erfolgen müssen. Daher am besten: Barrierefreiheit im Web oder bei Software von Beginn an beachten und keine faulen Ausreden suchen.

Accessibility ist mit technischen Mitteln ausgedrückte Inklusion. Sie nutzt jedem Menschen. Berücksichtigt sie in euren Projekten!

Jetzt teilen auf:

Jetzt kommentieren