Lesezeit: ca. 10 min
Lernziele für diesen Abschnitt:
- Den Unterschied zwischen verschiedenen Ansätzen zur Entwicklung von mobilen Apps verdeutlichen
- Mögliche Probleme bei der Anwendung verschiedener Entwicklungsansätze aufzeigen
- Auf spezifische Richtlinien für die Entwicklung von mobilen Apps verweisen
Native Apps, plattformübergreifende Apps oder Web Apps
Permalink zu "Native Apps, plattformübergreifende Apps oder Web Apps"Es gibt verschiedene Arten von Apps: Native Apps, plattformübergreifende Apps und Web Apps. Hinsichtlich der Entwicklung und der sich ergebenden Barrierefreiheit gibt es wichtige Unterschiede. Bei der Entwicklung einer App steht am Anfang die Entscheidung, was für eine App erstellt werden soll. Grundlage hierfür ist auch, ob z.B. Code wiederverwendet werden soll. Hierfür eignen sich besonders native Apps oder Web Apps. Beide Arten von Apps lassen sich unter mehreren Betriebssystemen ohne oder nur mit geringen Anpassungen benutzen.
Native Apps
Permalink zu "Native Apps"Eine native App wird in der Programmiersprache des jeweiligen Systems entwickelt und nutzt direkt die Programmierschnittstelle der jeweiligen Plattform. Bei Apples iOS ist dies z.B. die Programmiersprache Swift, bei Android die Programmiersprachen Java und Kotlin.
Für die Entwicklung von barrierefreien Apps kann durch die enge Verzahnung mit der Plattform die dort angebotenen und dokumentierten Funktionen direkt genutzt werden. Native Apps haben daher den Vorteil, dass der Entwickler den maximalen Einfluss auf die Barrierefreiheit der App hat, da die einzige Abhängigkeit hier zu den Schnittstellen des Betriebssystems besteht. Wir gehen aktuell davon aus, dass dadurch auch die maximal mögliche Barrierefreiheit erreicht werden kann.
Die jeweiligen Richtlinien zur barrierefreien Entwicklung von nativen Apps zeigen auf, wie die Möglichkeiten der Plattform genutzt werden können, beispielsweise für Apple iOS (en). Die Android-Guidelines (en) umfassen sogar Hilfestellungen für die barrierefreie Gestaltung, die barrierefreie Entwicklung sowie zum Testen während der Entwicklung.
Plattformübergreifende Apps
Permalink zu "Plattformübergreifende Apps"Eine Alternative zu den nativen Apps stellen plattformübergreifende oder cross-platform Apps dar. Dabei wird die App zunächst auf der Basis eines speziellen Frameworks entwickelt, statt für eine bestimmte Plattform. Vereinfacht gesagt ist eine solche mit einem entsprechenden Framework entwickelte App erstmal plattformunabhängig. Das Framework erlaubt oftmals die Nutzung von vorgefertigten Bausteinen und Funktionen. Erst im letzten Schritt wird die auf diese Weise entwickelte App automatisiert an die Zielplattform „angepasst“.
Damit die App auf der Zielplattform funktioniert, wird eine Runtime (Laufzeitumgebung) benötigt. Diese führt den Code aus und stellt die Verbindung zum Betriebssystem her. Für die Barrierefreiheit bedeutet dies, dass im Fall der plattformübergreifenden Apps zwei Komponenten für die Barrierefreiheit verantwortlich sind. Zum Einen die App selbst, in der alle angebotenen Barrierefreiheitsfunktionen korrekt konfiguriert werden müssen. Zum Anderen die Laufzeitumgebung, die alle in der App konfigurierten Barrierefreiheitsfunktionen korrekt an die jeweiligen Schnittstellen des Betriebssystems weiterreichen muss. Für die Entwicklung einer App stehen also nur die Barrierefreiheitsfunktionen zur Verfügung, die sowohl vom eingesetzten Framework inklusive der Laufzeitumgebung, als auch vom jeweiligen Betriebssystem unterstützt werden.
Zur optimalen Umsetzung der Barrierefreiheit muss unter Umständen auf die Dokumentation des jeweiligen Frameworks zurückgegriffen werden, da die in der Dokumentation des Betriebssystems beschriebenen Funktionen im Framework eventuell nicht zur Verfügung stehen. Beispiele für solche Frameworks sind (ohne Anspruch auf Vollständigkeit) Qt (en), Xamarin (en) oder Flutter (en).
Bei der Nutzung von Frameworks sollte immer die aktuelle Version verwendet werden Grund hierfür ist, dass neue oder verbesserte Funktionen der Barrierefreiheit von den Herstellern als neue Funktionalität (englisch: Feature) und nicht als Fehlerbehebung (englisch: Bug) angesehen werden. In der Konsequenz werden diese nur in neuen Versionen umgesetzt. Eine entsprechende Aktualisierung in älteren Versionen findet häufig nicht statt. Auch kann der erreichbare Grad der Barrierefreiheit einer App davon abhängen, wie gut das verwendete Framework diese jeweiligen Funktionen implementiert hat.
Da sich die Barrierefreiheitsfunktionen der beiden großen Betriebssysteme Android und iOS unterscheiden, sollte beim Einsatz von Frameworks im Vorfeld der Entwicklung geprüft werden, ob und welche Beschränkungen bei einem Einsatz bestehen.
Web Apps
Permalink zu "Web Apps"Diese Apps basieren auf HTML-Seiten, die meist in einem gekapselten Browser dargestellt werden, der als Solches für die Nutzenden nicht zu erkennen ist. In Web Apps können alle HTML-Strukturelemente verwendet werden. Da die Darstellung mit Hilfe des Browsers erfolgt, ist auch die Zugänglichkeit identisch zu “normalen” Web-Seiten. Entwickler müssen für die Barrierefreiheit darauf achten, die Anforderungen der WCAG umzusetzen. Bei der Barrierefreiheit von Web Apps gibt es keinen Unterschied, ob diese im Browser auf dem Desktop oder als Web App auf dem mobilen Endgeärt dargestellt wird. Allerdings sollte bei der Gestaltung beachtet werden, dass sich das Aussehen und das Bedienverhalten nicht an einer Web-Seite, sondern an den Gestaltungsrichtlinien der jeweiligen Plattform und an den Bediengewohnheiten der Nutzenden orientiert. Dies ist für eine gute und effiziente Bedienung der Web App entscheidend und sollte explizit im Entwicklungsprozess aufgegriffen werden.
Eine besondere Form der Apps stellen die sogenannten hybriden Apps dar. Diese sind in der Regel eine Mischung aus der nativen oder plattformübergreifenden App, in der z.B. Inhalte als HTML dargestellt werden. Ein Beispiel hierfür sind Apps von Nachrichtenplattformen, in denen die einzelnen Artikel aus dem jeweiligen Web-Angebot eingebettet werden.
Alexander Pfingstl, Daniel Ziegler, Stephan Heinke · · CC-BY-SA 4.0