Gilt das BFSG auch für meine App?
Kurzantwort: Wenn die App Teil einer erfassten Dienstleistung ist, ja. Der technische Maßstab ist dann aber nicht nur die WCAG, sondern Kapitel 11 der EN 301 549 — und das verlangt mehrere Dinge, die in der WCAG überhaupt nicht vorkommen.
Auf einen Blick:
- Das BFSG nennt mobile Anwendungen ausdrücklich — etwa bei Personenbeförderungsdiensten (§ 1 Abs. 3 Nr. 2 Buchst. b).
- Kapitel 11 EN 301 549 = WCAG plus X. Die Erfolgskriterien werden auf Nicht-Web-Software übertragen, dazu kommen Anforderungen an die Zusammenarbeit mit Hilfsmitteln.
- Der entscheidende Zusatz ist Abschnitt 11.5: Ihre App muss den Barrierefreiheitsdiensten der Plattform die richtigen Informationen liefern.
- 11.6.2 verbietet Sabotage: Software darf dokumentierte Barrierefreiheitsfunktionen der Plattform nicht stören.
- Fünf Inhaltsarten sind ausgenommen (§ 1 Abs. 4 BFSG), darunter Archive und Fremdinhalte ohne eigene Kontrolle.
Welche Apps sind betroffen?
Das BFSG erfasst keine „Apps” als Kategorie, sondern Dienstleistungen. Ihre App fällt darunter, wenn sie eine dieser Dienstleistungen erbringt:
Ausdrücklich genannt sind mobile Anwendungen bei Personenbeförderungsdiensten im Luft-, Bus-, Schienen- und Schiffsverkehr — dort zählt § 1 Abs. 3 Nr. 2 Buchst. b „auf Mobilgeräten angebotene Dienstleistungen, einschließlich mobiler Anwendungen” auf.
Über die Dienstleistung erfasst sind außerdem Apps für Bankdienstleistungen für Verbraucher, für E-Books und die zugehörige Software, für Telekommunikationsdienste und für Dienstleistungen im elektronischen Geschäftsverkehr. Eine Shopping-App ist damit nicht weniger erfasst als der Shop im Browser.
Wenn Ihre App nichts davon tut — eine reine Info-App, ein internes Werkzeug, ein Spiel ohne Verkaufsfunktion —, greift das BFSG in der Regel nicht. Die Einordnung folgt derselben Logik wie bei Websites, die der Ratgeber BFSG-Pflicht beschreibt.
Was ist ausdrücklich ausgenommen?
§ 1 Abs. 4 BFSG nimmt fünf Inhaltsarten von Webseiten und mobilen Anwendungen aus:
| Ausnahme | Wichtig dabei |
|---|---|
| Aufgezeichnete zeitbasierte Medien, veröffentlicht vor dem 28.06.2025 | Für später veröffentlichte Videos gilt die Ausnahme nicht |
| Dateiformate von Büro-Anwendungen, veröffentlicht vor dem 28.06.2025 | Neue Dokumente fallen darunter — siehe barrierefreie PDFs |
| Online-Karten und Kartendienste | Nur, wenn wesentliche Navigationsinformationen barrierefrei digital bereitstehen |
| Inhalte Dritter ohne Finanzierung, Entwicklung oder Kontrolle durch Sie | Eingebundene Inhalte, die Sie steuern, sind nicht ausgenommen |
| Archivinhalte, die nach dem 28.06.2025 nicht mehr aktualisiert werden | Sobald Sie etwas überarbeiten, ist es kein Archiv mehr |
Die Kartenausnahme wird regelmäßig überdehnt. Sie befreit die Karte, nicht die Adresse. Wer eine Filiale nur als Kartenpin anbietet, muss die wesentlichen Informationen zusätzlich in zugänglicher digitaler Form bereitstellen.
Warum WCAG allein nicht reicht
Kapitel 11 der EN 301 549 heißt „Software” und gilt für Nicht-Web-Software, also auch für native Apps. Die Abschnitte 11.1 bis 11.4 übertragen die WCAG-Erfolgskriterien auf Software — Abschnitt 11.1.3.4 verlangt zum Beispiel, dass Nicht-Web-Software mit Benutzeroberfläche das Erfolgskriterium 1.3.4 „Orientation” erfüllt.
Danach kommt der Teil, den Webentwicklung nicht kennt.
11.5 Interoperabilität mit assistiven Technologien. Ihre App muss den Barrierefreiheitsdiensten der Plattform die richtigen Informationen zur Verfügung stellen. Die Norm zählt dafür einzeln auf: Objektinformationen, Zeilen, Spalten und Überschriften, Werte, Label-Beziehungen, Eltern-Kind-Beziehungen, Text, die Liste verfügbarer Aktionen, deren Ausführung, das Verfolgen und Ändern von Fokus und Auswahl, Änderungsbenachrichtigungen sowie Änderungen an Zuständen, Eigenschaften und Werten.
Im Klartext: Ein selbstgezeichnetes Bedienelement, das optisch wie ein Schalter aussieht, aber der Plattform nicht mitteilt, dass es ein Schalter ist, welchen Zustand es hat und welche Aktion es anbietet, erfüllt diesen Abschnitt nicht — auch wenn es visuell einwandfrei ist.
11.6.2 Keine Störung von Barrierefreiheitsfunktionen. Software mit Benutzeroberfläche darf die in der Plattformdokumentation beschriebenen Barrierefreiheitsfunktionen nicht stören, außer der Nutzer verlangt das selbst während der Bedienung. Eine App, die die Systemschriftgröße ignoriert oder eigene Gesten über die des Screenreaders legt, verstößt dagegen.
11.7 Nutzerpräferenzen und 11.8 Autorenwerkzeuge kommen hinzu, letzteres, wenn Ihre App Inhalte erzeugen lässt.
Was das für iOS und Android konkret heißt
Nutzen Sie die Standardkomponenten der Plattform. UIKit, SwiftUI und die Android-Views bringen die Informationen aus 11.5 mit. Jedes selbstgebaute Bedienelement müssen Sie diese Rolle, diesen Zustand und diese Aktionen selbst mitteilen — über Accessibility-Traits und -Labels beziehungsweise über die Accessibility-Node-Informationen.
Testen Sie mit dem Screenreader der Plattform. VoiceOver auf iOS, TalkBack auf Android. Das ist keine Randgruppe: In der WebAIM-Erhebung nutzen 91,3 % der Befragten einen Screenreader auch auf dem Mobilgerät, 70,6 % davon auf iOS. Details dazu stehen im Ratgeber Screenreader testen.
Respektieren Sie die Systemeinstellungen. Dynamische Schriftgrößen, reduzierte Bewegung, erhöhter Kontrast, Farbfilter. Wer feste Punktgrößen setzt, bricht 11.6.2 und nebenbei die Erwartung der Nutzenden.
Prüfen Sie beide Orientierungen. Erfolgskriterium 1.3.4 verlangt, dass die App nicht ohne Not auf Hoch- oder Querformat festgelegt ist — für Menschen mit fest montiertem Gerät ist das ein hartes Hindernis.
Wenn Sie eine WebView einbetten: Dann gelten für deren Inhalt die Web-Anforderungen. Die Grenze zwischen App und Web verläuft nicht am App-Icon.
Häufige Fragen
Reicht es, wenn unsere Website barrierefrei ist und die App dasselbe anzeigt?
Nein. Sobald es sich um native Software handelt, gilt Kapitel 11 der EN 301 549 mit den Anforderungen an die Zusammenarbeit mit Barrierefreiheitsdiensten der Plattform — die auf der Website gar nicht existieren. Eine App, die dieselben Inhalte zeigt, kann trotzdem für Screenreader unbedienbar sein.
Gibt es für Apps eigene Prüfverfahren?
Die EN 301 549 enthält in Annex A zwei getrennte Tabellen für die EU-Richtlinie zu Websites und mobilen Anwendungen öffentlicher Stellen: eine für Webseiten und Dokumente, eine für mobile Anwendungen. Methodisch lässt sich eine App nach WCAG-EM prüfen; das Verfahren spricht ausdrücklich von digitalen Produkten, nicht nur von Websites.
Müssen wir alte Videos in der App nachträglich untertiteln?
Aufgezeichnete zeitbasierte Medien, die vor dem 28. Juni 2025 veröffentlicht wurden, sind nach § 1 Abs. 4 Nr. 1 BFSG ausgenommen. Für alles, was danach veröffentlicht wurde oder wird, gilt die Ausnahme nicht.
Wie steht es um Apps in Österreich und der Schweiz?
Österreich verweist im BaFG ebenfalls auf die EN 301 549, sodass für Apps dieselben technischen Anforderungen gelten — Details unter BaFG Österreich. In der Schweiz gibt es für private Anbieter keine entsprechende Pflicht, siehe BehiG Schweiz.