Wer eine App barrierefrei gestalten will, macht oft einen folgenschweren Denkfehler: Er überträgt sein Wissen aus der Web-Welt eins zu eins auf die mobile Anwendung. Das geht schief. Eine App funktioniert technisch anders als eine Website – sie wird mit anderen Hilfsmitteln bedient, über andere Gesten gesteuert und über andere Programmierschnittstellen barrierefrei gemacht. Hinzu kommt: Seit dem 28. Juni 2025 erfasst das Barrierefreiheitsstärkungsgesetz auch mobile Anwendungen ausdrücklich, von der Banking-App bis zum Onlineshop. In diesem Leitfaden zeige ich Ihnen, was App-Barrierefreiheit von der Website unterscheidet, welche konkreten Kriterien und Werte gelten, und warum Sie eine App am Ende nur auf echter Hardware wirklich prüfen können. Mit Zahlen, mit Plattform-Details und aus der Erfahrung vieler Audits.

Was bedeutet es, eine App barrierefrei zu machen?

Eine App ist barrierefrei, wenn jeder Mensch sie unabhängig von seinen Fähigkeiten vollständig bedienen kann – ein blinder Nutzer mit dem Screenreader, ein Mensch mit motorischen Einschränkungen über große, gut erreichbare Schaltflächen, ein sehbehinderter Nutzer mit vergrößerter Schrift. Konkret bedeutet das: Alle Bedienelemente tragen aussagekräftige Beschriftungen, die der Screenreader vorlesen kann, komplexe Gesten haben einfache Alternativen, Texte lassen sich vergrößern, und Inhalte werden nicht allein über Farbe vermittelt.

Dass mobile Barrierefreiheit kein Randthema ist, zeigt eine Zahl deutlich: Laut Erhebungen von WebAIM greifen rund 70 Prozent der Screenreader-Nutzer mobil auf digitale Inhalte zu. Wer seine App barrierefrei aufstellt, bedient also nicht eine kleine Minderheit, sondern erreicht den Ort, an dem ein Großteil dieser Nutzer ohnehin unterwegs ist. App-Barrierefreiheit ist damit zugleich eine Frage der Reichweite und der gesetzlichen Pflicht.

Im Kern folgt eine barrierefreie App denselben vier Prinzipien wie jede zugängliche Anwendung – wahrnehmbar, bedienbar, verständlich und robust –, nur dass jedes dieser Prinzipien auf dem Smartphone seine eigene Ausprägung hat. Eine App barrierefrei zu gestalten heißt also nicht, ein neues Regelwerk zu lernen, sondern bekannte Prinzipien in die Sprache der jeweiligen Plattform zu übersetzen.

Warum App-Barrierefreiheit anders funktioniert als im Web

Der entscheidende Unterschied beginnt beim Hilfsmittel. Auf dem Desktop navigieren blinde Nutzer ihren Screenreader vor allem über die Tastatur. Auf dem Smartphone gibt es keine Tastatur – stattdessen kommen die nativen Screenreader der Plattformen zum Einsatz: VoiceOver auf iOS und TalkBack auf Android. Beide werden über Touch-Gesten bedient, etwa durch Wischen zum Navigieren und Doppeltippen zum Aktivieren. Wer eine App barrierefrei machen will, muss diese Gestensteuerung verstehen, denn sie folgt einer völlig anderen Logik als die Tab-Navigation im Browser.

Der zweite Unterschied liegt unter der Oberfläche. Im Web sorgt semantisches HTML dafür, dass ein Screenreader weiß, was ein Button, eine Überschrift oder ein Eingabefeld ist. In nativen Apps gibt es kein HTML. Stattdessen stellen die Plattformen eigene Programmierschnittstellen bereit, über die Entwickler jedem Element seine Rolle, seinen Namen und seinen Zustand mitgeben. Diese Schnittstellen sind das mobile Gegenstück zur HTML-Semantik – und wer sie nicht nutzt, hinterlässt einen für den Screenreader stummen Bildschirm.

Aus diesen Unterschieden folgt eine klare Konsequenz: Web-Wissen ist eine gute Grundlage, aber kein Ersatz für mobiles Fachwissen. Die Prinzipien der Barrierefreiheit – wahrnehmbar, bedienbar, verständlich, robust – gelten zwar identisch, ihre Umsetzung unterscheidet sich aber grundlegend.

