Ein Leitfaden für barrierefreie Apps

Die Bedienungshilfen von iOS

Kommen ein Blinder, ein Tauber und ein Rollstuhlfahrer in den Apple Store...

Alleine in Deutschland gelten knapp 10 Millionen Menschen als schwerbehindert (Stand 2018, statistisches Bundesamt), somit stehen fast 10% der Gesamtbevölkerung bei der Bewältigung ihres Alltags vor ganz unterschiedlichen, individuellen und oft erheblichen Herausforderungen.

Vieles was für die meisten von uns ganz normal ist, stellt andere vor unterschiedlichste Probleme, Herausforderungen oder ist sogar unmöglich. Natürlich stellt die Bedienung moderner Smartphones hier keine Ausnahme dar. Für Menschen mit Beeinträchtigungen beim Hören, Sehen, bei der Motorik oder der Kognition entstehen eine Vielzahl an Hürden die der produktiven Nutzung eines Smartphones im Wege stehen: Die Texte sind teilweise viel zu klein, um bereits bei leichten Sehschwächen noch mühelos gelesen werden zu können. Die Bedienung umfangreicher Apps mit Fingergesten auf dem kleinen Bildschirm kann für Menschen mit motorischen Einschränkungen nahezu unmöglich sein.

Um diese Menschen abzuholen, ihnen ein möglichst barrierefreies Nutzungserlebnis moderner Technologie zu ermöglichen, bietet Apples mobiles Betriebssystem iOS eine Vielzahl unterschiedlicher Hilfsfunktionen und Konfigurationsmöglichkeiten, die sogenannten Bedienungshilfen, auch als Accessibility Features bezeichnet.

 

Was ist Accessibility? 

Übersetzen lässt sich der Begriff mit Barrierefreiheit oder auch Zugänglichkeit. Einfach gesagt gilt etwas accessible, also leicht zugänglich bzw. barrierefrei, wenn es 1) leicht anzueignen 2) leicht zu benutzen und 3) leicht zu verstehen ist. 

Im Folgenden werde ich zunächst einen Überblick über die Möglichkeiten geben, die iOS mit den Bedienungshilfen anbietet um eine inklusive, für möglichst viele Menschen optimale Nutzungserfahrung ihres Gerätes zu ermöglichen. Die einzelnen Bereiche unterteile ich nach den unterstützten Sinnesbereichen, also Sehen, Motorik und Hören. Im Anschluss stelle ich noch allgemeine Bedienungshilfen vor, die sich nicht in einen dieser Bereiche einteilen lassen. Im nächsten Teil gehe ich darauf ein was getan werden muss, um den Stand der Zugänglichkeit bei einer bestehenden App zu messen und wie man Barrierefreiheit testen kann, um sie letztendlich optimieren zu können. Weiter werde ich zeigen wieso es sinnvoll ist den Aspekt der Barrierefreiheit bei der Konzeptionierung und Entwicklung einer App bereits von Anfang an mitzudenken und zu berücksichtigen. Dann gehe ich noch auf einige der Herausforderungen ein, auf die man beim Design oder der Entwicklung einer App unweigerlich stößt, wenn man die Accessibility Features bestmöglich unterstützen will, stelle Lösungsmöglichkeiten vor und werde abschließend aufzeigen wieso die breite Unterstützung von Bedienungshilfen nicht einfach nur “das Richtige” zu tun ist, sondern wie sehr die ganze App und alle Nutzer davon profitieren können. 

 

Die Bedienungshilfen von iOS - ein Überblick

Viele Funktionen der Bedienungshilfen können direkt beim ersten Einrichten des Geräts aktiviert werden. Im Einstellungsmenü lassen sie sich anschließend noch konfigurieren und granular an individuelle Bedürfnisse anpassen. 

Und was sind solche Bedienungshilfen jetzt ganz konkret? 

Im Folgenden gehe ich kurz auf die wichtigsten Features und Möglichkeiten ein, die iOS an Unterstützung für unterschiedlichste Bedürfnisse und Herausforderungen zu bieten hat. 

 

Sehen 

