WCAG für mobile Apps: was gilt und wie Sie auf Android und iOS testen

Viele Shops und Dienste haben neben der Website eine App, und schnell kommt die Frage auf: Gelten die WCAG auch für mobile Apps? Kurz gesagt: Die WCAG wurden für Webinhalte geschrieben, ihre Kriterien werden aber auch für Apps verwendet. Das W3C veröffentlicht Hinweise, wie man sie anwendet, und die europäische Norm EN 301 549 hat ein Kapitel zu Software, das mobile Anwendungen nennt. Diese Seite erklärt, welche Dokumente wichtig sind und wie Sie eine App mit den Werkzeugen von Google und Apple testen.

Vorab: Pandus prüft Websites, einschließlich der mobilen Version einer Website, aber keine nativen iOS- oder Android-Apps. Für den App-Teil verweist Sie diese Seite auf die Werkzeuge der Plattformen. Das sind allgemeine Informationen, keine Rechtsberatung.

Gibt es WCAG für mobile Geräte?

Einen eigenen Standard gibt es nicht. Das W3C sagt deutlich, dass es keine gesonderten Richtlinien für mobile Barrierefreiheit hat. Stattdessen gilt:

• Die WCAG 2.2 decken Webseiten und Webanwendungen ab, einschließlich Inhalten, die auf mobilen Geräten genutzt werden. Eine mobile Website oder eine Webanwendung im Browser eines Smartphones ist schlicht Webinhalt.
• WCAG2ICT – Guidance on Applying WCAG 2 to Non-Web Information and Communications Technologies (Leitfaden zur Anwendung der WCAG 2 auf Nicht-Web-Informations- und Kommunikationstechnologien) – erklärt, wie die WCAG 2.0, 2.1 und 2.2 auf Nicht-Web-Dokumente und Software anzuwenden sind. Es ist ein Group Note des W3C vom Dezember 2025 und informativ: Er sagt selbst, dass er keine Anforderungen aufstellt und kein Standard ist.
• WCAG2Mobile – Guidance on Applying WCAG 2.2 to Mobile Applications (Leitfaden zur Anwendung der WCAG 2.2 auf mobile Anwendungen) – ist ein Group Draft Note vom Mai 2025 und noch in Arbeit. Er deckt native Apps, mobile Websites und hybride Apps ab und baut auf dem älteren Hinweis Mobile Accessibility: How WCAG 2.0 and Other W3C/WAI Guidelines Apply to Mobile auf. Auch er ist informativ, nicht normativ.

Die WCAG selbst ändern sich für Apps also nicht. Die Hinweise erklären Kriterium für Kriterium, wie sich für das Web geschriebene Begriffe – etwa „Webseite“ oder „Gruppe von Webseiten“ – auf Software übertragen lassen und wo ein Kriterium anders gelesen werden muss oder nicht zutrifft.

EN 301 549: Kapitel 11 für Software

In der Europäischen Union ist die EN 301 549 die technische Referenz für die Barrierefreiheit von IKT. Ihre Struktur trennt die Inhaltsarten:

• Kapitel 9 – Web. Webseiten. Ein Hinweis in der Norm sagt, dass Webanwendungen, einschließlich mobiler Webanwendungen, von ihrer weiten Definition einer Webseite erfasst werden.
• Kapitel 10 – Nicht-Web-Dokumente.
• Kapitel 11 – Software. Die allgemeine Klausel nennt Plattform-Software, Software mit Benutzerschnittstelle, Authoring-Werkzeuge, assistive Technologien und mobile Anwendungen.

Die Klauseln 11.1 bis 11.4 folgen für Software den WCAG-Prinzipien – wahrnehmbar, bedienbar, verständlich, robust –, und weitere Klauseln stellen eigene Anforderungen, etwa 11.5 Interoperabilität mit assistiven Technologien und 11.7 Nutzereinstellungen. WCAG2ICT erwähnt außerdem, dass nach der EN 301 549 die Kriterien 2.4.2 Seite mit Titel versehen und 3.1.2 Sprache von Teilen für Nicht-Web-Software nicht gelten. Kapitel 5, Allgemeine Anforderungen, gilt auch für Apps.