Ein konkretes Beispiel verdeutlicht den Unterschied: Im Web genügt oft ein korrektes button-Element, damit der Screenreader es als Schaltfläche ansagt und bedienbar macht. In der nativen App müssen Sie demselben Bedienelement aktiv Namen, Rolle und Zustand zuweisen – exakt das, was Erfolgskriterium 4.1.2 (Name, Rolle, Wert) plattformübergreifend verlangt. Vergisst der Entwickler das, sieht die Schaltfläche optisch völlig normal aus – für den Screenreader ist sie aber ein leeres, stummes Rechteck, das niemand bedienen kann.

Die mobil-spezifischen WCAG-Kriterien, die Sie kennen müssen

Die WCAG gelten für Apps genauso wie für Websites. Mehrere Erfolgskriterien wurden in den Versionen 2.1 und 2.2 eigens mit Blick auf mobile Bedienung ergänzt. Im Mai 2025 hat das W3C zusätzlich mit „WCAG2Mobile“ einen ersten Entwurf (First Draft Note) veröffentlicht, der praxisnah beschreibt, wie sich die WCAG 2.2 auf mobile Apps anwenden lässt – auf native Apps ebenso wie auf Web- und Hybrid-Apps. Wichtig zur Einordnung: Diese Leitlinie ist informativ, sie setzt also keine neuen Pflichten, sondern hilft bei der Auslegung der bestehenden Kriterien. Die folgenden gehören für Apps zu den wichtigsten.

Die wichtigsten im Überblick: Erfolgskriterium 1.3.4 Anzeigeausrichtung (AA) verlangt, dass Inhalte nicht auf eine einzige Ausrichtung – Hoch- oder Querformat – festgelegt sind, sofern nicht zwingend nötig. 1.4.10 Reflow (AA) fordert, dass Inhalte auf kleinen Bildschirmen ohne Zwei-Wege-Scrollen nutzbar bleiben. 2.5.1 Zeigergesten (A) verlangt für jede Mehrfinger- oder Pfadgeste eine Alternative mit nur einem Finger. 2.5.4 Bewegungsaktivierung (A) fordert Alternativen für Funktionen, die durch Gerätebewegung ausgelöst werden, etwa Schütteln oder Neigen. 2.5.7 Ziehbewegungen (AA) verlangt eine Einzelzeiger-Alternative für alles, was per Ziehen bedient wird. Und 2.5.8 Zielgröße (Minimum) (AA), neu in WCAG 2.2, schreibt eine Mindestgröße für Bedienelemente vor. Eine ausführliche Einordnung der Neuerungen finden Sie in unserem Ratgeber zu WCAG 2.2.

Touch-Targets: die konkreten Mindestgrößen

Bei der Größe von Bedienelementen werden die Anforderungen erfreulich konkret – und hier weichen die Maßstäbe von WCAG und Plattformen leicht voneinander ab. Die folgende Tabelle zeigt die Werte, an denen Sie sich orientieren sollten.

Die praktische Lehre daraus ist beruhigend: Wer den Gestaltungsrichtlinien von Apple und Google konsequent folgt, erfüllt und übertrifft die WCAG-2.2-Anforderung an die Zielgröße bereits. Die Plattformhersteller haben Barrierefreiheit an dieser Stelle in ihre eigenen Standards eingebaut. Das Problem entsteht meist dort, wo Designteams diese Vorgaben aus optischen Gründen unterlaufen – winzige Icon-Buttons, eng gesetzte Schließen-Kreuze, gedrängte Tab-Leisten. Genau diese Stellen lassen Menschen mit motorischen Einschränkungen oder Tremor regelmäßig danebentippen. Beachten Sie außerdem den Abstand: Liegen kleine Bedienelemente sehr dicht beieinander, verlangt das Kriterium einen ausreichenden Zwischenraum, um versehentliche Fehlauslösungen zu verhindern – ein gut gesetzter Abstand ist in der Praxis oft wichtiger als die reine Größe eines Elements.

Gesten brauchen immer eine Alternative

Dies ist der Bereich, der Web-Entwickler am häufigsten überrascht – und der bei App-Audits besonders oft auffällt. Komplexe Touch-Gesten sind für viele Menschen nicht ausführbar: Wer nur einen Finger benutzen kann, einen Stift im Mund führt oder mit Tremor lebt, scheitert an Mehrfingergesten und präzisen Ziehbewegungen. Die WCAG verlangen deshalb für jede solche Geste eine einfachere Alternative. Entscheidend ist dabei ein Punkt, den das W3C ausdrücklich betont: Eine Tastatur-Alternative reicht auf dem Smartphone nicht – die Alternative muss per Touch verfügbar sein.

