Tillgänglighet i mobilappar: WCAG 2.2-krav för iOS och Android

Över 72% av vuxna med funktionsnedsättning äger en smartphone, och enligt en undersökning förlitar sig ungefär 86% av skärmläsaranvändare på en mobil enhet — en högre andel än de som använder stationär dator eller laptop. Ändå har samma organisationer som noggrant granskar sina webbplatser ofta mobilappar som aldrig har testats mot ett enda tillgänglighetskriterium. Den klyftan minskar snabbt, driven av förändrad reglering, ökande rättsprocesser och — viktigast av allt — W3C:s egen vägledning som uttryckligen mappar WCAG 2.2 till inbyggda iOS- och Android-applikationer.

Varför WCAG 2.2 gäller för din mobilapp

Det finns en seglivad myt om att WCAG är en standard enbart för webben. Det är den inte. W3C har inga separata riktlinjer för mobil tillgänglighet — i stället hanteras mobil tillgänglighet inom det befintliga WCAG-ramverket, och W3C:s Mobile Accessibility Task Force (MATF) har tagit fram särskild vägledning med titeln Guidance on Applying WCAG 2.2 to Mobile Applications (WCAG2Mobile) som mappar varje framgångskriterium på nivå A och AA till inbyggda mobilappar, mobila webbappar och hybrida appar.

Den praktiska innebörden är betydande. När du läser ett WCAG-framgångskriterium som hänvisar till en "web page" ersätter WCAG2Mobile-dokumentet det uttrycket med "screen" eller "view". När ett kriterium diskuterar en "user agent" avses det mobila operativsystemet. De fyra POUR-principerna — Perceivable, Operable, Understandable, Robust — översätts direkt till hur en användare interagerar med en SwiftUI-vy i iOS eller en Jetpack Compose-layout på Android.

Ur ett juridiskt perspektiv är trycket inte längre teoretiskt. Enligt Title II i ADA kräver uppdaterade DOJ-föreskrifter som släpptes i april 2024 uttryckligen att delstatliga och lokala myndigheter gör sina mobilapplikationer tillgängliga enligt WCAG 2.1 AA. Vårdgivare som tar emot Medicare eller Medicaid står inför liknande krav enligt HHS-regler som fastställdes i maj 2024. Och även om stämningar mot mobilappar i privat sektor fortfarande är mindre vanliga än mot webbplatser, har åtminstone en stämningsbenägen kärande specifikt riktat in sig på mobilapplikationer på grund av bristande likvärdig tillgång enligt ADA, och den trenden förväntas accelerera när tidslinjerna för efterlevnad av Title II infaller 2026.

European Accessibility Act (EAA), som trädde i kraft den 28 juni 2025 och bygger på EN 301 549 som presumtiv teknisk standard, kräver också överensstämmelse med WCAG 2.2 för digitala produkter och tjänster, inklusive mobilappar som säljs eller erbjuds på EU-marknader. För alla organisationer med en global användarbas är WCAG 2.2 på mobil inte en framtida ambition — det är en aktuell skyldighet.

Vad som ändrades i WCAG 2.2 och är viktigast för mobil

WCAG 2.2, publicerad som en W3C Recommendation i oktober 2023, lägger till nio nya framgångskriterier och tar bort det numera föråldrade 4.1.1 Parsing. Den är fullt bakåtkompatibel: överensstämmelse med 2.2 innebär överensstämmelse med 2.1 och 2.0. Flera av de nya kriterierna skrevs med mobila interaktionsmönster uttryckligen i åtanke, och även de som formulerats kring tangentbordsanvändning har direkta motsvarigheter i hjälpmedelsteknik för iOS och Android.

