Die schwache Barrierefreiheit von Android

Dieser Blogeintrag ist eine Übersetzung des englischen Blogeintrags The poor State of Android accessibility des NVDA-Entwicklers James Teh. Sie wurde mit freundlicher Genehmigung des Autors vom Inhaber dieses Blogs erstellt. Sämtliche wiedergegebenen Meinungen entsprechen denen des Autors des englischsprachigen Artikels.

Die Mobilplattform Android finde ich wirklich spannend. Sie ist offen (was man vom iPhone nicht behaupten kann), und sie ist auf vielen Gebieten sehr erfolgreich. Ich würde mich mit ziemlicher Sicherheit für ein Android-Smartphone entscheiden, wäre da nicht der schlechte Zustand der Barrierefreiheit von Android.

Hinweis: Ich werde hier hauptsächlich die Zugänglichkeit für blinde Nutzer besprechen, denn damit bin ich am vertrautesten. Einiges hiervon gilt jedoch auch für andere Formen der Behinderung.

Am Anfang

Am Anfang gab es keinerlei Barrierefreiheit in Android. Es hätte Sinn gemacht, es vom Start weg unter Berücksichtigung der Barrierefreiheit zu designen, was die Sache stark vereinfacht hätte, aber wie es leider so oft der Fall ist, ist dies nicht geschehen. Dennoch gibt es Plattformen, die sich von dieser Nachlässigkeit erholt haben, und einige davon sogar sehr erfolgreich.

Das Eyes-Free Project

Dann erschien das Eyes-Free Project auf der Bildfläche, welches einen Satz selbst sprechender Anwendungen erstellte, welche es blinden Benutzern erlaubten, viele Funktionen eines Android-Phones zu nutzen. Von blinden Anwendern zu verlangen, diese speziellen Anwendungen zu verwenden, beschränkt die Funktionalität, auf die sie Zugriff haben, und isoliert sie komplett von der Erfahrung, die andere Anwender mit diesen Geräten machen. Dies ist nur einen kleinen Schritt von einem speziell für blinde Benutzer entwickelten Gerät entfernt. Ich schätze, es ist besser als nichts, aber auf lange Sicht ist es inakzeptabel.

Integrierte Accessibility API and Services

In Android 1.6 wurde eine Programmierschnittstelle zur Barrierefreiheit, ein Bildschirmleseprogramm (Talkback) und andere Barrierefreiheitsdienste in den Android-Kern mit eingebaut. Ein Entwickler außerhalb von Google begann außerdem mit der Entwicklung des Bildschirmleseprogrammes Spiel. Dies bedeutete, dass blinde Anwender nun Zugang zu Standard-Android-Anwendungen hatten wie jeder andere auch.

Leider ist die Barrierefreiheits-Programmierschnittstelle von Android extrem eingeschränkt. Das einzige, was sie tun kann, ist, ein Ereignis zu generieren, wenn etwas wichtiges in der Benutzerschnittstelle passiert. Ein Barrierefreiheitsdienst wie ein Bildschirmleseprogramm kann diese Ereignisse nach bestimmten Informationen befragen wie z. B. den Text des Objekts, das gerade aktiviert wurde. Außerhalb davon sind aber keine Abfragen möglich. Dies bedeutet, dass keine Informationen zu anderen sich auf dem Bildschirm befindlichen Objekten abgefragt werden können, es sei denn, sie werden aktiviert. Unter anderem macht dies das Erforschen des Bildschirms unmöglich. Sogar die inzwischen sehr betagte Microsoft Active Accessibility, die Programmierschnittstelle zur Barrierefreiheit, die in Windows verwendet wird, erlaubt trotz ihrer Einschränkungen und Defizite das Erforschen und Abfragen von und Interagieren mit Objekten.

Die Unmöglichkeit, Eingaben global abzufangen

