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.

In Pocket speichern vorlesen Druckansicht 2 Kommentare lesen
Barrierefreiheit: Stolpersteine bei mobilen Anwendungen überwinden, Teil 2
Lesezeit: 13 Min.
Von
  • Roman Zimmer
  • Alexander Huber
  • Martin Kinting
Inhaltsverzeichnis

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.

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.

Mehr Infos

Barrierefreiheit: Stolpersteine bei mobilen Anwendungen überwinden

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.

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.

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)

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)

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

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

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 TextViews) 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.