In einem älteren Artikel habe ich versucht, das Wahrnehmungsmodell von Sehbehinderten zu beschreiben. Im folgenden wollen wir uns das Gleiche für Blinde angucken.
So sieht der erste Teil meiner Website für Blinde aus
Bei Blinden gibt es eine ganze Reihe von Faktoren, die ihre Möglichkeit zur Bedienung programmierter Oberflächen einschränken oder erweitern können. Dazu gehört jenseits der Barrierefreiheit dieser Oberfläche aktuelle Technik, insbesondere aktuelle Hilfstechnik und ihre persönlichen Fähigkeiten, mit der Technik umzugehen. Beides ist selten optimal. Was Blinde mit Sehenden teilen ist oftmals mangelnde Geduld, sich mit einer Sache intensiv zu beschäftigen.
Das Surfverhalten auf unbekannten Seiten
Nehmen wir folgendes an: Der Blinde möchte eine Website besuchen, die er nicht so gut kennt. Er ist gewöhnt daran, dass viele Seiten für ihn nicht einwandfrei funktionieren.
Das klassische Modell der Interaktion geht davon aus, dass der Blinde die Website erst einmal erkundet, sich also den Aufbau ansieht, die Navigation überfliegt und vielleicht auch überprüft, ob es z. B. Sprunganker und andere Hilfen gibt.
Das ist allerdings nicht der Fall, ich kenne keinen Blinden, der so vorgeht. Der Blinde hat wie jeder andere Surfer ein spezifisches Erkenntnisinteresse und versucht das so schnell wie möglich zu befriedigen. Dazu sucht er gezielt nach dem Inhaltsbereich, wo die meisten interessanten Infos stehen.
Auf der Suche nach dem Inhalt
Für den Sehenden erscheint die Website als ein Neben- und Übereinander von Informationssegmenten, das Banner steht über dem Inhalt, der Inhalt steht neben der Navigation und so weiter. Für den Blinden gibt es hingegen nur Linearität, das heißt, ein Element befindet sich vor oder hinter einem anderen Element. Das gilt im übrigen auch für kleine Touchscreens wie beim iPhone. Der Blinde tippt irgendwo auf den Screen und erfasst ein bestimmtes Element, zum Beispiel einen Link. Er wischt dann nach rechts und erfasst das nächste Element, das könnte etwa ein Textabsatz sein.
Um die Anordnung von Elementen auf einer Website sozusagen haptisch erfassen zu können braucht er ein größeres Display, wobei 5- oder 6-Zoll-Displays schon ausreichen dürften. Hier haben wir den Vorteil, dass wir die Position des Inhalts recht gut erraten können. Auf dem iPhone muss man sich meistens mit einer Wischgeste begnügen, auf dem iPad kann man sich relativ sicher sein, dass der Inhalt im mittleren Drittel des Displays beginnt. Von da aus kann der Anfang des Artikels gesucht werden.
Bei den klassischen Screenreadern gibt es oft auch einen Modus zur Erkundung des gesamten Bildschirms, bei NVDA ist das der Flächenmodus, bei Jaws der Jaws-Cursor. Sind diese Modi aktiviert bewegt sich der Blinde mit den Pfeiltasten zeilenweise über den Bildschirm und kann damit sehr viele Elemente erfassen. Das ist ganz nützlich, wenn man weiß, dass es bestimmte Elemente gibt, die nicht mit dem normalen Modus erreicht werden können, aber der Blinde kann natürlich nicht wissen, ob solche Elemente vorhanden sind.
Es ist gar nicht so trivial, wie es auf den ersten Blick wirkt. Der Blinde muss nicht nur nach dem Inhalt suchen, er weiß nicht einmal, ob dieser Inhalt auf dieser Seite überhaupt vorhanden ist. Nehmen wir an, wir haben gerade ein Kontaktformular abgesendet und der einzige Text jenseits von Links oder klickbaren Elementen ist „Vielen Dank für Ihre Nachricht“, dann hat der Blinde kaum eine Chance, diesen Text zu finden. Er weiß also nicht genau, ob seine Interaktion mit der Seite erfolgreich war oder nicht. Der einfachste Weg, ihm mitzuteilen, dass er auf einer neuen Seite ist wäre übrigens die Änderung des Seitentitels. Ich halte mich mit konkreten schlechten Beispielen oft zurück, aber einige Seiten haben das wirklich schlecht gelöst, ein Beispiel dafür ist Wikio.
Zwei Wege durch die Website
Lassen wir das iPhone einmal beiseite, dann gibt es für den Blinden im wesentlichen zwei Strategien, eine Website zu erkunden. Dazu muss man wissen, das es neben der visuellen Struktur der Website auch eine nicht-visuelle Struktur auf der HTML-Ebene gibt. Man könnte es eine semantische Struktur nennen, die für den Blinden ähnlich funktioniert wie die visuelle Struktur für Sehende. Die Funktion eines Elements wird dabei nicht durch ihr Aussehen, sondern durch ihren Namen beschrieben. Wenn der Screenreader zum Beispiel auf eine Checkbox trifft sagt er “Checkbox” und gibt außerdem die Information aus, dass diese Box aktiviert oder nicht aktiviert ist. Der Name des Elements beschreibt also dessen Aufgabe oder Funktion.
Die erste Methode zur Erkundung von Webseiten ist sehr grob und vor allem für schlecht oder gar nicht semantisch strukturierte Seiten gedacht. Die Pfeiltasten sowie die Bild-Auf und Ab-Tasten und der Tabulator dienen dazu, sich stückweise durch die Website zu hangeln. Mit den Cursor-Tasten erwischt man alles, also auch jede Menge Leerzeilen, unbenannte Grafiken und anderes wenig hilfreiches. Viele auch aktuelle Foren sind zum Beispiel schlecht bis gar nicht strukturiert, so dass der Blinde sich durch zahllose für ihn nutzlose Elemente lavieren muss.
Mit den Bild-Tasten kann die Website grob überflogen werden. Wenn sie halbwegs einfach aufgebaut ist ist damit eine recht gute wenn auch grobkörnige Orientierung möglich. Mit der Tabulatortaste können alle anklickbaren Elemente wie links oder Formularelemente erwischt werden. Die Screenreader Jaws und NVDA haben außerdem einen Tastenbefehl, mit dem man Links und andere anklickbaren Elemente überspringen kann. In vielen Fällen findet man mit dieser Taste den Inhaltsbereich.
Die zweite Methode funktioniert bei gut strukturierten Webseiten.
Dabei versuchen Blinde mittels der Navigationstasten des Screenreaders den Inhalt zu erkunden. Wir suchen zum Beispiel gezielt nach Überschriften. Dabei gibt es zwei problematische Situationen: Es gibt gar keine Überschriften oder Hunderte davon, zum Beispiel bei Ministerien. Der Screenreader ermöglicht es, nach vielen Elementen wie Eingabefeldern, Überschriften verschiedener Ebenen und vielen anderen Elementen gezielt zu suchen.
In der Praxis verfolgen wir eine Mischstrategie. Es geht nach wie vor um unbekannte Seiten, deren Aufbau wir ja gerade nicht erkunden oder gar erlernen wollen. Ob der Mensch H1 für seinen Inhalt verwendet oder H6 interessiert uns nicht, ob die Navigation als Liste umgesetzt ist kann uns solange egal sein, wie wir uns nur für den konkreten Inhalt der aufgerufenen Unterseite interessieren. Auch bei Seiten, die ich täglich besuche weiß ich nicht, ob sie eine H1 für die Content-Überschrift verwenden oder nicht.
Die Parallelen zur Orientierung in unbekannten Umgebungen sind übrigens recht groß. Jenseits einiger großer Bahnhöfe gibt es in Deutschland so gut wie kein Areal mit Blinden-Leitsystem, das Leitsystem hat in etwa die Funktion der Semantik auf Webseiten. Daher muss der Blinde sich in unbekannten Gebäuden ähnlich durchlavieren wie auf Webseiten, durch Trial and Error.
Semantik statt Farbe und Form
Die intuitive Bedienung fällt für einen Blinden vollkommen anders aus als für einen Sehenden. Die Gestaltgesetze gelten kaum. Die Farbe oder Positionierung von Elementen oder ihre optische Gestaltung spielt für den Blinden keine Rolle. Der Blinde kann nicht über die Icons erkennen, was ein Programm oder eine Einstellung tut, er sieht keine Pfeile oder angedeuteten Bewegungen für Menüs oder viele andere Hilfen, die eine Benutzeroberfläche für Sehende intuitiv benutzbar macht. Oftmals weiß er nicht, dass ein Element eine Untereinheit eines größeren Segments ist. Wenn ich mit den Bild-Tasten einen Link erwische weiß ich oft nicht, ob er zur Navigation, zum Inhalt oder zur Fußzeile gehört.
Die Arbeit mit Menüs oder den Navigationstasten ist nicht immer optimal, da wir zum Beispiel nicht wissen können, ob es an irgendeiner anderen Stelle des Programms hilfreiche Funktionen gibt, die uns die Arbeit erleichtern könnten. Einige Funktionen scheinen gar nicht über Menüs zugänglich zu sein, zum Beispiel die Überarbeiten-Funktionen in Word 2003, mit der Korrekturen anderer Autoren übernommen oder verworfen werden können.
Bei Webseiten haben wir ein ähnliches Problem, wenn die Entwickler unsauber gearbeitet haben. Nehmen wir an, wir hangeln uns mit der Navigationstaste für Formulare durch ein langes Formular. Dann übersehen wir alle Elemente, die nicht als HTML-Formular-Element umgesetzt wurden, zum Beispiel eine Auswahlliste, die nur über JavaScript realisiert wurde.
Immer vorausgesetzt, die Systeme sind barrierefrei programmiert helfen dem Blinden ähnlich wie im Web semantische Auszeichnungen. Ein Menü ist also nicht nur visuell als Menü zu erkennen, sondern der Screenreader erhält die Information, dass es sich bei einem Objekt um ein Menü, einen Schalter oder eine Checkbox handelt. Ein frisch installierter Screenreader gibt auch zumeist weiterführende Informationen zu den Objekten wie „Bewegen Sie sich mit den Pfeitasten durch das Menü“ und so weiter.
Surfen auf bekannten Seiten
Das klingt alles schlimmer als es ist. Zum einen bewegen sich die meisten Läute den Großteil ihrer Zeit auf ihnen wohlbekannten Seiten. Dabei wirkt es sich nicht so extrem negativ aus, wenn die Seite schlecht strukturiert ist. In der Zeit, die ein Mausnutzer zum Ansteuern eines Links braucht habe ich den Link zwei Mal aufgerufen.
Es gibt ein ganz nettes Buch zur Webkonzeption von Jens Jacobsen. An einer Stelle berichtet er darüber, warum benutzerfreundliche Systeme manchmal scheitern. Ein Grund dafür ist, dass vor allem die Alt-Nutzer radikale Neuerungen ablehnen, weil sie die Macken des alten Systems beherrschen. Wir passen uns den Programmen an, statt die Programme an uns anzupassen.
Das trifft auch auf Blinde zu: häufig benutzen sie uralte Programme und Screenreader, weil sie keine Lust zum Umlernen haben. Das mag man für legitim halten, aber am Ende schadet es doch ihnen selbst am meisten. Der Knackpunkt ist die Frage, ob eine blindengerechte intuitive Gestaltung ihnen beim Umstieg helfen würde.
Wofür das Ganze?
Einige Läute werden einwenden, dass man das eigentlich nicht braucht. Schließlich wissen wir ja nach x Jahren Nutzung, wo die einzelnen Menüpunkte von Word oder Excel sind. Es spielt also keine Rolle für uns, ob es Kacheln, Fenster oder Symbolleisten sind, Hauptsache, das Teil ist bedienbar. Das stimmt in Bezug auf Programme, die wir täglich nutzen. Aber es gibt auch Programme oder Websites, die wir vielleicht nur einmal benötigen und hier hilft uns eine intuitive Bedienung ungemein.
Für graphische Benutzeroberflächen gibt es deshalb nur eine praktikable Alternative, die Touchscreens. Natürlich gibt der Screenreader bei Berührung die gleichen Informationen aus wie bei einer Tastatursteuerung. Allerdings hat der Blinde hier die Möglichkeit, die gesamte Programmoberfläche zu erkunden. Er gewinnt damit nicht nur einen Eindruck, wie die Programmoberfläche aufgebaut ist, sondern kann alle Bedienelemente erkunden, auch diejenigen, die er ansonsten nie entdeckt hätte.
Natürlich stellen Touchscreens Anforderungen eigener art, sobald es über die übliche Drei-Button-App hinaus geht. Ein Desktop-Programm kann ähnlich wie eine Website Hunderte von Elementen enthalten. Aber hier kommt uns tatsächlich die grafische Oberfläche zugute. Normalerweise sind Programme oder Websites nicht wie Kraut und Rüben angeordnet, sondern folgen in ihrem Aufbau einer gewissen Logik. Verwandte Funktionen sind nebeneinander angeordnet, Funktionen aus unterschiedlichen Bereichen sind in Symbolleisten untereinander gruppiert und so weiter.
Ein großflächiges Braille-Display könnte ebenfalls eine gute Lösung sein. Allerdings sind die Braille-Module so teuer, dass das für niemanden erschwinglich sein wird. Für die Darstellung von Vektorgrafiken sind diese Displays außerdem viel zu grobkörnig. Es gibt noch einige alternative Ansätze für haptische Displays, die aber meines Wissens nach weit von der Marktreife entfernt sind.
Das alles könnte zu dem Schluss führen, dass es sinnvoll ist, spezielle Anwendungen für Blinde zu entwickeln, weil graphische Benutzeroberflächen für sie nie optimal nutzbar sein werden. Genau das Gegenteil ist richtig, wir brauchen neue Strategien, um graphische Interfaces besser nutzbar zu machen.
Aktuell können wir zwei parallele Entwicklungen beobachten. Auf der einen Seite nehmen webbasierte Technologien immer mehr Raum ein, auf der anderen Seite ist zu befürchten, dass es zu einer erneuten Spezialisierung kommt. Es gibt keine Textversionen für Blinde, stattdessen gibt es spezielle Navi-Apps, Lese-Apps und andere Insellösungen. Auch wenn die Blinden aktuell die Vorteile dieser speziellen Apps genießen mögen, so droht diesen Insellösungen doch das gleiche Schicksal wie den Textversionen von 1999, sie werden nicht weiterentwickelt oder vergessen und am Ende gibt es nutzlose Insellösungen für Blinde und nicht-barrierefreie Anwendungen für alle anderen.
Ich lehne nicht generell Sonderlösungen für Behinderte ab, sie sind dort sinnvoll, wo sie besondere Bedürfnisse von Behinderten erfüllen, die von klassischen Apps gar nicht oder unzureichend abgedeckt werden. Nicht-Behinderte brauchen zum Beispiel meistens keine Apps zur unterstützen Kommunikation.
Einige Anwender lehnen Apps generell ab, auch diesen Standpunkt teile ich nicht. Apps haben einen Vorteil, sie können besser auf die Accessibility-APIs zugreifen als Web-Apps das können. Dort, wo Apps diesen Vorteil ausnutzen, sind sie durchaus sinnvoll, der Rest ist Spielzeug für langweilige Nachmittage. Die Blinden tun gut daran, weiterhin die Barrierefreiheit allgemeiner Anwendungen zu fordern und Sonderlösungen konsequent abzulehnen.
