Barrierefreiheit mobiler Apps: Pflicht und Umsetzung

Muss eine App barrierefrei sein?

Keine Rechtsberatung.Dieser Abschnitt fasst kurz zusammen, was ich in zwei Ratgebern aus amtlichen Quellen zusammengetragen habe. Lesen Sie für Ihren Fall den Gesetzestext und fragen Sie eine Juristin oder einen Juristen.

Die kurze Antwort: Bieten Sie eine Dienstleistung an, die unter das BFSG fällt, betrifft das sehr wahrscheinlich auch Ihre App. Laut der Bundesfachstelle Barrierefreiheit gilt das Gesetz seit dem 28. Juni 2025, unter anderem für Bankdienstleistungen und den elektronischen Geschäftsverkehr. Ausdrücklich genannt sind auch auf Mobilgeräten angebotene Dienstleistungen, inklusive Apps, im überregionalen Personenverkehr.

Auch der European Accessibility Act, den das BFSG umsetzt, denkt Apps mit: Nach Artikel 3(30) der Richtlinie ist eine Dienstleistung im elektronischen Geschäftsverkehr eine, die über eine Website oder eine mobile App erbracht wird. Kleinstunternehmen, die Dienstleistungen anbieten, sind ausgenommen. Die Einzelheiten stehen im Ratgeber zum European Accessibility Act.

Zu den Normen schreibt die Bundesfachstelle, dass die EN 301 549 V3.2.1 die zentrale technische Referenz ist. Die Norm behandelt neben Websites ausdrücklich auch Software und Apps, in Abschnitt 11. Was das für WCAG heißt, steht im WCAG-Ratgeber.

Wie WCAG auf eine mobile App angewendet wird

Das W3C schreibt keinen eigenen Leitfaden für Mobilgeräte. Laut der WAI-Seite zur mobilen Barrierefreiheit deckt WCAG auch Inhalte ab, die auf Mobilgeräten genutzt werden. Dieselbe Seite schreibt, dass WCAG 2.1 und 2.2 neue Erfolgskriterien zur mobilen Barrierefreiheit hinzugefügt haben.

Für Apps gibt es auch ein Hilfsdokument: WCAG2Mobile. Es ist eine Entwurfsnotiz vom 6. Mai 2025, nicht verbindlich, nur informativ. Es wendet die Kriterien A und AA von WCAG 2.2 auf native, hybride und mobile Web-Apps an.

Der nützlichste Teil des Dokuments ist für mich dieser: Der „Seite“ im Web entspricht in der App ein einzelner Screen. Das Dokument nennt auch seine eigene Grenze: Allein reicht es nicht.

WCAG 2.2 ist die W3C-Empfehlung vom 12. Dezember 2024. Alle Kriterien und Stufen beschreibe ich im WCAG-Ratgeber. Auf dieser Seite schaue ich auf die Themen, die mobil am häufigsten kaputtgehen.

Screenreader: VoiceOver und TalkBack

Auf dem iPhone heißt der Screenreader VoiceOver, auf Android TalkBack. Apple beschreibt VoiceOver als Screenreader, der mit Gesten bedient wird und den Screen per Sprache beschreibt. TalkBack liest laut Android Inhalte für Menschen, die nicht oder schlecht sehen, mit synthetischer Stimme vor.

Laut Apples Testleitfaden wählt Wischen nach rechts oder links bei aktivem VoiceOver das nächste oder vorherige Element. Bei jedem Element soll der Nutzer Namen, Rolle und gegebenenfalls Zustand hören. Das Kriterium 4.1.2 Name, Rolle, Wert der WCAG 2.2 (Stufe A) verlangt, dass Name und Rolle programmatisch bestimmbar sind.

Probieren Sie den Screen unten in beiden Fassungen aus. Gehen Sie zuerst die Fassung ohne Labels von Anfang bis Ende durch, wechseln Sie dann zur Fassung mit Labels und machen Sie dasselbe.

Screenreader und Schriftgröße

Rechnung bezahlen

Kundennummer Kundennr.z. B. 1042 7781 Steht oben links auf Ihrer Rechnung.

48,60 € bezahlen

Zwei Fassungen eines Screens zum Bezahlen einer Rechnung. Navigieren Sie mit Nächstes Element wie ein Screenreader; der vorgelesene Text erscheint im gelben Kasten. Der Schieberegler vergrößert die Schrift, ein gestrichelter Rahmen zeigt Elemente mit abgeschnittenem Text. Die vorgelesenen Wörter sind beispielhaft; was ein echter Screenreader sagt, hängt von Version und Sprache ab.