In der Praxis bedeutet das konkrete Lösungsmuster, die Sie kennen sollten. Eine Wisch-zum-Löschen-Funktion braucht zusätzlich einen Bearbeiten-Modus mit sichtbaren Lösch-Schaltflächen oder ein Kontextmenü über langes Drücken. Ein Neuordnen per Ziehen und Ablegen braucht alternative Hoch- und Runter-Schaltflächen oder ein „Verschieben nach“-Menü. Ein Schieberegler braucht ein Texteingabefeld zur direkten Werteingabe. Diese Alternativen kosten wenig Aufwand, entscheiden aber darüber, ob ein erheblicher Teil Ihrer Nutzer eine Funktion überhaupt erreichen kann.

Aus der Praxis: Eine Liefer-App ließ ihre gesamte Bestellverwaltung über Wischgesten laufen – nach rechts wischen zum Bestätigen, nach links zum Stornieren, lange ziehen zum Verschieben. Schön gedacht, für VoiceOver-Nutzer aber eine Sackgasse: Keine dieser Aktionen war ohne die Geste erreichbar. Wir ergänzten für jede Wischaktion einen regulären Button im Detailbildschirm. Der visuelle Komfort der Gesten blieb erhalten, aber die Funktionen waren nun für alle zugänglich. Eine App barrierefrei zu machen heißt selten, etwas wegzunehmen – meist heißt es, einen zweiten Weg zu ergänzen.

VoiceOver und TalkBack: die nativen Screenreader

Im Zentrum der App-Barrierefreiheit stehen die beiden nativen Screenreader. VoiceOver auf iOS und TalkBack auf Android lesen blinden und sehbehinderten Menschen vor, was auf dem Bildschirm passiert, und ermöglichen die Bedienung per Gesten. Damit sie das leisten können, müssen Entwickler jedem Element die nötigen Informationen mitgeben – über die Barrierefreiheits-Schnittstellen der Plattform.

Auf iOS geschieht das über Eigenschaften wie accessibilityLabel für den vorzulesenden Namen, accessibilityHint für einen ergänzenden Bedienhinweis und accessibilityTraits für die Rolle, etwa „Schaltfläche“ oder „ausgewählt“. Auf Android übernimmt unter anderem die contentDescription diese Aufgabe. Der häufigste Fehler ist, reine Icon-Buttons ohne Beschriftung zu belassen – der Screenreader meldet dann nur „Schaltfläche“ ohne jeden Hinweis auf die Funktion. Ebenso wichtig sind eine logische Fokus-Reihenfolge, die der sichtbaren Anordnung folgt, und das sinnvolle Gruppieren zusammengehöriger Elemente, damit der Nutzer nicht durch Dutzende Einzelteile wischen muss.

Ein mobiler Stolperstein, den man im Web so nicht kennt: Ein selbst gezeichnetes Bedienelement – ein als Bild gerendertes Icon, eine per Canvas gemalte Schaltfläche – trägt für den Screenreader zunächst gar keine Rolle. VoiceOver und TalkBack kündigen es bestenfalls als „Bild“ an, nicht als „Schaltfläche“, sodass der Nutzer nicht einmal ahnt, dass es antippbar ist. Sie müssen solchen Elementen die Rolle explizit zuweisen – auf iOS über das passende accessibilityTrait, auf Android über die Rolle im Accessibility-Node. Je weiter eine App von den Standard-Bedienelementen der Plattform abweicht, desto mehr dieser Zuweisungen müssen Sie von Hand nachziehen – ein Aufwand, den selbstgebaute Designsysteme regelmäßig unterschätzen.

Eine besondere Herausforderung sind dynamische Änderungen. Wenn sich der Bildschirm ändert, ohne dass der Nutzer es unmittelbar ausgelöst hat – ein Ladevorgang endet, eine Fehlermeldung erscheint, der Warenkorb aktualisiert sich –, muss der Screenreader das aktiv ankündigen. Beide Plattformen stellen dafür eigene Mechanismen für Statusmeldungen bereit, auf iOS etwa über gezielte Ankündigungen an VoiceOver. Bleiben solche Änderungen stumm, bemerkt ein blinder Nutzer sie schlicht nicht und arbeitet mit einem veralteten Stand weiter – ein Fehler, der gerade in Bezahl- und Formularabläufen schwer wiegt.

