App Barrierefreiheit: So testen Sie Ihre App mit VoiceOver und TalkBack

In diesem Leitfaden verzichten Talha Aslan und Team auf einen allgemeinen Überblick zur Barrierefreiheit. Wir konzentrieren uns auf eine Frage: Lässt sich Ihre App mit einem Screenreader wirklich bedienen? Deshalb endet jeder Abschnitt mit einer Checkliste, einer Entscheidungstabelle oder nummerierten Testschritten. Code zeigen wir bewusst nicht. So können Produktverantwortliche, Design und Qualitätssicherung mit derselben Liste arbeiten. Die Webseite des Themas behandeln wir gesondert im Beitrag barrierefreie Website nach WCAG und BFSG.

Wie liest ein Screenreader eine App vor?

Ein Screenreader ist ein Systemdienst, der jedes Element auf dem Bildschirm der Reihe nach vorliest. Auf iPhone und iPad heißt er also VoiceOver, auf Android TalkBack. Die Person wischt nach rechts oder links zum nächsten Element und tippt doppelt, um das ausgewählte Element zu aktivieren. Die Android Entwicklerdokumentation nennt diese beiden Wege lineare Navigation und Erkunden durch Berühren.

Für jedes Element spricht der Screenreader drei Dinge: den Namen (die Beschriftung), die Art (Schaltfläche, Schalter, Überschrift) und gegebenenfalls den Zustand (ausgewählt, aus). Daher muss Ihre App alle drei korrekt liefern. Ein Symbol, das optisch völlig klar wirkt, klingt ohne Beschriftung nur wie „Taste“. Dann muss die Person raten, was es tut, und die App Barrierefreiheit leidet sofort. Genau darum geht es beim Testen: Sie bedienen die App mit den Ohren, nicht mit den Augen.

Wie aktivieren Sie VoiceOver zum Testen?

VoiceOver aktivieren Sie in der App Einstellungen des iPhone im Bereich Bedienungshilfen. Die Gesten fühlen sich anfangs ungewohnt an, deshalb üben Sie zunächst ein paar Minuten. Diese Schritte erleichtern den Test:

1. Legen Sie den Kurzbefehl für Bedienungshilfen auf VoiceOver, damit Sie ihn per Dreifachklick auf die Seitentaste ein- und ausschalten.
2. Wischen Sie mit einem Finger nach rechts und hören Sie jedes Element der Reihe nach.
3. Tippen Sie doppelt, um das Element zu aktivieren, und achten Sie darauf, ob das Ergebnis angesagt wird.
4. Springen Sie mit der Rotorgeste zwischen Überschriften. Sind Überschriften nicht als solche markiert, funktioniert das nicht.
5. Schalten Sie den Bildschirmvorhang ein, damit Sie wirklich ohne Sicht testen.

Vor allem der letzte Schritt lehrt am meisten. Solange Sie den Bildschirm sehen, ergänzen Ihre Augen, was die Sprachausgabe auslässt. Sobald er dunkel ist, spüren Sie dieselbe Unsicherheit wie Ihre Nutzerinnen und Nutzer. Die Human Interface Guidelines von Apple zur Barrierefreiheit beschreiben die Gestaltungsseite dazu, etwa Beschriftungen, Schriftgröße und Farbe.

Wie aktivieren Sie TalkBack zum Testen?

Laut dem Android Leitfaden zum Testen der Barrierefreiheit öffnen Sie die Einstellungen des Geräts, gehen zu Bedienungshilfen, wählen TalkBack und schalten es ein. Beim ersten Start beginnt zunächst eine Einführung. Überspringen Sie sie nicht, denn ein Test ohne Kenntnis der Gesten führt in die Irre.

Außerdem beschreibt die Dokumentation zwei hilfreiche Einstellungen für Testende. In den Entwicklereinstellungen von TalkBack können Sie die Protokollstufe auf ausführlich stellen und die Sprachausgabe zusätzlich auf dem Bildschirm anzeigen lassen. Somit hören und lesen Sie, was TalkBack sagt. Das hilft vor allem bei Fehlerberichten. Statt „die Taste klingt falsch“ notieren Sie genau, was Sie gehört haben.

Stellen Sie beim TalkBack Durchlauf die Fragen, die die Dokumentation vorschlägt. Vermittelt die Sprachausgabe jedes Elements Inhalt oder Zweck? Sind die Ansagen knapp oder unnötig lang? Können Sie die Hauptabläufe bequem abschließen? Erreichen Sie jedes Element per Wischen? Liest TalkBack Hinweise und kurze Meldungen vor?

