Gilt das BFSG für Ihre App?
Die Frage wird häufig falsch gestellt. Das BFSG kennt Apps nicht als eigene Kategorie — es kennt Produkte nach § 1 Abs. 2 und Dienstleistungen nach § 1 Abs. 3. Eine App ist kein Produkt in diesem Sinne; „Verbraucherendgeräte mit interaktivem Leistungsumfang“ meint Geräte, nicht Software darauf. Die Frage lautet deshalb: Erbringen Sie über die App eine erfasste Dienstleistung?
- Kann man in der App bestellen, buchen, abschließen oder einen Vertrag ändern? Dann ist es eine Dienstleistung im elektronischen Geschäftsverkehr — erfasst.
- Ist die App der Zugang zu einer Bankdienstleistung für Verbraucher, zu einem Telekommunikationsdienst, zu einer Personenbeförderung oder zu E-Books? Dann ist sie über diese Dienstleistung erfasst.
- Ist es eine reine Informations- oder Markenanwendung ohne Abschluss? Dann fällt sie nicht darunter — genauso wenig wie die entsprechende Website.
- Ist es eine App ausschließlich für die eigene Belegschaft? Kein BFSG. Arbeitsrechtliche und behindertengleichstellungsrechtliche Pflichten gelten unabhängig davon weiter.
Der praktische Punkt: In den allermeisten Fällen ist die App die zweite Oberfläche auf dieselbe Dienstleistung, die auch im Browser läuft. Dann teilt sie deren rechtliches Schicksal — und es wäre ohnehin schwer zu begründen, warum ein Kunde am Telefon bekommt, was er im Browser nicht bekommt.
Maßstab ist auch hier die EN 301 549. Für Software — und damit für Apps — verweist sie in Kapitel 11 auf dieselben WCAG-2.1-Erfolgskriterien wie für Webinhalte, sinngemäß auf Software übertragen, und ergänzt sie um Anforderungen an das Zusammenspiel mit den Bedienungshilfen der Plattform. Praktisch heißt das: Was Ihre App tut, muss VoiceOver und TalkBack korrekt melden — und zwar über die Programmierschnittstellen des Betriebssystems, nicht über eine eigene Nachbildung.
Die fünf Kriterien, die es nur wegen Touch gibt
WCAG 2.1 ist 2018 erschienen und hat gegenüber 2.0 siebzehn Erfolgskriterien ergänzt. Fünf davon existieren, weil zwischen 2008 und 2018 die Bedienung vom Mauszeiger auf den Finger gewechselt ist. Sie sind der Kern dieser Seite — und in Web-Checklisten stehen sie fast nie, weil sie auf einer Broschürenseite nie greifen.
| Kriterium | Was es verlangt | Woran es in Apps scheitert |
|---|---|---|
| 2.5.1 Zeigergesten (A) | Alles, was eine Geste mit mehreren Fingern oder einem bestimmten Pfad verlangt, muss auch mit einem einfachen Tippen bedienbar sein. | Wischen zum Löschen, Zusammenziehen zum Zoomen, Ziehen zum Sortieren — jedes davon ohne Alternative ist ein Verstoß. Die Lösung ist selten aufwendig: ein Kontextmenü mit denselben Befehlen. |
| 2.5.2 Zeigerabbruch (A) | Eine Handlung darf nicht beim Aufsetzen des Fingers ausgelöst werden, sondern erst beim Loslassen — und ein Wegziehen muss sie abbrechen. | Eigene Schaltflächen, die auf das Berühren statt auf das Loslassen reagieren. Wer zittert oder mit Sprachsteuerung arbeitet, kann eine Fehlberührung dann nicht mehr zurücknehmen. |
| 2.5.3 Beschriftung im Namen (A) | Was auf der Schaltfläche steht, muss im programmatischen Namen enthalten sein. | Der klassische Fall: Sichtbar steht „Weiter“, im accessibilityLabel steht „Nächster Schritt“. Wer per Sprachsteuerung „Tippe auf Weiter“ sagt, erreicht die Schaltfläche nicht. |
| 2.5.4 Bewegungsaktivierung (A) | Was durch Bewegen des Geräts ausgelöst wird, muss auch über ein Bedienelement gehen — und abschaltbar sein. | Schütteln zum Rückgängigmachen, Kippen zum Wechseln der Ansicht. Für jemanden mit Tremor löst das ungewollt aus, für jemanden mit fixiertem Gerät gar nicht. |
| 1.3.4 Ausrichtung (AA) | Der Inhalt darf nicht auf eine einzige Bildschirmausrichtung festgelegt sein, außer sie ist wesentlich. | Die Fixierung auf Hochformat. Wer sein Gerät an einem Rollstuhl montiert hat, kann es nicht drehen — und „wesentlich“ ist eine hohe Hürde: Ein Klavier oder ein Scheckeinzug ja, ein Bestellvorgang nein. |
Wenn Sie an dieser Seite nur eine Sache mitnehmen: Gehen Sie Ihre App nach Gesten durch, nicht nach Bildschirmen. Jede Geste, die mehr als ein Tippen verlangt, braucht einen zweiten Weg zum selben Ziel.
Was Ihnen zu Recht niemand vorschreibt — und was doch
Eine Behauptung, die in Angeboten und Prüfberichten regelmäßig auftaucht: Schaltflächen müssten mindestens 44 mal 44 Punkte groß sein, sonst sei die App nicht konform. Das stimmt so nicht, und es ist wichtig, den Unterschied zu kennen — weil er darüber entscheidet, wo Sie Ihr Geld einsetzen.
- 2.5.5 Zielgröße ist in WCAG 2.1 Stufe AAA. Die EN 301 549 verlangt für Webinhalte und Software die Stufe AA. Eine Zielgröße ist damit nach dem Maßstab des BFSG nicht gefordert.
- 2.5.8 Zielgröße (Minimum) mit 24 mal 24 CSS-Pixeln ist Stufe AA — aber erst in WCAG 2.2. Die EN 301 549 verweist auf 2.1. Auch das gilt also derzeit nicht.
- Die Plattformvorgaben verlangen es trotzdem: Apples Human Interface Guidelines nennen 44 mal 44 Punkte, Googles Material Design 48 mal 48 dp. Das sind keine Gesetze, aber es sind die Maßstäbe, an denen eine App im Alltag scheitert.
Unsere Empfehlung ist deshalb unbequem einfach: Halten Sie sich an die Plattformvorgaben, weil sie richtig sind — aber schreiben Sie in Ihre Erklärung zur Barrierefreiheit nicht, Sie hätten damit ein Kriterium erfüllt, das gar nicht gilt. Eine Erklärung, die mehr behauptet, als der Maßstab verlangt, fällt bei einer Prüfung negativ auf.
Was die Plattform mitbringt — und was Sie kaputt machen können
Der große Unterschied zum Web: iOS und Android liefern erhebliche Teile der Barrierefreiheit von sich aus, solange man die Standardelemente benutzt. Wer sie benutzt, hat einen Großteil geschenkt. Wer sie nachbaut, muss alles selbst liefern — und liefert es erfahrungsgemäß nicht.
| Was das System kann | Was es kostet, wenn Sie es umgehen |
|---|---|
| Dynamische Schriftgröße — iOS Dynamic Type, Android Schriftgröße und Anzeigegröße | Feste Punktgrößen im Layout ignorieren die Systemeinstellung. Damit bricht 1.4.4 Textgröße ändern. Das trifft nicht nur Blinde, sondern jeden über fünfzig. |
| Fokus- und Lesereihenfolge aus der Ansichtshierarchie | Eine Ansicht, die optisch umsortiert wurde, ohne die Hierarchie zu ändern, liest sich mit VoiceOver in der alten Reihenfolge vor. Bricht 1.3.2 und 2.4.3. |
| Rollen und Zustände über die Bedienungshilfen-Schnittstellen | Eine als Schaltfläche gestaltete Ansicht ohne die passende Auszeichnung wird als „Text“ angesagt. Bricht 4.1.2 — und man kommt gar nicht erst darauf, dass man tippen kann. |
| Ansagen nach einer Aktion — Live-Bereiche auf Android, Ankündigungen auf iOS | Nach dem Absenden dreht sich ein Ladekreis, danach wechselt die Ansicht — akustisch passiert nichts. Bricht 4.1.3, und der Nutzer sendet ein zweites Mal. |
| Reduzierte Bewegung und Kontrastverstärkung als Systemschalter | Aufwendige Übergänge, die den Schalter ignorieren, lösen bei manchen Menschen Übelkeit aus. Das ist kein Randfall — es ist der Grund, warum es den Schalter gibt. |
| Automatisches Ausfüllen über Textinhaltstypen und Ausfüllhinweise | Ohne sie füllt der Passwortmanager nichts aus. Bricht 1.3.5 und macht die Anmeldung für viele zur Sackgasse. |
Der Sonderfall: App aus Webtechnik
Bei Apps, die im Kern eine Webansicht sind — gleich ob als Container um eine Website oder mit einem plattformübergreifenden Rahmenwerk —, gilt beides gleichzeitig: die WCAG-Kriterien für den Webinhalt und die Erwartung der Plattform an das Zusammenspiel mit den Bedienungshilfen. Das ist keine Verdoppelung der Arbeit, aber es ist eine Verdoppelung der Prüfung: Was im mobilen Browser funktioniert, kann im eingebetteten Webinhalt anders klingen, weil die Brücke zu VoiceOver oder TalkBack eine andere ist.
Prüfen Sie deshalb immer in der App und nie nur im Browser. Der Unterschied fällt genau an den Stellen auf, an denen es zählt: bei Ansagen nach dem Absenden, bei modalen Dialogen und beim Fokus nach einem Ansichtswechsel.
Wie Sie es in einer Stunde selbst prüfen
Bevor Sie irgendjemanden beauftragen: Die folgenden vier Durchläufe kosten zusammen eine Stunde und zeigen Ihnen den größten Teil dessen, was ein Bericht auf achtzig Seiten auflisten würde. Nehmen Sie dafür Ihren wichtigsten Ablauf — den, mit dem Sie Geld verdienen.
- Bildschirmvorlesen einschalten (VoiceOver auf iOS, TalkBack auf Android) und den Ablauf einmal vollständig durchführen, ohne hinzusehen. Notieren Sie jede Stelle, an der Sie nicht wissen, was passiert ist. Genau das sind Ihre Statusmeldungen.
- Schriftgröße im System auf die größte Stufe stellen und denselben Ablauf wiederholen. Wo Text abgeschnitten wird oder Schaltflächen übereinanderliegen, bricht 1.4.4 — und Sie verlieren nicht Blinde, sondern Ihre ältesten Kunden.
- Das Gerät drehen. Wenn die App im Querformat nicht funktioniert oder gar nicht dreht, prüfen Sie 1.3.4 und fragen Sie sich ehrlich, ob die Fixierung wirklich wesentlich ist.
- Jede Geste einmal ohne die Geste versuchen: Gibt es zu jedem Wischen, Ziehen und Zusammenziehen einen zweiten Weg über eine Schaltfläche? Wenn nicht, ist das 2.5.1 — der häufigste Verstoß in Apps.
Was diese vier Durchläufe nicht ersetzen: den Blick von jemandem, der tatsächlich täglich mit einem Screenreader arbeitet. Der findet in zwanzig Minuten Dinge, die man selbst nach vier Stunden nicht sieht — weil man weiß, wo man hinwill.
Wie wir daran arbeiten
Wie bei Webanwendungen beginnt es mit einer Sichtung statt mit einem Angebot: ein Tag, an dem wir Ihren Hauptablauf mit Bildschirmvorlesen, größter Schriftgröße und ohne Gesten durchgehen und aufschreiben, welche Kriterien betroffen sind und wie oft. Erst danach steht eine Aufwandsspanne, und zwar nach oben und unten begründet.
Danach wird nicht bildschirmweise gearbeitet, sondern an den gemeinsamen Bauteilen: Wenn Ihre Schaltflächen, Listenzeilen, Dialoge und Formularfelder aus einer gemeinsamen Bibliothek kommen, wirkt jede Korrektur an vielen Stellen gleichzeitig. Das ist der einzige Teil der Arbeit, der sich vervielfacht — und der Grund, warum ein Aufwand pro Bildschirm die falsche Kalkulationsgrundlage ist.
Was wir nicht tun: Konformität testieren. Wer baut, sollte nicht prüfen. Für eine unabhängige Prüfung gibt es Stellen, die nichts anderes tun — und wir sagen Ihnen, wann dieser Schritt sinnvoll ist, nämlich erst, wenn die Bauteile sitzen.
Häufige Fragen
Prüfen Apple und Google die Barrierefreiheit bei der Freigabe?
Nein. Beide Stores enthalten Empfehlungen und Werkzeuge, aber eine Ablehnung wegen fehlender Barrierefreiheit ist nicht der Regelfall. Verlassen Sie sich also nicht darauf, dass eine erfolgreiche Store-Freigabe irgendetwas über Konformität aussagt — sie sagt nichts darüber aus.
Wir haben eine App und eine Website. Reicht es, wenn eines von beiden barrierefrei ist?
Nein. Erfasst ist die Dienstleistung, und wenn Sie sie über zwei Kanäle anbieten, muss sie über beide zugänglich sein. Eine Ausnahme wäre allenfalls denkbar, wenn die App gar keine eigene Dienstleistung erbringt, sondern nur auf die Website verweist — dann ist sie aber auch keine App, sondern ein Lesezeichen.
Müssen Schaltflächen mindestens 44 Punkte groß sein?
Nach dem Maßstab des BFSG nicht. 2.5.5 Zielgröße ist in WCAG 2.1 Stufe AAA, und 2.5.8 Zielgröße (Minimum) ist WCAG 2.2 — die EN 301 549 verweist auf WCAG 2.1 Stufe AA. Die Plattformvorgaben von Apple und Google nennen 44 Punkte beziehungsweise 48 dp, und daran sollten Sie sich halten. Nur schreiben Sie in Ihre Erklärung bitte nicht, Sie hätten damit eine Anforderung erfüllt, die es nicht gibt.
Unsere App ist mit einem plattformübergreifenden Rahmenwerk gebaut. Ist das ein Problem?
Kein grundsätzliches. Die verbreiteten Rahmenwerke bringen inzwischen brauchbare Bedienungshilfen-Anbindungen mit; entscheidend ist, ob Ihr Team sie benutzt oder eigene Bedienelemente nachbaut. Prüfen Sie es empirisch statt theoretisch: Ein Durchlauf mit Bildschirmvorlesen auf beiden Plattformen beantwortet die Frage in zwanzig Minuten.
Wie hoch ist der Aufwand, eine bestehende App nachzurüsten?
Er hängt fast vollständig davon ab, ob es eine gemeinsame Bauteilbibliothek gibt. Kommen Schaltflächen, Listenzeilen und Dialoge von einer Stelle, wirkt jede Korrektur überall — dann ist es ein überschaubarer Posten. Sind dieselben Muster über Jahre einzeln nachgebaut worden, wird daraus ein Umbau der Oberfläche. Welcher Fall vorliegt, sieht man an einem Tag, und deshalb steht am Anfang eine Sichtung.
Wie es weitergeht
45 Minuten mit dem Geschäftsführer. Kostenlos.
Sie beschreiben Ihren Prozess. Wir sagen Ihnen ehrlich, ob sich eine Eigenentwicklung für Sie rechnet — und wenn nicht, welches Standardprodukt besser passt. Danach bekommen Sie eine Einschätzung zu Aufwand und Kosten. Keine Präsentation, kein Verkaufsgespräch.
Termin vereinbaren