Aus der Praxis: Eine Banking-App war technisch sauber gebaut, hatte aber alle Symbol-Schaltflächen ihrer Navigationsleiste ohne Beschriftung gelassen. Ein blinder Tester hörte beim Durchwischen viermal nur „Schaltfläche, Schaltfläche, Schaltfläche, Schaltfläche“ – ohne zu wissen, welche zum Konto, zur Überweisung oder zum Profil führte. Das Hinzufügen aussagekräftiger Labels war eine Sache weniger Stunden und machte die App auf einen Schlag bedienbar.

Dynamische Schrift, Kontrast und Dark Mode

Die wahrnehmbare Seite einer App entscheidet sich vor allem an der Schrift. Beide Plattformen bieten eine systemweite Einstellung zur Textvergrößerung – auf iOS unter dem Namen Dynamic Type. Eine barrierefreie App respektiert diese Einstellung und passt ihre Schriftgrößen entsprechend an, ohne dass Text abgeschnitten wird oder Layouts zerbrechen – das mobile Gegenstück zu Erfolgskriterium 1.4.4 (Textgröße ändern). Der klassische Fehler sind fest in Punkten oder dp verdrahtete Schriftgrößen, die jede Vergrößerung ignorieren – für Menschen mit Sehbehinderung eine unüberwindbare Hürde. Gehen Sie hier großzügig vor: Beide Systeme bieten sehr große Schriftstufen für Menschen mit starker Sehbehinderung, und wer eine App barrierefrei gestalten will, sollte auch diese extremen Stufen verkraften, ohne dass Bedienelemente unerreichbar werden oder Texte sich überlagern. Testen Sie Ihre Bildschirme deshalb bewusst bei maximaler Schriftgröße.

Hinzu kommen die vertrauten Anforderungen an den Kontrast (Kriterium 1.4.3): Text muss sich ausreichend vom Hintergrund abheben, mit den bekannten Mindestwerten von 4,5:1 für normalen und 3:1 für großen Text. Eine Besonderheit mobiler Apps ist der Dark Mode: Prüfen Sie Kontraste und Lesbarkeit immer in beiden Erscheinungsbildern, hell und dunkel, denn eine Farbkombination, die im hellen Modus funktioniert, kann im dunklen versagen. Und auch hier gilt der Grundsatz, Information niemals allein über Farbe zu transportieren (Kriterium 1.4.1) – ein rot markierter Fehlerzustand braucht zusätzlich ein Symbol oder einen Text.

Apps fallen unter das BFSG

Die Frage nach der App-Barrierefreiheit ist seit Mitte 2025 keine reine Kür mehr. Der European Accessibility Act, den das deutsche Barrierefreiheitsstärkungsgesetz umsetzt, erfasst mobile Anwendungen ausdrücklich. Wer also eine App im Geltungsbereich betreibt – typischerweise im Endkundengeschäft – muss sie barrierefrei gestalten. Das betrifft eine breite Palette: Banking- und Zahlungs-Apps, die Apps von Onlineshops und Marktplätzen, Apps im Personenverkehr und in der Reisebuchung sowie weitere Dienstleistungen für Verbraucher. Wer hier nicht liefert, riskiert nicht nur den Ausschluss eines erheblichen Nutzerkreises, sondern auch die Aufmerksamkeit der Marktüberwachungsbehörden, an die sich Betroffene mit Beschwerden wenden können – mit möglichen Anordnungen und Bußgeldern als Folge.

Die rechtliche Logik ist dabei dieselbe wie im Web: Maßstab sind die harmonisierte europäische Norm und über sie die WCAG auf den Stufen A und AA. Für eine App barrierefrei umzusetzen heißt damit konkret, die in diesem Leitfaden beschriebenen Kriterien zu erfüllen – von den Gesten-Alternativen über die Touch-Targets bis zur sauberen Screenreader-Unterstützung. Ausführlicher gehen wir auf die gesetzlichen Hintergründe im Ratgeber zum European Accessibility Act ein.

Barrierefreiheit im App-Entwicklungsprozess verankern

Wie im Web gilt auch bei mobilen Anwendungen: Nachträglich eingebaute Barrierefreiheit ist teuer und lückenhaft, von Anfang an mitgedachte ist günstig und robust. Der wirksamste Hebel ist ein Komponenten- und Design-System, in dem die Bausteine bereits barrierefrei angelegt sind – Schaltflächen in der richtigen Mindestgröße, Bedienelemente mit hinterlegten Beschriftungen, definierte Fokus-Reihenfolgen. Wer aus solchen geprüften Komponenten baut, erzeugt eine barrierefreie App fast nebenbei, statt jeden Bildschirm einzeln nachbessern zu müssen.

