Seit dem 28. Juni 2025 gilt das Barrierefreiheitsstärkungsgesetz (BFSG). Damit wird Barrierefreiheit für viele privatwirtschaftliche digitale Angebote von einem „nice to have“ zu einer rechtlichen Verpflichtung. In der Praxis zeigt sich jedoch schnell: Rechtskonformität bedeutet noch lange nicht gute Nutzbarkeit.
Zudem stammen viele Beispiele, Leitfäden und Checklisten aus der Webentwicklung. Die zugrunde liegenden Prinzipien sind zwar übertragbar, die konkrete Umsetzung in nativen Apps funktioniert jedoch nicht eins zu eins.
Dieser Beitrag beleuchtet typische Stolpersteine in App-Projekten: Wo entstehen Barrieren tatsächlich? Warum bestehen Apps formale Audits und frustrieren dennoch Nutzende? Und wie lässt sich verhindern, dass Accessibility mit jedem Release wieder beschädigt wird?
BFSG in der Realität: Scope zuerst klären
Bevor einzelne UI-Details optimiert werden, sollte der Anwendungsbereich klar definiert sein. Betrifft das BFSG ausschließlich die App selbst oder auch Onboarding-Mails, In-App-Hilfen, Checkout-Prozesse und Support-Strecken?
Diese End-to-End-Betrachtung entscheidet später über Aufwand, Risiko, Verantwortlichkeiten und Nachweisbarkeit. Wer den Scope zu eng fasst, riskiert Lücken in der Barrierefreiheit entlang der gesamten Nutzerreise.
„Kriterien erfüllt“ vs. „Nutzer kommen durch“
In Audits begegnet man häufig Apps, die formal vieles richtig machen: Labels sind gesetzt, Kontraste stimmen, Text ist skalierbar. Trotzdem berichten Screenreader-Nutzende von Brüchen im Flow.
Der Grund liegt auf der Hand: Barrierefreiheit ist nicht nur eine Eigenschaft einzelner UI-Elemente, sondern vor allem eine Frage der Interaktion.
Typische Ursachen sind:
- Eine unplausible oder springende Fokuslogik.
- Zustände (ausgewählt, deaktiviert, Fehler), die ausschließlich visuell erkennbar sind.
- Modals, die den Fokus nicht korrekt einfangen oder ihn nach dem Schließen nicht sinnvoll zurückgeben.
- Fehlermeldungen, die zwar existieren, aber nicht kontextnah angekündigt werden.
Wird Accessibility lediglich als Sammlung technischer UI-Attribute verstanden, bleibt die eigentliche Herausforderung ungelöst: ein durchgängig nutzbarer Journey-Flow.
Warum Web-Beispiele bei Apps oft nicht passen
Grundsätzlich gelten Standards auch im mobilen Kontext. Dennoch unterscheiden sich die typischen Fehlerbilder deutlich.
Im Web lässt sich die Bedienlogik häufig über DOM-Reihenfolgen und Tab-Navigation erklären. In nativen Apps hingegen hängen Vorlese- und Navigationsreihenfolge stark von der View-Hierarchie, dem Accessibility-Tree und plattformspezifischen Konventionen ab. Eine visuell „richtige“ Anordnung garantiert daher noch keine sinnvolle Screenreader-Reihenfolge.
Hinzu kommt: Viele Web-Beispiele setzen implizit eine Tastaturbedienung voraus. Auf dem Smartphone dominieren jedoch Screenreader-Gesten, Switch Control, externe Tastaturen oder Sprachsteuerung als Eingabemodelle.
Gleichzeitig sind mobile UIs stark von Betriebssystemeinstellungen geprägt. Schriftgrößen, Display-Zoom, fetter Text, reduzierte Bewegung oder Kontrastoptionen können Layout und Interaktion erheblich verändern. Eine App muss unter diesen Bedingungen nicht nur technisch stabil bleiben, sondern auch in der Bedienung konsistent funktionieren.
Zentrale Herausforderungen in App-Projekten
Touch Targets
Zu kleine Touch-Ziele gehören sowohl in Audits als auch in der täglichen Nutzung zu den häufigsten Ursachen für Frustration – insbesondere bei iconbasierten Controls, Chips oder dicht gepackten Listeneinträgen.
Ein häufiger Irrtum besteht darin, die sichtbare Icon-Größe mit der tatsächlich interaktiven Touch-Fläche gleichzusetzen. Entscheidend ist jedoch die effektive Trefferfläche.
Nachhaltig wird das Thema meist erst dann gelöst, wenn Touch Targets als explizites Qualitätsmerkmal definiert und systematisch geprüft werden – etwa durch Design-Reviews, automatisierte Scans und manuelle Tests auf realen Geräten.
Screenreader-Qualität
Bei Screenreadern beginnt Barrierefreiheit nicht mit der bloßen Existenz eines Labels, sondern mit einer verständlichen und handlungsleitenden Ausgabe.
Wichtige Fragen sind dabei:
- Ist die Aktion eines Buttons eindeutig formuliert?
- Werden Zustände wie „ausgewählt“, „deaktiviert“ oder „Fehler“ konsistent angesagt?
- Werden dynamische Änderungen (z. B. Filter, Summen, Statuswechsel) so kommuniziert, dass Nutzende die Orientierung behalten?
Bewährt hat sich, für zentrale Komponenten und Journeys eine klare Vorleselogik festzulegen – also zu definieren, was wann und in welcher Reihenfolge angesagt wird – und diese Logik als Teil der UX-Texte und Produktanforderungen zu versionieren.
Formulare & Checkout
Formulare und Checkout-Strecken sind in Apps besonders fehleranfällig. Hier treffen zahlreiche Interaktionsmuster aufeinander: Feldvalidierung, dynamische Hinweise, Formatmasken, Autocomplete sowie Sicherheits- und Verifikationsschritte.
Typische Bruchstellen sind:
- Fokusverschiebungen nach Validierungen,
- Fehlermeldungen, die nur visuell auffallen,
- Eingabemasken, die Screenreader aus dem Tritt bringen,
- Verifikationsschritte, die nicht für alle Nutzungsarten barrierefrei bedienbar sind.
Zuverlässig wird es, wenn Kernformulare als verbindliches Abnahmekriterium definiert und regelmäßig unter realistischen Bedingungen getestet werden: mit VoiceOver und TalkBack, mit großer Schrift und Zoom sowie mit alternativen Eingaben wie externer Tastatur oder Switch Control.
Teststrategie: Von der formalen Prüfung zur realen Nutzung
Um die Lücke zwischen formaler Konformität und tatsächlicher Nutzbarkeit zu schließen, braucht es mehr als das bloße Abhaken einzelner Kriterien.
Automatisierte Tools eignen sich gut, um wiederkehrende Regressionen, etwa Kontrastprobleme oder fehlende Labels, frühzeitig zu erkennen. Typische Interaktionsfehler erfassen sie jedoch nur eingeschränkt.
In der Praxis hat sich daher ein mehrstufiger Ansatz bewährt:
- Automatisierte Scans in der CI-Pipeline, um offensichtliche Verstöße kontinuierlich abzufangen.
- Regelmäßige manuelle Screenreader-Smoke-Tests auf einer definierten Geräte- und OS-Matrix.
- Tests mit realistischen Systemeinstellungen, z. B. großer Schrift, Zoom, Dark Mode oder reduzierter Bewegung.
- Usability-Tests mit Betroffenen, um zu prüfen, ob die App im Alltag tatsächlich gut bedienbar ist.
Erst diese Kombination macht sichtbar, ob die Barrierefreiheit wirklich gegeben ist.
Accessibility regressionssicher verankern
Damit Accessibility nicht mit jedem Release wieder bricht, muss sie als dauerhaftes Qualitätsmerkmal im Entwicklungsprozess verankert werden.
Besonders wirksam ist es, klare Abnahmekriterien in der Definition of Done für zentrale Komponenten und Journeys festzuschreiben, etwa zur Fokusführung, zu Zuständen, zu Touch Targets und zum Verhalten bei großer Schrift.
Ein Design-System mit barrierefreien Standardkomponenten reduziert zusätzlich das Risiko, da bewährte Lösungen wiederverwendet werden können.
Ergänzend hilft ein kleiner, fester Satz an Testszenarien, die bei jedem Release mit VoiceOver und TalkBack überprüft werden. So werden typische Rückfälle frühzeitig sichtbar. Voraussetzung dafür ist eine klare Verantwortung im Team, damit Findings priorisiert und konsequent nachverfolgt werden.
Fazit
Das BFSG setzt den rechtlichen Rahmen. Entscheidend für App-Projekte ist jedoch die tatsächliche Nutzbarkeit.
Diese zeigt sich in stabilen Journeys: nachvollziehbare Fokusführung, eindeutig kommunizierte Zustände, robuste Formular- und Checkout-Abläufe, ausreichend große Touch Targets und eine Bedienung, die auch unter typischen Betriebssystemeinstellungen zuverlässig funktioniert.
Wer Barrierefreiheit als kontinuierliche Produktqualität versteht und mit klaren Tests sowie wirksamem Regressionsschutz verankert, erfüllt nicht nur gesetzliche Anforderungen, sondern verbessert die Nutzung für möglichst viele Menschen.
0 Kommentare