Focus Order — was es ist, Prinzipien und wie man es in mobilen Apps konfiguriert

Was ist Focus Order in der Barrierefreiheit

Focus Order ist die Reihenfolge, in der der Benutzer sich zwischen interaktiven Elementen mit alternativen Eingabemethoden bewegt: Tastatur (Tab), Switch Control (Schritt für Schritt), VoiceOver (Wischen nach rechts/links) oder TalkBack. Im Gegensatz zu einer Maus oder einem Touchscreen, bei dem der Benutzer ein Element direkt auswählt, ist die Fokusnavigation linear — jeder Schritt bewegt den Fokus zum nächsten Element.

Laut Apple HIG, 2024 verwendet VoiceOver die Reihenfolge der Elemente im Barrierefreiheitsbaum, der auf der visuellen Platzierung basiert: obere linke Ecke → untere rechte Ecke. Wenn der Bildschirm ein komplexes Layout (Spalten, Grid, ZStack) hat, kann der Baum von der visuellen Reihenfolge abweichen.

WCAG 2.4.3-Prinzip: „Wenn eine Webseite sequenziell durch Abschnitte navigiert werden kann und die Fokusreihenfolge die Bedeutung beeinflusst, dann muss der Fokus einer Reihenfolge folgen, die Bedeutung und Bedienbarkeit bewahrt“. Ausnahme: dynamische Inhalte, bei denen der Fokus zur Aufmerksamkeitslenkung springen kann (Warnungen, modale Fenster).

Warum Focus Order für die Barrierefreiheit kritisch ist

Ein Switch Control-Benutzer (Menschen mit motorischen Beeinträchtigungen) bewegt sich automatisch durch Elemente — Zyklus für Zyklus. Wenn die Reihenfolge gestört ist, benötigt der Benutzer dreimal so lange zum Ausfüllen des Formulars. Laut Deque University, 2024 reduziert eine korrekte Focus Order die Formularausfüllzeit für Benutzer assistiver Technologien um 60%.

Focus Order und modale Fenster

Besondere Aufmerksamkeit — modale Fenster. Nach dem Öffnen eines modalen Fensters muss der Fokus sofort auf das erste interaktive Element innerhalb des Modals verschoben werden (normalerweise ein „Schließen“- oder „Bestätigen“-Button). Nach dem Schließen — Rückkehr zu dem Element, das das Modal ausgelöst hat. Dies ist eine Anforderung von WCAG 2.4.3 und auch ein häufiger Fehler.

iOS: Verwaltung der Fokusreihenfolge

In iOS erstellt VoiceOver automatisch die Reihenfolge basierend auf der Geometrie: Elemente werden nach Y, dann nach X sortiert. Bei Bildschirmen mit komplexer Struktur kann diese Reihenfolge falsch sein — der Entwickler muss eingreifen.

Hauptwerkzeuge:

• shouldGroupAccessibilityElement — gruppiert Kindelemente in einem logischen Block
• accessibilityElements — Array, das die benutzerdefinierte Reihenfolge der Kindelemente definiert
• UIAccessibilityPostNotification(UIAccessibilityLayoutChangedNotification, element) — programmgesteuerte Fokusbewegung

Beispiel für die Festlegung einer benutzerdefinierten Reihenfolge für eine Produktkarte:

class ProductCardView: UIView {
    let titleLabel = UILabel()
    let priceLabel = UILabel()
    let buyButton = UIButton()

    override var accessibilityElements: [Any]? {
        get {
            return [titleLabel!, priceLabel!, buyButton!]
        }
        set {}
    }
}

Für programmgesteuerte Fokusbewegung nach einer Aktion:

UIAccessibility.post(
    notification: .layoutChanged,
    argument: newlyAddedItem
)

shouldGroupAccessibilityElement in der Praxis