Ist JavaScript aus, lesen Sie denselben Vergleich in dieser Tabelle.

Reihenfolge	Vorgelesen auf dem Screen ohne Labels	Vorgelesen auf dem Screen mit Labels
1	Taste.	Zurück, Taste.
2	48,60 € bezahlen, Taste.	Zu Favoriten hinzufügen, Schalter, aus.
3	ic_star_outline, Taste.	Rechnung bezahlen, Überschrift.
4	Rechnung bezahlen.	Kundennummer, Textfeld. Steht oben links auf Ihrer Rechnung.
5	Bild.	48,60 € bezahlen, Taste.
6	Textfeld.	Kein Element mehr zum Vorlesen. Das Zierbild wurde übersprungen.

Wie man ein Label schreibt

Apples Regel ist klar: Geben Sie jedem wichtigen Element der Oberfläche ein alternatives Label und halten Sie es aktuell, wenn sich die Oberfläche ändert. Zierbilder blenden Sie für VoiceOver aus.

Auf Android wird das Label mit contentDescription vergeben. Für Elemente mit Text braucht es das nicht, weil TalkBack den Text selbst vorliest. Das ist der Grund, warum die Taste Bezahlen in der Demo auch ohne Label richtig vorgelesen wird.

Android hat zwei praktische Hinweise. Schreiben Sie die Rolle nicht ins Label: nicht „Senden-Taste“, sondern „Senden“. Geben Sie in einer Liste jedem Element ein eigenes Label; hört der Nutzer ein Label erneut, weiß er, dass er beim selben Element ist.

Dynamische Schriftgröße

Nutzer vergrößern die Schrift des Handys in den Einstellungen. Apple nennt diese Systemeinstellung Dynamic Type und empfiehlt, dass Text idealerweise um mindestens 200 Prozent wachsen kann. Auch das Kriterium 1.4.4 der WCAG 2.2 (Stufe AA) verlangt, dass beim Vergrößern bis 200 Prozent kein Inhalt und keine Funktion verloren geht.

Der Verlust zeigt sich meist als abgeschnittener Text. Das Fehlerbeispiel F69 des W3C beschreibt das: Schneidet die Vergrößerung Text oder Steuerelemente ab, kappt oder überdeckt sie, ist das Kriterium nicht erfüllt.

Ziehen Sie in der Demo oben den Regler auf 200 %. In der Fassung ohne Labels werden Überschrift, Textfeld und Taste Bezahlen abgeschnitten, weil sie eine feste Höhe haben. In der Fassung mit Labels wachsen die Kästen mit der Schrift.

Apples Testliste fragt dasselbe: Bei großen Größen für Barrierefreiheit soll das Layout neu fließen, Text darf nicht abgeschnitten werden, Elemente dürfen sich nicht überlagern.

Tippziele

In Apples Tabelle ist die Standardgröße eines Steuerelements auf iOS 44 × 44 pt, die kleinste 28 × 28 pt. Android empfiehlt für jedes interaktive Element mindestens 48 dp × 48 dp und sagt „größer ist besser“.

Das Kriterium 2.5.8 der WCAG 2.2 (Stufe AA) setzt eine niedrigere Untergrenze: 24 × 24 CSS-Pixel, mit einigen Ausnahmen. Mobil ziele ich auf die Empfehlung der Plattform und sehe WCAG als Boden.

Auch der Abstand ist wichtig. Apple schreibt, dass um gerahmte Elemente etwa 12 pt und um ungerahmte etwa 24 pt Abstand gut funktionieren.

Kontrast

Das Kriterium 1.4.3 der WCAG 2.2 (Stufe AA) verlangt für Text mindestens 4,5:1 Kontrast und setzt für großen Text eine niedrigere Schwelle. Android schreibt dieselbe Schwelle in eigener Einheit: 4,5:1 bei Text unter 18 sp oder fettem Text unter 14 sp, 3:1 bei anderem Text.

Apple schreibt, dass der Accessibility Inspector die Werte von WCAG AA nutzt: 4,5:1 bei Text bis 17 pt, 3:1 bei Text mit 18 pt und bei fettem Text.

Apple verlangt noch zwei Dinge. Gibt es einen Dunkelmodus, messen Sie den Kontrast in beiden Modi. Reichen die Standardfarben nicht, bieten Sie bei aktivem „Kontrast erhöhen“ ein kräftigeres Farbschema an.