Wie schreiben Sie Screenreader Beschriftungen für App Barrierefreiheit?

Eine Beschriftung ist der Name, den der Screenreader für ein Element spricht. Eine gute Beschriftung ist also kurz, eindeutig und auf den Zweck ausgerichtet. Die Android Dokumentation nennt klare Regeln. Beschreiben Sie Zweck und Ergebnis der Aktion, nicht das Aussehen. Zudem gehört die Elementart nicht in die Beschriftung, denn das System sagt sie bereits an. Zum Beispiel heißt eine Sendetaste „Senden“ und nicht „Taste Senden“.

Außerdem muss jede Beschriftung eindeutig sein. Enthält eine Liste zehn Tasten „Löschen“, weiß niemand, welche Taste welchen Eintrag löscht. Ergänzen Sie deshalb den Namen des Eintrags, etwa „Adresse Hamburg löschen“. Rein dekorative Bilder blenden Sie zudem für den Screenreader aus. Sonst verlieren Personen Zeit mit Elementen ohne Bedeutung. Prüfen Sie Beschriftungen mit dieser Checkliste:

• Hat jede Symboltaste eine Beschriftung?
• Beschreiben die Beschriftungen die Aktion statt des Bildes?
• Wiederholen Beschriftungen Wörter wie „Taste“ oder „Symbol“?
• Sind wiederkehrende Tasten in Listen eindeutig?
• Sind dekorative Bilder für den Screenreader ausgeblendet?
• Passt die Beschriftung jedes Formularfelds zum sichtbaren Text darüber?

Warum sind Lesereihenfolge und Fokus so wichtig?

Ein Screenreader liest Elemente zunächst in einer festen Reihenfolge. Passt diese nicht zum sichtbaren Layout, kann sich niemand ein Bild vom Bildschirm machen. Liest eine Produktkarte zum Beispiel zuerst den Preis, dann den Namen und zuletzt das Bild, bleibt unklar, wozu der Preis gehört. Laut Android Dokumentation führt der Vorabbericht der Play Console solche Probleme unter dem Punkt Implementierung auf, als Navigationsreihenfolge, die nicht zur logischen Anordnung passt.

Ebenso wichtig ist deshalb die Fokussteuerung. Öffnet sich ein Dialog, sollte der Fokus hineinwandern. Schließt er sich, sollte der Fokus dorthin zurückkehren, wo die Person herkam. Zudem sollte der Screenreader eine erscheinende Fehlermeldung ansagen. Andernfalls erfährt die Person nie, warum sich das Formular nicht absenden lässt. Ein Beispielszenario: Jemand öffnet in einem Buchungsformular die Datumsauswahl, doch der Fokus bleibt auf dem Formular dahinter hängen. Die Person hört nie, dass sich die Auswahl geöffnet hat, und kann die Buchung nicht abschließen.

Konkret stellen Sie zum Testen drei Fragen. Folgt die Lesereihenfolge dem Bildschirm logisch von oben nach unten? Erhält neuer Inhalt beim Öffnen den Fokus? Gibt geschlossener Inhalt den Fokus an die richtige Stelle zurück?

Wie groß sollten Tippflächen sein?

Eine Tippfläche ist der Bereich einer Taste oder eines Links, den ein Finger treffen kann. Kleine Tippflächen erschweren nicht nur Menschen mit motorischen Einschränkungen die Bedienung, sondern allen, die unterwegs ihr Telefon nutzen. Der Android Leitfaden für barrierefreie Apps empfiehlt für jedes interaktive Element eine Tippfläche von mindestens 48dp x 48dp und ergänzt, dass größer noch besser ist. Die meisten Standardkomponenten erfüllen diese Größe bereits. Bei eigenen Elementen müssen Sie die Größe allerdings selbst festlegen.

Auch die Human Interface Guidelines von Apple verlangen Bedienelemente, die groß genug und mit genügend Abstand bequem antippbar sind; die aktuelle Größe prüfen Sie direkt in den Richtlinien. Ein kleines Symbol ist trotzdem kein Problem für die App Barrierefreiheit. Sie lassen das Symbol klein und vergrößern die Tippfläche darum herum. Setzen Sie außerdem zwei Ziele nicht zu dicht nebeneinander. Ein Fehltipp schadet besonders bei Aktionen wie Löschen oder Bezahlen. Für die Platzierung hilft unser Leitfaden zur Daumenzone im mobilen Design.

