Barrierefreiheit in mobilen Anwendungen – Vollständiger Leitfaden in der Praxis

Über Barrierefreiheit zu sprechen ist einfach. Die Implementierung von Barrierefreiheit in einer realen Anwendung mit engen Fristen, technischen Schulden und komplexem Design ist eine andere Geschichte.

Dieser „in der Praxis“-Leitfaden richtet sich an mobile Entwickler (Android/iOS/Flutter/React Native) und Designer, die sich heute die Hände schmutzig machen müssen. Lassen Sie uns die Philosophie überspringen und direkt zum Implementierungs-Workflow übergehen.

Das „Survival Kit“ für mobile Barrierefreiheit

Bevor Sie Code schreiben, benötigen Sie die richtigen Tools zum Testen. Ohne sie tappen Sie im Dunkeln.

Accessibility Scanner: Google-App im Play Store verfügbar. Es erstellt einen Screenshot Ihres Bildschirms und schlägt Korrekturen vor (Text, Kontrast, Berührungsbereich erhöhen).
VoiceOver (iOS) / TalkBack (Android): Grundlegende Gesten lernen.
- Nach rechts wischen: Nächstes Element.
- Nach links wischen: Vorheriger Artikel.
- Doppeltippen: Aktivieren/Klicken.
Farbenblindheits-Simulator: Mit Apps wie „Sim Daltonism“ (Mac/iOS) können Sie auf dem Bildschirm Ihrer App so aussehen, als ob Sie an verschiedenen Arten von Farbenblindheit leiden würden.

Checkliste für die praktische Umsetzung

1. Fokusreihenfolge (Durchlaufreihenfolge)

Der Bildschirmleser liest den Bildschirm von oben nach unten und von links nach rechts (in westlichen Sprachen). Aber komplexe Layouts können dies durcheinander bringen.

Problem: Der Leser liest die Fußzeile vor dem Hauptinhalt.
Praktische Lösung:
- Android: Verwenden Sie android:accessibilityTraversalBefore und android:accessibilityTraversalAfter, um die logische Reihenfolge zu erzwingen, wenn das XML nicht visuell geordnet ist.
- iOS: Passen Sie das accessibilityElements-Array in Ihrem View Controller an.

2. Inhaltsgruppierung (Gruppierung)

Stellen Sie sich eine Produktkarte vor mit: [Foto von Sneakers] [Name: Nike Air] [Preis: 500 R$]. Wenn sich der Leser auf jeden Artikel einzeln konzentriert, muss der Benutzer dreimal „wischen“, um ein einzelnes Produkt zu verstehen. Das ist anstrengend.

Praktische Lösung: Gruppieren Sie den Container.
- Flutter: Wickeln Sie das Karten-Widget in ein Semantics(container: true, label: "Tênis Nike Air, preço 500 reais") ein und verbergen Sie die semantischen Kinder (excludeSemantics). Somit liegt der Fokus nur auf der gesamten Karte.

3. Dynamische Schriftarten (Dynamic Type)

Der Nutzer hat in den Handyeinstellungen die Schriftart erhöht, da er an Presbyopie (müdes Sehvermögen) leidet. Respektiert Ihre App dies oder macht sie alles kaputt?

Übung: Stellen Sie Schriftgrößen niemals in festen Pixeln (px) ein.
- Android: Verwenden Sie sp (maßstabsunabhängige Pixel).
- iOS: Dynamische Schriftarten verwenden (UIFont.preferredFont(forTextStyle: .body)).
- React Native: Vermeiden Sie die Einschränkung von numberOfLines={1} in wichtigen Texten. Lassen Sie den Text umbrechen, wenn die Schriftart zunimmt.

4. Farben und Kontrast (Dunkler Modus)

Bei der Zugänglichkeit geht es auch um Sehkomfort.

Übung: Testen Sie Ihre App im Dunkelmodus und Hellmodus. Hellgrauer Text, der auf weißem Hintergrund schön aussieht, verschwindet möglicherweise auf schwarzem Hintergrund, wenn Sie keine semantischen Systemfarben (z. B. SystemGray unter iOS) anstelle von fest codierten Hex-Farben verwenden.

5. Berühren Sie Ziele

Die Schaltfläche sieht groß aus, aber nur das 24-Pixel-Symbol in der Mitte ist anklickbar.

Übung: Verwenden Sie die Tools „Debug Paint“ oder „Layoutgrenzen anzeigen“ in den Android-Entwickleroptionen, um die tatsächliche Größe des anklickbaren Felds anzuzeigen. Wenn es weniger als 48 dp beträgt, erhöhen Sie die interne Polsterung der Komponente.

Zugänglicher Entwicklungsstrom (DoD)

Um sicherzustellen, dass Barrierefreiheit in der Praxis geschieht, nehmen Sie diese Elemente in Ihre „Definition of Done“ für jede Aufgabe auf:

Haben alle interaktiven Elemente Beschriftungen?
Habe ich durch die gesamte Funktion nur mit der Tastatur/dem Bildschirmlesegerät navigiert?
Besteht der Farbkontrast den WCAG AA-Test?
Wenn wir die Systemschriftart erhöhen, passt sich dann das Layout an (scrollen) oder schneidet es den Text ab?

Barrierefreiheit in WebViews (Vorsicht!)

Viele Apps sind hybrid und laden Webseiten in sich.

Die Gefahr: Die native Barrierefreiheit (TalkBack/VoiceOver) des Mobiltelefons kommuniziert nicht immer gut mit dem HTML des WebView, wenn es nicht gut gemacht ist.
Die Praxis: Bei Verwendung von WebViews MUSS die geladene Website zugänglich sein (semantisches HTML, ARIA-Labels). Die native App kann fehlerhaftes HTML nicht auf magische Weise „reparieren“.

Fazit

Bei der Zugänglichkeit geht es in der Praxis weniger um Heldentum als vielmehr um Gewohnheit. Es erzeugt den Muskelreflex, immer dann contentDescription hinzuzufügen, wenn man ImageView hinzufügt. Es ist üblich, vor dem Senden der Pull-Anfrage zwei Minuten lang mit aktiviertem TalkBack zu testen.

Kleine tägliche Aktionen schaffen ein robustes Produkt. Beginnen Sie noch heute, auf dem nächsten Bildschirm programmieren Sie.