Mobile App oder mobile Website: Was das BFSG wirklich verlangt

Viele Unternehmen betreiben parallel eine native App und eine mobile Website – und fragen sich, ob beide Kanäle gleichermaßen unter das BFSG fallen oder ob sich der Aufwand auf einen Kanal konzentrieren lässt.

Die kurze Antwort: Beide Kanäle fallen grundsätzlich unter dieselben Anforderungen, sobald sie Teil eines digitalen Produkts oder einer Dienstleistung sind. Die Unterschiede liegen weniger im Ob als im Wie der Umsetzung.

Dieser Beitrag ordnet native App, progressive Web App und mobile Website nach ihren jeweiligen Anforderungen ein und zeigt, wie Unternehmen mit begrenzten Ressourcen zwischen den Kanälen priorisieren können.

Zwei Kanäle, eine grundsätzliche Pflicht

Ob ein Unternehmen seine Kunden über eine native App, eine progressive Web App oder eine klassische mobile Website erreicht, ändert an der grundsätzlichen Pflicht zur Barrierefreiheit wenig. Entscheidend ist, dass ein digitales Angebot genutzt wird, nicht die konkrete technische Umsetzung.

Trotzdem unterscheiden sich die technischen Wege dorthin erheblich, weshalb Unternehmen mit mehreren Kanälen häufig vor der Frage stehen, wo sich begrenzte Ressourcen zuerst sinnvoll einsetzen lassen.

Diese Frage stellt sich besonders dann, wenn App und Website nicht denselben Funktionsumfang bieten. Bietet die App zusätzliche Funktionen, die auf der Website fehlen, muss auch die App in vollem Umfang barrierefrei gestaltet sein, nicht nur als Zweitkanal behandelt werden.

Native App, PWA und mobile Website im Vergleich

Eine native App nutzt die Bedienungshilfen des jeweiligen Betriebssystems direkt, etwa VoiceOver unter iOS oder TalkBack unter Android, braucht dafür aber eine separate Umsetzung je Plattform. Details dazu liefert der Beitrag Mobile Apps und BFSG.

Eine progressive Web App liegt technisch zwischen App und Website: Sie lässt sich wie eine App installieren, basiert aber auf denselben Web-Technologien wie eine klassische Seite und profitiert entsprechend von denselben Grundregeln.

Eine mobile Website läuft im Browser und wird durch responsives Design an kleinere Bildschirme angepasst, ohne eine eigene Installation zu erfordern.

Für Nutzer bedeutet die Wahl des Kanals auch einen Unterschied im Zugang zu vertrauten Bedienungshilfen: Wer sein Betriebssystem bereits auf größere Schrift oder invertierte Farben eingestellt hat, profitiert davon bei einer nativen App oder PWA unmittelbarer als bei einer Website, die eigene Einstellungen mitbringt.

Was für native Apps zusätzlich gilt

Native Apps unterliegen zusätzlich den Vorgaben der jeweiligen App-Stores und nutzen betriebssystemeigene Bedienungshilfen-APIs, die eigene Kenntnisse in der jeweiligen Entwicklungsumgebung voraussetzen und sich nicht direkt aus Web-Wissen übertragen lassen.

Zwei Betriebssysteme bedeuten in der Praxis auch zwei getrennte Testläufe: Eine für iOS mit VoiceOver zugängliche App ist nicht automatisch auch unter Android mit TalkBack vollständig bedienbar.

Auch App-Updates durchlaufen eine Store-Prüfung, bevor sie bei Nutzern ankommen. Eine dringend nötige Korrektur einer Barriere braucht dadurch realistisch betrachtet mehr Vorlaufzeit als eine vergleichbare Korrektur auf einer Website.

Wo die mobile Website häufig im Vorteil ist

Eine mobile Website profitiert von der langjährig etablierten Web-Barrierefreiheit mit einheitlichen Standards, die unabhängig vom Betriebssystem des Nutzers gelten, statt für jede Plattform gesondert geprüft werden zu müssen.

