Innehållsförteckning
Mobilappar som riktar sig till konsumenter måste uppfylla LPTT:s tillgänglighetskrav. Här får du en översikt över vad som gäller för både iOS och Android, gemensamma principer som fungerar på båda plattformarna, och vägledning för att komma igång med tillgänglighetsarbetet i din app.
Mobilappar och LPTT
LPTT omfattar flera typer av tjänster som ofta levereras via mobilappar, inklusive e-handel, bank- och betaltjänster, elektronisk kommunikation, persontransporttjänster, audiovisuella medietjänster och e-böcker. Om din organisation erbjuder någon av dessa tjänster till konsumenter via en mobilapp måste appen uppfylla tillgänglighetskraven i EN 301 549-standarden.
Standarden kräver att mobilappar följer WCAG 2.1 nivå AA samt ytterligare tekniska krav specifika för mobila plattformar. Det spelar ingen roll om din app är utvecklad för iOS, Android eller båda – kraven gäller lika oavsett plattform.
Vilka appar omfattas?
Native appar som laddas ner via App Store eller Google Play och installeras direkt på enheten omfattas av LPTT om de tillhandahåller konsumentinriktade tjänster inom lagens omfattning.
Webb-appar som körs i mobilwebbläsaren följer samma regler som webbplatser och måste vara WCAG 2.1 AA-kompatibla.
Hybrid-appar som kombinerar native och webbteknologi måste uppfylla krav för både native appar och webbinnehåll, beroende på vilka delar som används.
Progressive Web Apps (PWA) behandlas som webbinnehåll men måste även fungera väl med mobila hjälpmedel.
Gemensamma tillgänglighetsprinciper
Oavsett om du utvecklar för iOS, Android eller båda plattformarna finns grundläggande principer som gäller för alla tillgängliga mobilappar.
Skärmläsarstöd är avgörande
Både iOS och Android har inbyggda skärmläsare – VoiceOver på iOS och TalkBack på Android. Din app måste fungera fullt ut med dessa hjälpmedel. Det innebär att alla interaktiva element måste ha begripliga beskrivningar, att användare kan navigera logiskt genom innehållet, och att dynamiska förändringar i appen kommuniceras tydligt.
Skärmläsare tolkar appens struktur och förmedlar den genom tal eller punktskrift. Om din app saknar semantisk information eller har felaktigt märkta element blir den oanvändbar för många användare. Testa alltid din app med både VoiceOver och TalkBack för att säkerställa att den fungerar korrekt.
Touch targets måste vara tillräckligt stora
Apple rekommenderar minst 44×44 punkter för klickbara element på iOS, medan Google specificerar minst 48×48 dp (density-independent pixels) för Android. Dessa storlekar säkerställer att användare med motoriska begränsningar eller synnedsättningar kan träffa rätt element utan att av misstag aktivera fel funktion.
Om designen kräver mindre visuella element kan du utöka den klickbara ytan utan att ändra den visuella storleken. Mellanrum mellan klickbara element är också viktigt – det ska vara tillräckligt med avstånd för att användare inte råkar trycka på fel knapp.
Färgkontrast och visuell design
Texten i din app måste ha tillräcklig kontrast mot bakgrunden. WCAG 2.1 AA kräver minst 4,5:1 för normal text och 3:1 för stor text. Detta gäller både ljusa och mörka lägen om din app stödjer båda.
Färg får aldrig vara det enda sättet att förmedla information. Om du använder röd text för att visa fel måste det även finnas en ikon, symbol eller textbeskrivning som kommunicerar samma information till färgblinda användare.
Både iOS och Android erbjuder systemstöd för olika färgblindhetssimulationer som du kan aktivera för att testa hur din app ser ut för användare med olika synförhållanden.
Textförstoring och dynamisk text
Användare måste kunna förstora texten i din app utan att funktionalitet eller innehåll går förlorat. På iOS kallas denna funktion Dynamic Type, medan Android använder systemets textstorlek-inställningar.
Din app ska stödja textskalning upp till minst 200 procent. Layouten måste anpassa sig så att text inte klipps av, överlappar andra element eller blir oläsbar. Undvik hårdkodade textstorlekar och använd istället systemets skalningsfunktioner.
Tänk på att när text förstoras kan layouten behöva förändras radikalt. Knappar kan behöva staplas vertikalt istället för horisontellt, och vissa element kanske behöver döljas eller flyttas för att ge plats åt den större texten.
Gester och alternativ interaktion
Många mobilappar använder komplexa gester som svep med flera fingrar, knipgester eller långtryckningar. Alla funktioner som kräver sådana gester måste även gå att utföra med enklare interaktioner, som ett enkelt tryck eller standard UI-kontroller.
iOS erbjuder AssistiveTouch och Switch Control för användare som inte kan utföra standardgester. Android har liknande funktioner genom Accessibility Suite. Din app måste fungera med dessa hjälpmedel.
Tänk också på att vissa användare styr sina enheter med externa tangentbord eller switchar. Även om detta är mindre vanligt på mobil än på desktop måste grundläggande tangentbordsnavigation fungera.
iOS vs Android – Skillnader att känna till
Även om de grundläggande tillgänglighetsprinciperna är desamma mellan iOS och Android finns viktiga skillnader i hur plattformarna implementerar tillgänglighet.
Designfilosofier
iOS följer Human Interface Guidelines (HIG) från Apple, som betonar konsekvens, tydlighet och djup. iOS-appar förväntas använda systemets standardkomponenter och beteenden där det är möjligt, vilket automatiskt ger bra tillgänglighet om komponenterna används korrekt.
Android följer Material Design från Google, som fokuserar på responsivitet, naturliga rörelser och taktil återkoppling. Material Design-komponenter har inbyggt tillgänglighetsstöd, men implementationen kan variera mellan olika Android-versioner och enhetstillverkare.
Skärmläsare och navigation
VoiceOver på iOS har funnits längre och brukar anses vara mer moget och konsekvent. VoiceOver använder specifika gester och navigeringssätt som iOS-användare lär sig, och dessa fungerar på samma sätt i alla appar.
TalkBack på Android har utvecklats mycket de senaste åren och är nu mycket kapabelt, men kan uppföra sig olika på enheter från olika tillverkare eller med olika Android-versioner. TalkBack har också lite andra navigeringsgester än VoiceOver, vilket innebär att du behöver testa med båda för att säkerställa god användarupplevelse.
API:er och utvecklarverktyg
iOS använder UIAccessibility API (UIKit) eller Accessibility modifiers (SwiftUI) för att märka element och definiera deras beteende för hjälpmedel. Xcode innehåller Accessibility Inspector som hjälper utvecklare att testa och felsöka tillgänglighet under utveckling.
Android använder AccessibilityNodeInfo och View-klassens accessibility-attribut för att exponera information till TalkBack och andra hjälpmedel. Android Studio har Accessibility Scanner som kan identifiera många vanliga problem automatiskt.
Båda plattformarna erbjuder omfattande dokumentation och exempel, men du behöver lära dig de specifika API:erna för varje plattform om du utvecklar native appar.
Testverktyg
På iOS är Accessibility Inspector det primära utvecklarverktyget, tillsammans med manuell testning med VoiceOver, Voice Control och Switch Control.
På Android är Accessibility Scanner en app som kan installeras på enheten för att identifiera problem, medan Android Studio även har lint-varningar för tillgänglighet. TalkBack måste testas manuellt.
Båda plattformarna kräver en kombination av automatiserade verktyg och manuell testning för att säkerställa verklig tillgänglighet.
Cross-platform utveckling och tillgänglighet
Om du utvecklar för både iOS och Android samtidigt har du flera alternativ, var och en med sina egna tillgänglighetsöverväganden.
React Native
React Native är ett populärt ramverk som låter dig skriva kod en gång och distribuera till både iOS och Android. React Native har inbyggt stöd för tillgänglighet genom accessibility props som accessibilityLabel, accessibilityHint och accessibilityRole.
Tillgängligheten i React Native har förbättrats mycket, men du behöver fortfarande testa noga på båda plattformarna eftersom implementationen kan skilja sig. Vissa avancerade tillgänglighetsfunktioner kan kräva native moduler eller plattformsspecifik kod.
Flutter
Flutter från Google använder Dart och renderar sitt eget UI istället för att använda native komponenter. Flutter har ett accessibility layer som översätter widgets till tillgänglig information för både iOS och Android.
Eftersom Flutter inte använder native komponenter måste du vara extra noga med att testa tillgänglighet. Standardwidgets har oftast bra tillgänglighetsstöd, men custom widgets kräver explicit accessibility-implementation.
Xamarin och andra ramverk
Xamarin och liknande ramverk har varierande stöd för tillgänglighet. Generellt gäller att ju närmare native plattformen du är, desto bättre blir tillgängligheten automatiskt. Ramverk som abstraherar bort plattformsskillnader kräver mer manuellt arbete för att säkerställa god tillgänglighet.
Oavsett vilket cross-platform-ramverk du väljer är nyckeln att testa tidigt och ofta på båda faktiska enheter med VoiceOver och TalkBack.
Kom igång med tillgängliga mobilappar
Att bygga tillgängliga mobilappar behöver inte vara överväldigande om du följer en systematisk approach och integrerar tillgänglighet från start.
Börja med standardkomponenter
Både iOS och Android erbjuder standardkomponenter som har inbyggt tillgänglighetsstöd. UIButton på iOS och Button i Material Design på Android är redan tillgängliga om du använder dem korrekt. Börja med att använda dessa istället för att bygga custom komponenter från grunden.
När du väl behöver custom komponenter, studera hur standardkomponenterna implementerar tillgänglighet och följ samma mönster. Återanvänd beprövade lösningar istället för att uppfinna hjulet på nytt.
Integrera tillgänglighet i designprocessen
Tillgänglighet ska inte vara något du ”lägger till” i slutet av utvecklingen. Diskutera färgkontrast, touch target-storlekar och interaktionsmönster redan i designfasen. Skapa prototyper som kan testas med skärmläsare tidigt i processen.
Involvera hela teamet – designers, utvecklare och produktägare – i tillgänglighetsarbetet. Alla har ansvar för att appen blir tillgänglig.
Testa kontinuerligt med riktiga hjälpmedel
Automatiserade verktyg som Accessibility Inspector och Accessibility Scanner är användbara, men de hittar bara en del av problemen. Du måste testa manuellt med VoiceOver och TalkBack för att förstå hur appen faktiskt upplevs av användare som är beroende av dessa hjälpmedel.
Om möjligt, involvera användare med funktionsnedsättningar i testprocessen. Deras feedback är ovärderlig och avslöjar ofta problem som ingen automatiserad process kan hitta.
Dokumentera och utbilda
Skapa riktlinjer för tillgänglighet specifikt för ditt team och din app. Dokumentera beslut, lösningar på vanliga problem och best practices. Utbilda nya teammedlemmar i tillgänglighet så att kunskapen sprids och blir en naturlig del av utvecklingsprocessen.
Se Unicefs appkatalog för inspiration
Letar du efter mobilappar som är tillgängliga för att få inspiration för utveckling och design? Unicefs appkatalog innehåller appar för barn som är granskade av experter och personer med nedsättningar.
Nästa steg
Nu när du har fått en översikt över tillgängliga mobilappar kan du fördjupa dig i den plattform du arbetar med:
För iOS-utveckling: Lär dig om UIAccessibility API, VoiceOver-testning och iOS-specifika riktlinjer.
För Android-utveckling: Utforska Android Accessibility Suite, TalkBack och Material Design accessibility.