Allt synligt på en iOS-skärm har, eller kan ha, en tillgänglighetsbeskrivning. Apple levererar den beskrivningen via det informella protokollet UIAccessibility, implementerat av UIView och varje systemkontroll, och via UIAccessibilityElement, en lättviktsklass man allokerar för de delar av gränssnittet som ritas men inte i sig är vyer — tecken i ett egentritat diagram, glyfer inuti en Core Graphics-scen, regioner inuti ett CALayer. VoiceOver, Switch Control, Full Keyboard Access och Voice Control konsumerar alla samma protokoll; att lära sig det en gång ger dig fyra hjälpmedel.

Protokollet exponerar fyra primitiver som spelar roll för nästan varje skärm. Tillgänglighetsetiketten (label) är det korta, läsbara namnet på elementet — “Skicka”, “Profilfoto av Asha”, “Tillbaka”. Tillgänglighetstraits (traits) är en bitmask av rollliknande flaggor — .button, .header, .image, .selected, .adjustable, .staticText, .updatesFrequently — som talar om för VoiceOver hur det ska bete sig kring elementet och vilka gester som ska aktiveras. Tillgänglighetsvärdet (value) är en strängrepresentation av det aktuella tillståndet (“På”, “75%”, “Torsdag 22 maj”). Tillgänglighetstipset (hint) är den längre, valfria förklaringen (“Dubbeltryck för att öppna fotovyn”) som VoiceOver talar efter en fördröjning om användaren inte agerar på etiketten ensam.

De fyra primitiverna komponeras. En knapp läses som etikett + trait + värde: “Wi-Fi, knapp, På”. En reglage läses som etikett + trait + värde + tips: “Volym, justerbar, 60 procent, svep uppåt eller nedåt för att justera”. En egentritat diagramstapel läses som en kedja av UIAccessibilityElements, var och en med en etikett, ett värde och en ram inuti sin behållare. Kedjan är API-ytan — VoiceOver går igenom den linjärt när användaren sveper höger, och respekterar den ordning i vilken du publicerar elementen via behållarens accessibilityElements-array.

Android tar en annan väg. Där iOS hänger tillgänglighet på ett platt protokoll på varje vy, serialiserar Android hela tillgänglighetsträdet som ett diagram av AccessibilityNodeInfo-objekt, vart och ett en ögonblicksbild av en vy i det ögonblick en TalkBack-förfrågan anländer. Ramverket konstruerar ögonblicksbilderna lazily; en View publicerar sin nod genom att åsidosätta onInitializeAccessibilityNodeInfo() (eller, i Compose, genom att ange semantikmodifierare), och plattformen sy ihop förälder-barn-relationerna till ett träd som speglar vyhierarkin.

Primitiverna skiljer sig från iOS på tre meningsfulla sätt. För det första exponerar Android en roll via ett strängtypat className-fält — android.widget.Button, android.widget.CheckBox, android.widget.EditText. TalkBack läser klassnamnet och bestämmer hur det ska annonseras (“knapp”, “kryssruta”, “textruta”). Compose översätter sin Role.Button-, Role.Checkbox-, Role.RadioButton-semantik till samma fält. Rollen är mer detaljerad än en iOS-trait-bitmask, men också mer rigid — det finns ingen “helt anpassad” roll om du inte accepterar annonseringen som “vy”.

För det andra representerar Android interaktivitet som en uppsättning åtgärder kopplade till noden: ACTION_CLICK, ACTION_LONG_CLICK, ACTION_SCROLL_FORWARD, ACTION_SET_TEXT, ACTION_FOCUS, och en lång lista av anpassade åtgärder du kan registrera med AccessibilityNodeInfo.AccessibilityAction. TalkBack exponerar de anpassade åtgärderna via “åtgärder”-rotorn — användaren sveper uppåt med ett finger och hör varje anpassad åtgärd vid namn. iOS har samma koncept (UIAccessibilityCustomAction), men på Android är åtgärdslistan ytan; på iOS är gestvokabulären det.

För det tredje har Android importantForAccessibility, en per-vy-enum (auto, yes, no, noHideDescendants) som kontrollerar om noden visas i trädet alls. noHideDescendants är det enskilt kraftfullaste verktyget i Android-tillgänglighet och det som oftast glöms bort — det tar bort hela underträdet från TalkBacks genomgång, motsvarigheten till aria-hidden=“true” på webben. iOS har ingen exakt analog; det närmaste är att ställa accessibilityElements till en tom array på behållaren, vilket bara tar bort behållarens direkta barn, inte hela underträdet.

Varje plattformsoberoende mobilramverk måste ta de två API:erna ovan och presentera en enda, ramverksformad yta. Inget av dem lyckas helt. De tre metoderna dominerar marknaden 2026 — React Native, Flutter och Kotlin Multiplatform med Compose Multiplatform — var och en ett lite annorlunda kompromiss mellan läckage och abstraktion.

Mönstret över alla tre är detsamma: ett syntetiskt, ramverksformat semantikträd på ena sidan, två plattformsformade tillgänglighetsträd på den andra, och en översättare däremellan som hanterar enkla fall väl och komplexa fall med ett märkbart fidelitetsförlust. De enkla fallen — en knapp med en etikett, en bild med alternativtext, en rubrik — passerar utan förlust. De komplexa fallen — en anpassad gest med tvåfingersvep, ett diagram vars element bör vara en fokusbar grupp, en live region som måste utlösas på iOS utan en vyinbunden artighetsinställning — läcker det underliggande plattformens vokabulär upp i den plattformsoberoende koden, eller misslyckas helt enkelt med att översätta.