Updates lassen sich zudem sofort für alle Nutzer ausrollen, ohne auf eine App-Store-Freigabe warten zu müssen – ein praktischer Vorteil, wenn eine Barriere schnell behoben werden soll.

Auch die Zahl der verfügbaren Test- und Scan-Werkzeuge ist für Web-Inhalte deutlich größer als für native Apps, was die laufende Kontrolle für kleinere Teams ohne spezialisierte App-Testumgebung erheblich vereinfacht.

Wenn beide Kanäle parallel existieren

Betreibt ein Unternehmen App und mobile Website nebeneinander, sollte die Barrierefreiheits-Erklärung beide Angebote abdecken und für beide jeweils den tatsächlichen Umsetzungsstand angeben, statt nur den einen Kanal zu erwähnen, der besser abschneidet.

Bei begrenzten Ressourcen lohnt sich eine Priorisierung nach tatsächlicher Nutzung: Der Kanal mit den meisten aktiven Nutzern verdient in der Regel die erste Prüfung und die dringendere Behebung gefundener Barrieren.

Zusätzlich lohnt sich ein Blick darauf, ob bestimmte Kundengruppen strukturell eher den einen oder den anderen Kanal nutzen. Wird etwa die App überwiegend von Stammkunden verwendet, während neue Kunden zuerst über die Website in Kontakt kommen, verändert das die Reihenfolge der Priorisierung.

Entscheidungshilfe für kleine Unternehmen ohne eigene App-Entwicklung

Für kleinere Unternehmen ohne eigenes App-Entwicklungsteam ist eine gut gepflegte, barrierefreie mobile Website meist der wirtschaftlichere Weg, weil sie ohne separate Entwicklung für iOS und Android auskommt.

Eine progressive Web App kann als Zwischenschritt sinnvoll sein, wenn app-ähnliche Funktionen wie Offline-Nutzung oder ein Startbildschirm-Icon gewünscht sind, ohne den vollen Aufwand einer nativen App-Entwicklung zu betreiben. Mehr zu realistischen Budgets liest du im Beitrag Was kostet Barrierefreiheit?

Migrationsszenario: App einstellen zugunsten der Website

Manche Unternehmen entscheiden sich, eine wenig genutzte native App einzustellen und die Ressourcen stattdessen in die mobile Website zu investieren. Barrierefreiheits-Anforderungen bleiben dabei unverändert bestehen, verschieben sich aber vollständig auf den verbleibenden Kanal.

Vor einer solchen Migration lohnt sich eine Bestandsaufnahme, welche App-spezifischen Funktionen – etwa Push-Benachrichtigungen oder Kamerazugriff – sich webseitig gleichwertig nachbilden lassen, damit keine Funktion für bestehende Nutzer ersatzlos wegfällt.

Bestehende App-Nutzer sollten rechtzeitig und in verständlicher Sprache über die Einstellung informiert werden, mit einer klaren Anleitung zum Umstieg auf die Website, statt eines plötzlichen Wegfalls der gewohnten App ohne Vorwarnung.

Prüfablauf für beide Varianten

Für die mobile Website liefert ein automatisierter Scan einen schnellen ersten Überblick, ergänzt durch einen manuellen Test mit Tastatur und Screenreader auf einem echten mobilen Gerät.

Für native Apps braucht es zusätzlich einen Test mit den jeweiligen betriebssystemeigenen Bedienungshilfen direkt auf einem iOS- und einem Android-Gerät, da sich App-Barrieren mit reinen Web-Tools nicht vollständig erfassen lassen.

Beide Prüfabläufe sollten regelmäßig wiederholt werden, nicht nur einmalig vor dem Launch, da sowohl Betriebssystem-Updates als auch Änderungen an der eigenen Website oder App neue Barrieren einführen können.

Hinweis: Dieser Beitrag bietet allgemeine technische Orientierung zur Kanalwahl zwischen App und Website und ersetzt keine individuelle Rechtsberatung.

Häufig gestellte Fragen