Det är värt att förstå bakgrunden här. Efter 2018 såg Mobile Accessibility Task Force till att mobila överväganden formade både WCAG 2.1 och 2.2. Kriterier som 1.3.4 Orientation (AA), 1.4.10 Reflow (AA), 2.5.1 Pointer Gestures (A), 2.5.4 Motion Actuation (A) och de nya 2.5.7 Dragging Movements (AA), 2.5.8 Target Size Minimum (AA) och 3.3.7 Redundant Entry (A) speglar alla specifika mobila användbarhetsmönster som identifierats genom tester i verkliga miljöer med användare med funktionsnedsättning på smartphones och surfplattor.

De nio nya framgångskriterierna som introduceras i WCAG 2.2 riktar in sig på specifika hinder som verkliga användare stöter på: inloggningsflöden som straffar alla med minnesproblem, gränssnitt som kräver stadiga händer för precisa tryck, hjälpfunktioner som är gömda på olika delar av varje skärm och fokusindikatorer som försvinner bakom klistriga navigationsfält. Varje kriterium täpper till ett konkret hål — och nästan alla har en direkt mobil tillämpning.

De nya WCAG 2.2-kriterierna och hur de gäller för iOS och Android

2.5.8 Target Size Minimum (nivå AA)

Detta är förmodligen det mest betydelsefulla nya kriteriet för mobilteam. Det kräver att interaktiva mål — knappar, länkar, formulärfält, kryssrutor, reglage — har en minsta storlek på 24 × 24 CSS-pixlar, eller att ett avstånd på 24 pixlar finns mellan intilliggande mål om själva målet är mindre. Motiveringen är enkel: användare med handtremor, Parkinsons sjukdom eller begränsad finmotorik kan i praktiken inte pålitligt träffa en ikonknapp på 16 pixlar, och även användare utan funktionsnedsättning gör avsevärt fler fel på små mål.

För inbyggd mobilutveckling är WCAG 2.2:s minimum 24 × 24 faktiskt ett golv, inte ett tak. Apples Human Interface Guidelines rekommenderar ett minsta tryckmål på 44 × 44 punkter på iOS och iPadOS. Googles Material Design rekommenderar 48 × 48 densitetsoberoende pixlar (dp) på Android. Om din app följer Apples eller Googles plattformsriktlinjer överträffar du redan WCAG 2.2:s minimum — men många appar gör inte det. De där pyttesmå stängknapparna på modala ark, de tunna kryssrutorna på inställningsskärmar och verktygsfältsikoner som bara mäter 20 × 20 dp är alla regelefterlevnadsproblem som väntar på att upptäckas i en granskning.

En praktisk notering: WCAG:s krav gäller den interaktiva träffytan, inte ikonens visuella storlek. En ikon på 16 punkter innesluten i 14 punkters padding på varje sida har ett effektivt tryckmål på 44 × 44 punkter. Det innebär att utvecklare kan uppfylla kriteriet utan att visuellt förstora elementen — men de måste medvetet ange den paddingen, inte lita på att systemet gör det automatiskt.

2.5.7 Dragging Movements (nivå AA)

Detta kriterium kräver att all funktionalitet som implementeras via en draggest — reglage, drag-och-släpp-omordning, pull-to-refresh, skrollning i karusell — också måste kunna utföras genom en åtgärd med en enda pekare som inte kräver dragning. På iOS och Android hanterar plattformarnas egna hjälpmedelstekniker vissa gester annorlunda, men själva appen måste exponera icke-dragbaserade alternativ för all anpassad dragbeteende den implementerar.

I praktiken innebär detta att en lista som ordnas om genom dragning måste erbjuda ett alternativ som en "upp/ner"-stegknapp. Ett anpassat intervallreglage som bara svarar på en draggest måste också svara på tryck på specifika punkter eller tillhandahålla knappar för ökning/minskning. Kriteriet gäller inte om det underliggande operativsystemet eller hjälpmedelstekniken automatiskt tillhandahåller alternativet, men utvecklare bör testa detta uttryckligen i stället för att anta att det alltid hanteras åt dem.

