Standards wie die WCAG decken die technischen Anforderungen von Blinden an digitale Benutzer-Oberflächen recht gut ab. Technische Konformität muss aber nicht heißen, dass eine Anwendung für Blinde auch angenehm zu nutzen ist. Vielfach schrecken formal barrierefrei, aber schlecht nutzbare Anwendungen Blinde eher ab.
Wenn blinde Menschen Anwendungen regelmäßig nutzen, können sie damit in der Regel sehr gut arbeiten. Die Herausforderung besteht darin, dass wir heutzutage oft sehr schnell mit neuen Anwendungen arbeiten müssen oder Programme haben, die wir so selten nutzen, dass wir mit ihnen nicht vertraut werden – ein Bereich, in welchem eine gute User Experience besonders wichtig wäre.
Bei den folgenden Beispielen gehe ich davon aus, dass die Anwendung im Großen und Ganzen barrierefrei, also standardkonform ist. Es versteht sich von selbst, dass nicht-barrierefreie Anwendungen von Blinden nicht oder nur mit großen Schwierigkeiten genutzt werden können. Ein typisches Beispiel ist ein Button, der als verlinkte Grafik oder anklickbares JavaScript-Element umgesetzt wird. Das ist zwar generell bedienbar, aber nicht standardkonform, weil die Rolle des Elements nicht korrekt ist.
Häufige Probleme
Oft sind es Kleinigkeiten, welche Blinden die Nutzung erschweren. Ein typisches Design-Pattern besteht darin, den Abbrechen-Button rechts und den Zustimmen-Button links zu platzieren.
Das führt häufig dazu, dass der Abbrechen-Button per Tab zuerst erreicht wird. Passt man als NutzerIn nicht auf, bricht man aus Versehen den Vorgang ab. In den meisten Fällen dürfte aber das Bestätigen die gewünschte Option sein.
Blinde Menschen gehen bei der Nutzung von Web- oder App-Oberflächen stets von oben nach unten. Das heißt, dass sie nicht mitbekommen, wenn sich etwas vor ihrer aktuellen Position ändert. Stellen Sie sich vor, Sie scrollen durch eine längere Seite, klicken etwas an und es ändert sich etwas oben außerhalb Ihres Viewports. Das passiert etwa bei Google-Anwendungen wie Gmail. Wählen Sie eine Mail aus, um sie vielleicht zu löschen, tauchen die entsprechenden Buttons oberhalb der Mail-Liste auf, eine blinde Person würde sie aber unterhalb der Mail-Liste suchen, weil sie ja oben schon „vorbeigekommen“ ist und zu diesem Zeitpunkt war dort nichts.
Eine weitere Herausforderung ist die zunehmende Komplexität von Tastenkürzeln: Blinde nutzen bei Desktop-Anwendungen unzählige Tastenbefehle, um die Arbeit zu beschleunigen. Mit dem Tastenkürzel „Alt + 1“ kann man zum Beispiel einen Text-Abschnitt als Überschrift 1 markieren.
Auch im Web gibt es solche Kürzel, die aber sehr komplex sein können. Sie bestehen häufig aus dem Drücken von drei oder mehr Tasten gleichzeitig. Das ist sowohl motorisch als auch kognitiv eine Herausforderung: Je mehr Tasten man drücken muss, desto höher die Wahrscheinlichkeit einer Fehl-Bedienung. Hinzu kommt, dass es keinen Standard für Tastaturbefehle gibt. Bei Tools zur Video-Kommunikation sehen die Symbole zum Aktivieren des Videos oder der Kamera immer ähnlich aus, so dass Sehende sich schnell zurechtfinden. Die Tasten-Kombinationen für diese Funktionen sind hingegen jeweils anders, für Blinde ist das nicht intuitiv.
Die Komplexität der Anwendungen nimmt stetig zu: Vor allem Single-Page-Applikationen wie Google Docs oder auch sehr lange Formulare sind eine Herausforderung für Blinde. Blinde können nicht „scannen“, also eine große Menge an Informationen und UI-Elementen schnell überfliegen. Das erschwert es, solche Anwendungen flüssig zu bedienen.
Lösungs-Möglichkeiten
Für einige Probleme gibt es Lösungen, bei anderen ist es allerdings schwieriger.
Die Anforderungen blinder Menschen sollten frühzeitig berücksichtigt werden. Dazu gehört – wie oben angedeutet – eine gute Orientierung über HTML- oder ARIA-Regionen und eine für die Nutzer*In schlüssige Tastatur-Navigation mit bekannten Tasten-Kürzeln. Bei komplexen Formularen und Anwendungen ist außerdem ein gutes Fehler-Management wichtig. Fehl-Eingaben sollten antizipiert werden, Angaben sollten möglichst sofort validiert und der Nutzer*In kommuniziert werden, damit sie korrigiert werden können.
Bei dynamischen Änderungen wie geändertem Text oder neu eingefügten UI-Elementen sollten die Änderungen möglichst hinter dem Element stattfinden, mit dem sie ausgelöst wurden. Alternativ sollte der Nutzer*In zumindest exakt mitgeteilt werden, wo sie die Änderungen findet und wie sie dort hinkommt. Das Hijacken des Screenreader-Fokus, also das Verschieben per JavaScript ist zwar möglich, aber bei Blinden nicht besonders beliebt, da sie dann nicht mehr wissen, wo auf der Seite sie sich befinden.
Wünschenswert für alle Nutzer*Innen, aber besonders für Blinde ist mehr Einfachheit bei Anwendungen. Buche ich etwa ein Ticket bei der Deutschen Bahn über die Desktop-Website, sehe ich dennoch die komplette Navigation von bahn.de. Das Buchungs-Formular und ein Button zum Abbrechen der Buchung würde vollkommen ausreichen und die Orientierung deutlich erleichtern.
Fazit
Generell ist es sinnvoll, mit blinden Anwender*Innen zu testen und deren Feedback frühzeitig zu berücksichtigen. Allerdings ist es vor allem bei komplexen Anwendungen schwierig, ausreichend qualifiziertes Feedback zu bekommen. Dann ist es sinnvoll, Feedback-Möglichkeiten für blinde Nutzer*Innen anzubieten und dieses Feedback in Optimierungen einfließen zu lassen.
Wichtig wäre außerdem, dass sich assistive Technologien weiterentwickeln. Aktuell sind sie nach wie vor auf Desktop-Anwendungen optimiert. Es ist aber absehbar, dass viele Anwendungen ins Web abwandern werden. Problematisch ist auch, dass sich in den Screenreadern teilweise keine einheitlichen Bezeichnungen für gängige UI-Elemente wie etwa Checkboxen durchgesetzt haben.
Auch fehlt es teilweise an etablierten Design Patterns für Blinde. Wie oben erwähnt haben sich noch keine einheitlichen Tasten-Kürzel für ähnliche Aufgaben in unterschiedlichen Anwendungen etabliert.