Die Eigenschaft shouldGroupAccessibilityElement ist nützlich für Karten in Sammlungen. Wenn sie auf der Elternkarte auf true gesetzt wird, nimmt VoiceOver die gesamte Karte als ein Element wahr. Der Benutzer kann doppelt tippen, um die gesamte Karte zu aktivieren, oder den Rotor für die interne Navigation konfigurieren. Empfohlen für UICollectionViewCell und UITableViewCell.

Android: Fokusrichtungsattribute

In Android verwendet TalkBack ebenfalls die geometrische Reihenfolge, aber explizite nextFocus*-Attribute haben Vorrang. Diese Attribute werden in XML oder programmgesteuert gesetzt:

Beispiel für ein Registrierungsformular:

<EditText
    android:id="@+id/field_email"
    android:nextFocusDown="@+id/field_password" />

<EditText
    android:id="@+id/field_password"
    android:nextFocusDown="@+id/btn_submit" />

Für RecyclerView ist die Fokusreihenfolge dynamisch — vom Adapter bestimmt. Wenn Zellen eine komplexe Struktur haben, setzen Sie descendantFocusability = „beforeDescendants“ und definieren Sie die Reihenfolge im Listenelementknoten. Für Jetpack Compose wird die Fokusreihenfolge über Modifier.focusOrder() und FocusOrder festgelegt. Priorität: previous (Kind), next (nächstes), benutzerdefinierter Schlüssel.

TouchDelegate, Trefferbereich und Fokusbereich

Wenn ein Element für den Fokus zu klein ist (kleiner als 44pt), vergrößern Sie den Trefferbereich über TouchDelegate in iOS oder minWidth/minHeight in Android. Laut Google Material Design, 2024 beträgt der minimale Berührungsbereich 48×48dp. VoiceOver und TalkBack fokussieren auf die Begrenzungsbox des Elements. Elemente unter 30pt können für den Gestenfokus unzugänglich sein — der Benutzer kann sie physisch nicht antippen.

Häufige Verstöße gegen WCAG 2.4.3

Springender Fokus — wenn nach einer Aktion (z. B. Löschen eines Elements) der Fokus an den Anfang der Liste oder zur systemeigenen „Zurück“-Schaltfläche springt. Der VoiceOver-Benutzer verliert den Kontext. Lösung: Programmgesteuertes Verschieben des Fokus auf das Element, das dem gelöschten am nächsten liegt.

Unsichtbarer Fokus — ein Element erhält Fokus, aber es gibt keine visuelle Anzeige (Tastaturbenutzer sehen nicht, wo sie sind). In iOS überprüfen Sie UIAccessibility.isVoiceOverRunning für benutzerdefinierte Indikatoren. Laut Deque University, 2024 ist unsichtbarer Fokus die zweithäufigste Ursache für das Scheitern eines Barrierefreiheits-Audits.

Modale — der Fokus bleibt nach dem Öffnen eines Modals auf dem Hintergrundinhalt. In iOS erfasst die modale Ansicht automatisch den Fokus, wenn modalPresentationStyle = .pageSheet gesetzt ist. In Android verwenden Sie setFocusable(true) auf dem Dialogcontainer.

Fokusfalle

Das umgekehrte Problem: Der Fokus bleibt innerhalb eines Modals stecken und kann nicht entweichen (außer durch Schließen). Dies ist nur für modale Fenster akzeptabel — der Benutzer muss das Fenster bewusst schließen. Für normale Bildschirme ist eine Fokusfalle ein kritischer Fehler. Lösung: Stellen Sie sicher, dass das letzte Element des Modals (die „Schließen“-Schaltfläche) den Fokus zurückgibt.

Benutzerdefinierte Bildschirme und programmgesteuerter Fokus

Für benutzerdefinierte Bildschirme (Karten, Leinwände, Spiele) ist die automatische geometrische Reihenfolge nicht anwendbar. Der Entwickler muss den Barrierefreiheitsbaum manuell erstellen. In iOS wird zu diesem Zweck die Methode UIAccessibilityContainer überschrieben.

