Barrierefreie App-Navigation

Was App-Navigation für Hilfstechnologien bedeutet

Sehende Nutzer:innen überblicken einen App-Bildschirm in Sekunden und springen mit dem Blick dorthin, wo es weitergeht. Wer eine Hilfstechnologie nutzt, hat diesen Überblick nicht. Ein Screenreader wie VoiceOver(iOS) oder TalkBack(Android) führt linear durch die Oberfläche: Mit einem Wisch nach rechts springt der Fokus zum nächsten Element, mit einem Wisch nach links zum vorigen. Alternativ tasten Nutzer:innen den Bildschirm mit dem Finger ab und hören, was sie gerade berühren.

„App-Navigation" meint in diesem Artikel deshalb nicht nur Tab-Bars und Menüs, sondern die Reihenfolge und Struktur, in der eine Hilfstechnologie durch deine Oberfläche führt. Drei Dinge entscheiden über eine gute Bedienung: dass die Fokusreihenfolge der sichtbaren Logik folgt, dass Überschriften ein schnelles Springen erlauben, und dass der Fokus bei Wechseln (Tab-Wechsel, Dialog, neuer Bildschirm) an der richtigen Stelle landet.

Die Fokusreihenfolge folgt der Lese-Logik

Standardmäßig leiten beide Plattformen die Fokusreihenfolge aus der Anordnung ab: Android arbeitet die Elemente in der erwarteten Lesereihenfolge ab, also üblicherweise von links nach rechts und von oben nach unten; iOS folgt der View-Hierarchie und der visuellen Position. Solange Aufbau und Sichtbarkeit übereinstimmen, passt das. Probleme entstehen dort, wo das Layout optisch anders gruppiert ist, als der Code es anordnet, etwa bei zwei nebeneinanderliegenden Spalten oder frei positionierten Elementen.

Den Maßstab dafür liefert die WCAG 2.2, der internationale Standard für digitale Barrierefreiheit. Über das Begleitdokument WCAG2ICT und die europäische Norm EN 301 549 (Kapitel 11) gelten ihre Kriterien sinngemäß auch für Apps. Zwei davon betreffen die Reihenfolge direkt: Erfolgskriterium 1.3.2 (Bedeutungstragende Reihenfolge) verlangt, dass die richtige Lesereihenfolge programmatisch ermittelbar ist; 2.4.3 (Fokus-Reihenfolge) verlangt, dass eine sinnvolle, die Bedienbarkeit erhaltende Reihenfolge eingehalten wird. Beide sind Konformitätsstufe A, also die Basis.

iOS: Reihenfolge und Gruppen steuern

Unter iOS bestimmst du die Reihenfolge auf drei Wegen. Innerhalb eines Containers legt accessibilityElements die Reihenfolge explizit als Liste fest. Mit accessibilitySortPriority (in SwiftUI accessibilitySortPriority ) hebst du einzelne Elemente vor: Höhere Werte werden zuerst angesteuert, der Standard ist 0. Und shouldGroupAccessibilityChildren hält die Kinder eines Containers als zusammenhängende Gruppe beieinander, sodass der Fokus sie nicht mit anderen Elementen vermischt.

 // UIKit: Reihenfolge im Container explizit als Liste setzen 
container.accessibilityElements = [titelLabel, betragLabel, sendenButton] // UIKit: zusammengehoerige Kinder als Gruppe halten 
karteView.shouldGroupAccessibilityChildren = true // SwiftUI: Vorrang erhoehen, hoeher wird zuerst angesteuert (Standard 0) 
wichtigerHinweis
    .accessibilitySortPriority(1)

Eine Faustregel: Verlasse dich zuerst auf einen sauberen, logischen Aufbau der View-Hierarchie. Greife erst dann zu accessibilitySortPriority oder einer expliziten accessibilityElements -Liste, wenn die natürliche Reihenfolge nachweislich nicht passt. So bleibt die Reihenfolge auch bei späteren Layout-Änderungen stabil.

Android: Traversal-Reihenfolge steuern

