Jedes sichtbare Element auf einem iOS-Bildschirm hat oder kann eine Barrierefreiheitsrepräsentation besitzen. Apple stellt diese Repräsentation über das informelle Protokoll UIAccessibility bereit, das von UIView und jedem System-Control implementiert wird, sowie über UIAccessibilityElement — eine schlanke Klasse, die für Bereiche der Oberfläche allokiert wird, die gezeichnet, aber keine eigenständigen Views sind: Zeichen in einem selbst gezeichneten Diagramm, Glyphen in einer Core-Graphics-Szene, Bereiche innerhalb eines CALayer. VoiceOver, Switch Control, Full Keyboard Access und Voice Control konsumieren dasselbe Protokoll; wer es einmal versteht, beherrscht damit vier assistive Technologien.

Das Protokoll legt vier Primitive offen, die für fast jeden Bildschirm relevant sind. Das Barrierefreiheits-Label ist der kurze, menschenlesbare Name des Elements — „Senden“, „Profilfoto von Asha“, „Zurück“. Die Barrierefreiheits-Traits sind eine Bitmask aus rollenähnlichen Flags — .button, .header, .image, .selected, .adjustable, .staticText, .updatesFrequently — die VoiceOver mitteilen, wie es sich gegenüber dem Element verhalten und welche Gesten es aktivieren soll. Der Barrierefreiheits-Value ist eine String-Repräsentation des aktuellen Zustands („Ein“, „75 %“, „Donnerstag, 22. Mai“). Der Barrierefreiheits-Hint ist die längere, optionale Erläuterung („Doppeltippen, um den Foto-Viewer zu öffnen“), die VoiceOver nach einer Verzögerung vorliest, wenn der Nutzer nach dem Label allein nicht handelt.

Die vier Primitive ergänzen sich. Ein Schalter wird als Label + Trait + Value vorgelesen: „WLAN, Schalter-Taste, Ein“. Ein Schieberegler als Label + Trait + Value + Hint: „Lautstärke, einstellbar, 60 Prozent, nach oben oder unten wischen zum Anpassen“. Ein selbst gezeichneter Diagrammbalken wird als Kette von UIAccessibilityElements abgebildet, jedes mit einem Label, einem Value und einem Frame innerhalb seines Containers. Die Kette ist die API-Oberfläche — VoiceOver durchläuft sie linear, wenn der Nutzer nach rechts wischt, und respektiert die Reihenfolge, in der die Elemente über das accessibilityElements-Array des Containers publiziert werden.

Android geht einen anderen Weg. Während iOS Barrierefreiheit als flaches Protokoll an jedem View verankert, serialisiert Android den gesamten Barrierefreiheitsbaum als Graph von AccessibilityNodeInfo-Objekten, von denen jedes eine Momentaufnahme eines Views zum Zeitpunkt einer TalkBack-Abfrage darstellt. Das Framework konstruiert die Momentaufnahmen verzögert; ein View veröffentlicht seinen Knoten durch Überschreiben von onInitializeAccessibilityNodeInfo() (oder in Compose durch Setzen von Semantics-Modifiern), und die Plattform verbindet die Eltern-Kind-Beziehungen zu einem Baum, der die View-Hierarchie widerspiegelt.

Die Primitive unterscheiden sich von iOS in drei wesentlichen Punkten. Erstens legt Android eine Rolle über ein string-typisiertes className-Feld offen — android.widget.Button, android.widget.CheckBox, android.widget.EditText. TalkBack liest den Klassennamen und entscheidet, wie er ankündigt („Schaltfläche“, „Kontrollkästchen“, „Eingabefeld“). Compose übersetzt seine Role.Button-, Role.Checkbox- und Role.RadioButton-Semantik in dasselbe Feld. Die Rolle ist granularer als eine iOS-Trait-Bitmask, aber auch starrer — eine vollständig benutzerdefinierte Rolle gibt es nicht, es sei denn, man akzeptiert die Ankündigung als „View“.

