Barrierefreie Apps: iOS und Android nach BFSG 2026

Stand: Mai 2026 · Lesezeit: 8 Minuten · Plattformen: iOS, Android, React Native, Flutter

Mobile Apps stehen seit dem 28. Juni 2025 unter der Pflicht des Barrierefreiheitsstärkungsgesetzes (BFSG). § 1 BFSG erfasst nicht nur Webseiten, sondern jede Software, die Verbrauchern zugänglich gemacht wird — also auch native iOS- und Android-Apps, Hybrid-Apps und Progressive Web Apps.

Dieser Leitfaden zeigt, was § 8–10 BFSG für mobile Anwendungen konkret bedeuten, welche Anforderungen aus EN 301 549 Kapitel 11 für Apps gelten und wie Sie Ihre App in unter 30 Tagen WCAG-2.2-AA-konform machen.

Welche Apps unter das BFSG fallen

Praktisch jede App mit Verbraucherzugang ist betroffen:

E-Commerce-Apps (Zalando, Otto, MediaMarkt, IKEA, Lieferando)
Banking-Apps (Sparkasse, ING, N26, Trade Republic)
ÖPNV- und Reise-Apps (DB Navigator, BVG, FlixBus, Lufthansa)
Energieversorger-Apps (E.ON, EnBW, Stadtwerke)
Medien- und Streaming-Apps (ARD, ZDF, RTL+, ProSiebenSat.1)
Health- und Fitness-Apps (mit DiGA-Status sogar zusätzlich MDR-pflichtig)

Praxis-Hinweis: Reine B2B-Apps (z. B. interne Mitarbeiter-Tools) fallen nicht unter das BFSG. Sobald aber eine App auch von Kleinstunternehmern oder Selbstständigen genutzt wird, gilt sie als Verbraucher-App.

Die rechtliche Grundlage: EN 301 549 Kapitel 11

Während Webseiten WCAG 2.2 Level AA erfüllen müssen, gibt es für Mobile-Apps zusätzliche Anforderungen aus Kapitel 11 der EN 301 549. Wichtig:

11.5.2.5 — Bewegungsaktivierung muss deaktivierbar sein (z. B. „Schütteln zum Rückgängigmachen")
11.5.2.6 — Konzeptionelle Sprachausgabe (Programmatic Speech) für Screen-Reader
11.5.2.13 — Statusmeldungen müssen Screen-Reader-zugänglich sein
11.6.2 — Ziele für Eingaben (Touch-Targets) mindestens 24×24 CSS-Pixel
11.7 — Benutzereinstellungen des Systems respektieren (Schriftgröße, Kontrast, Reduce Motion)

iOS — VoiceOver, Dynamic Type, Reduce Motion

Apple liefert seit iOS 13 robuste Accessibility-APIs. Die wichtigsten Anforderungen für BFSG-Konformität:

VoiceOver-Unterstützung

Jedes interaktive UI-Element braucht accessibilityLabel, accessibilityHint und korrekte accessibilityTraits. Beispiel in Swift:

button.accessibilityLabel = "Überweisung starten" button.accessibilityHint = "Öffnet das Formular für Banküberweisungen" button.accessibilityTraits = .button

Dynamic Type

Apps müssen System-Schriftgrößen respektieren. UIFont.preferredFont(forTextStyle: .body) statt UIFont.systemFont(ofSize: 16). SwiftUI hat das automatisch über .font(.body).

Reduce Motion

Animationen müssen abschaltbar sein. Prüfen Sie UIAccessibility.isReduceMotionEnabled und ersetzen Sie animierte Übergänge durch Cross-Fades.

Voice Control

iOS 13+ erlaubt Sprachsteuerung. Buttons brauchen klare, eindeutige Labels (kein „OK", lieber „Bestellung bestätigen").

Android — TalkBack, Switch Access, Color Inversion

TalkBack-Unterstützung

In Jetpack Compose: Modifier.semantics { contentDescription = "Überweisung starten" }. In klassischem Android XML: android:contentDescription="...".

Touch-Target-Größe

Material Design empfiehlt 48dp×48dp. WCAG 2.2 AAA verlangt 44×44 CSS-Pixel; AA Level 24×24. Verwenden Sie android:minHeight="48dp" und android:minWidth="48dp" für interaktive Elemente.

Tastaturnavigation

Android-Geräte mit physischer Tastatur (Tablets, Foldables) brauchen android:focusable="true" und logische Tab-Reihenfolge über android:nextFocusForward.

Live Regions

Statusmeldungen wie „Überweisung erfolgreich" müssen Screen-Reader automatisch ansagen. announceForAccessibility(text) oder android:accessibilityLiveRegion="polite".

Cross-Platform: React Native, Flutter, Ionic

React Native

accessibilityLabel auf jedem View
accessibilityRole (button, link, image)
AccessibilityInfo.isReduceMotionEnabled()
Test mit „Accessibility Inspector" (Xcode) und „Accessibility Scanner" (Android Studio)

Flutter

Widget Semantics(label: ..., hint: ...)
MediaQuery.of(context).disableAnimations
MediaQuery.of(context).textScaleFactor respektieren
Test mit Flutter „SemanticsDebugger"-Widget

Häufige Fehler, die Apps zum BFSG-Verstoß machen

Bilder ohne Alt-Texte — Produktbilder im Onlineshop nur als „Bild" angekündigt
Nicht-bezeichnete Buttons — Icon-Buttons ohne accessibilityLabel
Hardcodierte Schriftgrößen — Layout bricht bei 200% System-Schriftgröße
Animierte Splash-Screens — Lassen sich nicht abschalten
CAPTCHA ohne Audio-Alternative — Vor allem in Login-Formularen
Modal-Dialoge ohne Fokus-Trap — Screen-Reader liest Hintergrund weiter
Toasts und Snackbars zu kurz — Verschwinden bevor Screen-Reader sie vorliest
Sprach-Einstellung wird ignoriert — App sagt deutschen Text in englischer Aussprache
Gestik ohne Alternative — Wischen zum Löschen ohne Button-Alternative
Farb-Codierung als einzige Information — „Roter Status = Fehler" — was bei Farbenblindheit?

Test-Workflow für mobile Apps

Automatisierte Tests in der CI: Accessibility Scanner (Android), Xcode-Audits (iOS)
Statische Analyse: SwiftLint mit Accessibility-Regeln, Lint mit Android-Accessibility-Checks
Manueller Walk-Through mit Screen-Reader (VoiceOver, TalkBack) für jede neue Feature-Story
System-Einstellungen testen: Schriftgröße auf 200%, Kontrast erhöht, Reduce Motion aktiviert
Externe Audits einmal pro Quartal (BFSGuard kann nicht-native Web-Views in Apps scannen)

App-Store-Erklärung nach § 14 BFSG

Apple und Google verlangen seit 2025 eine eigene Barrierefreiheitserklärung für Apps. Die Erklärung muss:

Im App-Store-Listing sichtbar sein (verlinkt im Datenschutz-Abschnitt)
Innerhalb der App über das Settings-Menü erreichbar sein
Stand der Konformität nennen: vollständig / teilweise / nicht konform
Nicht-konforme Bereiche auflisten und Begründung liefern
Feedback-Mechanismus enthalten (E-Mail oder Formular)
Datum der letzten Prüfung enthalten

Vorsicht: Apps ohne Barrierefreiheitserklärung können von Apple oder Google im Review-Prozess abgelehnt werden — auch ohne BFSG-Bezug, weil beide Plattformen eigene Accessibility-Richtlinien durchsetzen.

App-Web-View jetzt prüfen

BFSGuard scannt Web-Views in Hybrid-Apps und liefert WCAG-2.2-AA-Bericht. Auch für Native-Apps können wir gemeinsam einen Audit-Plan aufsetzen.

Web-View kostenlos scannen →

Häufige Fragen zu BFSG für Mobile Apps

Gilt das BFSG auch für interne Firmen-Apps?

Nein. Reine B2B- und Mitarbeiter-Apps fallen nicht unter das BFSG. Sobald die App aber auch Kleinstunternehmern und Selbstständigen zugänglich ist, gilt sie als Verbraucher-Software.

Reicht es, die WebView in einer Hybrid-App barrierefrei zu machen?

Nein. Native UI-Elemente (Tab-Bar, Navigation, Push-Notifications) müssen ebenfalls die EN-301-549-Kapitel-11-Anforderungen erfüllen.

Muss meine App auch ohne Internet barrierefrei sein?

Ja. Offline-Funktionalität (lokale Datenanzeige, Cache) muss dieselben Accessibility-Standards erfüllen wie Online-Modus.

Können Apple oder Google Apps wegen BFSG-Verstößen entfernen?

Direkt nein — Apple und Google handeln nach eigenen Accessibility-Richtlinien. Indirekt ja, weil deren Vorgaben das BFSG inhaltlich abdecken. Eine Ablehnung im Review wegen „Accessibility violations" ist faktisch eine BFSG-Sperre.

Was kostet ein App-Accessibility-Audit?

Manueller Audit durch eine Agentur: 5.000–15.000 € pro App. Automatisierte Scans (BFSGuard für Web-Views): ab 19,99 € / Monat. Kombi-Audit (BFSGuard Auto-Scan + manuelle Native-Review): typischerweise 2.000–4.000 € einmalig.