Ihre Farben messen Sie im Kontrastrechner. Android empfiehlt außerdem, den Kontrast mit der App Accessibility Scanner zu prüfen.

Bewegung reduzieren

Bewegung auf dem Screen löst bei manchen Menschen Schwindel und Übelkeit aus. Das W3C zählt Kopfschmerzen zu diesen Reaktionen, die vom Innenohr ausgehen. Laut Apple können Menschen, die dafür anfällig sind, die Einstellung „Bewegung reduzieren“ einschalten.

Ist die Einstellung an, soll die App Animationen reduzieren, die von selbst starten und sich wiederholen: Zoomen, Skalieren, Bewegung am Rand des Screens. Apples Empfehlungen sind konkret. Reduzieren Sie das Federn von Animationen und ersetzen Sie Übergänge, die entlang einer Achse gleiten, durch langsames Ein- und Ausblenden.

In WCAG entspricht dem das Kriterium 2.3.3; es gehört zur Stufe AAA. Ich verlange trotzdem, dass diese Einstellung beachtet wird, weil es in den meisten Projekten eine kleine Arbeit ist. Auch auf dieser Website halten die Animationen an, wenn die Einstellung an ist.

Alternativen zu Gesten

Zum Löschen wischen oder mit zwei Fingern zoomen geht schnell, aber nicht jeder kann diese Gesten ausführen. Das Kriterium 2.5.1 der WCAG 2.2 (Stufe A) verlangt: Was mit einer Geste mit mehreren Fingern oder einem Pfad geht, muss auch mit einem Finger und ohne Pfad gehen. Ist die Geste wesentlich, gibt es eine Ausnahme; Ziehen behandelt das Kriterium 2.5.7.

Das Beispiel des W3C ist eine Karte: neben dem Zoomen mit zwei Fingern Tasten für Plus und Minus. Apple sagt dasselbe: Schließen Sie eine Ansicht per Wischen, setzen Sie auch eine Taste zum Antippen dazu.

Bei aktivem Screenreader dient Wischen der Navigation zwischen Elementen, deshalb braucht eine Aufgabe, die per Wischen geht, einen anderen Weg. Android empfiehlt dafür eigene Aktionen für Barrierefreiheit (customActions) für Dinge wie Wischen und Ziehen. Im Beispiel der Dokumentation wird ein Artikel per Wischen aus der Liste entfernt; dieselbe Aufgabe steht auch im Aktionsmenü als „Aus Liste entfernen“.

Fokus-Reihenfolge

Ein Screenreader liest Elemente in einer Reihenfolge vor. Laut Apple ist das die Lesereihenfolge der jeweiligen Sprache, im Englischen von oben nach unten und von links nach rechts. Auch die Compose-Dokumentation von Android beschreibt als Standard links nach rechts, dann oben nach unten.

Ein Problem entsteht, wenn das visuelle Layout nicht zu dieser Reihenfolge passt. Im Beispiel von Android wird ein zweispaltiges Layout Zeile für Zeile gelesen, und die Sätze geraten durcheinander. Die Lösung: zusammengehörige Elemente mit isTraversalGroup gruppieren und bei Bedarf mit traversalIndex ordnen.

Das Kriterium 2.4.3 der WCAG 2.2 (Stufe A) verlangt genau das: Der Fokus wandert in einer Reihenfolge, die Bedeutung und Bedienung erhält. Im Screen ohne Labels in der Demo verletzt die zweite Position der Taste Bezahlen diese Regel.

Formularlabels

Das Kriterium 3.3.2 der WCAG 2.2 (Stufe A) ist kurz: Wird vom Nutzer eine Angabe verlangt, braucht es ein Label oder eine Anweisung. Die Abkürzung, die ich mobil am häufigsten sehe: das Label weglassen und nur den blassen Hinweis im Feld stehen lassen.

Auch Android trennt beides. Der Hinweistext gibt ein Beispiel für eine gültige Eingabe; das Label sagt, was ins Feld gehört. Im Feld mit Labels in der Demo stehen beide zusammen: das Label „Kundennummer“ und der Hinweis „z. B. 1042 7781“.

Neben dem Label braucht es auch die richtige Tastatur und verständliche Fehlermeldungen. Das beschreibe ich in den Mustern zum Formulardesign und zu Fehlermeldungen.

Überschriften, Gruppen und Bildschirmausrichtung

Wer einen Screenreader nutzt, hört nicht jedes Element einzeln. Mit dem Rotor von VoiceOver kann man laut Apple in einem Dokument oder auf einer Webseite zwischen Überschriften und Links springen. Damit das Springen funktioniert, muss die Überschrift im Code als Überschrift ausgezeichnet sein.