Wie testen Sie die dynamische Schriftgröße?

Zudem vergrößern viele Menschen die Schrift auf ihrem Telefon. Unter iOS heißt diese Funktion Dynamic Type, unter Android finden Sie sie in den Einstellungen für Schrift und Anzeigegröße. Nutzt Ihre App die Textstile des Systems, wächst die Schrift mit. Haben Sie feste Schriftgrößen gesetzt, ändert die Einstellung nichts, und die Person bleibt bei kleiner Schrift.

Gehen Sie beim Test so vor:

1. Stellen Sie die Schriftgröße des Geräts auf den größten Wert.
2. Öffnen Sie jeden Hauptbildschirm und prüfen Sie, ob die Schrift wächst.
3. Suchen Sie nach Text, der abgeschnitten ist, sich überlappt oder aus Tasten herausläuft.
4. Prüfen Sie, ob sich langer Text scrollen und vollständig lesen lässt.
5. Wiederholen Sie den Test im Querformat.

In der Praxis sehen wir am häufigsten abgeschnittenen Text in Tasten mit fester Höhe. Planen Sie deshalb schon im Design Tasten und Karten, die mit ihrem Text mitwachsen.

Welches Kontrastverhältnis brauchen Sie?

Kontrast ist der Unterschied in der wahrgenommenen Helligkeit zwischen Textfarbe und Hintergrund. Der Android Leitfaden nennt eine klare Schwelle. Text unter 18sp oder fetter Text unter 14sp sollte ein Kontrastverhältnis von mindestens 4.5:1 erreichen. Für allen anderen Text gilt mindestens 3:1. Diese Werte decken sich außerdem mit den WCAG Schwellen im Web.

Zudem zählt Kontrast auch bei bedeutungstragenden Symbolen und Rahmen von Formularfeldern, nicht nur bei Text. Vermitteln Sie außerdem nie Informationen allein über Farbe. Ein rot gefärbtes Feld sagt einer Person mit Farbsehschwäche zum Beispiel nichts. Kombinieren Sie die Farbe stattdessen mit einem Symbol und einer kurzen Fehlermeldung. Nutzen Sie diese Checkliste:

• Erreichen Fließtext und kleine Beschriftungen mindestens 4.5:1?
• Erreichen große Überschriften und großer Text mindestens 3:1?
• Bleiben deaktivierte Tasten lesbar?
• Tragen Fehler, Warnung und Erfolg ein Signal neben der Farbe?
• Gelten im dunklen Modus dieselben Verhältnisse?

Welche Werkzeuge helfen beim Testen der App Barrierefreiheit?

Der manuelle Test steht immer am Anfang, aber Werkzeuge finden, was Ihnen entgeht. Diese Entscheidungstabelle fasst zusammen, wofür sich welches Werkzeug eignet:

Laut Android Dokumentation gruppiert der Vorabbericht für einen in die Play Console hochgeladenen Build die Befunde zur Barrierefreiheit nach Tippflächengröße, niedrigem Kontrast, Inhaltsbeschriftung und Implementierung. Er wirkt also wie ein kostenloses zweites Augenpaar. Trotzdem ersetzt er den manuellen Test nicht.

Mit welchen Bildschirmen sollten Sie anfangen?

Ihre App hat zum Beispiel vielleicht Dutzende Bildschirme. Alle auf einmal zu testen, ermüdet das Team und lässt die Arbeit halb fertig liegen. Beginnen Sie daher mit den Abläufen, für die Menschen die App öffnen. In den meisten Apps sieht die Reihenfolge so aus:

1. Registrierung und Anmeldung, denn wer hier scheitert, erreicht nichts anderes.
2. Startbildschirm und Hauptnavigation.
3. Suche und Listen.
4. Detailseite für Produkt, Leistung oder Inhalt.
5. Warenkorb, Bezahlung oder Formularversand.
6. Einstellungen, Profil und Hilfe.

Wenn Sie die ersten vier Punkte innerhalb einer Woche testen, zeigen sich meist die meisten kritischen Probleme. Beheben Sie danach gemeinsame Probleme im Designsystem, verbessern sich die übrigen Bildschirme von selbst. Korrigieren Sie zum Beispiel die Lesereihenfolge einer Kartenkomponente einmal, gilt das für jede Liste mit dieser Karte.

Wie testen Sie einen Bildschirm Schritt für Schritt?

Wenn Sie auf jedem Bildschirm dieselbe Reihenfolge nutzen, wird der Test wiederholbar. Unser Team arbeitet deshalb so:

1. Screenreader einschalten und prüfen, ob der Bildschirmtitel als Erstes vorgelesen wird.
2. Nach rechts durch alle Elemente wischen. Elemente ohne Beschriftung, ohne Sinn oder mit Wiederholung notieren.
3. Die Hauptaufgabe nur per Sprachausgabe erledigen, etwa ein Formular ausfüllen und absenden.
4. Einen ungültigen Wert eingeben und prüfen, ob die Fehlermeldung angesagt wird.
5. Einen Dialog oder ein unteres Blatt öffnen und prüfen, ob der Fokus hineinwandert.
6. Die Schriftgröße auf den größten Wert stellen und den Bildschirm erneut prüfen.
7. Kontrast mit einem Werkzeug messen und Tippflächen prüfen.
8. Jedes Problem mit Bildschirm, Element, erwarteter und gehörter Ansage dokumentieren.

Machen Sie aus dieser Reihenfolge eine Testvorlage, prüfen Sie dieselben Bildschirme bei jeder Version in wenigen Minuten. Somit wird Barrierefreiheit vom einmaligen Projekt zum festen Teil jeder Veröffentlichung. Nutzen Sie außerdem jedes Mal dasselbe Gerät und dieselben Einstellungen, damit Unterschiede zwischen Versionen auffallen.

Was tun, wenn Ihr Team die Probleme nicht allein lösen kann?

Angenommen, Sie haben getestet und eine lange Mängelliste erhalten. An diesem Punkt sehen die meisten Teams dasselbe Muster. Ein Teil der Probleme stammt aus dem Designsystem, ein Teil aus eigenen Komponenten und ein Teil aus der Grundstruktur der App. Beschriftungen zu ergänzen, ist einfach, weil es lokale Arbeit ist. Ein Designsystem mit festen Höhen auf dynamische Schrift umzustellen oder die Fokussteuerung neu aufzubauen, ist dagegen Architekturarbeit.

Für die Priorisierung beheben Sie zuerst die Hauptabläufe: Anmeldung, Suche, Warenkorb, Bezahlung und Formularversand. Können Personen diese nicht abschließen, verlieren andere Verbesserungen ihren Wert. Übersteigt das die Kapazität Ihres Teams, verankert unsere App Entwicklung Barrierefreiheit vom Designsystem bis zur Testvorlage, sodass jeder neue Bildschirm mit denselben Regeln entsteht. Läuft Ihre App plattformübergreifend, erklärt unser Beitrag Was ist React Native, was beide Plattformen teilen und wo sie sich unterscheiden.

Wie wirken sich Gesten, Animationen und Zeitlimits aus?

Funktionieren manche Aktionen nur über komplexe Gesten, erreichen Menschen mit Screenreader oder Schaltersteuerung sie nicht. Lässt sich ein Eintrag zum Beispiel nur per Wischen nach links löschen, bieten Sie dieselbe Aktion zusätzlich über ein Menü oder eine benutzerdefinierte Aktion an. Die Android Dokumentation schlägt vor, beim Test der Schaltersteuerung zu fragen, ob jede Gestenfunktion auch als auswählbares Bedienelement oder benutzerdefinierte Aktion verfügbar ist.

Bei Animationen zeigen Sie Personen, die in den Systemeinstellungen Bewegungen reduzieren, keine großen Übergangseffekte. Außerdem verschwinden Meldungen, die sich selbst ausblenden, oft, bevor ein Screenreader sie vorliest. Halten Sie daher wichtige Meldungen sichtbar oder geben Sie ihnen genug Zeit. Bei zeitbegrenzten Aktionen wie einem Bestätigungscode erlauben Sie eine Verlängerung. Kurz gesagt braucht jede Interaktion einen Weg, der keine schnelle, präzise Fingerbewegung voraussetzt.

Wie machen Sie Formulare und Fehlermeldungen barrierefrei?

In Formularen häufen sich die meisten Probleme der mobilen Barrierefreiheit. Erstens braucht jedes Feld eine sichtbare, dauerhafte Beschriftung. Verlassen Sie sich nicht allein auf blassen Platzhaltertext im Feld. Er verschwindet, sobald jemand tippt, und Screenreader lesen ihn nicht immer zuverlässig vor.