Beispiel für eine benutzerdefinierte Leinwand:

class CanvasView: UIView {
    var shapes: [ShapeView] = []

    override var accessibilityElements: [Any]? {
        get {
            // Formen nach Z-Index sortieren, nicht nach Geometrie
            return shapes.sorted { $0.zIndex < $1.zIndex }
        }
        set {}
    }
}

In Android überschreiben Sie für eine benutzerdefinierte View onInitializeAccessibilityNodeInfo:

override fun onInitializeAccessibilityNodeInfo(
    info: AccessibilityNodeInfo
) {
    super.onInitializeAccessibilityNodeInfo(info)
    info.addChild(firstElement)
    info.addChild(secondElement)
    info.isFocusable = true
}

Für dynamische Listen (Chat, Nachrichten-Feed) verschieben Sie nach dem Hinzufügen eines Elements den Fokus auf das erste neue Element. In iOS: UIAccessibility.post(notification: .layoutChanged, argument: newMessage). In Android: sendAccessibilityEvent(AccessibilityEvent.TYPE_VIEW_FOCUSED).

AccessibilityFrame und Fokusgeometrie

iOS bestimmt automatisch den Fokusbereich basierend auf dem Rahmen des Elements. Wenn ein Element eine Transformation (transform, rotation) aufweist, kann VoiceOver auf den falschen Bereich fokussieren. Setzen Sie explizit accessibilityFrame in Bildschirmkoordinaten: element.accessibilityFrame = UIAccessibility.convertToScreenCoordinates(element.bounds, in: element). Dies stellt sicher, dass VoiceOver den richtigen Bereich hervorhebt.

UIKit Dynamics und Barrierefreiheit

Für animierte Bildschirme (UIKit Dynamics, Lottie, SpriteKit) ist der programmgesteuerte Fokus besonders wichtig. VoiceOver kann keinen Barrierefreiheitsbaum für dynamisch bewegte Elemente erstellen. Setzen Sie isAccessibilityElement = false auf Animationscontainern und true nur auf interaktiven Elementen im Inneren.

Testen der Fokusreihenfolge

Manuelles Testen: Aktivieren Sie VoiceOver (iOS) oder TalkBack (Android), wischen Sie nach rechts durch die gesamte Sequenz. Der Fokus muss der visuellen Reihenfolge folgen — links nach rechts, oben nach unten. Jedes interaktive Element muss genau einmal den Fokus erhalten.

Automatisiertes Testen ist herausfordernd, aber möglich:

func testKeyboardFocusOrder() {
    let app = XCUIApplication()
    app.launch()
    app.textFields["Email"].tap()
    // Tab — nur mit Hardware-Tastatur
}

Für Android verwenden Sie das Accessibility Testing Framework:

@Test
fun testFocusOrder() {
    onView(withId(R.id.fieldEmail))
        .check(matches(isFocusable()))
    onView(withId(R.id.fieldEmail))
        .perform(focus())
    onView(withId(R.id.fieldPassword))
        .check(matches(isFocused()))
}

Die zuverlässigste Methode ist ein UI-Szenario-Test: Füllen Sie das Formular Schritt für Schritt aus (E-Mail → Passwort → Senden), und überprüfen Sie, dass jeder Schritt erfolgreich abgeschlossen wird. Wenn die Fokusreihenfolge gestört ist, schlägt das Szenario beim Versuch der Interaktion mit einem Element außerhalb des Fokus fehl.

Xcode Accessibility Inspector zum Debuggen

Das Accessibility Inspector-Werkzeug in Xcode zeigt den vollständigen Barrierefreiheitsbaum. Sie können die Elemente in der VoiceOver-Reihenfolge durchgehen und den genauen Fokuspfad sehen. Verwenden Sie die Registerkarte „Audit“ zur automatischen Erkennung von Focus-Order-Verstößen.