Viele mobile Apps erscheinen heute parallel für Android und iOS. Auf den ersten Blick wirken die Varianten nahezu identisch. Doch bedeutet das auch, dass sie in Sachen Barrierefreiheit gleich gut funktionieren?
Reicht es aus, nur eine Plattform zu prüfen – oder verbergen sich unter der Oberfläche unterschiedliche Hürden für Nutzende mit Behinderungen?
Eine App, zwei Plattformen, unterschiedliche Barrieren?
Viele mobile Apps werden in Varianten sowohl für Android als auch für iOS entwickelt. Diese Varianten sehen oft ähnlich aus und funktionieren ähnlich. Viele Anbieter fragen sich, ob es ausreicht, die Barrierefreiheit auf nur einem der beiden Systeme zu prüfen. Diese Frage stellt sich besonders dann, wenn eine Entwicklungsumgebung wie Flutter oder React Native genutzt wird, um sogenannte Cross-Platform-Apps – also Varianten für beide Betriebssysteme – zu generieren.
Bei vielen Anforderungen, die sich auf visuelle Eigenschaften beziehen, gibt es tatsächlich gleiche oder sehr ähnliche Ergebnisse. Dazu gehört zum Beispiel der Kontrast von Text und Grafiken sowie die Größe interaktiver Elemente. Auch Informationen, die nur über Farben vermittelt werden, und Anforderungen an eingebundene Medien, etwa Untertitel bei Videos, fallen darunter.
Anders sieht es aus, wenn man Barrieren untersucht, die sich bei der nicht-visuellen Nutzung mit dem Screenreader zeigen. Das Hilfsmittel ist in den Bedienungshilfen der Betriebssysteme integriert und gibt visuelle Informationen als Sprache aus.
Häufig zeigen sich Unterschiede, wenn man die iOS-Variante der App mit dem Screenreader VoiceOver und die Android-Variante mit dem Screenreader TalkBack untersucht und anschließend bei aktiviertem Screenreader mit den Apps interagiert. So sind manche grafischen Bedienelemente in der einen Version unbenannt, in der anderen nicht. Auch Rollen- und Zustandsinformationen solcher Elemente sind häufig unterschiedlich.
Auch für Tastaturnutzende gibt es gravierende Unterschiede, besonders bei der Tab-Reihenfolge. Bei Einbindung von sogenannten web views in native Apps ist das Verhalten oft uneinheitlich: Ein Inhaltbereich ist beim ersten Aufruf nicht erreichbar, später dann doch. Leider sind solche Probleme nicht immer reproduzierbar.
Wer sich jetzt fragt: Moment, warum testet man denn überhaupt Apps mit der Tastatur, die nutze ich doch über Touchgesten? – den oder die muss ich auf einen späteren Beitrag dieser Blogserie vertrösten.
Kurze Zwischenfrage: Gibt es nicht Betriebssystem-Alternativen? Immer wieder werden, meist basierend auf Linux / Android, Alternativen entwickelt, die bisher auf dem Markt für Endnutzende aber keine große Rolle spielen. Die Weiterentwicklung von Windows Mobile wurde eingestellt, der Support endete im Jahr 2019. Android und iOS teilen sich in Deutschland den Markt – in anderen Ländern wie China hat das Android-basierte Betriebssystem HarmonyOS signifikante Marktanteile. Huawei hat zudem einen eigenen (vermutlich TalkBack-basierten) Screenreader namens NEXT entwickelt. Außerdem gibt es weiter Versuche, Alternativen zu Android zu entwickeln. Der Artikel Open Source Mobile OS Alternatives to Android gibt einen recht aktuellen Überblick. Aufgrund der Dominanz von Android und iOS fokussieren wir jedoch in dieser Blogserie auf diese beiden Plattformen.
Einem Anbieter, der die Zugänglichkeit verbessern und gesetzliche Vorgaben wie das Barrierefreiheitsstärkungsgesetz (BFSG), die Barrierefreie-Informationstechnik-Verordnung (BITV) oder entsprechende Landesverordnungen erfüllen möchte, bleibt also nichts übrig, als beide App-Versionen zu testen. Dies gilt auch, wenn eine Cross-Platform-Entwicklungsumgebung wie Flutter oder React Native eingesetzt wurde, denn bei der Übersetzung in die Zielplattformen iOS und Android tauchen oft Unterschiede hinsichtlich der Barrierefreiheit auf.
Alle Felder sind Pflichtfelder