Zweitens müssen dann Fehlermeldungen sichtbar und hörbar sein. Sendet jemand ein fehlerhaftes Formular ab, sollte der Fokus zum ersten fehlerhaften Feld springen, und der Screenreader sollte die Meldung ansagen. Die Meldung selbst nennt außerdem die Lösung. Statt „Ungültige Eingabe“ schreiben Sie etwa „Die Postleitzahl hat fünf Ziffern“. Drittens passt die Tastatur zum Feld. Ein E-Mail Feld öffnet die E-Mail Tastatur, ein Telefonfeld den Ziffernblock. Zudem senkt automatisches Ausfüllen den Tippaufwand für Menschen mit motorischen Einschränkungen deutlich.

Wie sagen Sie Offline und Statusmeldungen für den Screenreader an?

Jede sichtbare Statusänderung sollte auch für Screenreader hörbar sein. Bleiben Meldungen wie ein Fortschrittsindikator, ein Hinweis „gespeichert“ oder eine Warnung über eine getrennte Verbindung stumm, denken Personen womöglich, die App sei eingefroren. Die Android Dokumentation empfiehlt ausdrücklich, beim TalkBack Test zu prüfen, ob kurze Hinweise vorgelesen werden. Für kurze Statusmeldungen hilft unser Beitrag Toast Benachrichtigungen gestalten.

Das zählt vor allem in Apps mit wechselnder Verbindung. Statusanzeigen, die zeigen, ob ein Datensatz auf dem Gerät liegt oder den Server erreicht hat, muss auch der Screenreader vorlesen. Unser Schwesterbeitrag zum Offline Modus in Apps erklärt, wie Sie diese Anzeigen gestalten. Für die Barrierefreiheit gilt also eine einfache Regel: Jede wichtige Änderung, die man sieht, muss man auch hören.

Wie machen Sie Bilder, Diagramme und Videos barrierefrei?

Zunächst braucht jedes Bild mit Informationsgehalt eine Textalternative. Für ein Produktfoto reicht zum Beispiel eine kurze Beschreibung. Vermittelt aber ein Diagramm oder eine Tabelle als Bild Daten, brauchen Screenreader Nutzer dieselben Daten. Nennen Sie deshalb die Kernaussage als Text neben dem Diagramm oder bieten Sie die Daten als lesbare Liste an. Ein Satz wie „Der Umsatz stieg gegenüber dem Vormonat“ ist für sie oft wertvoller als das ganze Diagramm.

Bei Video und Audio sind außerdem Untertitel eine Grundvoraussetzung für gehörlose und schwerhörige Menschen. Außerdem übertönt ein automatisch startendes Video mit Ton den Screenreader und bringt die Person in eine schwierige Lage. Daher starten Personen Videos selbst, und die Wiedergabesteuerung ist beschriftet. Für Alternativtexte und Untertitel in sozialen Netzwerken beschreibt unser Beitrag Barrierefreiheit in Social Media ähnliche Prinzipien.

Unterscheidet sich der Test auf iOS und Android?

Die Prinzipien der App Barrierefreiheit sind auf beiden Plattformen gleich. Jedes Element braucht Namen, Art und Zustand, die Schrift muss skalieren, und der Kontrast muss reichen. Allerdings unterscheiden sich die Details. Die Gesten ähneln sich zwar, sind aber nicht identisch. Zum Beispiel funktionieren der Rotor von VoiceOver und die Lesesteuerung von TalkBack unterschiedlich. Deshalb muss die testende Person beide Screenreader getrennt lernen.

Zudem kann eine App aus einer gemeinsamen Codebasis auf beiden Plattformen unterschiedlich ansagen. Ein plattformübergreifendes Framework überträgt eine Beschriftung vielleicht auf einer Plattform korrekt und auf der anderen gar nicht. Folglich ist die Annahme „auf Android getestet, also passt iOS“ nicht sicher. Schließen Sie bei jeder Version die Hauptabläufe auf beiden Plattformen mindestens einmal per Sprachausgabe ab. Denken Sie außerdem daran, dass die Einstellungen zur Schriftgröße auf beiden Systemen andere Namen und Bereiche haben. Der Test mit dem größten Wert deckt auf beiden Seiten die meisten Fehler auf.

Wie dokumentieren Sie Befunde, damit sie behoben werden?

Ein guter Fehlerbericht lässt also die Entwicklung das Problem nachstellen und schnell beheben. Bei Barrierefreiheit hilft eine vage Notiz wie „Screenreader geht nicht“ nicht weiter. Füllen Sie stattdessen in jedem Ticket diese Felder aus: Plattform und Screenreader, Bildschirm, Element, erwartete Ansage, gehörte Ansage, Auswirkung und Lösungsvorschlag. Zum Beispiel: „Android, TalkBack, Warenkorb, Papierkorbsymbol. Erwartet ‚Artikel aus dem Warenkorb entfernen‘. Gehört ‚Taste‘. Artikel lässt sich nicht entfernen.“