Ob ein Gesetz verlangt, dass Ihre App barrierefrei ist, hängt davon ab, wer Sie sind und was Sie verkaufen. Unser EAA-Leitfaden erklärt den European Accessibility Act, der die EN 301 549 als technische Referenz nutzt.

Die WCAG-2.2-Kriterien, die in Apps am wichtigsten sind

Alle Kriterien der Stufen A und AA sind relevant, aber diese tauchen in App-Prüfungen immer wieder auf:

So testen Sie Barrierefreiheit auf Android

Der Testleitfaden von Google verbindet automatische und manuelle Prüfungen:

1. Accessibility Scanner. Eine kostenlose App aus Google Play. Aktivieren Sie ihn unter Einstellungen → Bedienungshilfen → Accessibility Scanner, öffnen Sie Ihre App und tippen Sie auf Snapshot für einen Bildschirm oder auf Record für einen Ablauf. Er schlägt Verbesserungen bei Inhaltsbeschriftungen, Größe der Touch-Ziele, anklickbaren Elementen sowie Text- und Bildkontrast vor. Er braucht Android 9.0 oder neuer, und Google sagt, dass er manuelle Tests nicht ersetzt.
2. TalkBack. Der in Android eingebaute Screenreader. Wischen Sie nach rechts und links durch jedes Element: Wird jedes mit einem klaren Namen und Zweck angesagt, erreichen Sie alle, werden vorübergehende Meldungen vorgelesen?
3. Automatische UI-Tests. Ab Compose 1.8.0 kann das Accessibility Test Framework in Compose-UI-Tests laufen: Fügen Sie die Abhängigkeit ui-test-junit4-accessibility hinzu und rufen Sie enableAccessibilityChecks() an der Test-Regel auf. Die Prüfungen decken fehlende Beschriftungen, Farbkontrast, kleine Touch-Ziele und die Reihenfolge der Navigation ab.

Tests im Android-Emulator. Emulatoren werden ohne installiertes TalkBack geliefert. Das Codelab von Google rät, ein Emulator-Image mit Play Store zu wählen und die Android Accessibility Suite von dort zu installieren. Google weist außerdem darauf hin, dass das Accessibility Test Framework in Android Studio Probleme nicht erkennen kann, die nur auftreten, wenn die App auf einem Gerät läuft. Testen Sie daher vor dem Release auf einem echten Smartphone.

So testen Sie Barrierefreiheit auf iOS

1. Accessibility Inspector. Öffnen Sie ihn in Xcode über Xcode → Open Developer Tool → Accessibility Inspector. Apple beschreibt ihn als Werkzeug, um Barrierefreiheitsinformationen der Elemente Ihrer App anzuzeigen, abzufragen und zu testen und um auf Probleme wie abgeschnittenen Text, unbeschriftete Elemente, Textgröße und Farbkontrast zu prüfen.
2. VoiceOver auf einem Gerät. Der Testleitfaden von Apple sagt, die App sei auf einem echten Gerät zu installieren, da VoiceOver im Simulator nicht verfügbar ist. Schalten Sie es unter Einstellungen → Bedienungshilfen → VoiceOver ein und nutzen Sie den Bildschirmvorhang, um zu testen, ohne den Bildschirm zu sehen.
3. Automatische Audits in UI-Tests. Der Leitfaden von Apple verweist außerdem darauf, Barrierefreiheits-Audits in Ihre UI-Tests aufzunehmen.

Zu „Barrierefreiheit im iOS-Simulator testen“ gilt also: Sie können mit dem Accessibility Inspector untersuchen und prüfen, aber ein echter Screenreader-Test braucht ein iPhone oder iPad.

Was Pandus abdeckt und was nicht

