Accessibility im Überblick – Teil 3

Accessibility Labels optimieren

Im vorangegangenen Artikel dieser Serie haben wir uns detailliert mit den Accessibility Labels auseinandergesetzt. Sie dienen dazu, Views mit einem alternativen Text zu versehen, der vom System vorgelesen werden kann. Das ist für die Funktionsweise von Techniken wie VoiceOver enorm wichtig.

Doch einfach ein Accessibility Label mit einem (scheinbar) passenden Wert zu setzen, reicht meist nicht. Es ist wichtig, sich als Entwickler Gedanken darüber zu machen, in welchem Kontext eine View zum Einsatz kommt, und auf Basis dessen ein passendes Accessibility Label zu wählen.

Im Folgenden gehe ich auf ein paar Aspekte ein, die bei der Wahl eines passenden Accessibility Labels eine Rolle spielen und worauf zu achten ist.

Doppelte Beschreibungen vermeiden

Setzt man ein Accessibility Label für einen Button, kann man getrost auf die explizite Angabe „Button“ verzichten. Dazu ein Beispiel:

addNoteButton.accessibilityLabel = "Add note button"

Das Problem hierbei ist, dass das System dem Nutzer automatisch mitteilt, um welche Art von View es sich handelt; im Falle eines Buttons benennt das System die View also entsprechend. Fügt man nun aber jene View-Art auch in das Accessibility Label mit ein, führt das bei der Ausgabe via VoiceOver zu einer unschönen Dopplung. So wird der eben gezeigte addNoteButton mit VoiceOver wie folgt wiedergegeben:

„Add note button, Button“

Die Traits einer View bestimmen, welche Funktion sie innehat, und das System gibt in bestimmten Fällen eine entsprechende Info darüber aus. Ein Button besitzt den Trait Button, womit man sich einen gleichnamigen Text in einem Accessibility Label sparen kann. Das Beispiel von addNoteButton lässt sich entsprechend so besser umsetzen:

addNoteButton.accessibilityLabel = "Add note"

Kontext beachten

Ein Accessibility Label ist mehr als eine Beschreibung eines Elements. Betrachten wir dazu als Beispiel einen simplen Plus-Button. Womöglich würde man dessen Accessibility Label wie folgt setzen:

plusButton.accessibilityLabel = "Plus"

Das mag für uns einleuchtend erscheinen, doch gilt das auch für den Nutzer? Insbesondere, wenn er nicht erkennen kann, in welchem Kontext der Plus-Button zum Einsatz kommt? Was für eine Funktion besitzt dieser Button überhaupt? Fügt er beispielsweise in einer Shopping-App einen Artikel zum Warenkorb hinzu? Oder zur Favoritenliste? Oder erweitert er den Bereich des Beschreibungstextes?

Solche Fragen sollen beim Nutzer nicht aufkommen. Es soll klar sein, welche Funktion ein Element besitzt. Verwendet man also ein generisches Element wie den beschriebenen Plus-Button in einer App, sollte man das Accessibility Label an jeder Stelle immer passend setzen, beispielsweise wie folgt:

plusButton.accessibilityLabel = "Add to cart"

Unnötige Details vermeiden

So wichtig es ist, ein klar verständliches und zum Kontext passendes Accessibility Label zu wählen, sollte man sich dennoch nicht in Details verlieren.

Betrachten wir hierzu als Beispiel eine App zur Wiedergabe von Musik. Die Player-Ansicht verfügt über einen Play-, Pause- und Next-Button, die jeweils mit einem passenden Accessibility Label versehen werden sollen. Eine erste Idee für eine entsprechende Umsetzung sähe womöglich wie folgt aus:

playButton.accessibilityLabel = "Play song"

pauseButton.accessibilityLabel = "Pause song"

nextButton.accessibilityLabel = "Next song"

Prinzipiell ist an dieser Umsetzung nichts verkehrt. Doch der Kontext stellt eigentlich klar, dass wir es in dieser Anwendung mit der Wiedergabe von Songs zu tun haben; schließlich nutzen wir eine Musik-App. Entsprechend kann man sich die unnötige Wiederholung von „song“ innerhalb der Accessibility Labels in diesem Kontext auch getrost sparen:

playButton.accessibilityLabel = "Play"

pauseButton.accessibilityLabel = "Pause"

nextButton.accessibilityLabel = "Next"

Fazit

Accessibility Label ist nicht gleich Accessibility Label. Es ist wichtig, sich genau Gedanken darüber zu machen, welche Informationen man für einer View via VoiceOver transportieren möchte bzw. muss. Dabei gilt: so viele Details wie nötig, aber auch so wenig wie möglich. Das erleichtert Nutzern die Bedienung und sorgt dafür, dass eine App, die über gute und passend gewählte Accessibility Labels verfügt, eher genutzt und weiterempfohlen wird.

Euer Thomas

Bisherige Artikel in dieser Serie


Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert