Barrierefreiheit: Stolpersteine bei mobilen Anwendungen überwinden, Teil 2
Der barrierefreie Zugang zu Apps ist wichtig. Allgemeine Designrichtlinien und konkrete Maßnahmen helfen bei der Umsetzung.
![Barrierefreiheit: Stolpersteine bei mobilen Anwendungen überwinden, Teil 2](https://heise.cloudimg.io/width/610/q85.png-lossy-85.webp-lossy-85.foil1/_www-heise-de_/imgs/18/2/7/3/3/6/8/1/accessibility-shutterstock-f03f3155d0416c40.jpeg)
- Roman Zimmer
- Alexander Huber
- Martin Kinting
Im Frühjahr 2009 erschien die erste nach einer Süßspeise benannte Version des damals noch jungen mobilen Betriebssystems Android. Cupcake (Android 1.5) besaß noch keine Funktion zur barrierefreien Bedienung. Das änderte sich jedoch noch im gleichen Jahr mit der Veröffentlichung von Donut (Android 1.6) sowie Googles mobile Screenreader TalkBack. Damit hielt eine grundlegende Zugänglichkeit Einzug in Android, die kontinuierlich mit jeder neueren Version verbessert und dokumentiert wurde. Damit feiert der komfortable Weg, zugängliche Apps unter Android zu entwickeln, im Jahr 2019 zehnjähriges Jubiläum – eine gute Gelegenheit für einen Blick auf den Status quo.
Stolperfallen verhindern
Eine App unter Android zugänglicher zu gestalten, erfordert in der Regel keine größeren Umstrukturierungen des Quellcodes. Vielmehr gilt es, ähnlich wie bei der Unterstützung unterschiedlicher Displaygrößen einige grundsätzliche Empfehlungen und Ergänzungen zu beherzigen – idealerweise ab dem Start der Entwicklung. Bereits kleine Anpassungen während des Erstellens der Layoutdateien haben einen großen positiven Effekt auf die Zugänglichkeit der App.
Barrierefreiheit: Stolpersteine bei mobilen Anwendungen überwinden
- Teil 1: Herangehensweise und Hindernisse
- Teil 2: Praktische Umsetzung für Android
Allgemeine Designempfehlungen zum Gestalten zugänglicher Apps hat Google im Rahmen der Dokumentation zum Material Design veröffentlicht. Im Folgenden stehen daher konkrete Maßnahmen für Entwickler nativer Apps auf Basis der offiziellen Richtlinien von Google im Fokus. Die Codebeispiele konzentrieren sich vorwiegend auf die jeweils ausschlaggebenden XML-Attribute in den Layout-Ressourcen. Diese statischen Angaben sind zu wählen, wenn sich die Werte nicht zur Laufzeit der App ändern. Sollte sich das Aussehen der Bedienelemente beispielsweise durch Nutzerinteraktion dynamisch anpassen, gilt es, die jeweiligen Werte programmatisch zu setzen, um eine barrierefreie App-Bedienung zu gewährleisten. Die Beschreibung der XML-Attribute der View-Klasse hilft dabei, die passende dynamische Methode schnell zu finden.
Beschriftung von Elementen
Um die Funktion eines Bedienelements über einen Screenreader zu vermitteln, sollten Entwickler dem Bedienelement eine aussagekräftige Beschriftung (Label) gegeben. Dabei müssen sie das Vorleseverhalten des Screenreaders berücksichtigen und eventuelle textuelle Redundanzen vermeiden. Die meisten Screenreader einschließlich TalkBack nennen automatisch den Elementtyp, sodass zum beispielsweise "Speichern" eine bessere Beschriftung als "Speicher-Button" ist. Darüber hinaus greift das gewohnte Wechseln der Ressourcen abhängig von der (Sprach-)Konfiguration des Geräts. Die üblichen Regeln zum Lokalisieren von Android-Apps gelten somit auch für Beschriftungen im Interesse einer verbesserten Zugänglichkeit.
Eingabefelder
Bei einem Eingabefeld wie EditText
lässt sich das Label folgendermaßen über den Hinweistext setzen (ab API-Level 1):
Statisch (XML):
<EditText
...
android:hint="@string/label" />
Dynamisch (Kotlin):
editText.hint = getString(R.string.label)
Text- und grafische Elemente
Bei einem Textelement wie TextView
ist das Setzen eines Labels in der Regel nicht erforderlich, weil der Screenreader den angezeigten Text automatisch erfasst und wiedergibt. Umso wichtiger ist dafür eine klare und verständliche Ausdrucksweise.
Bei einem grafischen Element wie ImageView
oder ImageButton
lässt sich das Label – analog zum Alternativtext in HTML – über eine zusätzliche Beschreibung setzen (ab API-Level 4):
Statisch (XML):
<ImageButton
...
android:contentDescription="@string/label" />
Dynamisch (Kotlin):
imageButton.contentDescription = getString(R.string.label)
Ausschluss grafischer Elemente
Grafische Elemente, die ausschließlich einen dekorativen Zweck erfüllen, sollten Entwickler als irrelevant für den Screenreader markieren. Das Vorgehen hängt vom minimal unterstützten API-Level der App ab und ist wie folgt möglich:
Statisch (XML):
<!-- ab API-Level 4... -->
<ImageView
...
android:contentDescription="@null" />
<!-- ...oder ab minimalem API-Level 16 -->
<ImageView
...
android:importantForAccessibility="no" />
Dynamisch (Kotlin):
// ab API-Level 4...
imageView.contentDescription = null
// ...oder ab minimalem API-Level 16
imageView.importantForAccessibility =
View.IMPORTANT_FOR_ACCESSIBILITY_NO
Label-Elemente
Ab API-Level 17 lässt sich zudem definieren, dass ein Element als Label für ein anderes Element dienen soll:
Statisch (XML):
<TextView
...
android:text="@string/label"
android:labelFor="@id/input_field" />
<EditText
android:id="@+id/input_field"
... />
Dynamisch (Kotlin):
textView.labelFor = R.id.input_field
Gruppierung von Elementen
Logisch beziehungsweise inhaltlich zusammengehörige Elemente sollten gruppiert sein, sodass der Screnreader ihren Inhalt als zusammenhängende Einheit betrachtet und vorliest. Die Gruppierung lässt sich folgendermaßen über einen fokussierbaren Container in Form einer beliebige Unterklasse von ViewGroup
erreichen:
<LinearLayout
...>
<RelativeLayout
android:id="@+id/group1"
...
android:focusable="true">
<TextView ... />
<TextView ... />
</RelativeLayout>
<RelativeLayout
android:id="@+id/group2"
...
android:focusable="true">
<TextView ... />
<TextView ... />
</RelativeLayout>
</LinearLayout>
Eine ViewGroup
mit android:focusable="true"
bildet demnach eine Einheit, die der Screenreader als Ganzes anspringt und die enthaltenen Elemente zusammenhängend vorliest. Für obigen Code fokussiert das Vorleseprogramm die erste Gruppe group1
, liest deren Inhalt vor und setzt nach einer Nutzerinteraktion bei der zweiten Gruppe group2
seinen Dienst fort. Die einzelnen Kindelemente (hier die TextView
s) sind dabei nicht mehr direkt fokussier- beziehungsweise ansteuerbar. Das bedeutet für die Nutzer weniger Navigationsaufwand und erspart ihnen zudem unnötige Pausen beim Erfassen von wichtigen, zusammengehörigen Informationen.
Ein Hinweis sei noch angebracht: android:focusable
wirkt sich auf die Navigationsreihenfolge bei Nutzung von Eingabehardware wie einer Tastatur aus. Daher lässt sich ab Android 9 Pie (API-Level 28) das nur für Screenreader gültige android:screenReaderFocusable
anstelle von android:focusable
in Situationen benutzen, in denen Letzteres unerwünschte Seiteneffekte bei der Navigation hätte.