Android-Apps für die Sprachausgabe zugänglich machen

Dass Apps für iOS für blinde Menschen zugänglich gemacht werden können, ist inzwischen hinlänglich bekannt. Was viele Entwickler aber noch nicht wissen, ist, dass Android bei der Zugänglichkeit aufholt und inzwischen ein fast ebenbürtiger Mitspieler bei den mobilen Betriebssystemen für Menschen mit Behinderungen ist. Seit Android 2.2 gibt es den Screen Reader TalkBack im Google Play Store, und seit Version 4.0 wird dieser standardmäßig im Betriebssystem gleich mitgeliefert.

Die Sprachausgabe einrichten

Um voll funktionsfähige Bedienungshilfen zu erhalten, sollten die folgenden Komponenten vom Google Play Store installiert werden, wenn nicht bereits vorhanden:

  • Accessibility Preferences (ab Android 4.0 bereits installiert)
  • TalkBack (seit Android 4.0 bereits installiert)
  • SoundBack (optional, wenn beim navigieren und Aktivieren von Elementen Sounds wiedergegeben werden sollen. Seit Android 4.0 in TalkBack integriert und bereits installiert)
  • KickBack (optional, wenn beim Navigieren und Aktivieren von Elementen haptisches Feedback gegeben werden soll. Seit Android 4.0 in TalkBack integriert und bereits installiert)
  • Eyes-Free Keyboard (für Geräte ohne physische Tastatur, und für Android 4.0 für ein besseres Zusammenspiel mit TalkBack und dem Touch Screen. Ab Android 4.1 sollte dieses nicht mehr installiert werden!)

Um die Bedienungshilfen einzuschalten:

  • Öffnet man die Einstellungen und darin Bedienungshilfen
  • Aktiviert Bedienungshilfen bzw. Accessibility (ab Android 4.0 nicht mehr vorhanden, da bereits vorinstalliert)
  • Aktiviert TalkBack und konfiguriert auf Wunsch auch KickBack und SoundBack

WebViews wie auch der Standard-Browser von Android sind standardmäßig nicht zugänglich. Es gibt eine Unterstützung durch ein paar Skripts, die ebenfalls im Dialog Bedienungshilfen installiert werden können und sollten, wenn in der eigenen App eine WebView zum Einsatz kommt.

Grundzüge der Bedienung

Nach dem Start von TalkBack unter Android 4.0 und 4.1+ empfiehlt es sich, das Tutorial für die TouchScreen-Bedienung durchzugehen, um sich mit der durch TalkBack geänderten Gestensteuerung vertraut zu machen. Die wichtigsten Gesten sind hier kurz zusammengefasst.

Für Android 4.0:

Finger auf Display legen und hin und her bewegen
Spricht das Element, auf das der Finger gelangt.
Finger anheben und an gleicher Stelle wieder aufsetzen
Aktiviert das Element unterm Finger.
Mit zwei Fingern nach oben, unten, rechts oder links schieben
Scrollt den Bildschirm rauf, runter, nach rechts oder links

Für Android 4.1 oder höher:

Bildschirm antippen
Element unterm Finger sprechen.
Nach links oder rechts wischen
Den Talkback- oder Accessibility-Focus zum vorherigen bzw. nächsten Element bewegen und es sprechen.
An beliebiger Stelle auf dem Bildschirm doppelt tippen
Das zuletzt gesprochene Element aktivieren. Doppeltippen und halten bewirkt dasselbe wie das Tippen und Halten ohne TalkBack.
Scrollbewegungen mit zwei Fingern
Siehe oben.

Talkback unter Android < 4.0 unterstützt nur das Navigieren mit einem direktionalen Controller, D-Pad oder den Pfeiltasten der Tastatur. Aktiviert werden Elemente durch Drücken von enter.

Wird das Eyes-Free Keyboard verwendet, muss dies als Standard-Keyboard eingestellt werden. Es hat drei Modi, die durch das lange Drücken von Laut oder Leise zirkular umgeschaltet werden: Navigieren, Tippen und Aus.

Im Modus Tippen wird eine virtuelle Tastatur eingeblendet, die von TalkBack vollständig unterstützt wird. Man tippt einen Buchstaben an und hebt den Finger, um ihn einzugeben. Hat man den falschen Buchstaben erwischt, belässt man den Finger auf dem Touch Screen, zieht ihn auf den richtigen Buchstaben und hebt ihn dann an.

Im Modus Navigieren besteht das untere Drittel des Touch Screens aus einem Navigationskreuz, also einem virtuellen D-Pad. Links, Rechts, Oben und Unten werden durch Wischen in der entsprechenden Richtung erzeugt. Enter wird durch das Tippen ungefähr in der Mitte dieses Drittels ausgelöst.