Ebenso entscheidend ist das frühe und kontinuierliche Testen. Nehmen Sie Barrierefreiheits-Prüfungen in Ihre Entwicklungs-Pipeline auf und gewöhnen Sie Ihr Team daran, die wichtigsten Abläufe regelmäßig selbst mit VoiceOver oder TalkBack durchzugehen – ein einmaliger Test am Ende des Projekts genügt nicht. Jedes Update und jede neue Funktion kann frische Barrieren einführen, weshalb es eine fortlaufende Aufgabe ist, eine App barrierefrei zu halten, und kein einmaliges Projekt mit Enddatum.

Warum Sie eine App nur auf echten Geräten testen können

Hier kommt der Punkt, an dem sich Anspruch und Wirklichkeit trennen. Automatische Prüfwerkzeuge und Emulatoren können erste Hinweise liefern – ob ein Label fehlt, ob ein Kontrast zu schwach ist. Was sie nicht beurteilen können, ist das eigentliche Erlebnis: ob die Fokus-Reihenfolge mit VoiceOver tatsächlich Sinn ergibt, ob sich ein blinder Mensch durch den Bezahlvorgang navigieren kann, ob eine Geste auf einem realen Gerät mit aktiviertem Screenreader wie erwartet funktioniert. Das W3C und die Fachwelt sind sich einig: Mobile Barrierefreiheit braucht einen hybriden Ansatz aus Automatisierung und manueller Prüfung auf echter Hardware.

Genau hier setzt unser Anker-Audit Access Ready an. Wir prüfen Apps nicht im Emulator und nicht per Skript-Abhaken, sondern mit echten Nutzern assistiver Technologien auf echten Geräten – mit VoiceOver und TalkBack, durch jeden zentralen Ablauf, von der Anmeldung bis zum Abschluss. So sehen Sie nicht, ob ein Label technisch existiert, sondern ob ein blinder Mensch Ihre App tatsächlich bedienen kann. Andere prüfen, was eine Maschine im Emulator erkennt; wir prüfen, was auf dem realen Gerät bei realen Menschen ankommt – und führen Sie bis zum rechtlich belastbaren Zertifikat. Bei einer App, deren Barrieren man dem Code nicht ansieht, ist dieser Unterschied entscheidend. Und weil jede App und jede Plattformversion ihre Eigenheiten mitbringt, lässt sich dieser menschliche, gerätenahe Blick durch kein automatisches Werkzeug ersetzen – er ist der Kern dessen, was Access Ready leistet.

Aus der Praxis: Ein Entwicklungsteam hatte seine App mit einem automatischen Tool im Emulator geprüft – Ergebnis: nahezu fehlerfrei. Im echten Test mit VoiceOver auf dem iPhone zeigte sich ein anderes Bild: Nach dem Öffnen eines Dialogs sprang der Fokus nicht in den Dialog, sondern blieb im Hintergrund hängen, sodass blinde Nutzer den Dialog gar nicht bemerkten. Kein Emulator hatte das gemeldet. Erst die Hand am echten Gerät machte die Barriere sichtbar.

Vom barrierefreien Code zum belastbaren Nachweis

Eine App barrierefrei zu machen ist anspruchsvoller, als viele zunächst annehmen – aber es folgt klaren Regeln. Sie kennen jetzt die mobil-spezifischen Kriterien, die Plattform-Schnittstellen, die Touch-Targets und die Notwendigkeit echter Tests. Was bleibt, ist der Nachweis, dass Ihre App in der Hand echter Nutzer auch wirklich funktioniert – und dass Sie damit Ihre gesetzlichen Pflichten erfüllen. Eine App barrierefrei zu machen ist am Ende kein Hexenwerk, sondern eine Frage von Sorgfalt, dem richtigen mobilen Fachwissen und ehrlichem Testen auf echter Hardware.

Wenn Sie wissen wollen, ob Ihre App den Anforderungen nach BFSG standhält und sie für jeden Menschen bedienbar ist, führt der Weg über Access Ready, unser zertifiziertes Tiefen-Audit mit echten Nutzern auf echten Geräten. Eine Übersicht über die rechtlichen Pflichten und Grundlagen finden Sie in unserem Ratgeber zur digitalen Barrierefreiheit, und wie die zugrundeliegenden Standards funktionieren, erklärt unser Beitrag zum WCAG-Standard. Ich verspreche Ihnen keine perfekte App per Knopfdruck – aber die Gewissheit, dass jeder Mensch sie bedienen kann, und das Dokument, mit dem Sie Ihre Sorgfaltspflicht belegen.