Zweitens stellt Android Interaktivität als Menge von Actions dar, die dem Knoten beigefügt sind: ACTION_CLICK, ACTION_LONG_CLICK, ACTION_SCROLL_FORWARD, ACTION_SET_TEXT, ACTION_FOCUS sowie eine lange Liste benutzerdefinierter Actions, die mit AccessibilityNodeInfo.AccessibilityAction registriert werden können. TalkBack zeigt die benutzerdefinierten Actions über den „Actions“-Rotor an — der Nutzer wischt mit einem Finger nach oben und hört jede benutzerdefinierte Action namentlich. iOS kennt dasselbe Konzept (UIAccessibilityCustomAction), doch auf Android ist die Action-Liste die Oberfläche; auf iOS ist es das Gestenvokabular.

Drittens besitzt Android importantForAccessibility, ein View-weises Enum (auto, yes, no, noHideDescendants), das steuert, ob der Knoten überhaupt im Baum erscheint. noHideDescendants ist das mächtigste Werkzeug in der Android-Barrierefreiheit und das am häufigsten vergessene — es entfernt den gesamten Teilbaum aus der TalkBack-Traversierung, gleichbedeutend mit aria-hidden=“true” im Web. iOS hat kein exaktes Gegenstück; das Nächste ist, accessibilityElements am Container auf ein leeres Array zu setzen, was jedoch nur die direkten Kinder des Containers entfernt, nicht den gesamten Teilbaum.

Jedes plattformübergreifende mobile Framework muss die beiden oben beschriebenen APIs nehmen und eine einheitliche, framework-eigene Oberfläche daraus bauen. Keines gelingt das vollständig. Die drei dominierenden Ansätze im Jahr 2026 — React Native, Flutter und Kotlin Multiplatform mit Compose Multiplatform — sind jeweils ein etwas anderer Kompromiss zwischen Abstraktionsleckage und Abstraktion.

Das Muster ist bei allen dreien gleich: ein synthetischer, framework-geformter Semantikbaum auf der einen Seite, zwei plattformgeformte Barrierefreiheitsbäume auf der anderen, und ein Übersetzer dazwischen, der die einfachen Fälle gut und die komplexen mit spürbarem Qualitätsverlust behandelt. Einfache Fälle — ein Button mit einem Label, ein Bild mit Alternativtext, eine Überschrift — werden verlustfrei übersetzt. Komplexe Fälle — eine benutzerdefinierte Geste mit Zwei-Finger-Wischen, ein Diagramm, dessen Elemente eine fokussierbare Gruppe sein sollten, eine Live-Region, die auf iOS ohne eine View-gebundene Höflichkeitseinstellung feuern muss — lassen das Vokabular der darunterliegenden Plattform in den plattformübergreifenden Code durchsickern oder scheitern schlicht an der Übersetzung.

Sowohl iOS als auch Android rendern Webinhalte über einen System-WebView — WKWebView auf iOS, android.webkit.WebView (oder Chrome Custom Tabs) auf Android. In beiden Fällen ist der WebView aus Sicht der Host-App eine Black Box: Die App sieht einen einzelnen View, doch der Screenreader sieht den gesamten DOM-Barrierefreiheitsbaum innerhalb des WebViews. Die Brücke zwischen den beiden Bäumen ist der Ort, an dem überraschend viel mobile Web-Barrierefreiheit still schiefläuft.

Der Mechanismus ist, auf den ersten Blick, unkompliziert. Wenn der Fokus eines Screenreaders in einen WebView eintritt, liest die Plattform den Barrierefreiheitsbaum des Dokuments direkt aus der Browser-Engine — WebKit auf iOS, Blink auf Android — und traversiert ihn als Teilbaum des Host-App-Baums. Die Rollen, Labels und ARIA-Attribute des Webs werden in Echtzeit in das Vokabular der Plattform übersetzt. Ein button-Element ohne explizite Rolle im WebView wird auf beiden Plattformen als Schaltfläche vorgelesen; eine aria-live=“polite”-Region wird auf beiden korrekt angekündigt; ein aria-label auf einem Link erscheint als Barrierefreiheits-Label des Links. In den ersten drei Jahren mobiler Web-Nutzung funktionierte das einfach.