Android nennt die Fokusreihenfolge Traversal-Reihenfolge. Im klassischen View-System verschiebst du einzelne Elemente mit den Attributen android:accessibilityTraversalBefore und android:accessibilityTraversalAfter , die jeweils auf die ID eines anderen Elements zeigen. In Jetpack Compose übernehmen das zwei Semantik-Eigenschaften: isTraversalGroup kennzeichnet eine zusammengehörige Gruppe, deren Kinder vollständig abgearbeitet werden, bevor es weitergeht; traversalIndex ordnet einzelne Elemente, wobei ein kleinerer Wert früher kommt.

 // XML (View-System): TalkBack-Reihenfolge explizit setzen 
<TextView
    android:id="@+id/preis"
    android:accessibilityTraversalAfter="@id/titel" /> // Compose: Gruppe zusammenhalten 
Row(Modifier.semantics { isTraversalGroup = true }) { // ... Kinder werden zusammenhaengend abgearbeitet 
} // Compose: einzelnes Element nach vorne ziehen (kleiner = frueher) 
Text("Hinweis", Modifier.semantics { traversalIndex = -1f })

isTraversalGroup ist das Mittel der Wahl, wenn Compose bei nebeneinanderliegenden Spalten oder frei platzierten Elementen die Reihenfolge falsch errät. Du setzt es auf das umschließende Element, etwa eine Row , Column oder Box , und steuerst innerhalb der Gruppe bei Bedarf mit traversalIndex nach.

Überschriften als Sprungmarken

Sich durch jede einzelne Zeile zu wischen, ist auf langen Bildschirmen zäh. Deshalb bieten beide Screenreader eine Sprungnavigation über Überschriften. Unter iOS stellt man im Rotor „Überschriften" ein und springt dann mit einem Wisch nach oben oder unten von Überschrift zu Überschrift. Unter Android übernehmen das die Lesesteuerungen von TalkBack, ebenfalls mit Überschriften als einer der wählbaren Stufen. Beides funktioniert nur, wenn deine App ihre Überschriften auch als solche auszeichnet.

In SwiftUI markierst du eine Überschrift mit .accessibilityAddTraits(.isHeader) , in Jetpack Compose mit Modifier.semantics { heading() } . Damit wird aus einer optisch fetten Textzeile eine echte Sprungmarke, die VoiceOver und TalkBack in ihrer Überschriften-Navigation anbieten.

Fokus bei Bildschirmwechseln führen

Der häufigste Navigationsfehler passiert nicht innerhalb eines Bildschirms, sondern beim Wechsel. Öffnet sich ein Dialog, wechselt ein Tab oder erscheint ein neuer Bildschirm, muss der Fokus mitgehen. Bleibt er an der alten Stelle, hören Screenreader-Nutzer:innen nicht, dass sich etwas verändert hat, und tippen ins Leere.

Unter iOS kündigst du einen größeren Wechsel mit UIAccessibility.post(notification: .screenChanged) an und übergibst gleich das Element, auf das der Fokus springen soll; für kleinere Änderungen innerhalb eines Bildschirms gibt es .layoutChanged . Unter Android setzt du den Fokus gezielt auf das neue, wichtige Element oder meldest eine Statusänderung über eine Live-Region, die TalkBack automatisch vorliest, ohne den Fokus zu verschieben.

 // iOS: nach Bildschirmwechsel Fokus setzen und ansagen 
UIAccessibility.post(notification: .screenChanged,
                     argument: ueberschriftLabel) // Android (Compose): Statusmeldung als Live-Region ansagen 
Text(status, Modifier.semantics {
    liveRegion = LiveRegionMode.Polite
})

Typische Fallstricke

Die immer gleichen Muster machen eine technisch saubere App für die Tastatur- und Screenreader-Navigation trotzdem unbrauchbar. Sie sind fast alle schnell behoben:

Zwei verbreitete Irrtümer

Wie die Screenreader, für die du das alles baust, sich tatsächlich bedienen lassen, zeigen die Artikel zu VoiceOver und TalkBack. Wie du einzelnen Elementen Bedeutung und Rolle gibst, steht unter Semantik in SwiftUI und Jetpack Compose. Die offiziellen Quellen von W3C, Apple und Google sind unten verlinkt.