Statusmeldungen in Apps: Änderungen ansagen, ohne den Fokus zu stehlen

Worin das Problem liegt

Stell dir vor, du füllst ein Formular aus und tippst auf „Absenden". Oben auf dem Bildschirm erscheint die Zeile „3 Fehler gefunden". Wer sehen kann, nimmt diese Meldung sofort wahr, auch ohne hinzuschauen, weil sie im Augenwinkel auftaucht. Eine Person, die mit VoiceOver oder TalkBack arbeitet, hört dagegen erst einmal: nichts. Ihr Lese-Fokus steht weiterhin auf dem Absenden-Knopf, und die neue Meldung weiter oben wurde nie vorgelesen.

Genau diese Lücke schließt 4.1.3. Eine Statusmeldung ist eine inhaltliche Änderung, die dem Bedienfokus nicht folgt. Sie soll trotzdem von Hilfstechnologien angesagt werden, und zwar so, dass sie die Arbeit nicht unnötig unterbricht. Der entscheidende Punkt: Du sollst keine neuen Meldungen erfinden. Wenn deine App aber eine Meldung zeigt, muss diese auch hörbar werden.

Was als Statusmeldung zählt

Nicht jede Änderung ist eine Statusmeldung. Die WCAG definiert den Begriff eng: Es geht um eine Änderung, die keinen Kontextwechsel auslöst (also keinen Fokus verschiebt, keine neue Seite öffnet) und die zu einem dieser vier Zwecke informiert:

Bewusst nicht erfasst sind Dinge, die ohnehin schon angesagt werden. Öffnet sich ein Dialog, der den Fokus übernimmt, ist das ein Kontextwechsel, den die Hilfstechnologie selbst meldet. Auch das Auf- und Zuklappen eines Menüs oder das Umschalten eines Tabs zählt nicht, weil dessen Zustand bereits über Rolle und Eigenschaften (Kriterium 4.1.2) bekannt ist. Und die eigentliche Trefferliste einer Suche ist keine Statusmeldung, wohl aber der kurze Hinweis „18 Treffer" darüber.

Was 4.1.3 verlangt

Der Kern ist: Eine Statusmeldung muss programmatisch bestimmbar sein, über eine Rolle oder Eigenschaft, sodass Hilfstechnologien sie ansagen können, ohne dass sie den Fokus bekommt. Im Web löst man das mit ARIA-Live-Regionen ( role="status" , role="alert" , aria-live ). In nativen Apps gibt es dafür eigene, gleichwertige Bordmittel. Das folgende Bild zeigt die Entsprechungen:

Für native Apps ist die rechtliche Brücke EN 301 549(Kapitel 11), die das WCAG-Kriterium auf Software überträgt, und das BFSG, das diese Norm in Deutschland verbindlich macht. 4.1.3 gilt damit auch für Apps, nicht nur für Websites.

Statusmeldungen unter iOS

Apples Bordmittel heißt Accessibility-Notification. Für eine einmalige Ansage, etwa nach einer erfolgreichen Aktion, postest du eine .announcement . VoiceOver liest den übergebenen Text vor, ohne den Fokus zu verschieben. In SwiftUI gibt es dafür seit iOS 17 eine eigene, deklarative Schnittstelle:

 // UIKit: Ansage an VoiceOver, ohne den Fokus zu bewegen 
UIAccessibility.post(notification: .announcement,
                     argument: "Formular gesendet" 
) // SwiftUI ab iOS 17: deklarativ posten 
AccessibilityNotification.Announcement( "Formular gesendet" 
).post() // Nach groesseren Layout-Aenderungen den neuen Stand melden 
UIAccessibility.post(notification: .layoutChanged, argument: nil)

Zeigt deine App dagegen einen Wert, der sich laufend ändert, etwa einen Zähler oder eine Statuszeile, dann ist es meist besser, dem Element ein passendes accessibilityValue zu geben und es bei Bedarf zu aktualisieren, statt ständig neue Ansagen zu posten. Für reine Lade-Anzeigen eignet sich zusätzlich das Trait updatesFrequently .

Statusmeldungen unter Android

Auf Android ist der empfohlene Weg die Live-Region. Du markierst das Element, dessen Text sich ändert, als Live-Region, und TalkBack sagt jede Änderung automatisch an. In Jetpack Compose geschieht das über die Semantics, im klassischen View-System über accessibilityLiveRegion :

 // Jetpack Compose: Statuszeile als hoefliche Live-Region 
Text(
    text = statusText,
    modifier = Modifier.semantics {
        liveRegion = LiveRegionMode. Polite 
}
) // Klassisches View-System 
statusView.accessibilityLiveRegion =
    View.ACCESSIBILITY_LIVE_REGION_POLITE

Höflich oder bestimmt: die richtige Dringlichkeit

Sowohl iOS als auch Android kennen zwei Dringlichkeitsstufen, analog zum Web. Die Wahl entscheidet, ob eine Ansage wartet oder sofort dazwischenfunkt:

Ein Mythos

Auf einen Blick

Wenn deine App dynamisch Rückmeldungen zeigt, geh diese Punkte durch:

Damit deckst du die häufigsten Lücken ab. Die genaue Definition mit allen Sonderfällen, etwa entfernter oder rein bildhafter Statusinhalt, steht im Begleitdokument des W3C.