Elk zichtbaar element op een iOS-scherm heeft een toegankelijkheidsrepresentatie, of kan die hebben. Apple levert die representatie via het informele protocol UIAccessibility, geïmplementeerd door UIView en elk systeembesturingselement, en via UIAccessibilityElement, een lichtgewicht klasse die men toewijst voor de onderdelen van de interface die weliswaar getekend worden maar zelf geen views zijn — tekens in een op maat getekend diagram, glyfen in een Core Graphics-scène, regio’s in een CALayer. VoiceOver, Schakelaarbediening, Volledige toetsenbordtoegang en Stembesturing verwerken allemaal hetzelfde protocol; het eenmalig leren ervan levert vier hulptechnologieën op.

Het protocol stelt vier primitieven beschikbaar die voor vrijwel elk scherm van belang zijn. Het toegankelijkheidslabel is de korte, mensleesbare naam van het element — “Verzenden”, “Profielfoto van Asha”, “Terug”. De toegankelijkheidstraits zijn een bitmask van rolachtige vlaggen — .button, .header, .image, .selected, .adjustable, .staticText, .updatesFrequently — die VoiceOver vertellen hoe het zich rond het element moet gedragen en welke gebaren ingeschakeld moeten worden. De toegankelijkheidswaarde is een tekenreeksrepresentatie van de huidige toestand (“Aan”, “75%”, “donderdag 22 mei”). De toegankelijkheidshint is de langere, optionele toelichting (“Dubbeltik om de fotokijker te openen”) die VoiceOver na een vertraging uitspreekt als de gebruiker niet reageert op het label alleen.

De vier primitieven werken samen. Een schakelaar klinkt als label + trait + waarde: “Wi-Fi, schakelaarknop, Aan”. Een schuifregelaar klinkt als label + trait + waarde + hint: “Volume, instelbaar, 60 procent, veeg omhoog of omlaag om aan te passen”. Een op maat getekende diagrambalk klinkt als een reeks UIAccessibilityElements, elk met een label, een waarde en een frame in zijn container. De reeks is het API-oppervlak — VoiceOver doorloopt het lineair wanneer de gebruiker naar rechts veegt, en respecteert de volgorde waarin de elementen via de accessibilityElements-array van de container worden gepubliceerd.

Android volgt een andere route. Waar iOS toegankelijkheid koppelt aan een plat protocol op elke view, serialiseert Android de volledige toegankelijkheidsboom als een graaf van AccessibilityNodeInfo-objecten, elk een momentopname van een view op het moment dat een TalkBack-query binnenkomt. Het framework stelt de momentopnamen lui samen; een View publiceert zijn knooppunt door onInitializeAccessibilityNodeInfo() te overschrijven (of in Compose door semanticsmodifiers in te stellen), en het platform weeft de ouder-kindrelaties samen tot een boom die de viewhiërarchie weerspiegelt.

De primitieven verschillen op drie betekenisvolle manieren van iOS. Ten eerste stelt Android een rol beschikbaar via een tekenreeks-getypt className-veld — android.widget.Button, android.widget.CheckBox, android.widget.EditText. TalkBack leest de klassenaam en bepaalt hoe het de aankondiging doet (“knop”, “selectievakje”, “invoervak”). Compose vertaalt zijn Role.Button-, Role.Checkbox- en Role.RadioButton-semantiek naar hetzelfde veld. De rol is gedetailleerder dan een iOS trait-bitmask, maar ook rigider — er is geen “volledig aangepaste” rol, tenzij men de aankondiging als “view” accepteert.

Ten tweede stelt Android interactiviteit voor als een set acties gekoppeld aan het knooppunt: ACTION_CLICK, ACTION_LONG_CLICK, ACTION_SCROLL_FORWARD, ACTION_SET_TEXT, ACTION_FOCUS en een lange lijst aangepaste acties die men kan registreren met AccessibilityNodeInfo.AccessibilityAction. TalkBack maakt de aangepaste acties zichtbaar via de “acties”-rotor — de gebruiker veegt omhoog met één vinger en hoort elke aangepaste actie bij naam. iOS heeft hetzelfde concept (UIAccessibilityCustomAction), maar op Android is de actielijst het oppervlak; op iOS is het gebarenvocabulaire dat.

Ten derde heeft Android importantForAccessibility, een per-view-enum (auto, yes, no, noHideDescendants) die bepaalt of het knooppunt überhaupt in de boom verschijnt. noHideDescendants is het krachtigste instrument in Android-toegankelijkheid en het meest vergeten — het verwijdert de volledige deelboom uit TalkBacks doorloop, het equivalent van aria-hidden=“true” op het web. iOS heeft geen exacte tegenhanger; het dichtstbijzijnde is het instellen van accessibilityElements op een lege array op de container, waardoor alleen de directe kinderen van de container worden verwijderd, niet de hele deelboom.

Elk cross-platform mobiel framework moet de twee bovenstaande API’s nemen en één frameworkvormig oppervlak presenteren. Geen enkel slaagt daar volledig in. De drie benaderingen domineren de markt in 2026 — React Native, Flutter en Kotlin Multiplatform met Compose Multiplatform — elk een iets andere afruil tussen lekkage en abstractie.

Het patroon bij alle drie is hetzelfde: een synthetische, frameworkvormige semantische boom aan de ene kant, twee platform-vormige toegankelijkheidsbomen aan de andere kant, en een vertaler tussenin die de eenvoudige gevallen goed afhandelt en de complexe gevallen met merkbaar kwaliteitsverlies. De eenvoudige gevallen — een knop met een label, een afbeelding met alternatieve tekst, een koptekst — gaan verliesvrij door elk framework en worden correct aangekondigd op beide platforms. De complexe gevallen — een aangepast gebaar met twee-vinger-veegbewegingen, een diagram waarvan de elementen een focusseerbare groep moeten vormen, een live region die op iOS moet worden geactiveerd zonder een view-gebonden beleefdheidssetting — laten het vocabulaire van het onderliggende platform lekken in de cross-platform code, of slagen er simpelweg niet in te vertalen.

