Alt synligt på en iOS-skærm har — eller kan have — en tilgængelighed-repræsentation. Apple leverer den repræsentation via den uformelle protokol UIAccessibility, implementeret af UIView og alle systemkontroller, og via UIAccessibilityElement, en letvægtklasse, man allokerer til de dele af grænsefladen, der er tegnet men ikke i sig selv er views — tegn i et brugerdefineret diagram, glyffer i en Core Graphics-scene, regioner inde i et CALayer. VoiceOver, Switch Control, Full Keyboard Access og Voice Control forbruger alle den samme protokol; at lære den én gang giver adgang til fire hjælpeteknologier.

Protokollen eksponerer fire primitiver, der er vigtige for næsten alle skærme. Tilgængeligheds-labelet er elementets korte, menneskelig-læsbare navn — “Send”, “Profilbillede af Asha”, “Tilbage”. Tilgængeligheds-traits er en bitmask af rollelignende flag — .button, .header, .image, .selected, .adjustable, .staticText, .updatesFrequently — der fortæller VoiceOver, hvordan det skal opføre sig over for elementet, og hvilke gestikker det skal aktivere. Tilgængeligheds-value er en strengrepræsentation af den aktuelle tilstand (“On”, “75%”, “torsdag den 22. maj”). Tilgængeligheds-hintet er den længere, valgfrie forklaring (“Dobbelt-tryk for at åbne fotofremviseren”), som VoiceOver udtaler med forsinkelse, hvis brugeren ikke handler på labelet alene.

De fire primitiver sammensættes. En knap til/fra læses som label + trait + value: “Wi-Fi, afbryderknap, On”. En skyder læses som label + trait + value + hint: “Lydstyrke, justerbar, 60 procent, stryg op eller ned for at justere”. En brugerdefineret diagrambjælke læses som en kæde af UIAccessibilityElementer, hver med et label, en value og en ramme inde i sin container. Kæden er API-fladen — VoiceOver gennemløber den lineært, når brugeren stryger til højre, og respekterer den rækkefølge, hvori elementerne publiceres via containerens accessibilityElements-array.

Android tager en anden rute. Hvor iOS hænger tilgængelighed op på en flad protokol på hvert view, serialiserer Android hele tilgængelighed-træet som en graf af AccessibilityNodeInfo-objekter, hvert et snapshot af et view i det øjeblik, en TalkBack-forespørgsel ankommer. Frameworket konstruerer snapshotterne dovent; et View publicerer sin node ved at tilsidesætte onInitializeAccessibilityNodeInfo() (eller, i Compose, ved at sætte semantics-modifikatorer), og platformen syr forældre-barn-relationer til et træ, der spejler view-hierarkiet.

Primitiverne adskiller sig fra iOS på tre meningsfulde måder. For det første eksponerer Android en rolle via et strengtypet className-felt — android.widget.Button, android.widget.CheckBox, android.widget.EditText. TalkBack læser klassenavnet og beslutter, hvordan det skal annonceres (“knap”, “afkrydsningsfelt”, “redigeringsfelt”). Compose oversætter sine Role.Button-, Role.Checkbox-, Role.RadioButton-semantik til det samme felt. Rollen er mere granulær end en iOS trait-bitmask, men også mere rigid — der er ingen “fuldt brugerdefineret” rolle, medmindre man accepterer annonceringen som “view”.

For det andet repræsenterer Android interaktivitet som et sæt handlinger knyttet til noden: ACTION_CLICK, ACTION_LONG_CLICK, ACTION_SCROLL_FORWARD, ACTION_SET_TEXT, ACTION_FOCUS og en lang liste af brugerdefinerede handlinger, man kan registrere med AccessibilityNodeInfo.AccessibilityAction. TalkBack eksponerer de brugerdefinerede handlinger via “handlinger”-rotoren — brugeren stryger op med én finger og hører hver brugerdefineret handling ved navn. iOS har det samme koncept (UIAccessibilityCustomAction), men på Android er handlingslisten fladen; på iOS er gestik-vokabularet det.

For det tredje har Android importantForAccessibility, en per-view-enum (auto, yes, no, noHideDescendants), der styrer, om noden overhovedet optræder i træet. noHideDescendants er det mest kraftfulde enkeltværktøj i Android-tilgængelighed og det, der oftest glemmes — det fjerner hele undertræet fra TalkBacks gennemløb, svarende til aria-hidden=“true” på nettet. iOS har ingen nøjagtig pendant; det nærmeste er at sætte accessibilityElements til et tomt array på containeren, som kun fjerner containerens direkte børn, ikke hele undertræet.

Ethvert tværplatform mobilframework er nødt til at tage de to API’er ovenfor og præsentere en enkelt, framework-formet flade. Ingen af dem lykkes fuldstændigt. De tre tilgange dominerer markedet i 2026 — React Native, Flutter og Kotlin Multiplatform med Compose Multiplatform — hver en lidt anden handel mellem læk og abstraktion.

Mønsteret på tværs af alle tre er det samme: et syntetisk, framework-formet semantisk træ på den ene side, to platformformede tilgængelighed-træer på den anden, og en oversætter imellem, der håndterer de simple tilfælde godt og de komplekse med et mærkbart tab af trouvailles. De simple tilfælde — en knap med et label, et billede med alternativ tekst, en overskrift — round-tripper uden tab. De komplekse tilfælde — en brugerdefineret gestik med to-fingersstrygning, et diagram, hvis elementer bør være en fokuserbar gruppe, en live region, der skal aktiveres på iOS uden en view-bundet politeness-indstilling — lækker det underliggende platforms vokabular op i tværplatformkoden eller fejler simpelthen i oversættelsen.

