Barrierefreie App: Warum der Entwicklungsansatz über die Pflicht entscheidet

Eine barrierefreie App verlangt das Barrierefreiheitsstärkungsgesetz seit Juni 2025 auch von privaten Anbietern. In erster Linie stehen hier selten Kontraste oder Alternativtexte im Fokus, sondern die Nachrüstbarkeit der vorhandenen Anwendung. Denn wie viel Mobile Accessibility überhaupt erreichbar ist, hängt vom gewählten Entwicklungsansatz ab.
Zwei Kollegen sitzen sich an einem Schreibtisch in einem belebten Büro gegenüber und vergleichen zwei baugleiche Smartphones, auf denen dieselbe Anwendung unterschiedlich dargestellt ist: links drängen sich Textblöcke und Bedienelemente, rechts sitzt das Layout luftig. Sinnbild für eine barrierefreie App, deren Bedienbarkeit sich mit dem Betriebssystem verschiebt, ohne dass am Code etwas geändert wurde.
© KI-generiert (TenMedia)

Barrierefreie App: wann das BFSG Apps erfasst

Die Überwachungsstelle des Bundes prüfte 2025 in Angeboten öffentlicher Stellen genau neun mobile Anwendungen eingehend, gegenüber 268 Webauftritten (BFIT-Jahresbericht 2025). Die barrierefreie App ist der blinde Fleck der Prüfpraxis.

Eine barrierefreie App ist eine mobile Anwendung, die sich mit den Bedienungshilfen des Betriebssystems vollständig nutzen lässt, etwa mit der Sprachausgabe VoiceOver unter iOS oder TalkBack unter Android. Maßgeblich sind die Anforderungen der harmonisierten Norm EN 301 549, die webbasierte, nicht-webbasierte und hybride Technologien erfasst. Für private Anbieter gilt das Barrierefreiheitsstärkungsgesetz, für öffentliche Stellen die BITV 2.0.

Warum eine App als Dienstleistung gilt

Zwischen Produkten und Dienstleistungen unterscheidet das BFSG. Apps fallen in die zweite Kategorie, und diese Einordnung ist der eigentliche Hebel, denn sie entscheidet, welche Pflichten aus dem Barrierefreiheitsstärkungsgesetz überhaupt greifen. Erfasst ist eine Anwendung, wenn sie eine Dienstleistung der Telemedien erbringt, also elektronisch und auf individuelle Anfrage von Verbraucherinnen und Verbrauchern. Eine Buchung, eine Zahlung oder ein Vertragsabschluss löst die Pflicht zur barrierefreien App damit aus, eine reine Informationsanzeige eher nicht. Ob am Ende jemand die Konformität feststellt, klärt der Abschnitt Wo steht die Erklärung zur Barrierefreiheit?, denn eine Vorabprüfung gibt es nicht.

Behörden-App und Unternehmens-App

Die häufigste Verwechslung betrifft das anwendbare Gesetz. Eine App, die eine Behörde oder eine Kommune betreibt, folgt dem Behindertengleichstellungsgesetz und der BITV 2.0, nicht dem BFSG. Apps privater Anbieter fallen umgekehrt genau darunter. Beide Wege laufen auf dieselbe technische Norm zu, Pflichtenträger und Aufsicht unterscheiden sich aber. Diese Doppelstruktur prägt die digitale Barrierefreiheit in Deutschland insgesamt, nicht erst seit dem BFSG. Apps sind darin nur der jüngste Fall.

Eine barrierefreie App wird vor allem dort zur Pflicht, wo diese Funktionen im Spiel sind:

Der Entwicklungsansatz setzt die Obergrenze

Bevor eine einzige Anforderung geprüft wird, steht eine Entscheidung fest, die niemand für die Barrierefreiheit getroffen hat. Die Wahl der Technik legt fest, welche Funktionen der Bedienungshilfen einer barrierefreien App überhaupt zur Verfügung stehen. Der Entwicklungsansatz entscheidet über die erreichbare App-Barrierefreiheit, nicht das Budget für die Nachbesserung. Kosten und Wartung trennen native von hybrider App-Entwicklung entlang anderer Linien als die Barrierefreiheit.

Native Apps und die Bedienungshilfen des Systems