Das Eyes-Free Keyboard wird nicht automatisch eingeblendet. Wird der Focus auf ein Editierfeld gesetzt, muss per langem Drücken auf den Lautstärkebalken die Tastatur manuell eingeblendet werden.

Views zugänglich machen

Wenn Sie mit Standard-Android-Komponenten arbeiten, kommt die Zugänglichkeit automatisch mit. Sie müssen dann lediglich die Label entsprechend setzen. TalkBack verwendet die Eigenschaft contentDescription, um Elemente vorzulesen.

Wenn Sie eigene Komponenten erzeugen, müssen Sie diese contentDescription setzen. Tun Sie dies nicht, wird das Element von TalkBack ignoriert. Die contentDescription wird bei allen eigenen Komponenten benötigt, inklusive sind ImageButtons, Checkboxen und ImageViews.

Lassen Sie diese Eigenschaft nur bei dekorativen Elementen weg.

Eine Ausnahme bilden EditBoxen, wo man statt der ContentDescription android:hint zuweisen muss, um die Feldbezeichnung zusammen mit dem Inhalt von TalkBack sprechen zu lassen.

Beinhaltet Ihre App Elemente, deren Zustand sich ändert wie z. B. ein Wiedergabe/Pause-Schalter, aktualisieren Sie auch die contentDescription!

TalkBack spricht zusätzlich zu der contentDescription auch den Typ eines Elements. Daran sind bestimmte Erwartungen eines Benutzers geknüpft. Ein Button führt normalerweise eine Aktion aus, ein Link bringt den Anwender zu einer anderen View. Stellen Sie also sicher, dass nicht z. B. ein Button sich wie ein Link verhält und umgekehrt, um Verwirrungen zu vermeiden.

Alle Elemente, inklusive Textbeschriftungen, müssen per Berührung, Tastatur und direktionalem Controller zugänglich sein. Dies wird erreicht, indem die folgenden, zur jeweiligen Situation passenden Eigenschaften verwendet werden: android:focusable=“true“, setFocus, isFocusable oder requestFocus. Die Focus-Reihenfolge wird standardmäßig durch die Nähe verschiedener Steuerelemente zueinander, gemessen von oben links nach unten rechts, bestimmt. Sollte sich diese nicht als logisch erweisen, können Sie die Focus-Reihenfolge selbst verwalten, indem Sie den Komponenten nextFocusRight, nextFocusDown, nextFocusLeft und nextFocusUp zuweisen.

Manchmal kann es angebracht sein, dass Sie andere Inhalte darstellen möchten, abhängig davon, ob ein Android-Screen-Reader verwendet wird oder nicht. So könnten Sie z. B. zwei verschiedene Tutorials zur Benutzung Ihrer App anbieten, die eine für sehende Benutzer, die andere für solche, die TalkBack verwenden. Verwenden Sie hierzu die Eigenschaft isScreenReaderActive. Es sollte jedoch das Ziel sein, dass 99% des Standard-Inhalts Ihrer App zugänglich sein sollte und diese Extras nur die absolute Ausnahme bleiben sollten!

Um die Effizienz von Anwendern zu erhöhen und Fehlerquellen zu vermeiden, sollten freie Eingabefelder weitgehend vermieden werden. Stattdessen sollten RadioButton, Checkbox und Umschalt-Buttons verwendet werden, um die meisten Eingaben zu tätigen, die nicht zwingend eine freie Eingabe erfordern.

Für Hybrid-Anwendungen, die auch Webinhalte darstellen, gilt, dass die Webinhalte genauso zugänglich sein sollten wie bei Webseiten für Desktop- und Mobilbrowser: Alternativtexte für Bilder, korrekt mit label/for zugewiesene Beschriftungen zu Inputs, Überschriftenstrukturen usw.

Es empfiehlt sich, Webinhalte nicht nur mit dem eingebauten Webbrowser, sondern auch mit Chrome und Firefox für Android, die TalkBack beide unterstützen, zu testen, um die korrekte Funktionsweise sicherzustellen.

Testen

Mit Lint können einige grundlegende Tests auch der Zugänglichkeit durchgeführt werden. So testet Lint, ob die contentDescription immer vorhanden ist oder ob der Typ eines Objekts korrekt ist.

Dies kann jedoch das Testen durch Anwender oder die eigene Benutzung von TalkBack nicht ersetzen. Sie sollten also immer Tests durch Menschen durchführen lassen, um sicherzustellen, dass die Elemente nicht nur beschriftet sind, sondern dass diese für den Kontext auch adäquat vergeben wurden. Wenn Sie TalkBack wie oben beschrieben eingerichtet haben, sollten Sie also Folgendes testen:

  1. Sind alle Elemente beschriftet?
  2. Werden ausschmückende Objekte ignoriert?
  3. Sind alle Formularfelder beschriftet?
  4. Werden Zustandsänderungen angesagt?
  5. Werden die korrekten Objekttypen gesprochen?
  6. Ist die Focus-Reihenfolge schlüssig?