Um ein Smartphone produktiv nutzen zu können, ist es unerlässlich sehen und erkennen zu können was auf dem Bildschirm passiert… möchte man meinen, tatsächlich aber hat sich Apple eine ganze Menge einfallen lassen, um es Menschen mit unterschiedlichsten Sehbehinderungen und/oder -einschränkungen zu ermöglichen ein iPhone nutzen zu können ohne dabei auf fremde Hilfe angewiesen zu sein. 

VoiceOver ist hierbei sicherlich das Prunkstück von iOS, was man schon daran erkennt, dass es als einziges Accessibility Feature seinen coolen techy Namen nicht in der deutschen Übersetzung des Betriebssystems verloren hat. Das auch nicht zu unrecht, VoiceOver ist ein durchaus mächtiges Feature, weit mehr als eine bloße Vorlesefunktion. Natürlich steht das Vorlesen von Bildschirminhalten im Vordergrund, aber VoiceOver kann noch mehr, wie etwa Bilder und Gesichtsausdrücke von Personen in Fotos beschreiben und Texte in Bildern oder Fotos vorlesen; von völlig unkommentierten Bildern und Fotos wohlgemerkt. 

Gesteuert wird VoiceOver über eine eigene Gestensteuerung die individuell anpassbar ist und auch Gesten bietet, die dem normalo iOS Nutzer bisher verborgen waren, etwa der sogenannte Rotor: Durch eine Drehgeste mit zwei Fingern, so als würde man einen Drehknopf bedienen, navigiert man sich durch Webseiten, Dokumente oder Apps; also fast wie das Drehen von Bildern und ähnlichem. Bei einer Zeitungs Webseite kann man via Rotor von Überschrift zu Überschrift springen und sich nur diese vorlesen lassen - wenn denn daran gedacht wurde, den entsprechenden Inhalt daraufhin auch zu optimieren. VoiceOver hilft auch bei der Texteingabe, verschiedene Modi u.a. auch Handschrift werden unterstützt. Braille kann VoiceOver natürlich auch, systemweit werden Braillecodes in 6- und 8- Punkt Braille unterstützt, so lässt sich Braille auch ohne physische Braille-Tastatur eingeben. Diese werden aber umfangreich unterstützt, insgesamt über 80 internationale Brailletabellen und mehr als 70 aktualisierbare Braillezeilen. Der richtige VoiceOver Power-User kann dann noch per Aussprache-Editor die Vorlese Funktion ganz auf eigene Bedürfnisse anpassen, sämtlichen Gesten eigene Befehle zuweisen und mit dem Bildschirmvorhang das Display deaktivieren - es wird ja nun nicht mehr gebraucht (:  


VoiceOver in iMessage, Bild: NEXT Munich

 

iOS bietet neben VoiceOver aber noch weitere unterschiedliche Sehhilfen für die kleinen Bildschirme. Für den der es braucht können mit einer Lupe Bildschirminhalte bis 1500x vergrößert werden, mit Zoom die Texte systemweit vergrößert werden, noch weit mehr als in den herkömmlichen iOS-Tastatureinstellungen.

iOS kann aber nicht nur vorlesen und vergrößern, auch die Darstellung der Inhalte an sich kann individuell angepasst werden. Der Kontrast lässt sich systemweit erhöhen, Transparenz und Bewegungen lassen sich reduzieren, hier nicht ganz unwichtig: diese Einstellungen funktionieren auch dann noch wenn der schicke Darkmode aktiv ist. 

Audiobeschreibungen, also das Vorlesen der Audiobeschreibungen von Videos, gibts natürlich auch. 

 

Motorik

iOS denkt auch an Menschen mit motorischen Einschränkungen. Das korrekte Bedienen eines handtellergroßen Touchscreens kann schon ohne motorische Einschränkungen eine Herausforderung sein, zum Glück hat Apple auch an diejenigen gedacht, die nicht nur zu tollpatschig zum Bedienen eines Touchscreens sind sondern für die das ohne Weiteres schlicht nicht möglich ist. Neben einer systemweiten und vielseitig einstellbaren Sprachsteuerung, einem umfangreichen Support für die Schaltersteuerung durch adaptives Zubehör, kann auch das Verhalten des Gerätes bei Berührungen geändert werden. So gibt es einen Einhandmodus, die Haltedauer bei Streichgesten ist konfigurierbar, wiederholte Berührungen können ignoriert werden und und und… Selbst Face-ID kann mit Hilfe der Bedienungshilfen eingerichtet werden, falls man nicht in der Lage sein sollte, seinen Kopf in der vorgeschriebenen Weise zu bewegen. Die Funktionen der wenigen - aber noch vorhandenen - physischen Knöpfe können ebenfalls angepasst werden. Sowohl die Bildschirm- wie auch eine angeschlossene physische Tastatur können ebenfalls konfiguriert und mit Accessibility Features versehen werden. 

 

Hören

 

Hörhilfen Konfiguration in iOS, Bild: apple.com

 

Der dritte große Bereich der Bedienungshilfen behandelt das Hören. Moderne Hörhilfen sind kompatibel mit iOS und können dort auch vielseitig angepasst werden. Die beiden Protokolle RTT (Real-Time Text) und TTY (Teletype) ermöglichen es Menschen, denen Hören oder Sprechen Schwierigkeiten bereitet, per Telefon zu kommunizieren. So kann Text beim Schreiben übermittelt werden und dem Empfänger das sofortige Lesen der Nachricht erlauben. RTT übermittelt beim Eingeben von Text zusätzlich Audiosignale. Selbst Notrufe können so abgesetzt werden, wenn die örtlichen Behörden RTT/TTY unterstützen. 

Weitere granulare Anpassungsmöglichkeiten sind etwa die Möglichkeit den LED Blitz anstelle von Audiosignalen für Hinweise verwenden zu können und verschiedene Einstellungen der Tonwiedergabe des Gerätes wie Mono-Audio, Audiobalance oder Noise Cancelling.

 

Allgemein

Ein ebenfalls zentrales Element der Bedienungshilfen stellt der geführte Zugriff da - zumindest in Marketing-Dokumenten - passend zu VoiceOver - gerne auch AssistiveTouch genannt. Mit dem geführten Zugriff kann das Touch Display an individuelle Bedürfnisse angepasst werden, so können die Gestensteuerung geändert, eigene Gesten erstellt und das Layout des AssistiveTouch Menüs konfiguriert werden. Das iPhone kann sogar darauf konfiguriert werden, befestigt an einem Rollstuhl als dessen Steuerzentrale zu dienen, wer braucht da noch CarPlay? 

Nicht vergessen werden darf natürlich Siri, die digitale Assistentin von Apples mobilem Betriebssystem. Siri ist oftmals die einfachste Möglichkeit, die Bedienungshilfen auf einem iOS Gerät zu nutzen. Zum einen können die vielfältigen Fähigkeiten Siris Menschen mit körperlichen Einschränkungen beim Erreichen ihrer Ziele direkt unterstützen zum anderen lassen sich die Bedienungshilfen auch mit Hilfe von Siri einrichten, anpassen und verwalten. Zudem lässt sich Siri nicht nur per Sprache sondern auch per Texteingabe steuern und auch Siri’s Sprach-Feedback lässt sich konfigurieren. 

Neben Siri gibt es noch ein weiteres iOS Feature, welches zwar nicht zu den Bedienungshilfen zählt, aber als solche wertvolle Dienste verrichten kann und zwar die Kurzbefehle, auch Shortcuts genannt. Mit der Kurzbefehle App lassen sich Kurzbefehle erstellen, die aus mehreren Arbeitsschritten bestehen können, somit lassen sich ganze Arbeitsabläufe automatisieren. Ähnlich einem Baukasten lassen sich einzelne Aktionen anpassen, mischen und zu Aktionsketten zusammenfügen, die dann per Knopfdruck ausgeführt werden können. Solche Kurzbefehle lassen sich natürlich auch in Verbindung mit den Bedienungshilfen erstellen, diese können somit einfach verwaltet, schnell ein- und wieder ausgeschalten werden und durch Kombination einzelner Aktionen können völlig neue Tools geschaffen werden, die individuell auf die Bedürfnisse des Nutzers hin optimiert sind. 

 

Kurzbefehle-App, Bild: NEXT Munich

 

 

Und wie kriegt man jetzt eine barrierefreie App? 

Okay, was iOS alles kann weiss ich jetzt, aber ich habe immer wieder gelesen, dass App bzw. Inhalt auch daraufhin ausgerichtet sein müssen. Ich bin jetzt in der Realität angekommen und will allen Menschen gleichermaßen unkomplizierten Zugang zu meiner App ermöglichen, wie geht das und vor allem, wird das teuer? 

Wie meist bei pauschalen Fragen ist hier die Antwort: „Jein“. 
Wird eine App neu konzipiert und werden die Möglichkeiten der Bedienungshilfen von Anfang an mitgedacht, dann entsteht dadurch kein großer Mehraufwand, es entsteht vielmehr eine Menge Mehr-Nutzen, dieser sogar, wie ich später noch ausführen werde, dort wo man ihn zunächst nicht vermuten würde. 

Anders kann dies aber bei bestehenden Applikationen der Fall sein. Diese fit zu machen für die verfügbaren Accessibility Features hängt ganz von deren bestehender Architektur ab. Handelt es sich etwa um Legacy-Code der noch vor AutoLayout geschrieben wurde, dann könnte sich die Etablierung einer äußerst dynamischen Anzeige, wie sie für einige Bedienungshilfen benötigt wird, als ziemlich kompliziert und aufwändig erweisen.

Um festzustellen wie es um die Zugänglichkeit einer bestehenden App bestellt ist, gibt es zwei, also eigentlich doch nur eine Möglichkeit: testen

Mit zwei meine ich einmal das menschliche Testen durch Bedienung der App mit aktivierten Bedienungshilfen und einmal das automatisierte Testen durch Tools wie etwa den AccessibilityInspector. Mit doch nur einer Möglichkeit meine ich, dass man beides machen muss, wenn man es richtig machen will. 

Beim automatisierten Audit oder einfach auch Test genannt, wird die App von einem Programm wie etwa dem AccessibilityInspector, einem Entwickler Tool in Xcode, überprüft und auf Unterstützung der Bedienungshilfen hin untersucht. Sehr praktisch ist hier die so genannte live preview Funktion mit der man die App mit verschiedenen Accessibility Features direkt testen kann ohne dazu jedesmal in die Systemsteuerung gehen zu müssen um die entsprechenden Tools zu aktivieren und deaktivieren. 

Da solche Tools aber bisher zumindest noch keinen Kontext verstehen, bleibt der Test durch einen humanoiden Tester bis auf Weiteres unerläßlich.

Der Inspector erkennt zwar ob ein Element ein accessibility label hat oder nicht - zu diesen Labeln später noch mehr - ob das aber auch Sinn macht kann er nicht beurteilen. 

Ein menschlicher Test gestaltet sich dann so, dass ein Tester via VoiceOver und anderen Bedienungshilfen die App zunächst wie ein normaler Nutzer nutzt, dann bei sämtlichen Features sicherstellt, dass sie überhaupt noch funktionieren; das klingt erstmal trivial, aber man muss bedenken, dass bspw. der löschen Button oft kein sichtbares Element ist, sondern erst durch eine Geste, durch Wischen nach links, an die Oberfläche gebracht werden muss. Ist eine App nicht für Accessibility Features optimiert, dann wäre der löschen Button in diesem Falle für VoiceOver nicht verfügbar. Nicht mehr ganz so trivial. 

Anschließend wird dann noch nach Optimierungen und Tweaks gesucht wie man die App noch besser zugänglich machen könnte. Gar nicht mal so überraschenderweise stellt sich dann meist heraus, dass wenn eine App unnötig kompliziert mit Accessibility Features zu bedienen ist, dann ist sie es ohne auch.

 

Bei einer neuen App lohnt es sich also, aber wie geht barrierefrei jetzt konkret?

Nicht nur die Unterstützung der Bedienungshilfen sondern eine ganzheitliche Herangehensweise an die Thematik Zugänglichkeit sollten bereits von Anfang an eine zentrale Rolle während des Entstehungsprozesses einer App spielen und bei jedem Aspekt mitgedacht werden. 

Beispiele: es gibt 17 unterschiedliche Ausprägungen von Farbblindheit und viele Apps nutzen Ampellicht in unterschiedlichen Ausprägungen um Feedback allerlei Art zu geben, da müssen verschiedene grün und orange Töne auseinandergehalten und korrekt zugeordnet werden. Oft werden auch unterschiedliche Werte, dynamisch oder nicht, in lediglich graduellen Abstufungen der Intensität von ein und derselben Farbe reflektiert, man denke bspw. an den Ladestand von Elektrogeräten oder den Fettgehalt von Milch. Dass solche Design-Entscheidungen Menschen mit eingeschränktem Sehvermögen oder Farbblindheit vor Probleme stellen, ist eigentlich offensichtlich und zudem leicht vermeidbar. Man kann einerseits schon beim Entwurf einer App deren Darstellung in diversen Accessibility Features wie erhöhte Kontraste oder invertierte Farben berücksichtigen, andererseits könnte man auch auf Farbabstufungen o.ä. verzichten und stattdessen Symbole verwenden, die unabhängig ihrer Farbe verstanden werden können. 

Wie eine App aussieht auch wenn die Texte deutlich vergrößert dargestellt werden, sollte auch schon von Anfang an berücksichtigt werden. Hierbei sollten mindestens drei Aspekte beachtet werden: Der Text muss groß genug sein um lesbar zu sein, der Text muss vollständig lesbar sein und die UI der App soll immer noch schön aussehen. Jetzt könnte man bei längeren Texten die Zeichengröße skalieren, das würde ihn aber im Zweifel unlesbar machen. Eine weitere Möglichkeit wäre es die Textgrenzen zu beschränken, dann wäre er aber ab einer gewissen Größe und Länge ausgepunktet. Den Text in mehrere Zeilen zu wrappen könnte in diesem Fall die beste Wahl sein. Werden solche Probleme zu Beginn bereits gelöst, profitiert die App während ihres gesamten Lebenszyklus davon. 

Je dynamischer das Layout, desto besser beherrscht eine App unterschiedliche Bildschirmgrößen und -auflösungen und die Anpassung an neue Bildschirme und Geräte wird potentiell erleichtert, es ist also immer auch eine Investition in die zukunftssicherheit einer App. 
 

Ok. Cool. Konzept steht und jetzt?

Ein auf Inklusion ausgerichtetes und für die Bedienungshilfen optimiertes Konzept ist noch nicht alles. Natürlich muss man das auch während der Entwicklung beachten. 

Vereinfacht gesagt muss der Entwickler erst einmal jedes Element korrekt für die Bedienungshilfen markieren, also labeln. Jedes Objekt einer App kann ein Accessibility Element werden, wenn es mit dem entsprechendem Label versehen wird. So ein Label ist eine lokalisierte Zeichenfolge die das Element eindeutig identifiziert. So wissen VoiceOver und Konsorten das Objekt einzuordnen und können korrekt damit umgehen. VoiceOver ist schlau genug die Art des Objektes zu erkennen, also ob es sich um einen Button, ein Eingabefeld, ein Bild oder sonstwas handelt. Sobald eine App vernünftig gelabelt ist können bereits alle zentralen Bedienungshilfen damit umgehen. 

Beim vergeben von Labeln gibt es einige Herausforderungen, die bedacht sein mögen; so ist es etwa von zentraler Bedeutung den Kontext immer im Blick zu haben. Beispiel: Ein Plus Button soll ein Accessibility Label erhalten. Einfach nur “plus” ist im Zweifel wenig hilfreich, hier spielt der Kontext eine Rolle: handelt es sich um einen Button mit dem man Produkte in den Warenkorb legen kann, dann könnte “add to cart” ein passendes Label sein; handelt sich vielleicht um eine Favoritenfunktion, wäre “add to favorites” sinnvoll. Man merkt wie wichtig hier ausreichender Kontext ist. Dabei sollte aber beachtet werden das Ganze nicht zu übertreiben,sonst läuft man Gefahr redundante Label zu vergeben die den Nutzer eher nerven als einen Mehrwert bieten. Die Steuerungselemente eines Musikplayers etwa mit Labeln wie “play song”, “pause song”, “previous song”, “next song” usw. zu versehen muss nicht nötig sein, wenn der Kontext klar ist, könnte “play”, “pause”, “previous”, “next” etc.. bereits ausreichend sein. 

Hierbei gilt je spezifischer und konziser Label vergeben werden, umso besser wird die App mit den Bedienungshilfen bedienbar. 

Auch können nicht nur Bedienelemente mit Labeln versehen werden, im Grunde kann jedes Objekt ein Accessibility Label erhalten und sollte es auch wenn es denn sinnvoll ist. So sollten bedeutsame Bilder oder Animationen, die dem Nutzer wichtige Informationen oder Feedback geben ebenfalls mit Labeln versehen werden, damit sie zugänglich für die Accessibility Features werden. Man denke etwa an eine Ladeanimation, die dem Nutzer mitteilt wie weit der Ladefortschritt bereits fortgeschritten ist oder ein grünes Häckchen, dass das erfolgreiche Ausführen einer Aktion symbolisiert. Auch hier sollte man wieder den Kontext beachten, “green checkmark” enthält als Label potentiell deutlich weniger sinnvolle Informationen als etwa “sign up complete” wenn es um eine Registrierung geht. 

Wurden nun alle passenden Elemente für die Bedienungshilfen markiert, dann zeigt sich zudem ein weiterer großer Vorteil an zunächst unerwarteter Seite, nämlich dem automatisierten UI Testing. Diese Art des Testings profitiert ungemein von den Labeln, weil so sämtliche Elemente beim Erstellen und auch Auswerten eines solchen Tests bereits durch die Markierungen eindeutig identifizierbar sind und ihre Funktionsweise klar benannt wird. Das Vereinfacht das Erstellen solcher Tests deutlich, genauso wie das Erstellen automatisierter UI Tests beim vergeben von Accessibility Labeln helfen kann. (Falls jetzt jemand mehr über automatisierte UI Tests erfahren will, ich verlinke hier mal ganz schamlos meinen Artikel darüber.)

Wird eine App in Apples Programmiersprache Swift neu entwickelt, dann funktioniert die Unterstützung der Bedienungshilfen standardmäßig dank der in SwiftUI enthaltenen Accessibility API. Bei der Entwicklung der Programmiersprache Swift hat Apple die Chance ergriffen, die Funktionsweise einiger seiner Tools für Entwickler neu zu überdenken und Barrierefreiheit wurde von Anfang an mit eingeplant. Sogenannte Accessibility Teams waren integraler Bestandteil des Entwicklungsprozesses. Das Ergebnis ist beachtlich: Bilder sind accessible by default, alle Steuerelemente sind mit Textnamen verknüpft und dynamic type ist die Standardeinstellung.

Das bedeutet, es sind dann nur noch App spezifische Anpassungen nötig falls die vorgegebenen Werte unvollständig sind oder Swift beim generieren des AUI (Accessibility User Interface) Fehler unterlaufen sind. Mit Hilfe von UIAccessibility lässt sich festlegen welche Elemente und Objekte überhaupt Accessibility Elemente sein sollen, das Verhalten der einzelnen Tools bei diesen Elementen kann bestimmt werden, ergänzende deskriptive Strings können vergeben werden, Bilder können eingeteilt werden als relevant für die Accessibility oder nur als dekorativ und eine Menge weiterer Möglichkeiten, um sicher zu stellen dass App und Bedienungshilfen bestmöglich zusammenarbeiten. 

 

Fazit

So, jetzt wissen wir was die Bedienungshilfen leisten können, wie man eine App daraufhin optimieren kann und wie jeder davon profitieren kann. Wir haben auch gesehen, dass es keinen Grund gibt, wieso man nicht bereits beim Entwurf des Grundkonstruktes die unterschiedlichen Nutzungsszenarien, die die Bedienungshilfen ermöglichen, berücksichtigen sollte. Accessibility Support ist aber keine einmalige Sache, die einmal aufgesetzt in alle Zukunft funktionieren wird. Bei jedem Update oder Umbau einer App muss darauf geachtet werden, dass alle Label noch Sinn ergeben und passende Informationen liefern, es geht ganz schnell dass durch eine kleine Änderung im Aufbau die Informationen in einem oder mehreren Labeln nutzlos oder im schlimmsten Fall ganz falsch werden. Das Ganze ist als Prozess zu verstehen, der eine App während ihrer gesamten Lebensdauer begleitet. 

Natürlich stellt das immer einen gewissen Mehraufwand dar, aber die Vorteile überwiegen bei Weitem: Nicht nur ist die möglichst inklusive Gestaltung einer App einfach das Richtige zu tun, es ermöglicht auch deutlich mehr Nutzern die App zu nutzen und bietet zudem die nicht zu unterschätzende Gelegenheit eine völlig neue Perspektive auf die eigene App zu erhalten.

 

Philipp Röder, Head of QA, pro@next-munich.com