Native Apps entstehen in den Sprachen der Plattform, also in Swift für iOS und in Kotlin oder Java für Android. Sie greifen direkt auf die Accessibility-Schnittstellen des Betriebssystems zu, über die die Sprachausgabe erfährt, was ein Element ist. Bei nativer Entwicklung besteht laut der Überwachungsstelle des Bundes der maximale Einfluss auf die Barrierefreiheit. Eine barrierefreie Applikation ist hier vollständig erreichbar, sofern barrierefreie App-Entwicklung diese Schicht früh einplant, statt sie später zu suchen.

Diese Angaben übergibt eine native App an die Sprachausgabe:

Warum zwei Schichten über die Barrierefreiheit entscheiden

Plattformübergreifende Frameworks wie Flutter, Xamarin oder Qt erzeugen die Oberfläche selbst und übersetzen sie anschließend für das jeweilige System. Damit sind zwei Komponenten für die Barrierefreiheit verantwortlich, das Framework und das Betriebssystem. Eine App ohne Barrieren setzt deshalb voraus, dass beide Schichten dieselbe Funktion unterstützen. Fehlt einer Seite eine Funktion, ist sie in der fertigen Anwendung nicht vorhanden.

Die Schnittmenge aus Framework und System

Erreichbar ist nur die Schnittmenge beider Schichten, und diese Schnittmenge verschiebt sich mit jeder neuen Version auf beiden Seiten. Ein Framework, das ein Bedienelement nicht korrekt an die Sprachausgabe meldet, lässt sich im eigenen Code nicht reparieren. Der Ausweg ist eine eigene, plattformspezifische Umsetzung, und die kostet genau das, was der plattformübergreifende Ansatz einsparen sollte.

Mobile Accessibility in hybriden Apps

Hybride Apps mischen native Bestandteile mit Webinhalten in einem eingebetteten Browser. Für den Webteil greifen die WCAG-Richtlinien samt Zielgröße von Bedienelementen unmittelbar, für den nativen Teil die Schnittstellen der Plattform. Mobile Accessibility bedeutet hier, zwei Prüflogiken nebeneinander zu bedienen, weil die Sprachausgabe an der Grenze beider Welten den Kontext verliert.

Was Updates an der Bedienbarkeit verändern

Eine barrierefreie App erbt einen Teil ihrer Bedienbarkeit vom Betriebssystem. Anders als eine barrierefreie Website, deren Umgebung stabil bleibt, steht eine barrierefreie mobile Anwendung auf einer Grundlage, die sich mit jedem Systemrelease verschiebt.

Was ändert ein Update des Betriebssystems?

Ein Systemupdate kann die Bedienbarkeit verbessern oder beschädigen, obwohl an der App keine Zeile Code geändert wurde. Neue Schriftgrößen greifen tiefer in Layouts ein, geänderte Kontrastmodi überschreiben Farbfestlegungen, und eine neue Version der Sprachausgabe liest Elemente anders vor. Deshalb gehört eine barrierefreie App in die laufende Wartung und nicht in ein Projekt mit Enddatum.

Nur wiederkehrende Prüfläufe können diese App-Barrieren vermeiden:

❗ Layoutbruch bei größerer Systemschriftart
❗ Verlorene Beschriftungen nach Framework-Aktualisierung
❗ Geänderte Vorleseabfolge in der Sprachausgabe
❗ Überschriebene Farben im Kontrastmodus
❗ Neue Bedienelemente ohne Rollenangabe

Mobile Accessibility als Wartungsaufgabe

An dieser Stelle reicht kosmetische Nachbesserung nicht, auch wenn sie schnell umzusetzen ist. Kontraste und Alternativtexte sind notwendig, Screenreadertauglichkeit prüfen sie aber nicht. Der Prüfstein ist die Bedienung mit eingeschalteter Sprachausgabe, denn nur am Gerät lassen sich App-Barrieren vermeiden. Mobile Accessibility zeigt sich dort in Sekunden, wo eine Prüfliste noch Häkchen setzt. Werkzeuge wie der Accessibility Scanner unter Android finden fehlende Beschriftungen und zu kleine Trefferflächen, beurteilen aber keine Reihenfolge.

Barrierefreie App nachweisen und umsetzen