Sind diese Fragen mit „ja“ beantwortet, können Sie ziemlich sicher sein, alles richtig gemacht zu haben. Diese Techniken sollten Ihnen möglichst schnell in Fleisch und Blut übergehen, so dass Ihre Apps in zukunft standardmäßig mit den nötigen Zugänglichkeitseigenschaften ausgestattet sind und Sie dadurch eine qualitativ bessere Arbeit abliefern. Zugängliche Apps vergrößern Ihre Nutzerbasis, und das Zugänglichmachen einer App offenbart manchmal auch Probleme im Design einer App, deren Lösung allen Anwender, auch denen, die kein TalkBack verwenden, zugute kommt!

Danksagung

Ein besonderer Dank gebührt Henny Swan, deren im .net magazine erschienener englischsprachiges Tutorial zum Thema mir für diesen Artikel als grober Leitfaden diente.

8 Gedanken zu „Android-Apps für die Sprachausgabe zugänglich machen“

  1. Hallo!
    Ja, Android sollte man ebenfalls einbeziehen, neben Apple und immer noch microsoft.
    Mir liegt bekanntermassen die Perspektive der Sehbehinderten am Herzen.
    Mir ist inzwischen klar, dass für mich Android ohne tallgemeinem Zoom nicht nutzbar ist. Deshalb habe ich das Samsung note 2 wieder zurück gegeben, mit 4.0.
    Allerdings gibt es ja dort sehbehindertenspezifische Anwendungen mit grossen icons.
    Ab 4.2 soll ja allgemeines Zoom integriert sein. Als App mit overlay wäre es, wie mir ein Entwickler schrieb, nicht realisierbar.
    Schön ist die Austauschbarkeit der Schriften, z.B. in Frutiger, die als sehr geeignet gilt und auch von Designern geschätzt wird.
    Ich habe ein Nexus 10 bestellt und bin gespannt, wie sich die Welten unterscheiden.

  2. Hallo Marco,

    Sehr interessante Hinweise.
    Was hat sich denn mittlerweile in Version 4.4 getan. Kann man sagen, dass Android eine Alternative zum iPhone ist?
    Viele Grüße

    1. Hallo Maik,

      nein, viel hat sich nicht getan in 4.4. Es gibt ein paar kleinere Verbesserungen bei der API, die aber nur zum Tragen kommen, wenn man selbst Custom Views zugänglich macht. Aber deutsche Umlaute schreiben, wie ich dies in meinen Android-Tests ja bemängelt habe, geht immer noch nicht. Und andere Dinge, die ich kritisiert habe, sind ebenfalls weiterhin vorhanden.

  3. Ich habe gestern (28.8.2014) ein Medion Tablet mit Android 4.4.2. gekauft. Seitdem kämpfe ich mit dem Gerät. Eigentlich sollte es nur meine MP3-Dateien abspielen. Aber ich habe keinen MP3 Player gefunden, dessen Schaltflächen mit Namen versehen sind. Statt dessen wird nur die Nummer der Schaltfläche im SourceCode ausgegeben („Schaltfläche Nummer 96“). Das gilt sowohl für den vorinstallierten LifePlayer, als auch für den Standard Android Player und auch für Player von Drittanbietern. Hätte ich das vorher herausfinden können, ich hätte mir viele vergebliche Mühen sparen können.
    Da hatte ich doch mehr erwartet, gerade was die Standardsoftware angeht.
    P.S. Ich bin selbst nciht sehbehindert, sondern wollte das Gerät für meine Mutter einrichten, die erblindet ist.

    1. Hallo Klaus,
      Tja, willkommen in der fragmentierten Android-Welt! Medion ist nicht Google Nexus ist nicht Samsung ist nicht Sony ist nicht LG ist nicht sonstwas. Da baut jeder seine eigene Oberfläche, kocht sein eigenes Süppchen und rotzt einem dann auch mal völlig unzugänglichen Mist aufs Tablet. Sorry, dass Du es auf diese Weise erfahren musst!
      Ganz ehrlich: Wenn Du Deiner Mutter einen riesigen Gefallen tun willst, besorg‘ ihr ein iOS-Tablet, also ein iPad. Sie wird mit keinem Android glücklich werden. Ich habe selbst gerade ein Experiment vorzeitig beendet, bei dem ich 30 Tage ein Android-Gerät nutzen wollte. Ich bin an Tag 18 endgültig ausgestiegen.

Was denkst Du darüber?