Både iOS og Android gengiver webindhold via en system-WebView — WKWebView på iOS, android.webkit.WebView (eller Chrome Custom Tabs) på Android. I begge tilfælde er WebView en sort boks fra værtappens perspektiv: appen ser ét view, men skærmlæseren ser hele DOM-tilgængelighed-træet inde i det. Broen mellem de to træer er det sted, hvor en overraskende stor mængde mobiltilgængelighed går stille galt.

Mekanismen er, ved første øjekast, ligetil. Når en skærmlæsers fokus entrer en WebView, læser platformen dokumentets tilgængelighed-træ direkte fra browsermotoren — WebKit på iOS, Blink på Android — og gennemløber det som et undertræ af værtappens træ. Nettets roller, labels og ARIA-attributter oversættes til platformens vokabular i realtid. Et button-element uden eksplicit rolle inde i WebView læses som en knap på begge platforme; en aria-live=“polite”-region annoncerer korrekt på begge; en aria-label på et link fremkommer som linkens tilgængelighed-label. De første tre år af mobilt webliv fungerede dette bare.

Klippen dukker op tre steder. For det første er brugerdefinerede gestikker defineret i værtappen — en to-fingersstrygning for at afvise, et magic-tap for at afspille og sætte på pause — usynlige for WebViewens indhold; de aktiveres på det forkerte mål eller aktiveres slet ikke, når fokus er inde i dokumentet. For det andet konkurrerer værtappens UIAccessibilityElementer tegnet over WebView (en flydende handlingsknap, en brugerdefineret værktøjslinje) med WebViewens træ om gennemløbsrækkefølgen, og den resulterende læserækkefølge er ikke-deterministisk på tværs af iOS-versioner. For det tredje — og dette er den største enkeltfejlmode i mobil-webtilgængelighed — overholder WebView på iOS ikke aria-live politeness-niveauer på den måde, Safari gør på en fane: WKWebViews annonceringssystem dropper skelnen mellem polite og assertive, så alle live-opdateringer behandles som polite uanset markuppet.

Vi kortlagde 28 primitiver, som VoiceOver og TalkBack faktisk forbruger i praksis — fagforeningen af iOS UIAccessibility-protokolfladen, Android AccessibilityNodeInfo-fladen og de mest brugte React Native- og Flutter-tværplatformprops. Tabellen nedenfor fanger kun de omstridte rækker: de primitiver, hvor kortlægningen er ufuldstændig, asymmetrisk eller overraskende. Rækker, hvor kortlægningen er ren (label, knapperoll, billedrolle, overskrift), er udeladt af pladshensyn.

Tre mønstre springer frem af tabellen. For det første er asymmetrien omkring live regions den største enkeltårsag til tværplatform-divergens — Android har en per-view politeness-indstilling, iOS har kun en global imperativ post, og alle frameworks ovenfor er tvunget til at lyve om forskellen. For det andet er overskriftsniveauer det ene sted, Flutter faktisk forbedrer på begge native platforme; iOS- og Android-primitiverne ved kun “dette er en overskrift”, ikke “dette er en H3 under en H2”. For det tredje er “skjul fra tilgængelighed”-primitiven mere fleksibel på Android end på iOS — noHideDescendants skjuler et helt undertræ i ét træk, mens iOS kræver, at man skjuler hvert containers børn individuelt.

Det er fristende at tro — og framework-dokumentationen opmuntrer til denne tro — at et tværplatform tilgængeligheds-API er en enkelt, samlet abstraktion over to ækvivalente native API’er. Kortlægningstabellen i afsnit 5 modbeviser foreningen. De to native API’er er designet uafhængigt af to forskellige teams, omkring to forskellige mentale modeller for, hvordan skærmlæseren bør gennemgå et dokument; forskellene er reelle, de lækker igennem alle frameworks, og lækagen viser sig i de dele af brugeroplevelsen, der betyder mest — live-opdateringer, brugerdefinerede gestikker, skjulte undertræer, overskrifthierarkier.

De gode nyheder, efter det afsnit: grundlaget mapper. En knap med et label, et billede med alternativ tekst, en overskrift øverst i et afsnit — de round-tripper igennem alle frameworks og annonceres korrekt på begge platforme. Hvis man kun leverer disse primitiver, behøver man ikke tænke på UIAccessibility eller AccessibilityNodeInfo; frameworkets standardindstillinger er ærlige. Problemerne starter, når brugergrænsefladen begynder at gøre noget interessant, hvilket også er, når tilgængelighed begynder at betyde mest.

Spillebogen i afsnit 6 er den korteste version af argumentet, der får de fleste mennesker med handicap til en fungerende oplevelse: tænk i native primitiver først, test på rigtige enheder på begge platforme, bro ud af WebViews, når det er meningen, grupper bladnoder bevidst og brug de officielle inspektorer. Det framework, man valgte, hjælper med de første 80 procent og holder sig ude af vejen for de sidste 20 procent. De sidste 20 procent er der, hvor skærmlæserbrugeren lever.