Der Nachweis funktioniert anders als bei einer Zulassung. Es gibt kein Zertifikat und keine Vorabprüfung, sondern eine Marktüberwachung nach dem BFSG. Apps geraten dort anlassbezogen und auf Beschwerde in den Blick. Dazu kommen Verbände und Wettbewerber, die Unterlassungsansprüche geltend machen können. Für die Geschäftsführung heißt das, dass eine zugängliche App sich durch die eigene Dokumentation belegt und nicht durch ein Prüfsiegel.

Wo steht die Erklärung zur Barrierefreiheit?

Bei einer Website liegt die Erklärung auf einer eigenen Unterseite. Eine barrierefreie App hat diesen Ort nicht, deshalb gehört die Erklärung an zwei Stellen, in das Angebot im App Store und in die Anwendung selbst, erreichbar ohne Anmeldung. Wer nur die Unternehmenswebsite bespielt, erreicht die Nutzerschaft der App nicht.

Diese Angaben gehören in die Dokumentation der Prüfung:

Wer die Prüfung verantwortet

Verantwortlich für die App-Barrierefreiheit ist selten die Entwicklung allein, weil sie Freigabeentscheidungen berührt. Ein Prüflauf, der niemandem gehört, findet zwischen zwei Releases nicht statt. Tragfähig ist eine benannte Stelle und ein fester Zeitpunkt, üblicherweise vor der Release-Freigabe. Menschen, die die Bedienungshilfen täglich nutzen, bewerten Reihenfolgen und Formulierungen, die kein Werkzeug prüft.

TenMedia entwickelt native und hybride Anwendungen und zieht die Barrierefreiheit dabei in den Architekturentwurf, vor der Auslieferung, nicht danach. Für bestehende Anwendungen übernimmt TenMedia die Prüfung auf dem Gerät, die Behebung gefundener Barrieren und die Pflege über Systemupdates hinweg. Eine rechtliche Bewertung des Einzelfalls gehört ausdrücklich nicht dazu, dafür ist eine fachanwaltliche Prüfung der richtige Weg. Eine eigene Oberfläche mit voller Kontrolle über die Bedienungshilfen trägt etwa der KI-Assistent als App-Plattform.

Hinweis: Dieser Beitrag dient der allgemeinen Information und stellt keine Rechtsberatung dar. Für verbindliche Auskünfte zu regulatorischen Anforderungen empfehlen wir die Konsultation einer spezialisierten Rechtsberatung.

FAQs

Welcher Entwicklungsansatz erreicht welches Maß an Barrierefreiheit? keyboard_arrow_down keyboard_arrow_up
Barrierefreie App-Entwicklung kennt vier Wege mit unterschiedlicher Obergrenze. Native Entwicklung in Swift oder Kotlin greift direkt auf die Accessibility-Schnittstellen des Betriebssystems zu und erlaubt die vollständige Umsetzung. Plattformübergreifende Frameworks wie Flutter oder Xamarin schieben eine zweite Schicht dazwischen, verfügbar bleibt nur, was Framework und Betriebssystem gemeinsam unterstützen. Web-Apps im eingebetteten Browser fallen unmittelbar unter die WCAG. Hybride Apps kombinieren beide Logiken und verlangen besondere Aufmerksamkeit an den Übergängen. Bei der Barrierefreiheit mobiler Apps fällt die Entscheidung damit lange vor der ersten Prüfung und ist später nur mit hohem Aufwand korrigierbar.
Fällt eine App unter das BFSG als Produkt oder als Dienstleistung? keyboard_arrow_down keyboard_arrow_up
Als Dienstleistung. Erfasst ist eine Anwendung, wenn sie eine Dienstleistung der Telemedien erbringt, also elektronisch und auf individuelle Anfrage von Verbrauchern. Buchungen, Zahlungen und Vertragsabschlüsse lösen die BFSG-App-Pflicht aus. Ausgenommen sind Kleinstunternehmen mit weniger als zehn Beschäftigten und höchstens zwei Millionen Euro Jahresumsatz.
Wie wählt TenMedia den Entwicklungsansatz, wenn Barrierefreiheit gefordert ist? keyboard_arrow_down keyboard_arrow_up
TenMedia prüft zuerst, welche Bedienungshilfen die Anwendung braucht, und wählt danach die Technik. Bei voller Kontrolle über die Sprachausgabe fällt die Wahl auf native Entwicklung. Eine bestehende App barrierefrei machen heißt erst prüfen, dann umbauen. So entsteht eine barrierefreie App ohne Nachbesserung.