2.4.11 Focus Not Obscured — Minimum (nivå AA) och 2.4.12 (Enhanced, nivå AAA)

Dessa kriterier tar upp ett mönster som är extremt vanligt i både webb- och inbyggda mobilappar: att det fokuserade elementet delvis eller helt döljs av klistrig UI — en ihållande nedersta navigationsrad, en flytande åtgärdsknapp, en övre verktygsrad som överlappar skrollområdet. Minimivillkoret (nivå AA) kräver att när en komponent får fokus förblir åtminstone en del av den synlig. Den utökade versionen (nivå AAA) kräver att hela den fokuserade komponenten är synlig.

För inbyggd mobil tolkas "keyboard focus" brett för att inkludera fokusringen som används av Switch Control eller Switch Access, Full Keyboard Access (iOS 15+) och Voice Control/Access. En app där det fokuserade elementet glider under en nedersta navigationsrad under en Switch Control-genomgång bryter mot detta kriterium, även om inget fysiskt tangentbord är inblandat. Appens UI bör undvika att skymma fokuserade kontroller med överlägg skapade av utvecklaren, klistriga rader eller tillfälliga ytor.

2.4.13 Focus Appearance (nivå AA)

Detta kriterium fastställer minimikrav för fokusindikatorns visuella egenskaper: den måste ha en minsta yta motsvarande komponentens omkrets × 2 CSS-pixlar och en kontrastkvot på minst 3:1 mot angränsande färger. På inbyggda mobila plattformar styrs fokusringen för VoiceOver och TalkBack av operativsystemet, och utvecklare kan inte ändra hur den ser ut — vilket innebär att utvecklare i allmänhet får ett undantag för just detta kriterium. Appens styling får dock inte aktivt försämra fokusens synlighet genom att till exempel lägga ett genomskinligt skikt över fokuserade kontroller.

3.3.8 Accessible Authentication — Minimum (nivå A)

Detta kriterium innebär ett stort steg för kognitiv tillgänglighet. Det kräver att autentiseringsprocesser inte enbart bygger på ett kognitivt funktionstest — vilket betyder att användaren inte får tvingas memorera ett lösenord, lösa ett pussel eller skriva av en CAPTCHA — om inte appen tillhandahåller ett tillgängligt alternativ. På iOS innebär detta att stödja Apples Keychain och Sign in with Apple så att användare kan autentisera utan att memorera inloggningsuppgifter. På Android innebär det att stödja Googles Autofill-ramverk, biometrisk autentisering och att inte blockera användningen av lösenordshanterare från tredje part.

Mer konkret: om din app blockerar inklistring i lösenordsfält är den sannolikt inte förenlig med 3.3.8. Om ditt tvåfaktorsautentiseringsflöde kräver att användaren manuellt skriver in en engångskod från en avisering utan att tillhandahålla en kopiera-klistra in-mekanism, skapar det en onödig kognitiv belastning. Androids Messages-app tillhandahåller redan en "kopiera kod"-knapp i OTP-aviseringar just av denna anledning — vilket anpassar plattformsbeteendet till kriteriets avsikt.

Viktig insikt: Att stödja biometrisk autentisering (Face ID, Touch ID, Android Biometric API) är inte bara en UX-förbättring — det är en WCAG 2.2-efterlevnadsmekanism för användare med kognitiva funktionsnedsättningar som inte pålitligt kan komma ihåg lösenord.

3.3.7 Redundant Entry (nivå A)

Om ett flöde i flera skärmar i din app — kassa, onboarding, ett vårdintagsformulär — ber användaren att ange samma information mer än en gång, måste du antingen fylla i det tidigare angivna värdet automatiskt eller erbjuda ett sätt att välja det från tidigare inmatning. Detta kriterium är direkt tillämpligt på inbyggda mobilappar. Det klassiska misslyckandet är ett formulär för leveransadress som senare ber om en faktureringsadress utan alternativet "samma som leverans", vilket tvingar användare med motoriska eller kognitiva funktionsnedsättningar att skriva samma text flera gånger.