Pandus prüft Websites: jede Seite einer Website jede Woche, mit der Engine axe-core in einem echten Browser, gegen WCAG 2.2 A und AA. Dazu gehören Probleme, die mobilen Besuchern Ihrer Website schaden, etwa ein Viewport, der das Zoomen blockiert, oder zu kleine Touch-Ziele. Native iOS- oder Android-Apps prüft Pandus nicht, und auch die Bildschirme einer hybriden App innerhalb ihrer App-Hülle prüft es nicht.

Wenn Ihre Kundinnen und Kunden sowohl auf der Website als auch in der App kaufen, prüfen Sie die Website mit unserem kostenlosen WCAG-Checker oder einer kostenlosen Prüfung und testen Sie die App mit den oben genannten Werkzeugen der Plattformen. Die manuellen Schritte für Websites stehen unter WCAG testen. Unsere Prüfungen sind eine automatische Prüfung, kein vollständiges Audit und keine Rechtsberatung.

Häufige Fragen

Gelten die WCAG für mobile Apps?

Die WCAG sind für Webinhalte geschrieben, ihre Kriterien lassen sich aber auch auf native Apps anwenden. Das W3C erklärt, wie, in zwei informativen Hinweisen, WCAG2ICT und dem Entwurf WCAG2Mobile; die EN 301 549 enthält in Kapitel 11 Anforderungen an Software einschließlich mobiler Anwendungen.

Gibt es einen eigenen W3C-Standard für mobile Barrierefreiheit?

Nein. Das W3C sagt, es habe keine gesonderten Richtlinien für mobile Barrierefreiheit. Die WCAG decken Webinhalte auf mobilen Geräten ab, und die Hinweise erklären, wie man sie auf native und hybride Apps anwendet.

Wie teste ich Barrierefreiheit auf Android?

Nutzen Sie den Accessibility Scanner aus Google Play für automatische Vorschläge, TalkBack für einen Screenreader-Test und das Accessibility Test Framework in Compose-UI-Tests ab Compose 1.8.0. Der Scanner ersetzt keine manuellen Tests.

Kann ich VoiceOver im iOS-Simulator testen?

Nein. Apple sagt, VoiceOver sei im Simulator nicht verfügbar. Installieren Sie die App daher für einen Screenreader-Test auf einem echten Gerät. Der Accessibility Inspector in Xcode hilft, Elemente zu untersuchen und zu prüfen.

Prüft Pandus mobile Apps?

Nein. Pandus prüft Websites, einschließlich der mobilen Version einer Website, aber keine nativen iOS- oder Android-Apps. Für Apps nutzen Sie die Werkzeuge der Plattformen, die auf dieser Seite beschrieben sind.

Quellen

• W3C WAI, Mobile Accessibility at W3C: https://www.w3.org/WAI/standards-guidelines/mobile/
• W3C, WCAG2ICT (Group Note, December 2025): https://www.w3.org/TR/wcag2ict-22/
• W3C, Guidance on Applying WCAG 2.2 to Mobile Applications (WCAG2Mobile, Group Draft Note, May 2025): https://www.w3.org/TR/wcag2mobile-22/
• ETSI, EN 301 549 V3.2.1, clauses 9 and 11: https://www.etsi.org/deliver/etsi_en/301500_301599/301549/03.02.01_60/en_301549v030201p.pdf
• Android Developers, Test your app's accessibility: https://developer.android.com/guide/topics/ui/accessibility/testing
• Android Developers, Compose accessibility testing: https://developer.android.com/develop/ui/compose/accessibility/testing
• Android Developers, Accessibility in Jetpack Compose codelab (TalkBack on an emulator): https://developer.android.com/codelabs/jetpack-compose-accessibility
• Google, Get started with Accessibility Scanner: https://support.google.com/accessibility/android/answer/6376570
• Apple Developer, Accessibility Inspector: https://developer.apple.com/documentation/accessibility/accessibility-inspector
• Apple Developer, Performing accessibility testing for your app: https://developer.apple.com/documentation/accessibility/performing-accessibility-testing-for-your-app