Am 28. Juni 2025 ist das Barrierefreiheitsstärkungsgesetz verbindlich geworden, und viele Unternehmen denken dabei zuerst an ihre Website. Doch das Gesetz nennt mobile Anwendungen ausdrücklich als eigenständiges Angebot. Wer eine App für den Verkauf, das Banking, den Ticketkauf oder die Kundenbetreuung betreibt, fällt genauso unter die Pflicht wie ein Online-Shop im Browser. Und anders als bei manchen Bestandsdiensten mit langen Übergangsfristen gilt für eine App, die neu veröffentlicht oder wesentlich überarbeitet wird, der Standard sofort. Dieser Beitrag übersetzt WCAG 2.1 AA und die europäische Norm EN 301 549 in konkrete Anforderungen an iOS- und Android-Apps: von Screenreader-Labels über Touch-Ziele bis zur Bedienung ohne Gesten-Zwang.
Das Wichtigste in Kürze
- Das BFSG unterscheidet nicht zwischen Website und nativer App. Eine App, die nach dem 28. Juni 2025 neu erscheint oder wesentlich überarbeitet wird, kann sich nicht auf Übergangsregelungen berufen; der Barrierefreiheitsstandard gilt sofort.
- Maßstab ist EN 301 549 V3.2.1: Kapitel 11 überträgt die WCAG-Kriterien auf Software und ergänzt eigene Anforderungen. Umgesetzt wird über die Plattform-APIs mit VoiceOver unter iOS und TalkBack unter Android - ein reiner Web-Audit deckt die App nicht ab.
- Jedes Bedienelement braucht einen Namen, der die Funktion beschreibt, nicht das Symbol: Löschen statt Papierkorb, dazu Rolle und Zustand programmatisch. Mobil nutzen 70,6 Prozent VoiceOver und 34,7 Prozent TalkBack (WebAIM Screen Reader Survey 10, 2024).
- Touch-Ziele messen mindestens 44 mal 44 Punkt unter iOS (Apple Human Interface Guidelines) und 48 mal 48 dp unter Android (Google Material Design). Text muss bis 200 Prozent skalieren, Kontrast 4,5 zu 1 erreichen, geprüft in hellem und dunklem Modus.
- Jede Wisch- oder Zieh-Geste braucht eine Alternative durch einfaches Antippen (WCAG 2.5.1), bewegungsgesteuerte Aktionen müssen abschaltbar sein (2.5.4), und die App funktioniert in Hoch- und Querformat (1.3.4). Der Fokus wandert in Dialoge und kehrt zurück.
- In Cross-Plattform-Projekten entstehen Lücken durch Custom-Views ohne Rolle, Text als Grafik, falsche Traversal-Reihenfolge und ignorierte Systemeinstellungen. Geprüft wird auf echten Geräten mit Screenreader, ergänzt um Accessibility Inspector und Scanner.
Warum das BFSG jetzt auch Apps erfasst
Das Barrierefreiheitsstärkungsgesetz (BFSG) setzt den European Accessibility Act in deutsches Recht um und verpflichtet Anbieter bestimmter Produkte und Dienstleistungen zur digitalen Barrierefreiheit. Zu den erfassten Dienstleistungen zählen unter anderem der elektronische Geschäftsverkehr, Bankdienstleistungen für Verbraucher, Personenbeförderung und Telekommunikation. Entscheidend für App-Betreiber: Das Gesetz unterscheidet nicht zwischen Website und nativer Anwendung. Eine Shopping-App, eine Banking-App oder eine Buchungs-App erbringt dieselbe Dienstleistung wie die zugehörige Website und muss dieselben Anforderungen erfüllen (Bundesfachstelle Barrierefreiheit).
Wie groß der betroffene Personenkreis ist, zeigen zwei Zahlen. In Deutschland lebten Ende 2023 rund 7,9 Millionen schwerbehinderte Menschen, das entspricht 9,3 Prozent der Bevölkerung (Statistisches Bundesamt, 2024). Weltweit leben nach Schätzung der Weltgesundheitsorganisation etwa 1,3 Milliarden Menschen und damit rund 16 Prozent der Bevölkerung mit einer wesentlichen Behinderung (WHO, 2023). Ein erheblicher Teil dieser Menschen nutzt Smartphones mit assistiven Technologien. Unter den Screenreader-Nutzern greifen 91,3 Prozent auch auf einem mobilen Gerät auf einen Screenreader zurück (WebAIM Screen Reader Survey 10, 2024). Eine App, die diese Technologien ignoriert, schließt einen messbaren Anteil ihrer potenziellen Kundschaft aus.
Keine automatische Schonfrist für neue Apps
Für einen Überblick, welche Unternehmen und Angebote das Gesetz erfasst und welche Fristen gelten, hilft unser Beitrag BFSG 2025: Was Unternehmen jetzt wissen müssen. Ob und wann die eng gefasste Kleinstunternehmen-Regelung greift, ordnet der Artikel zur Ausnahme für Kleinstunternehmen ein. Beide Texte machen deutlich, dass die Ausnahmen schmaler sind, als viele annehmen.
Der rechtliche Rahmen: EN 301 549 und WCAG 2.1 AA
Der technische Maßstab für die Barrierefreiheit ergibt sich aus der harmonisierten europäischen Norm EN 301 549 in der Fassung V3.2.1 vom März 2021 (ETSI EN 301 549). Diese Norm verweist für Webinhalte auf die Web Content Accessibility Guidelines in der Version 2.1 auf Stufe AA (W3C Web Accessibility Initiative). Für native Apps ist ein eigenes Kapitel maßgeblich: Kapitel 11 der Norm überträgt die Erfolgskriterien der WCAG auf Software, die nicht im Browser läuft, und ergänzt sie um Anforderungen, die nur für nicht-webbasierte Anwendungen gelten. Ein reiner Web-Audit deckt diesen Software-Teil deshalb nicht ab.
Praktisch bedeutet das: Die vier WCAG-Prinzipien wahrnehmbar, bedienbar, verständlich und robust gelten auch für die App, nur ist die technische Umsetzung eine andere. Statt HTML-Semantik und ARIA nutzen native Apps die Barrierefreiheits-APIs der Plattform. Auf iOS ist das UIAccessibility mit dem Screenreader VoiceOver, auf Android die Accessibility-APIs mit dem Screenreader TalkBack. Welche konkreten Pflichten sich daraus ergeben, fasst unsere Seite zu den BFSG-Anforderungen zusammen.
| Aspekt | Website (Browser) | Native App (iOS/Android) |
|---|---|---|
| Norm-Grundlage | EN 301 549, Verweis auf WCAG 2.1 AA | EN 301 549 Kapitel 11 (Software) plus WCAG-Kriterien |
| Semantik | HTML-Elemente, ARIA-Rollen | Plattform-Barrierefreiheits-APIs (UIAccessibility / Accessibility) |
| Screenreader | je nach System und Browser | VoiceOver (iOS), TalkBack (Android) |
| Schriftskalierung | Browser-Zoom, Resize Text | Dynamic Type (iOS), Font Size / Display Size (Android) |
| Prüfung | Web-Audit nach WCAG 2.1 AA | App-Audit inklusive Software-Kriterien der Norm |
Der Kernsatz für App-Teams
Screenreader-Labels für VoiceOver und TalkBack
Der häufigste und zugleich folgenreichste Fehler in Apps sind fehlende oder unverständliche Bedienelement-Beschriftungen. Ein Icon-Button ohne Label wird von VoiceOver oder TalkBack bestenfalls als Schaltfläche ohne Namen angesagt, oft aber gar nicht sinnvoll erfasst. Für blinde und sehbehinderte Nutzer ist eine solche Schaltfläche schlicht nicht bedienbar. Das ist kein Randthema: VoiceOver wird von 70,6 Prozent (WebAIM Screen Reader Survey 10, 2024) und TalkBack von 34,7 Prozent (WebAIM, 2024) der befragten Screenreader-Nutzer auf mobilen Geräten eingesetzt, teils parallel.
Jedes interaktive Element braucht daher einen aussagekräftigen, zugänglichen Namen, der die Funktion beschreibt, nicht das Aussehen. Ein Papierkorb-Symbol heißt nicht Papierkorb, sondern Löschen. Zusätzlich sollten Rolle und Zustand programmatisch verfügbar sein, damit die assistive Technologie Schaltfläche, ausgewählt oder deaktiviert korrekt ansagt. Die grundlegende Systematik zu Name, Rolle und Zustand beschreibt unser Beitrag zur Screenreader-Optimierung für das Web; auf der App-Ebene gelten dieselben Prinzipien über die Plattform-APIs.
Aussagekräftige Labels
Jedes Icon, jeder Button und jedes Bildelement mit Funktion erhält einen zugänglichen Namen, der den Zweck beschreibt. Rein dekorative Grafiken werden dagegen vor dem Screenreader verborgen, damit die Ausgabe nicht mit Beiwerk überladen wird.
Rolle und Zustand
Über die Barrierefreiheits-APIs wird kommuniziert, ob ein Element eine Schaltfläche, ein Schalter oder ein Auswahlfeld ist und in welchem Zustand es sich befindet. So kündigt der Screenreader ausgewählt, aktiviert oder deaktiviert korrekt an.
Gruppierung und Reihenfolge
Zusammengehörige Elemente werden zu sinnvollen Einheiten gruppiert, damit der Screenreader eine Karte als Ganzes vorliest statt in Fragmenten. Die Vorlesereihenfolge folgt der logischen Struktur, nicht der zufälligen Position im Layout.
Überschriften-Semantik
Bildschirmtitel und Abschnittsüberschriften werden als Überschrift ausgezeichnet, damit Nutzer per Rotor oder Überschriften-Navigation springen können. Eine reine Schriftvergrößerung ohne semantische Auszeichnung reicht dafür nicht.
Statusmeldungen ansagen
Dynamische Rückmeldungen wie In den Warenkorb gelegt oder Formular unvollständig werden dem Screenreader aktiv mitgeteilt, ohne dass der Fokus springt. So bemerken auch Nutzer ohne Sicht auf den Bildschirm, dass sich etwas geändert hat.
Fokus sichtbar halten
Der aktuelle Bedienfokus ist visuell klar erkennbar und wandert nach dem Öffnen eines Dialogs auf das neue Element. Nach dem Schließen kehrt er an eine sinnvolle Stelle zurück, damit der Bedienpfad nachvollziehbar bleibt.
Ein Button ohne Label ist für einen sehenden Entwickler unsichtbar unproblematisch und für einen blinden Nutzer eine geschlossene Tür. Der Unterschied kostet in der Umsetzung wenige Minuten, im Betrieb entscheidet er über Nutzbarkeit oder Ausschluss.
Touch-Ziele, Schriftgrößen und Zoom
Motorische Einschränkungen, Tremor oder schlicht die Bedienung unterwegs machen kleine Bedienelemente zum Problem. Beide Plattformen geben deshalb Mindestgrößen für Touch-Ziele vor. Apple empfiehlt in den Human Interface Guidelines mindestens 44 mal 44 Punkt pro tippbarer Fläche (Apple Human Interface Guidelines). Googles Material-Design-Vorgaben nennen für Android mindestens 48 mal 48 dp, was physisch etwa neun Millimetern entspricht (Google Material Design). Wichtig ist dabei die tippbare Fläche, nicht die sichtbare Grafik: Ein kleines Icon kann eine ausreichend große unsichtbare Trefferzone besitzen.
Die WCAG kennen dazu passende Kriterien. Das Erfolgskriterium 2.5.5 Zielgröße verlangt auf der Stufe AAA mindestens 44 mal 44 CSS-Pixel (W3C Web Accessibility Initiative). Mit WCAG 2.2 kam das Kriterium 2.5.8 Zielgröße Minimum hinzu, das auf Stufe AA mindestens 24 mal 24 CSS-Pixel fordert (W3C Web Accessibility Initiative). Da das BFSG über die aktuelle Normfassung auf WCAG 2.1 verweist, sind die Plattform-Guidelines der praktisch verbindliche Maßstab, während die WCAG-Werte die Richtung vorgeben. Genügend Abstand zwischen benachbarten Zielen verhindert zusätzlich das versehentliche Auslösen der falschen Aktion.
Ebenso wichtig ist die frei skalierbare Schrift. Nutzer stellen in den Systemeinstellungen größere Schriftgrößen ein, und die App muss das respektieren, statt Text abzuschneiden oder in feste Pixelhöhen zu pressen. Das WCAG-Kriterium 1.4.4 verlangt, Text bis 200 Prozent ohne Verlust von Inhalt oder Funktion vergrößern zu können (W3C Web Accessibility Initiative). Auf iOS geschieht das über Dynamic Type, auf Android über die System-Schriftgröße und die Anzeigegröße. Layouts müssen mitwachsen, ohne dass Bedienelemente verschwinden.
| Anforderung | iOS | Android |
|---|---|---|
| Mindest-Touch-Ziel | 44 x 44 pt (Apple HIG) | 48 x 48 dp (Material Design) |
| Skalierbare Schrift | Dynamic Type | Schriftgröße und Anzeigegröße |
| Screenreader | VoiceOver | TalkBack |
| Kontrast-Test | Farb- und Kontrastprüfung | Farb- und Kontrastprüfung |
| Fokus-Steuerung | accessibilityElements, Fokus-Reihenfolge | Traversal-Reihenfolge, Fokus-Handling |
Der dritte Baustein ist der Farbkontrast. Text muss sich mit einem Verhältnis von mindestens 4,5 zu 1 vom Hintergrund abheben, große Schrift ab 3 zu 1 (W3C Web Accessibility Initiative, WCAG 1.4.3). Auch Bedienelemente und ihre Zustände brauchen ausreichenden Kontrast, damit Ränder und Fokusanzeigen erkennbar bleiben. Wie sich verlässliche Kontrastwerte planen und prüfen lassen, zeigt unser Beitrag zu Farbkontrasten in der Barrierefreiheit.
Dark Mode und Kontrast gemeinsam denken
Fokus-Reihenfolge und Bedienung ohne Gesten-Zwang
Touch-Oberflächen verführen zu komplexen Gesten: wischen, ziehen, zusammendrücken, kippen. Für Menschen mit motorischen Einschränkungen oder für Screenreader-Nutzer sind solche Gesten oft nicht ausführbar. Die WCAG fordern deshalb, dass jede Funktion, die einen komplexen oder pfadabhängigen Fingerzeig verlangt, alternativ mit einem einfachen Antippen bedienbar ist (W3C Web Accessibility Initiative, WCAG 2.5.1 Zeigergesten). Ein Karussell, das sich nur per Swipe bewegen lässt, braucht zusätzliche Vor- und Zurück-Schaltflächen.
Verwandt ist das Kriterium 2.5.4 Betätigung durch Bewegung: Funktionen, die durch Schütteln oder Neigen des Geräts ausgelöst werden, etwa Rückgängig per Schütteln, müssen auch über ein sichtbares Bedienelement erreichbar sein und sich abschalten lassen (W3C Web Accessibility Initiative). Ebenso darf eine App die Nutzung nicht auf eine einzige Bildschirmausrichtung festlegen, sofern nicht die Funktion es zwingend erfordert. Das Kriterium 1.3.4 Ausrichtung verlangt, dass Hoch- und Querformat gleichermaßen unterstützt werden (W3C Web Accessibility Initiative), was besonders Menschen betrifft, die ihr Gerät fest an einem Rollstuhl montiert haben.
- Einzeiger-Alternative: Jede Wisch-, Zieh- oder Mehrfinger-Geste hat eine Bedienung durch einfaches Antippen (WCAG 2.5.1).
- Bewegung abschaltbar: Durch Schütteln oder Neigen ausgelöste Aktionen sind auch per Schaltfläche erreichbar und deaktivierbar (WCAG 2.5.4).
- Freie Ausrichtung: Die App funktioniert in Hoch- und Querformat, außer die Funktion erfordert zwingend eine Ausrichtung (WCAG 1.3.4).
- Logische Fokus-Reihenfolge: Der Bedienfokus wandert in einer nachvollziehbaren Reihenfolge, Dialoge fangen den Fokus und geben ihn korrekt zurück.
- Genügend Zeit: Zeitlimits sind abschaltbar oder verlängerbar, damit langsamere Bedienung nicht zum Abbruch führt.
- Keine reine Farbcodierung: Zustände wie Fehler oder Auswahl werden nicht allein über Farbe, sondern zusätzlich über Symbol oder Text vermittelt.
Gerade die Fokus-Steuerung ist in dynamischen Oberflächen anspruchsvoll. Öffnet sich ein Overlay oder ein Bottom Sheet, muss der Fokus dorthin wandern und darf nicht hinter dem Dialog im Hintergrund hängen bleiben. Die Muster dafür ähneln stark denen im Web; unser Beitrag zum Fokus-Management in Single-Page-Anwendungen beschreibt die Prinzipien, die sich eins zu eins auf App-Navigationen übertragen lassen. Wer zusätzlich physische Tastaturen oder Schaltersteuerungen unterstützt, findet in unserem Beitrag zur Tastaturnavigation die passenden Grundlagen.
Overlay-Werkzeuge lösen das App-Problem nicht
Häufige Fehler in Cross-Plattform-Frameworks
Viele Apps werden nicht zweimal nativ, sondern einmal in einem plattformübergreifenden Framework entwickelt, das aus einer Codebasis eine iOS- und eine Android-App erzeugt. Das spart Aufwand, verschiebt aber die Verantwortung für Barrierefreiheit: Der geteilte Code muss die richtigen Informationen an beide Plattform-APIs durchreichen. Genau hier entstehen typische Lücken, weil eigene Zeichenflächen und Custom-Komponenten die native Semantik nicht automatisch mitbringen.
Fehlende Semantik bei Custom-Views
Selbst gezeichnete Bedienelemente sehen aus wie Buttons, sind für die Barrierefreiheits-API aber nur eine Fläche ohne Rolle. Ohne explizite Auszeichnung als Schaltfläche mit Namen bleiben sie für Screenreader stumm.
Falsche Fokus-Reihenfolge
Wenn die Baumstruktur der Oberfläche nicht der visuellen Ordnung entspricht, springt der Screenreader-Fokus unvorhersehbar. Die Traversal-Reihenfolge muss der logischen Lesereihenfolge folgen, nicht der Reihenfolge im Quellcode.
Text als Grafik
Wird Text in ein Bild gerendert, skaliert er nicht mit der System-Schriftgröße und trägt keine auslesbare Bedeutung. Echter Text mit Dynamic Type oder skalierbaren Einheiten bleibt lesbar und maschinell erfassbar.
Doppelte oder verwaiste Elemente
Manche Frameworks erzeugen unsichtbare Duplikate oder lassen abgeblendete Ebenen im Barrierefreiheitsbaum. Der Screenreader liest dann Elemente vor, die gar nicht bedienbar sind, und verwirrt die Navigation.
Verpasste Statusaktualisierungen
Ändert sich Inhalt dynamisch, muss die App die Änderung aktiv an die Plattform melden. Ohne diese Meldung bemerkt ein Screenreader neue Fehlermeldungen oder aktualisierte Preise nicht.
Ignorierte Systemeinstellungen
Reduzierte Bewegung, größere Schrift oder erhöhter Kontrast sind Systempräferenzen, die die App abfragen und respektieren sollte. Wer sie überschreibt, hebelt individuell eingestellte Hilfen wieder aus.
Die gute Nachricht: Alle etablierten Frameworks bieten Schnittstellen, um Rolle, Name, Zustand und Fokus korrekt zu setzen. Barrierefreiheit ist bei Cross-Plattform-Entwicklung keine Frage der Technologie, sondern der Sorgfalt und des Testens auf echten Geräten mit aktivem Screenreader. Wer die Semantik von Beginn an mitdenkt, vermeidet teure Nachbesserungen kurz vor dem Release.
App-Barrierefreiheit testen: manuell und automatisiert
Automatisierte Prüfwerkzeuge finden einen Teil der Probleme, etwa fehlende Labels oder zu geringe Kontraste, aber sie ersetzen die manuelle Prüfung nicht. Ob eine App mit VoiceOver oder TalkBack tatsächlich bedienbar ist, ob die Fokus-Reihenfolge stimmt und ob Gesten Alternativen haben, lässt sich nur im echten Betrieb beurteilen. Beide Plattformen liefern dafür Bordmittel: den Accessibility Inspector unter iOS und den Accessibility Scanner unter Android. Welche Rolle automatisierte Tests im Gesamtbild spielen, ordnet unser Beitrag zu Accessibility-Testing-Werkzeugen ein.
- Screenreader-Durchlauf: Die zentralen Abläufe einmal komplett mit VoiceOver und einmal mit TalkBack bedienen, ohne auf den Bildschirm zu sehen, und prüfen, ob jedes Element angesagt und erreichbar ist.
- Nur-Tippen-Test: Die App ausschließlich mit einfachen Tipps bedienen und dabei feststellen, ob jede Wisch- oder Zieh-Geste eine Alternative hat.
- Skalierung prüfen: Die System-Schriftgröße auf das Maximum stellen und kontrollieren, ob Text lesbar bleibt und keine Bedienelemente verschwinden.
- Kontrast messen: Text und Bedienelemente in hellem und dunklem Modus gegen die Grenzwerte 4,5 zu 1 und 3 zu 1 prüfen.
- Ausrichtung und Bewegung: Hoch- und Querformat testen sowie bewegungsgesteuerte Funktionen auf eine abschaltbare Alternative kontrollieren.
- Bordmittel einsetzen: Accessibility Inspector und Accessibility Scanner nutzen, um fehlende Rollen, Namen und Trefferzonen aufzuspüren.
Vom Test zum belastbaren Nachweis
Eine externe Prüfung nach WCAG 2.1 AA und EN 301 549 schafft dabei die nötige Distanz zum eigenen Entwicklungsteam. Ein WCAG-Audit für Ihre App deckt Barrieren strukturiert auf und priorisiert die Behebung nach Wirkung. Anschließend begleiten wir die barrierefreie Entwicklung über den gesamten Lebenszyklus, damit auch das nächste Feature-Release konform bleibt. Welchen Umfang Ihre App hat und welcher Prüfweg sinnvoll ist, klären wir gern über die Kontaktseite.
Quellen und Studien