3.2.6 Consistent Help (nivå A)

Om din app tillhandahåller en hjälpmekanism — en supportchattknapp, en hjälpikon, en "kontakta oss"-länk — måste den finnas på en konsekvent plats på alla skärmar i appen. Användare med kognitiva funktionsnedsättningar är beroende av förutsägbar placering av navigations- och supportmekanismer. Att placera hjälpknappen i sidhuvudet på vissa skärmar och i flikfältet på andra, eller gömma den i en inställningsmeny i vissa flöden, bryter mot detta kriterium.

WCAG 2.1-kriterier som fortfarande är kritiska för mobil

De nya WCAG 2.2-kriterierna får mest uppmärksamhet, men flera WCAG 2.1-krav som infördes specifikt med mobil i åtanke misslyckas fortfarande rutinmässigt i inbyggda appar, och ansvariga för efterlevnad bör inte förbise dem under granskningar.

1.3.4 Orientation (AA) förbjuder att låsa en app till stående eller liggande orientering om inte den orienteringen är väsentlig för innehållets funktion. Många appar låser till stående läge under onboarding-flöden eller i inbyggda videospelare utan motivering. Detta drabbar oproportionerligt användare med rullstolsmonterade enheter som inte kan roteras. 1.4.10 Reflow (AA) kräver att innehåll kan presenteras utan horisontell skrollning när det visas i 320 CSS-pixlars bredd (motsvarande 400% zoom), vilket i mobiltermer innebär att stödja Dynamic Type och systemets textstorleksskalning utan att layouten går sönder eller innehåll kapas.

2.5.1 Pointer Gestures (A) kräver att all funktionalitet som använder gester med flera pekare eller banbaserade gester — en nyp-zoom, en svepning med två fingrar — också har ett alternativ med en enda pekare. 2.5.4 Motion Actuation (A) kräver att funktionalitet som utlöses genom att skaka eller tilta enheten också kan styras via standardkontroller i UI:t, och att användare kan inaktivera rörelsebaserade utlösare för att undvika oavsiktlig aktivering.

För visuell presentation kräver 1.4.3 Contrast Minimum (AA) en kvot på minst 4,5:1 för normal text och 3:1 för stor text. Många appar misslyckas fortfarande här eftersom platshållartext i inmatningsfält, etiketter på inaktiverade knappar och text på fotografiska bakgrunder hamnar under minimum. Utvecklare bör säkerställa att all text, alla kontroller och allt innehåll fungerar med Dynamic Type, Bold Text, mörkt läge och systemnivåns kontrastalternativ på både iOS och Android.

Plattformsspecifik implementeringsvägledning

iOS och SwiftUI / UIKit

Apple tillhandahåller omfattande inbyggt stöd för tillgänglighet via UIAccessibility-API:et och, i SwiftUI, via accessibility-modifierare. För VoiceOver-stöd måste varje interaktivt element ha en meningsfull accessibility label, hint och value. Anpassade kontroller som inte ärver från standardkomponenter i UIKit måste uttryckligen anta en lämplig accessibility trait — .isButton, .isHeader, .isLink — så att VoiceOver annonserar dem korrekt. Xcode Accessibility Inspector kan hjälpa till att identifiera saknade etiketter och felaktiga traits under utvecklingen.

För Dynamic Type skalar UIKits UIFont.preferredFont(forTextStyle:) och SwiftUIs systemtypsnitt .font(.body) automatiskt med användarens föredragna textstorlek. Hårdkodade typsnittsstorlekar i punkter som inte använder scaledValue(for:) kommer att misslyckas med 1.4.4 Resize Text. För målstorlekar kan du utöka den tryckbara ytan för en liten ikon med contentEdgeInsets i UIKit eller modifieraren .contentShape() i SwiftUI utan att ändra elementets visuella presentation.