Auf Android erledigt das die Eigenschaft heading() in Compose. Die Dokumentation schreibt, dass Nutzer wählen können, statt zwischen Absätzen zwischen Überschriften zu navigieren. Die Zeile, die im Screen mit Labels in der Demo als „Rechnung bezahlen, Überschrift“ vorgelesen wird, ist ein Beispiel dafür.

Auch Gruppieren verkürzt die Lesezeit. Android empfiehlt, zusammengehörige Elemente, etwa die Details eines Songs, mit mergeDescendants auf einmal vorlesen zu lassen. Dann soll nur das umgebende Element interaktiv sein, nicht die Elemente darin.

Nutzen Sie Farbe nicht als einziges Signal. Im Beispiel von Android werden zwei Tasten, die nur durch Grün und Rot unterschieden werden, mit Text und Icon auch für Nutzer mit Farbsehschwäche verständlich.

Für die Bildschirmausrichtung gibt es das Kriterium 1.3.4 der WCAG 2.2 (Stufe AA): Ist die Ausrichtung nicht wirklich wesentlich, wird der Inhalt nicht auf hoch oder quer festgelegt. Das Beispiel des W3C: Bei manchen Nutzern ist das Gerät in fester Ausrichtung am Arm eines elektrischen Rollstuhls montiert. Diese Person kann das Handy nicht drehen, die App muss in dieser Ausrichtung funktionieren.

Wie man testet

Apples Testleitfaden empfiehlt, mit einer Liste der Hauptaufgaben zu beginnen. Schreiben Sie zuerst die Hauptaufgaben jedes Screens auf, etwa anmelden oder eine Rechnung bezahlen. Probieren Sie diese Aufgaben dann mit jeder Einstellung und jeder assistiven Technologie einzeln aus.

1. Nutzen Sie ein echtes Gerät. Apple schreibt, dass VoiceOver im Simulator nicht funktioniert. Installieren Sie die App auf dem Handy.
2. Schalten Sie den Bildschirmvorhang ein. Dreimal mit drei Fingern tippen verdunkelt bei aktivem VoiceOver den Screen. So erleben Sie, wie es ist, sich nur auf den Ton zu verlassen.
3. Stellen Sie die Schrift auf das Größte. Schalten Sie die großen Größen für Barrierefreiheit ein und erledigen Sie jede Hauptaufgabe erneut. Suchen Sie abgeschnittenen Text und übereinanderliegende Elemente.
4. Schalten Sie „Bewegung reduzieren“ und „Kontrast erhöhen“ ein. Schauen Sie, ob die App wirklich auf diese Einstellungen reagiert.
5. Machen Sie dasselbe auf Android mit TalkBack. Prüfen Sie den Kontrast auch mit der App Accessibility Scanner.

Der Maßstab in Apples Liste ist einfach: Der Nutzer muss jede Aufgabe in der App nur mit VoiceOver abschließen können. Die Methode für das Web beschreibe ich Schritt für Schritt im Ratgeber zur Barrierefreiheitsprüfung.

Apple erlaubt außerdem, auf der Produktseite im App Store Angaben zur Barrierefreiheit (Accessibility Nutrition Labels) zu machen. Dort geben Sie an, welche Funktionen die App auf jeder Plattform unterstützt, deshalb testen Sie vor der Angabe.

Meine Notiz

Der Fehler, den ich in mobilen Audits am häufigsten sehe, sind Icon-Tasten ohne Label. Pfeil zurück, Herz, Menü mit drei Punkten, Filtersymbol. In der Designdatei wirken alle verständlich, aber der Screenreader sagt „Taste“ und geht weiter.

Der zweite sind Kästen mit fester Höhe. Das Design wird bei 100 % Schriftgröße abgenommen, niemand schaut auf 200 %. Ich prüfe jeden Screen in mindestens zwei Größen und schreibe abgeschnittenen Text als Fehler auf.

Machen Sie die Korrektur nicht Screen für Screen, sondern in der Komponente. Verlangt eine Button-Komponente ein Label, wird jeder Screen korrigiert, der sie nutzt. Der günstigste Ort dafür ist das Designsystem.

Wenn Sie Ihre App mit diesem Blick prüfen lassen wollen: Der UX Audit enthält auch die Kernprüfungen der WCAG 2.2. Er ist kein Konformitätsnachweis für das BFSG, zeigt aber, wo Sie anfangen.