Weiterhin ist es einem Barrierefreiheitsdienst nicht möglich, Tastendrücke oder Berührungen des Touch Screens auf globaler Ebene abzufangen. Dies bedeutet nicht nur, dass ein Barrierefreiheitsdienst keine Befehle zur Erforschung des Bildschirms, zum Unterbrechen der Sprachausgabe, zum Verändern von Einstellungen usw. per Tastatur oder Bildschirmzur Verfügung stellen kann. Es macht außerdem die Barrierefreiheit der Benutzung des Touch Screens für blinde Anwender unmöglich. Ein blinder Anwender muss in der Lage sein können, den Touch Screen zu erkunden, ohne versehentlich ein Objekt zu aktivieren. Dies kann aber nur erreicht werden, wenn das Bildschirmleseprogramm den Bildschirm gesondert behandeln kann.

Nicht barrierefreie Ausgabe von Webseiten

Der in Android verwendete Ausgabemechanismus für Webseiten, die sog. Web Rendering Engine ist nicht barrierefrei. Es ist zur Zeit wahrscheinlich sogar unmöglich, diese auf Grund der extrem eingeschränkten Infrastruktur überhaupt barrierefrei zu machen, da ein Anwender in der Lage sein muss, sämtliche Objekte einer Webseite zu erkunden. Dies bedeutet, dass der eingebaute Browser, E-Mail-Client und die meisten anderen Anwendungen, die Webinhalte anzeigen, unzugänglich sind. Dies ist für ein modernes Smartphone völlig inakzeptabel!

Barrierefreier E-Mail-Client und Webbrowser von IDEAL Apps4Android

IDEAL Apps4Android haben einen barrierefreien E-Mail-Client und einen Webbrowser veröffentlicht. Die Erweiterungen zur Barrierefreiheit des K9 E-Mail-Clients (auf dem ihre Anwendung basiert) sind inzwischen in das K9-Projekt zurückgeflossen, und das ist großartig! Der Zugriff auf das Web erfordert jedoch immer noch einen separaten Webbrowser. Und obwohl Entwickler diese zugängliche Webunterstützung in ihre eigenen Anwendungen integrieren können, ist es doch nur ein Satz selbst sprechender Skripte, welche in die Applikation eingebettet werden müssen. Dies ist eher unelegant und eher aufgepfropfte Barrierefreiheit als Barrierefreiheit, die in die Webausgabe-Engine eingebaut wäre. Dies ist keine Kritik an IDEAL. Sie haben das bestmögliche getan im Angesicht der limitierten Programmierschnittstellen und gehören hoch gelobt. Dennoch ist es eine nicht zufriedenstellende Situation.

Weitere „barrierefreie“ Applikationen

Es gibt noch diverse weitere Applikationen außer den oben genannten, die als speziell barrierefreie Anwendungen konzipiert wurden, die jedoch Anwender mit einer Behinderung wiederum von denjenigen Anwendungen isolieren, die alle anderen einsetzen. Nochmal: Diese Isolation rührt primär von den extrem beschränkten Programmierschnittstellen für die Barrierefreiheit in Android her.

Die Lösung

Obwohl Android quelloffen ist, ist die Lösung des Problems für Entwickler außerhalb des Kernentwicklerteams schwer möglich, da diese Änderungen am Kern von Android erfordert. Das aktuelle Framework zur Barrierefreiheit muss erheblich erweitert oder vielleicht sogar redesignet werden, und Kernanwendungen müssen dann auch die Vorteile dieses redesignten Frameworks nutzen.

Fazit

Während in Android 1.6 und neuer erhebliche Fortschritte in Puncto Barrierefreiheit gemacht wurden, ist der Gesamtzustand immer noch sehr unzufriedenstellend. Android kann jetzt von blinden Anwendern verwendet werden, aber es ist längst nicht optimal oder einfach. Zusätzlich ist die Implementierung schlecht entworfen und unelegant. Diese Situation wird sich mit der Zeit nur noch verschlimmern, bis das Problem gelöst wird.

Ich empfinde es als sehr frustrierend, dass die Barrierefreiheit in Android in einem so schlechten Zustand ist. Es sieht so aus als wenn Google gar nichts aus der Vergangenheit der Barrierefreiheit gelernt hat. Dieses Chaos hätte vermieden werden können, wenn das Barrierefreiheits-Framework vernünftig entworfen worden wäre, anstatt des halbfertigen Stückwerks, das jetzt vorliegt. Ein gründliches Design ist ein Grund, warum die Barrierefreiheit im iPhone so hervorragend ist und „einfach funktioniert“.