// SwiftUI: utöka tryckytan utan att ändra visuell storlek
Image(systemName: 'xmark')
    .frame(width: 20, height: 20)
    .contentShape(Rectangle().size(CGSize(width: 44, height: 44)))
    .accessibilityLabel('Close')
    .accessibilityAddTraits(.isButton)

Android och Jetpack Compose / Views

Androids tillgänglighet exponeras via AccessibilityNodeInfo-API:et, som TalkBack och Switch Access använder. I Jetpack Compose låter Modifier.semantics-blocket dig ange content descriptions, roller, tillståndsbeskrivningar och slå samman underordnade semantiker. För vybaserade UI:n gör ViewCompat.setAccessibilityDelegate() det möjligt att programmässigt manipulera tillgänglighetsegenskaper på valfri vy.

För storlek på tryckmål rekommenderar Material Design-riktlinjerna minst 48 × 48 dp. Om en composable eller vy är visuellt mindre kan du använda Modifier.minimumInteractiveComponentSize() i Compose (introducerad i Material3) för att automatiskt upprätthålla ett minimum på 48 dp, eller kapsla in en liten vy i en TouchDelegate för att utöka dess träffyta i det äldre View-systemet. För textskalning bör du säkerställa att alla textstorlekar anges i sp (scale-independent pixels), inte dp, så att de respekterar användarens typsnittspreferenser som ställs in i Androids skärminställningar.

// Jetpack Compose: tillgänglig ikonknapp med minimistorlek
IconButton(
    onClick = { onClose() },
    modifier = Modifier
        .minimumInteractiveComponentSize() // upprätthåller minst 48dp
        .semantics { contentDescription = 'Close dialog' }
) {
    Icon(
        imageVector = Icons.Default.Close,
        contentDescription = null // beskrivs av föräldern
    )
}

Testa din app mot WCAG 2.2

Testning av mobil tillgänglighet kräver en kombination av automatiserade verktyg och manuell testning med verkliga hjälpmedelstekniker. Automatiserade verktyg — inklusive Deques axe DevTools Mobile, Googles Accessibility Scanner för Android och Apples Accessibility Inspector i Xcode — kan hitta saknade etiketter, otillräcklig kontrast och tryckmål som ligger under plattformarnas minimum. Men automatiserade verktyg fångar bara en bråkdel av verkliga tillgänglighetsproblem. Manuell testning med VoiceOver på iOS och TalkBack på Android är avgörande för att verifiera korrekt läsordning, meningsfulla etiketter och logisk fokus­hantering i komplexa flöden.

För WCAG 2.2-specifika kriterier är manuell testning särskilt viktig. För att testa 2.5.8 (Target Size) använder du ditt faktiska finger — inte en muspekare i iOS Simulator — för att försöka interagera med små kontroller. För att testa 3.3.8 (Accessible Authentication) verifierar du att ditt inloggningsflöde tillåter inklistring i lösenordsfält, stödjer lösenordshanterare (1Password, Bitwarden, systemets keychain) och stödjer biometrisk autentisering. För att testa 2.4.11 (Focus Not Obscured) navigerar du i din app enbart via Switch Control på iOS eller Switch Access på Android och bekräftar att inget fokuserat element försvinner bakom en navigationsrad, ett modalt överlägg eller en flytande knapp.

En heltäckande testplan för tillgänglighet bör inkludera testning på minst två fysiska enheter — en iPhone och en Android-enhet — med användarens standardtextstorlek och med maximal systemtextstorlek, med VoiceOver respektive TalkBack aktiverade. Testning enbart i simulator kommer att missa verkliga skillnader i rendering och beteende hos hjälpmedelsteknik.