Både iOS och Android renderar webbinnehåll via en systemwebview — WKWebView på iOS, android.webkit.WebView (eller Chrome Custom Tabs) på Android. I varje fall är WebView en svart låda ur värdappens perspektiv: appen ser en enda vy, men skärmläsaren ser hela DOM-tillgänglighetsträdet inuti den. Bryggan mellan de två träden är det ställe där en förvånansvärt stor mängd mobiltillgänglighet tyst går fel.

Mekanismen är, vid första anblick, enkel. När en skärmläsares fokus går in i en WebView läser plattformen dokumentets tillgänglighetsträd direkt från webbläsarmotorn — WebKit på iOS, Blink på Android — och traverserar det som ett underträd till värdappens träd. Webbens roller, etiketter och ARIA-attribut översätts till plattformens vokabulär i realtid. Ett button-element utan explicit roll inuti WebView läses som en knapp på båda plattformarna; en aria-live=“polite”-region annonserar korrekt på båda; ett aria-label på en länk framträder som länkens tillgänglighetsetikett. Under mobilwebbens första tre år fungerade detta bara.

Klippan dyker upp på tre ställen. Först: anpassade gester definierade i värdappen — ett tvåfingersvep för att stänga, ett magiknapp-tryck för att spela upp och pausa — är osynliga för WebViewens innehåll; de utlöses på fel mål eller utlöses inte alls när fokus är inuti dokumentet. Andra: värdappens UIAccessibilityElements ritade ovanpå WebView (en flytande åtgärdsknapp, en anpassad verktygsfält) konkurrerar med WebViewens träd om traverseringsordning, och den resulterande läsordningen är icke-deterministisk mellan iOS-versioner. Tredje — och detta är det enskilt största felläget i mobilwebbtillgänglighet — WebView på iOS respekterar inte aria-live-artighetsnivåer på det sätt Safari gör i en flik: WKWebViews annonseringssystem tappar distinktionen mellan polite och assertive, så varje live-uppdatering behandlas som polite oavsett markup.

Vi kartlade 28 primitiver som VoiceOver och TalkBack faktiskt konsumerar i praktiken — unionen av iOS UIAccessibility-protokollytan, Android AccessibilityNodeInfo-ytan och de mest använda React Native- och Flutter-plattformsoberoende propsarna. Tabellen nedan fångar bara de omstridda raderna: de primitiver där mappningen är ofullständig, asymmetrisk eller överraskande. Rader där mappningen är ren (etikett, knapproll, bildroll, rubrik) har utelämnats för längdens skull.

Tre mönster hoppar ut ur tabellen. Först är asymmetrin kring live regions den enskilt största källan till plattformsoberoende divergens — Android har en per-vy-artighetsinställning, iOS har bara en global imperativ post, och varje ramverk ovan tvingas ljuga om skillnaden. Andra är rubriknivåer det enda stället Flutter genuint förbättrar på båda inbyggda plattformar; iOS- och Android-primitiverna vet bara “det här är en rubrik”, inte “det här är en H3 under en H2”. Tredje är primitiven “dölj från tillgänglighet” mer flexibel på Android än på iOS — noHideDescendants döljer ett helt underträd i ett steg, medan iOS kräver att du döljer varje behållares barn individuellt.

Det är frestande att tro — och ramverksdokumentationen uppmuntrar denna tro — att ett plattformsoberoende tillgänglighets-API är en enda, enhetlig abstraktion över två likvärdiga inbyggda API:er. Mappningstabellen i avsnitt 5 motbevisar enhetsuppfattningen. De två inbyggda API:erna designades oberoende av två olika team, kring två olika mentala modeller för hur skärmläsaren ska gå igenom ett dokument; skillnaderna är verkliga, de läcker genom varje ramverk, och läckaget syns i de delar av användarupplevelsen som spelar mest roll — live-uppdateringar, anpassade gester, dolda underträd, rubrikhierarkier.

Den goda nyheten, efter det stycket: grunderna mappas. En knapp med en etikett, en bild med alternativtext, en rubrik högst upp i ett avsnitt — de passerar genom varje ramverk och annonseras korrekt på båda plattformarna. Om du bara levererar dessa primitiver behöver du inte tänka på UIAccessibility eller AccessibilityNodeInfo; ramverkets standardvärden är ärliga. Problemen börjar när användargränssnittet börjar göra något intressant, vilket också är när tillgängligheten börjar spela störst roll.

Handboken i avsnitt 6 är den kortaste versionen av argumentet som ger flest användare med funktionsnedsättning en fungerande upplevelse: tänk i inbyggda primitiver först, testa på riktiga enheter på båda plattformarna, brygga ut ur WebViews när du menar det, gruppera lövnoder medvetet och använd de officiella inspektionsverktygen. Ramverket du valt hjälper med de första 80 procenten och håller sig undan för de sista 20 procenten. De sista 20 procenten är där skärmläsaranvändaren bor.