Barrierefreiheit von nativen Apps spielt eine immer größere Rolle: Erst in den letzten Jahren haben spezifische Prüftools und Prüf-Verfahren einen brauchbaren Stand erreicht. An dieser Stelle möchte ich meine häufigsten Findings als Nutzer und Tester von Apps zusammenfassen. Diese Liste ist also subjektiv.
Ich bin ein Android-First-Nutzer und verwende iOS aktuell eher nebenbei. Das heißt, ich kenne beide Betriebssysteme gleichermaßen.
Generelle Probleme
Natürlich findet man die häufigsten Design-Fehler bei Apps, die man auch im Web oder in Software findet: Unzureichende Kontraste, Information nur über Farbe, Interagierbarkeit mit Hintergrund-Elementen, nicht-steuerbare Animationen und Multimedia und so weiter. Darauf möchte ich hier nicht weiter eingehen, um den Artikel nicht zu umfangreich zu machen.
Generell sind mir in Android mehr technische Fehler als in iOS aufgefallen. Ob das an den Developer Guidelines der jeweiligen Anbieter liegt oder daran, dass die Entwicklerinnen mehr behinderte Menschen bei iOS vermuten und Android daher vernachlässigen, kann ich nicht sagen. Eventuell sind auch die Prüftools von iOS besser oder Apple macht es leichter, barrierefreie Apps zu entwickeln, weil das Nutzen von Standard-Komponenten erzwingt. Auch schreitet in diesem Bereich die Spezialisierung fort: Die meisten entwickeln nur für eine Plattform oder sind gar auf bestimmte Frameworks spezialisiert, die automatisch für beide Plattformen Apps erzeugen können. Auch hier könnte es sein, dass der Code für Apple trotz gleicher Basis barrierefreier ausgegeben wird.
Auch muss man im Hinterkopf haben, dass es systembedingte Limitierungen und Probleme gibt. Das heißt, dass beide Systeme nicht 1:1 vergleichbar sind. iOS hat zwar einen Vorsprung bei der Barrierefreiheit für Blinde, aber zumindest was VoiceOver angeht eine schlechte Software-Qualität. Jedes Update kann dazu führen, dass wichtige Funktionen Bugs haben, die erst mit dem nächsten Update gefixt werden. ‚Android Talkback hat weniger Konfigurations-Möglichkeiten und möglicherweise auch weitere Probleme. iOS ist vollständig und Android teilweise eine Blackbox, da der Anbieter des OS gleichzeitig der Anbieter der assistiven Technologie ist und weder Google noch Apple hier transparent sind, was Bugs und Limitierungen der assistiven Technologien angeht.
Generell wird gesagt, dass die Verwendung nativer Komponenten zu weniger Barrierefreiheits-Problemen führt. Allerdings sind nicht alle nativen Komponenten vollständig barrierefrei.
Tastatur-Bedienung
Wenige wissen, dass für native Apps im Prinzip die gleichen Voraussetzungen für die Tastatur-Bedienbarkeit gelten wie für Websites und Software. Das heißt vor allem Interagierbarkeit, Tastatur-Fokus und logische Tab-Reihenfolge. Das ist bei den Apps, die ich geprüft habe im Grunde nie vollständig erfüllt worden und wurde mit Sicherheit auch nicht von den Entwicklerinnen getestet.
Der Hintergrund ist, dass die Tastatur-Schnittstelle auch teilweise von anderen assistiven Technologien genutzt wird. Auch für die Eingabe von Zahlen oder komplexen Zeichenketten wie Passwörtern ist die Tastatur für Blinde wichtig.
Name, Rolle, Wert
Bei Android sieht man sehr häufig Elemente, die keine oder keine korrekte Beschriftung haben. Im letzteren Fall scheitern auch die automatischen Prüftools, die ja nur sehen, das eine Beschriftung wie „Android_Class_23_Btn“ vorhanden ist. Gleiches gilt für Rolle und Wert. Sehr häufig wird der Status eines Elements wie aktiviert/nicht aktiviert bei Änderung nicht korrekt ausgegeben.
Auch wesentlich häufiger bei Android sind Elemente ohne korrekte Rolle, allerdings auch auf der Ebene des Betriebssystems selbst. Ein Eintrag im Menü wird nur als Text vorgelesen, aber nicht als aktivierbares Element wie Menüpunkt, Link oder Button ausgegeben. Es reicht hier nicht, wenn aus dem Kontext deutlich wird, dass etwas anklickbar ist.
Sowohl Android als auch iOS verfügen mittlerweile über Algorithmen, um UI-Elemente automatisch zu erkennen. Das heißt allerdings nicht, dass diese Elemente dadurch auch bedienbar werden und besonders zuverlässig ist das auch nicht. Bei einem anklickbaren Element kann das noch funktionieren. Spätestens bei einem Slider wird es schwierig.
Ich treffe öfter auf UI-Elemente, die zwar korrekt hinterlegt zu sein scheinen, aber nicht komfortabel nutzbar sind. Ein Beispiel ist Microsoft Teams unter iOS: Ich habe einen Thread in einem Team und bekomme nur die erste Nachricht vorgelesen. Normalerweise könnte man mit einem Rechts-Wisch zur nächsten Nachricht in diesem Thread gehen, aber das funktioniert nicht (könnte auch ein temporärer Bug sein). Wenn es abweichende Interaktions-Muster gibt, sollten diese für den Screenreader-Nutzenden ausgegeben werden.
Die Deutsche Bahn nutzt in der Android-Version ein nicht gut nutzbares Element, um die Uhrzeiten für die Fahrplan-Auskunft einzustellen. Man soll den Finger auflegen und dann nach oben oder unten ziehen, bis die gewünschte Zahl erscheint. Bei Screenreader-Nutzung wird aber beim Wischen nicht die aktuell fokussierte Ziffer vorgelesen. Genau gesagt wird die Wischen-Geste gar nicht von Talkback unterstützt, man muss halten und ziehen, bis die gewünsche Zahl erscheint, die Zahl wird aber nicht vorgelesen, die aktuell im Fokus ist.
Kein EVent-Trigger bei Screenreader
Elemente, die auf normalen Tap reagieren, tun das oft nicht bei aktiviertem Screenreader, also Double Tap. Vermutlich wurden UI-Elemente nicht nativ umgesetzt.
Verschiedenes
Schwebende Elemente sind oft nicht in der Fokus-Reihenfolge bei Touch- oder Tastatur-Bedienung. Sie werden etwa bei Twitter verwendet, wenn neue tweets verfügbar sind.
Unter Android ist oft kein komfortables Scrollen in einem Endless-Scrolling-Bereich möglich, Beispiel ist wieder Twittter. Scrollt man durch Nachrichten, landet der Fokus relativ bald wieder auf einer Mitteilung, die man bereits gelesen hat, weil Talkback die Liste der Nachrichten anscheinend nicht selbständig runterscrollen kann. Allerdings weiß ich nicht, ob das ein Barrierefreiheits- oder ein Talkback-Problem ist.
Kein Support für den Landscape-Modus
Inhalte sollen die Nutzerin nicht auf eine bestimmte Ausrichtung des Bildschirms, in der Regel auf den Portrait-Modus festlegen (1.3.4 Orientation (AA)). Es sei denn, ein bestimmter Modus ist für die Funktionalität notwendig. Der Landscape-Modus wird aber bei vielen Apps gar nicht unterstützt.
Das ist nur eine Vermutung, aber vermutlich müssen die Elemente so gestaltet werden, dass sie frei floaten können. Im Webdesign würde man sagen, dass man ein spezielles Stylesheet für den Landscape-Modus benötigt. Es sähe natürlich albern aus und wäre nicht hilfreich, wenn man den Bildschirm quer hält und sich alle Elemente auf dem linken Drittel des Bildschirms zusammenquetschen.
Fehlender Support für Nutzerinnen-Einstellungen
Kapitel 11.7 der EN 301549 verlangt, dass die Einstellungen der Nutzerinnnen unterstützt werden, hier speziell die Einstellung der Schriftgröße und die Invertierung des Bildschirms. Letzteres wird oft von beiden Systemen nicht unterstützt, die im System eingestellte höhere Schriftgröße wird nicht übernommen oder es kommt zu Überlappungen.
Der invertierte Zustand wird von iOS oft nicht unterstützt, die App verbleibt im normalen Zustand. Bei Android werden vermutlich die Farben einfach systemseitig geändert, so dass die Apps es sich nicht aussuchen können, ob sie invertiert werden wollen oder nicht.
Auch wenn der Modus grundsätzlich funktioniert kommt es oft vor, dass Elemente verschwinden oder der Kontrast auf einmal nicht mehr ausreicht, vielleicht weil die Schriftfarbe gleich bleibt, obwohl der Hintergrund verändert wurde.