Överväg att bygga in tillgänglighetskontroller i din CI/CD-pipeline. Både Espresso (Android) och XCUITest (iOS) stödjer skrivning av automatiserade UI-tester som verifierar tillgänglighetsegenskaper — content descriptions, traits och aktiverade tillstånd — så att regressioner fångas innan kod slås samman i stället för att upptäckas i en granskning i produktion.

Det juridiska och affärsmässiga skälet att agera nu

Utöver det moraliska imperativet om inkludering är det affärsmässiga argumentet för mobil tillgänglighet konkret. Företag som ligger i framkant när det gäller inkludering av personer med funktionsnedsättning genererar 1,6 gånger mer intäkter och 2,6 gånger mer nettoresultat än branschkollegor. Personer med funktionsnedsättning i USA har nästan en halv biljon dollar i disponibel inkomst. Och med tanke på att 69% av nätkonsumenter med funktionsnedsättning överger appar och webbplatser som de upplever som svåra att använda, är varje tillgänglighetshinder en konvertering som aldrig sker.

Den juridiska risken ökar. Stämningar mot företag med brister i digital tillgänglighet fortsätter att öka år för år. DOJ:s antagande av WCAG som teknisk standard för ADA-efterlevnad, tidsfrister för verkställighet av Title II 2026 och EAA:s ikraftträdande i juni 2025 skapar tillsammans ett krav på efterlevnad i flera jurisdiktioner som nu uttryckligen omfattar inbyggda mobilapplikationer. En tidigare WCAG 2.1-granskning visar inte automatiskt överensstämmelse med WCAG 2.2 — autentiseringsflöden, formulärfält, interaktiva komponenter och fokushantering måste alla omvärderas mot de nio nya framgångskriterierna.

Avgörande är att tillgänglighet i mobil inte är en funktion som kan eftermonteras billigt efter lansering. Att åtgärda WCAG-brister i en släppt app innebär uppdaterade tillgångar, ombyggda komponenter, reviderade layouter, omtestade flöden och potentiellt omarbetade autentiseringssystem. Team som bygger in WCAG 2.2-efterlevnad i sina designsystem och komponentbibliotek från början — genom att upprätthålla minimistorlekar för tryckmål, kontrasttokens, semantiska roller och autentiseringsmönster på komponentnivå — betalar en bråkdel av kostnaden jämfört med att åtgärda en otillgänglig app efter lansering.

Viktiga slutsatser

• WCAG 2.2 gäller för inbyggda iOS- och Android-appar. W3C:s WCAG2Mobile-vägledning mappar varje framgångskriterium på nivå A och AA till mobila skärmar och vyer, vilket innebär att din inbyggda app omfattas — inte bara din mobila webbplats.
• Storlek på tryckmål är det vanligaste nya felet i mobilgranskningar. WCAG 2.2:s minimum 24 × 24 är golvet; Apple rekommenderar 44 × 44 pt och Google rekommenderar 48 × 48 dp. Utöka träffytor med padding och plattformsinbyggda API:er, inte genom att visuellt förstora ikoner.
• Att blockera inklistring i lösenordsfält bryter sannolikt mot 3.3.8 Accessible Authentication. Stöd systemets keychains, lösenordshanterare, biometrik och automatisk ifyllning av engångskoder för att uppfylla kraven på kognitiv tillgänglighet i inloggningsflöden på båda plattformarna.
• Manuell testning med VoiceOver och TalkBack är icke förhandlingsbar. Automatiserade verktyg fångar bara en bråkdel av tillgänglighetsproblem. Testa på fysiska enheter med maximal textstorlek, med hjälpmedelsteknik aktiverad, i alla kritiska användarresor.
• Bygg in tillgänglighet i ditt designsystem nu, inte efter lansering. Att åtgärda otillgängliga appar efter lansering är betydligt dyrare än att upprätthålla tillgängliga komponentstandarder från dag ett. Med tidslinjer för verkställighet från DOJ, HHS och EAA som infaller 2025–2026 håller fönstret för billig efterlevnadsanpassning på att stängas.