Das Internet soll ein Ort sein, an dem sich alle begegnen können, egal wo sie wohnen, wie sie aussehen oder welche Einschränkungen sie haben – zumindest theoretisch. Die Realität sieht aber oft immer noch anders aus. Denn häufig werden Menschen mit körperlichen Einschränkungen dabei schlichtweg übersehen; und so ist der Zugang zum World Wide Web leider für viele Betroffene immer noch voller Stolpersteine.
Anschauliche Beispiele sind die visuellen Elemente von Webseiten wie auch die Bedienbarkeit abseits von Computermaus oder Trackpad. Wer sich einmal kurz vorstellt, auf einer Website nur über Tastenkürzel navigieren zu müssen, kommt als normaler Anwender schon meist an seine Grenzen. Dabei entspricht selbst diese Vorstellung meist noch nicht der wahren Herausforderung, der sich viele Betroffene tagtäglich stellen müssen.
Um auf Webseiten besser navigieren zu können braucht es beispielsweise ein auf die jeweilige Behinderung abgestimmtes Hilfsmittel. Das können zum einen softwarebasierte Hilfen im Browser sein, um Internetseiten zu vergrößern, sie mit der Tastatur oder per Touchscreen zu bedienen oder ähnliches. Zum anderen gibt es aber auch Hilfsmittel, die als zusätzliche Hard- oder Software angeschlossen oder installiert werden müssen, um dem Nutzer den Zugang zu ermöglichen. Hierbei muss der Browser mit diesen zusätzlichen Geräten oder Software kompatibel sein. Dabei hilft es, wenn die verschiedenen Zielgruppen an der Entwicklung des Browsers direkt beteiligt sind und ihre Erfahrung einfließen lassen können.
Bei Mozilla haben wir hierfür beispielsweise eine eigene Community namens A11y mit hunderten Freiwilligen, die ganz spezielle Bedürfnisse bei der Nutzung und Entwicklung des Webs haben: A11y (sprich Elli und kurz für Accessibility, also Zugänglichkeit) ist ein bekanntes Web-Numeronym, das sich darauf bezieht, wie der Mensch mit der Maschine interagiert – speziell in Sachen Barrierefreiheit.
Einige Mitglieder der Mozilla-A11y-Community haben Behinderungen, etwa eine Sehschwäche oder Einschränkungen des Bewegungsapparates. Das tägliche Surfen im Netz ist für sie meist leider eine Herausforderung. Das A11y-Team arbeitet deshalb daran, das Web barrierefrei zu machen und entwickelt außerdem den Barrierefreiheitsinspektor mit. Damit lassen sich Webseiten auf verschiedene Ansprüche hin überprüfen und so schon im Zuge der Programmierung verbessern.
Webseiten müssen hörbar sein
Für mich als blinder Nutzer ist beispielsweise ein Screen Reader unerlässlich. Der Screen Reader ist eine Software, die visuelle Informationen so aufbereitet, dass sie sinnvoll von einer synthetischen Stimme vorgelesen werden können. Dafür kommuniziert der Screen Reader mit dem Browser, der wiederum die Informationen der gerade geladenen Webseite bereitstellt.
Dies kann er am besten, wenn diese Webseite sich an die gängigen Standards hält. Hierzu gehört zum Beispiel, dass Grafiken immer einen alternativen Text haben müssen. In HTML wird dies zum Beispiel über das Attribut ‘alt’ definiert. Im besten Fall enthält der Text entweder eine sinnvolle Beschreibung der jeweiligen Grafik oder alternativ eine leere Zeichenfolge, also “”, die sie ganz klar als rein dekorative Grafik ausweist. Andere Standards legen fest, welche Attribute Formularfelder haben müssen, damit auch Screen Reader mitteilen können, was in das jeweilige Feld eingetragen werden soll oder ob es ausgewählt werden muss.
Ein positiver Nebeneffekt davon: Ist dies richtig zugeordnet, erhöht es auch die Möglichkeiten für Nutzer einer Maus oder eines Touchscreens, das Feld zu treffen. So können nämlich sowohl das Feld als auch die Beschriftung klickbar sein. Dann genügt es, eines von beiden zu treffen, damit der Cursor im Feld erscheint und die Tastatur zur Eingabe bereit ist.
Das barrierefreie Web ist eine bewährte Idee
Fehlende Beschriftungen von Grafiken und schlecht oder nicht beschriebene Formularfelder sind die zwei typischen Probleme, mit denen sehbehinderte Menschen im Internet zu kämpfen haben. Weitere typische Fehler sind fehlende oder falsch geordnete Überschriften, Overlays oder Pop-ups, die für Sehbehinderte unsichtbar aufgehen und den Rest der Seite blockieren, ohne dass dem Nutzer das mitgeteilt wird.
Ebenfalls problematisch sind rein grafisch dargestellte Informationen, zu denen es keinen Begleittext gibt. Man nehme zum Beispiel viele auf Facebook gepostete Screenshots ohne weiterführende Beschriftung – wobei hierbei meist die Nutzer selbst in der Pflicht sind.
Es ist in den allermeisten Fällen gar kein böser Wille dabei; wir werden einfach oft nur nicht mitbedacht. Doch auch wenn es für Nichtbetroffene verständlicherweise schwierig ist, sich in die vielen speziellen Situationen hineinzuversetzen, müssten sie sich eigentlich nur auf die Grundlagen des Internets besinnen. Denn die Sprache HTML liefert per Definition und Implementierung in den Browsern die Barrierefreiheit frei Haus mit.
Das Problem sind eher Designer, die wegen der Optik etwas auf eine ganz bestimmte Art angezeigt haben wollen. Damit sind Entwickler oft gezwungen, mit den einfachsten Elementen etwas zu bauen, das zwar hübsch aussieht, allerdings nur noch mit einer Computermaus bedienbar ist. Außerdem gibt es inzwischen hohe Ansprüche an Webapplikationen, die von HTML erst langsam erfüllt werden können. Aber weil es schnell gehen muss, wird mit einfachsten Elementen etwas zusammengebaut und auch hier wieder nur auf die Mausbenutzung geachtet.
Eigentlich muss man sich sogar anstrengen, etwas nicht barrierefrei zu gestalten
In den meisten Fällen gibt es für die beschriebenen Probleme schon vorhandene barrierefreie Lösungen im HTML-Standard. Ich habe über die Jahre, die ich in diesem Bereich schon tätig bin, Webentwickler getroffen, die noch nie davon gehört haben, dass es in HTML Elemente für Datentabellen gibt. Da werden dann Tabellengitter gemalt, aber der Screen Reader weiß nicht, dass das eine Tabelle sein soll. Dabei existieren bereits Elemente, die die Funktionalität inklusive Zuordnung von zum Beispiel Spaltenköpfen ohne weiteres Zutun anbieten.
Zusätzlich gibt es seit ein paar Jahren immer wieder neue Javascript-Frameworks, die diese schlechten Beispiele sogar noch befördern, indem sie selbst kein semantisch sinnvolles HTML erzeugen, wenn man ihre Funktionen nutzt. Hier steckt die Accessibility-Gemeinde anschließend viel Arbeit hinein, um in viel Kleinarbeit nachzubessern – alles in der Hoffnung, dass das nächste Redesign nicht wieder alles kaputt macht.
Hier sind ganz klar Schulen, Hochschulen und Unis gefragt, in ihren Lehrplänen endlich die Prinzipien von inklusivem Design und semantischem HTML zu verankern. Obwohl sich die Web-Accessibility-Initiative schon über 20 Jahre für das Thema engagiert, gibt es immer noch Hochschul-Abgänger, die zwar gute Javascript-Kenntnisse haben, trotzdem aber nicht wissen, wie man in HTML eine einfache, verschachtelte Liste mit römischen und arabischen Ziffern baut.
Captchas sperren nicht nur Bots aus
Eine weitere tägliche Herausforderung im World Wide Web sind die sogenannten Captchas – die completely automated public Turing test to tell computers and humans apart. Eigentlich dazu gedacht, Spam oder Fake-Accounts zu vermeiden, zeigen sich Captchas als teilweise unüberwindbare Hürde für Nutzer mit starken visuellen Einschränkungen.
Im Falle von Googles “Ich bin kein Roboter”-Feld geht es sogar noch häufig gut, da es zumindest eine Audioalternative gibt, bei der man aus einer verrauschten Aufnahme Wortschnipsel oder Ziffern heraushören muss. Aber Menschen, die nicht nur blind, sondern auch noch gehörlos sind, stehen vor einer unlösbaren Aufgabe. Außerdem sind viele dieser Captchas auch für Menschen mit kognitiven Einschränkungen schwer bis gar nicht lösbar.
Hier muss dringend der Seitenbetreiber in die Pflicht genommen werden, andere Lösungen zur Vermeidung von Spam zu finden und nicht die Verantwortung auf den Nutzer abzuwälzen.
Passende Mechanismen sind auch schon vorhanden, sie sind manchmal nur etwas aufwändiger zu implementieren. Auch gibt es gute Alternativen, die nicht auf Grafiken basieren und für Bots ähnlich schwer zu lösen sind, beispielsweise Rechenaufgaben, die in bestimmter Textform gestellt werden. Die nötigen Technologien gibt es also schon, sie müssen nur eingesetzt werden.
Gesetzlich ist das meiste schon geregelt
Neben der technischen Umsetzung gibt es auch schon eine Reihe von Richtlinien, die in den Web Content Accessibility Guidelines definiert werden. Diese sind in verschiedenen Ländern oder Staatengemeinschaften wie der EU für bestimmte Bereiche, wie den öffentlichen Sektor, auch gesetzlich vorgeschrieben. Dabei werden Seiten meist auf Struktur und Semantik, die Bedienbarkeit mit der Tastatur, das Einhalten von Farbkontrasten und sonstige Bedingungen hin untersucht.
Der Lesemodus ist für alle da
Eine Möglichkeit, Seiten störungsfrei zu genießen, ist der Lesemodus. Er eignet sich praktisch für jeden, der entspannt Artikel lesen möchte. Der Lesemodus bereitet Artikel zum angenehmeren Lesen mit den Augen auf, die Vorlesefunktion nutzt diese optimierte Darstellung aus und bietet zusätzlich ein paar Funktionen wie das Hervorheben des gerade vorgelesenen Satzes am Bildschirm.
Der Lesemodus gleicht den Inhalt für alle Nutzer an, auch wenn diese unterschiedliche Unterstützung benötigen würden. Für einen Sehenden ist beispielsweise sofort erfassbar, was eine Überschrift ist, was ein Link, was ein Absatz usw.. Ein Blinder hat diesen Überblick nicht. Blinde müssen alles sequentiell, also nacheinander, aufnehmen. Ein Querlesen, wie man dies als Sehender kennt, ist nicht so ohne weiteres möglich.
Außerdem müssen für Blinde mehr Informationen vorgelesen werden, beispielsweise ob es sich um eine Überschrift handelt, welche Ebene diese hat, ob es ein Link ist, eine Grafik oder etwas ganz anderes. Für einen Sehenden, der diese Informationen bereits hat, wären das nutzlose und verwirrende Zusatzinformationen. Trotzdem ist der Lesemodus eine Funktion, die auch Blinde nutzen können, nur lassen sich die meisten direkt die vollständige Webseite vom Screen Reader vorlesen – auch wenn der Lesemodus viel nutzlosen Ballast entfernt, den man fürs Lesen eines Artikels nicht braucht.
Lesen ist nicht alles
Leider beschränken sich Möglichkeiten wie der Lesemodus logischerweise auf Informationen und Artikel. Auf Social-Media-Seiten oder in Onlineshops nützt er hingegen wenig. In Onlineshops greifen beispielsweise auch wieder die typischen und bereits beschriebenen Probleme von Bannern, Bildern und Eingabefeldern. Noch dazu kommt, dass viele Shops, die nicht über ein modernes Shopsystem betrieben werden, meist auf einem veralteten Standard basieren und so zum Teil sehr unübersichtlich sind. Hier bilden auch Shops, die speziell Equipment für Menschen mit Einschränkungen anbieten, keine Ausnahme.
Barrierefreiheit ist ein Menschenrecht, kein Bedarfsartikel
Als Resümee lässt sich festhalten: Es gibt bereits viele gute und bewährte Ansätze wie Screen Reader und HTML-Möglichkeiten, die auch Menschen mit Einschränkungen die Tür zum Internet öffnen. All diese technischen Möglichkeiten sind aber sinnlos, wenn sie nicht angemessen genutzt werden.
Mit anderen Worten: Es steht und fällt mit dem allgemeinen Problembewusstsein sowie der zwischenmenschlichen Empathie. Technologie und technische Hilfsmittel sind dabei unerlässlich, denn für Menschen mit Behinderungen machen sie viele Dinge erst möglich. Dazu müssen wir in den Köpfen der Menschen verankern, wie wichtig Barrierefreiheit ist. So wie öffentliche Gebäude einen barrierefreien Zugang haben müssen, sollten auch digitale Angebote für jeden nutzbar sein.
Barrierefreiheit ist ein Menschenrecht, kein Bedarfsartikel.
Digitale Barrierefreiheit: Warum sich Unternehmen darum kümmern sollten