Danach sortieren Sie die Befunde nach Auswirkung. Ein Fehler, der einen ganzen Ablauf blockiert, steht oben, kosmetische Probleme können warten. So setzen Sie begrenzte Entwicklungszeit dort ein, wo sie die meisten Menschen erreicht. Die Option von TalkBack, die Sprachausgabe auf dem Bildschirm anzuzeigen, erleichtert solche Berichte erheblich.

Betrifft das Barrierefreiheitsstärkungsgesetz auch Apps?

Der European Accessibility Act der EU legt Anforderungen an die Barrierefreiheit bestimmter Produkte und Dienstleistungen fest; in Deutschland setzt das Barrierefreiheitsstärkungsgesetz (BFSG) ihn um. Zu den erfassten Dienstleistungen gehören Verbraucherdienste wie der elektronische Geschäftsverkehr und Bankdienstleistungen, und die mobilen Apps, über die diese Dienste laufen, fallen ebenfalls darunter. Bieten Sie Verbraucherinnen und Verbrauchern also eine solche Leistung per App an, ist App Barrierefreiheit für Sie möglicherweise eine gesetzliche Pflicht und nicht nur gute Praxis.

Anwendungsbereich, Ausnahmen etwa für Kleinstunternehmen und Details der Marktüberwachung prüfen Sie bitte in den aktuellen offiziellen Quellen. Wie Sie den Anwendungsbereich für Ihre Website einschätzen, erklären wir im Beitrag zur BFSG Pflicht für Websites. Dieser Abschnitt ist keine Rechtsberatung; klären Sie Ihre konkrete Lage mit Ihrer Rechtsberatung.

Warum wird Barrierefreiheit teurer, wenn Sie sie später nachrüsten?

Teams, die App Barrierefreiheit nach dem Start nachrüsten, stoßen auf dieselbe Hürde. Die meisten Probleme sitzen nicht auf einem einzelnen Bildschirm, sondern im Designsystem selbst. Konkret wiederholen sich Tasten mit fester Höhe, die Farbpalette, eigene Komponenten und die Lesereihenfolge überall. Daher bedeutet die Korrektur eines Fehlers oft, Dutzende Bildschirme gleichzeitig zu ändern.

Anders gesagt ist dieser Rückstau eine Form technischer Schulden. Unser Schwesterbeitrag zu technischen Schulden in Softwareprojekten erklärt das Konzept und den Umgang damit. Bei Barrierefreiheit senken Sie diese Schulden auf einfache Weise. Schreiben Sie Regeln zu Kontrast, Schriftgröße und Tippflächen von Anfang an ins Designsystem und nehmen Sie keine neue Komponente ab, bevor jemand sie mit einem Screenreader getestet hat. Außerdem helfen diese Regeln allen, von Menschen im hellen Sonnenlicht bis zu Personen, die mit einer Hand tippen.

Wie sieht die abschließende Checkliste zur App Barrierefreiheit aus?

Wir haben den Leitfaden in eine Liste übersetzt, die Sie vor jeder Veröffentlichung abhaken können:

• Lassen sich die Hauptabläufe mit VoiceOver und TalkBack allein per Sprachausgabe abschließen?
• Hat jedes interaktive Element eine kurze, eindeutige und zweckbezogene Beschriftung?
• Passt die Lesereihenfolge zum Layout, und wandert der Fokus in neue Inhalte?
• Erfüllen die Tippflächen die Empfehlungen der Plattform?
• Wird bei größter Schrift Text abgeschnitten oder läuft über?
• Erfüllen die Kontraste die Schwellen, und hängt keine Information allein an Farbe?
• Haben Gesten wie Wischen einen alternativen Weg?
• Sagt der Screenreader Fehler und Statusmeldungen an?
• Haben Sie die Hinweise aus Vorabbericht und Scanner geprüft?

Mit dieser Liste vor jeder Version wird Barrierefreiheit somit zur Gewohnheit statt zur Kampagne. Möchten Sie Ihre App von Anfang an barrierefrei aufbauen oder eine bestehende App nach dieser Liste überarbeiten, erfahren Sie auf unserer Seite App entwickeln lassen, wie wir arbeiten.