Im ersten Teil unserer Blogserie zum Testen mobiler Anwendungen beleuchten wir die zentralen Unterschiede zwischen der Prüfung nativer Apps und klassischen Webangeboten.
Die praktische Prüfung und Bewertung von Barrierefreiheit auf mobilen Plattformen unterscheidet sich in mehreren wesentlichen Punkten vom Web-Test. Dieser Beitrag ordnet mobile App-Tests im Kontext von WCAG, EN 301 549 und WCAG2ICT ein, und zeigt auf, welche methodischen und technischen Besonderheiten bei nativen Anwendungen zu berücksichtigen sind.
Die Grundlage für die meisten Tests der Barrierefreiheit von Websites und Anwendungen sind die Web Content Accessibility Guidelines (WCAG), derzeit gilt Version 2.2. Diese Richtlinien werden von der Accessibility Guidelines Working Group (AGWG) des W3C entwickelt. Sie bilden auch die Grundlage für den webbezogenen Teil der europäischen Zugänglichkeitsnorm EN 301 549 und indirekt auch für BITV 2.0, da sich diese Verordnung auf aktuelle europäische Normen bezieht.
Die WCAG-Dokumente und -Techniken helfen Entwicklern, Designern und Testern zu verstehen, was die individuellen Barrierefreiheitsanforderungen bedeuten, wie sie erfolgreich in die Webentwicklung integriert und wie sie bewertet werden können. Die WCAG-Dokumente sind jedoch auf Websites und Web-Anwendungen ausgerichtet. Das Testen von nativen mobilen Apps erfordert einen anderen Ansatz. Die Verwendung der integrierten Screenreader Talkback (Android) und VoiceOver (iOS) hat hier zum Beispiel einen höheren Stellenwert.
In Bezug auf die europäische Norm für Barrierefreiheit, EN 301 549 – die neueste, noch nicht veröffentlichte Version ist EN 301 549 V.4.1.0 (PDF) – fallen mobile Apps unter die Klausel 11 Software. Jeder, der sich diese Klausel ansieht, wird sofort erkennen, dass sie die in Klausel 9 Web wiedergegebenen WCAG-Erfolgskriterien weitgehend nachbildet. Ausgenommen sind sechs Erfolgskriterien, die nicht immer für Software passend sind – und hinzu kommen eine Reihe anderer Anforderungen, die z.B. speziell die Zugänglichkeit von Inhalten untersuchen, wenn Nutzende den Screenreader oder andere Hilfsmittel aktivieren. Was die WCAG-Erfolgskriterien betrifft, hat eine Taskforce der AGWG an einer neuen Version eines Dokuments namens Guidance on Applying WCAG 2 to Non-Web Information and Communications Technologies (WCAG2ICT) gearbeitet, welches die webbasierten Anforderungen der WCAG auf allgemeine Software und damit auch native mobile Apps überträgt. Die neueste Version, veröffentlicht im Dezember 2025, schließt auch Erfolgskriterien der WCAG 2.2 mit ein. Das Dokument zeigt, welche Anforderungen für Webtechnologien sich auf mobile Anwendungen übertragen lassen. Hinweise (NOTES) helfen, die Anwendung zu kontextualisieren bzw. die Anwendbarkeit einzuschränken.
Viele mobile Apps sind sogenannte „hybride“ Apps – sie enthalten Webinhalte, die in einer nativen Oberfläche verpackt sind. Oft wird die Navigation nativ erstellt, während die eigentlichen Inhalte über sogenannte Webviews eingebunden werden. Die Tagesschau-App ist ein Beispiel dafür. Während hier also tatsächlich „unter der Haube“ Web-Inhalte sitzen und die App den System-Browser für deren Darstellung nutzt, sind diese Inhalte dennoch Teil der mobilen App und müssen unter den Anforderungen für diese bewertet werden. Die neueste Version, EN 302 549 V4.1.0, stellt dies am Anfang von Klausel 11 Software fest:
„Wenn Teile von Nicht-Web-Software, wie z.B. mobile Apps, mit Webansichten implementiert werden, ist eine solche Ansicht in die App eingebettet und entspricht daher nicht der Definition einer Webseite. Die Anforderungen von Klausel 11 "Nicht-Web-Software" sind die entsprechenden Anforderungen, die auf diese Webansichten angewendet werden können. Es gibt keine Umstände, unter denen sowohl die Anforderungen von Klausel 9 als auch die entsprechenden Anforderungen von Klausel 11 anwendbar sind. Bei Zweifeln haben die Anforderungen nach Klausel 11 Vorrang.“
Spätestens seitdem die Europäische Web Accessibility Directive (WAD) Barrierefreiheit auch für mobile Apps vorschrieb, tauchte die Frage auf, wie diese Apps getestet werden könnten, da sie nicht auf Webstandards wie HTML, CSS und JavaScript (EcmaScript) basieren. Es gibt eine Reihe von signifikanten Unterschieden beim Testen nativer mobiler Apps:
- Während Web-Tester den Quellcode von Websites, wie er im DOM (Dokumentobjektmodell) des Browsers erscheint, untersuchen und sogar im DOM probeweise verändern können, ist der Quellcode nativer Apps normalerweise nicht verfügbar (es sei denn, die Tests haben vollen Zugriff auf die Entwicklungsumgebung).
- Beim Testen von Websites stehen eine Reihe nützlicher Tools zur Verfügung, die als Browser-Plug-Ins oder als Bookmarklets implementiert sind, um den Code zu untersuchen und auf Fehler hinzuweisen. Beim Testen mobiler Apps gibt es weniger Tools, die hier helfen, wie zum Beispiel der Android Accessibility Scanner, und sie decken weniger Anforderungen ab.
- Mehrere Unternehmen wie abra.ai oder evinced.com bieten Plattformen an, um mobile Tests zu erleichtern. Für Android gibt es auch die kostenlose Software Android Accessibility Inspector. Durch den Anschluss des mobilen Geräts an einen Computer geben sie Zugriff auf den Barrierefreiheitsbaum und automatisieren bis zu einem gewissen Grad Aufgaben wie die Kontrastmessung. Der eher „nackte“ Android-Zugänglichkeits-Inspektor ist eine kostenlose Software, die Zugriff auf den Barrierefreiheitsbaum bietet – einer Hierarchie der Elemente mit seinen Rollennamen und Attributwerten.
- Mehrere Anforderungen, die auf dem Browser als Benutzeragent basieren, wie z. B. Textsizing und Reflow, gelten nicht auf die gleiche Weise für native App-Inhalte
Das BIK BITV-Test / EN 301 549 (App) Testverfahren bietet detaillierte Schritte zum Testen mobiler iOS- und Android-Apps. In Ermangelung von WCAG Verständnistexten und WCAG Techniken für mobile Apps besteht immer noch einige Unsicherheit darüber, was genau erforderlich ist. Die Github Issues der Mobile Accessibility Task Force und anderer Orte wie die Slack-Kanäle Mobile-Tests und Native-Mobile zeigen die laufenden Diskussionen und Meinungsverschiedenheiten.
Wir werden in weiteren Beiträgen über verschiedene Aspekte des Testens mobiler Apps berichten und hierbei bestehende unterschiedliche Einschätzungen nicht unterschlagen. Für allgemeines Feedback sowie Hinweise und ggf. Korrekturen in den Kommentaren sind wir dankbar.
Alle Felder sind Pflichtfelder