Zowel iOS als Android renderen webinhoud via een systeem-WebView — WKWebView op iOS, android.webkit.WebView (of Chrome Custom Tabs) op Android. In beide gevallen is de WebView een black box vanuit het perspectief van de host-app: de app ziet één view, maar de schermlezer ziet de volledige DOM-toegankelijkheidsboom erin. De bridge tussen de twee bomen is de plek waar verrassend veel mobiele toegankelijkheid stilletjes misgaat.

Het mechanisme is, op het oog, eenvoudig. Wanneer de focus van een schermlezer een WebView binnenkomt, leest het platform de toegankelijkheidsboom van het document rechtstreeks uit de browserengine — WebKit op iOS, Blink op Android — en doorloopt het als een deelboom van de boom van de host-app. De rollen, labels en ARIA-attributen van het web worden in real time vertaald naar het vocabulaire van het platform. Een button-element zonder expliciete rol in de WebView wordt op beide platforms als een knop voorgelezen; een aria-live=“polite”-regio wordt op beide correct aangekondigd; een aria-label op een koppeling verschijnt als het toegankelijkheidslabel van de koppeling. In de eerste drie jaar van mobiel-webgebruik werkte dit gewoon.

De klif verschijnt op drie plaatsen. Ten eerste zijn aangepaste gebaren die in de host-app zijn gedefinieerd — een twee-vinger-veeg om te sluiten, een magic-tap om te spelen en te pauzeren — onzichtbaar voor de inhoud van de WebView; ze worden geactiveerd op het verkeerde doel of helemaal niet wanneer de focus binnen het document is. Ten tweede concurreren de UIAccessibilityElements van de host-app die boven de WebView worden getekend (een zwevende actieknop, een aangepaste werkbalk) met de boom van de WebView om de doorloopvolgorde, en de resulterende leesvolgorde is niet-deterministisch over iOS-versies heen. Ten derde — en dit is de grootste enkelvoudige faalwijze in mobiele webtoegankelijkheid — respecteert de WebView op iOS de beleefdheidsniveaus van aria-live niet op de manier waarop Safari dat doet in een tabblad: de aankondigingsroodleiding van WKWebView laat het onderscheid tussen polite en assertive vallen, zodat elke live-update als polite wordt behandeld, ongeacht de opmaak.

Er zijn 28 primitieven in kaart gebracht die VoiceOver en TalkBack in de praktijk daadwerkelijk verwerken — de unie van het iOS UIAccessibility-protocoloppervlak, het Android AccessibilityNodeInfo-oppervlak en de meest gebruikte React Native- en Flutter-cross-platform-props. De onderstaande tabel bevat alleen de betwiste rijen: de primitieven waarbij de mapping onvolledig, asymmetrisch of verrassend is. Rijen waarbij de mapping correct is (label, knoprol, afbeeldingsrol, koptekst) zijn omwille van de lengte weggelaten.

Drie patronen springen uit de tabel. Ten eerste is de asymmetrie rond live regions de grootste bron van cross-platform divergentie — Android heeft een per-view beleefdheidssetting, iOS heeft alleen een globale imperatieve post, en elk bovenstaand framework is gedwongen het verschil te verbergen. Ten tweede zijn koptekstniveaus de ene plek waar Flutter daadwerkelijk verbetert op beide native platforms; de iOS- en Android-primitieven weten alleen “dit is een koptekst”, niet “dit is een H3 onder een H2”. Ten derde is de primitieve “verbergen voor toegankelijkheid” flexibeler op Android dan op iOS — noHideDescendants verbergt een hele deelboom in één beweging, terwijl iOS vereist dat men de kinderen van elke container afzonderlijk verbergt.

Het is verleidelijk te geloven — en de framework-documentatie moedigt dit geloof aan — dat een cross-platform toegankelijkheids-API één verenigde abstractie is over twee gelijkwaardige native API’s. De mappingtabel in sectie 5 weerlegt de unificatie. De twee native API’s zijn onafhankelijk ontworpen, door twee verschillende teams, rond twee verschillende mentale modellen van hoe de schermlezer een document moet doorlopen; de verschillen zijn reëel, ze lekken door elk framework, en de lekkage is zichtbaar in de onderdelen van de gebruikerservaring die het meest van belang zijn — live-updates, aangepaste gebaren, verborgen deelbomen, kopteksthiërarchieën.

Het goede nieuws, na die alinea: de basis mapped. Een knop met een label, een afbeelding met alternatieve tekst, een koptekst boven aan een sectie — die gaan verliesvrij door elk framework en worden correct aangekondigd op beide platforms. Als men alleen die primitieven levert, hoeft men niet na te denken over UIAccessibility of AccessibilityNodeInfo; de standaardinstellingen van het framework zijn eerlijk. De problemen beginnen wanneer de gebruikersinterface iets interessants gaat doen, wat ook precies het moment is dat toegankelijkheid het meest van belang is.

Het stappenplan in sectie 6 is de kortste versie van het argument dat de meeste gebruikers met een beperking tot een werkende ervaring brengt: denk eerst in native primitieven, test op echte apparaten op beide platforms, bridge uit WebViews wanneer dat bedoeld is, groepeer bladknooppunten bewust, en gebruik de officiële inspectors. Het gekozen framework helpt met de eerste 80 procent en maakt ruimte voor de laatste 20 procent. Die laatste 20 procent is waar de gebruiker van een schermlezer leeft.