Die Klippe zeigt sich an drei Stellen. Erstens sind benutzerdefinierte Gesten, die in der Host-App definiert sind — ein Zwei-Finger-Wischen zum Schließen, ein Magic-Tap zum Starten und Pausieren — für den Inhalt des WebViews unsichtbar; sie feuern auf das falsche Ziel oder gar nicht, wenn der Fokus im Dokument liegt. Zweitens konkurrieren UIAccessibilityElements der Host-App, die über dem WebView gezeichnet werden (ein Floating-Action-Button, eine benutzerdefinierte Toolbar), mit dem Baum des WebViews um die Traversierungsreihenfolge, und die resultierende Lesereihenfolge ist über iOS-Versionen hinweg nicht deterministisch. Drittens — und das ist der bei weitem größte einzelne Fehlerfall in der mobilen Web-Barrierefreiheit — respektiert der WebView auf iOS die aria-live-Höflichkeitsstufen nicht so, wie Safari es in einem Tab tut: Die Ankündigungs-Pipeline von WKWebView verwirft die Unterscheidung zwischen polite und assertive, sodass jede Live-Aktualisierung unabhängig vom Markup als polite behandelt wird.

Erfasst wurden 28 Primitive, die VoiceOver und TalkBack in der Praxis tatsächlich auswerten — die Vereinigungsmenge der iOS-UIAccessibility-Protokolloberfläche, der Android-AccessibilityNodeInfo-Oberfläche und der meistgenutzten React-Native- und Flutter-Props. Die Tabelle zeigt nur die strittigen Zeilen: Primitive, bei denen die Abbildung unvollständig, asymmetrisch oder überraschend ist. Zeilen mit sauberer Abbildung (Label, Button-Rolle, Image-Rolle, Überschrift) wurden aus Platzgründen weggelassen.

Drei Muster stechen aus der Tabelle hervor. Erstens ist die Asymmetrie bei Live-Regionen die wichtigste Quelle plattformübergreifender Divergenz — Android hat eine View-gebundene Höflichkeitseinstellung, iOS nur einen globalen imperativen Post, und jedes oben genannte Framework ist gezwungen, den Unterschied zu verschleiern. Zweitens sind Überschriftsebenen der einzige Punkt, an dem Flutter beide nativen Plattformen tatsächlich übertrifft; die iOS- und Android-Primitive wissen nur, „dies ist eine Überschrift“, nicht „dies ist ein H3 unter einem H2“. Drittens ist das Primitiv zum Verbergen vor der Barrierefreiheit auf Android flexibler als auf iOS — noHideDescendants verbirgt einen gesamten Teilbaum in einem Schritt, während iOS verlangt, die Kinder jedes Containers einzeln zu verbergen.

Es ist verlockend zu glauben — und die Framework-Dokumentation fördert diesen Glauben —, dass eine plattformübergreifende Barrierefreiheits-API eine einheitliche Abstraktion über zwei gleichwertige native APIs darstellt. Die Vergleichstabelle in Abschnitt 5 widerlegt die Vereinheitlichung. Die beiden nativen APIs wurden unabhängig voneinander, von zwei verschiedenen Teams, auf der Grundlage zweier unterschiedlicher mentaler Modelle dafür entwickelt, wie der Screenreader ein Dokument traversieren soll; die Unterschiede sind real, sie dringen durch jedes Framework hindurch, und die Leckage zeigt sich in den Teilen der Nutzererfahrung, die am wichtigsten sind — Live-Aktualisierungen, benutzerdefinierte Gesten, verborgene Teilbäume, Überschriftshierarchien.

Die gute Nachricht nach diesem Absatz: Die Grundlagen funktionieren. Ein Button mit einem Label, ein Bild mit Alternativtext, eine Überschrift am Anfang eines Abschnitts — diese Primitive werden durch jedes Framework verlustfrei übertragen und auf beiden Plattformen korrekt angekündigt. Wer nur diese Primitive liefert, muss nicht über UIAccessibility oder AccessibilityNodeInfo nachdenken; die Framework-Standards sind ehrlich. Die Schwierigkeiten beginnen, wenn die Benutzeroberfläche etwas Interessantes tut — was zugleich der Moment ist, in dem Barrierefreiheit am meisten zählt.

Das Playbook in Abschnitt 6 ist die kürzeste Version des Arguments, die die meisten Menschen mit Behinderungen zu einer funktionierenden Erfahrung führt: zuerst in nativen Primitiven denken, auf echten Geräten auf beiden Plattformen testen, für assertive Meldungen aus WebViews heraus brücken, Blattknoten bewusst gruppieren und die offiziellen Inspectors verwenden. Das gewählte Framework hilft mit den ersten 80 Prozent und tritt für die letzten 20 Prozent beiseite. In diesen letzten 20 Prozent lebt der Screenreader-Nutzer.