Tillgängliga appar – VoiceOver och TalkBack
Av CodexierPublicerad 4 min läsning
Tillgänglighet i appar behandlas ofta som en sen punkt på checklistan, men det berör många verkliga användare: personer med nedsatt syn, motoriska funktionsnedsättningar, dyslexi eller bara en sprucken skärm i starkt solljus. Sedan juni 2025 omfattar den svenska tillgänglighetslagen också appar för e-handel och flera konsumenttjänster, så för många företag är det även ett lagkrav. Det goda är att de vanligaste felen är lätta att hitta och billiga att åtgärda om man testar tidigt. Så här gör du.
Skärmläsare: VoiceOver och TalkBack
En skärmläsare läser upp varje element när användaren sveper genom skärmen. Den är beroende av att appen talar om vad varje element är. De vanligaste felen är knappar som läses upp som knapp utan namn, ikoner utan etikett, bilder av text, en läsordning som hoppar runt och egna komponenter som skärmläsaren inte kan aktivera alls.
- Ge varje ikonknapp en tillgänglig etikett som säger vad den gör, som lägg i varukorgen, inte plus.
- Markera dekorativa bilder så att de hoppas över.
- Kontrollera att svepningarna går genom skärmen i logisk ordning.
- Meddela förändringar: när ett fel visas eller innehåll laddas måste skärmläsaranvändaren få veta det.
- Se till att dialogrutor håller kvar fokus och att fokus återgår dit användaren var när de stängs.
Dynamisk textstorlek
Många användare, inte bara äldre, förstorar systemets textstorlek. Appar med fasta teckenstorlekar ignorerar inställningen, och appar som respekterar den men har behållare med fast höjd får avklippta knappar och överlappande text. Använd plattformens textstilar, låt behållare växa, tillåt text att bryta över flera rader och testa i största inställningen. Skärmar som måste scrollas vid stor text är okej; skärmar som döljer innehåll är det inte.
Klickytor och gester
- Apple rekommenderar klickytor på minst 44 gånger 44 punkter, Google minst 48 gånger 48 dp. Små ikoner kan behålla sitt utseende men behöver en större tryckyta.
- Lämna avstånd mellan ytorna så att användaren inte träffar fel.
- Varje svep, långtryck eller gest med flera fingrar behöver ett synligt alternativ, som en knapp eller ett menyval.
- Undvik tidsgränser som stänger en skärm innan en långsammare användare är klar, eller låt användaren förlänga dem.
Kontrast och färg
Text behöver tillräcklig kontrast mot bakgrunden, vilket enligt WCAG nivå AA betyder minst 4,5 till 1 för normal text och 3 till 1 för stor text och gränssnittskomponenter. Kontrollera både ljust och mörkt läge, eftersom en palett som fungerar i det ena ofta brister i det andra. Använd aldrig enbart färg för att visa betydelse: ett felaktigt fält behöver en ikon eller text utöver rött, och en vald flik behöver mer än ett färgbyte.
Samma principer gäller på webben; vår guide om att designa för WCAG 2.2 går djupare, och tillgänglighetslagen för företagswebbplatser förklarar vilka lagen omfattar.
Testrutin inför varje release
| Kontroll | Tid | Hur |
|---|---|---|
| Huvudflödet med VoiceOver | 10 minuter | Genomför kärnuppgiften på en iPhone utan att titta |
| Huvudflödet med TalkBack | 10 minuter | Samma sak på en Android-enhet |
| Största textstorlek | 5 minuter | Öppna varje ändrad skärm |
| Kontrast i nya färger | 5 minuter | Kontrastverktyg på nya eller ändrade komponenter |
| Automatisk skanning | Några minuter | Xcodes Accessibility Inspector och Androids Accessibility Scanner |
Automatiska verktyg hittar saknade etiketter och små klickytor men inte om flödet är begripligt. Den manuella genomgången är den viktiga delen.
Billigast är att få tillgängligheten rätt i designfasen. En appprototyp och UX-design som bestämmer etiketter, textstilar, klickytor och kontrast från början sparar dyra åtgärder senare; priserna finns på prissidan. När du inte ska köpa av oss: är appen redan byggd och du bara behöver en snabb genomgång, börja med rutinen ovan själv. Hittar du mer än du hinner åtgärda, boka ett kostnadsfritt samtal.
Vanliga frågor
Gäller tillgänglighetslagen vår app?
Den gäller appar för e-handel och flera konsumenttjänster, som banktjänster och persontransporter, från företag som inte är mikroföretag. Kontrollera lagen och PTS vägledning för just er tjänst, eftersom omfattningen har detaljer.
Är plattformsoberoende appar sämre för tillgänglighet?
Inte i sig. React Native, Flutter och Capacitor stödjer alla skärmläsare, men egna komponenter behöver rätt etiketter och roller. Testrutinen är densamma.
Kan automatiska verktyg göra en app tillgänglig?
De hittar snabbt en användbar del av de tekniska felen, men inte om flödet fungerar för en skärmläsaranvändare. Kombinera alltid med ett manuellt test.
Ska vi ta med användare med funktionsnedsättning i testerna?
Ja, när det går. Redan ett eller två tester med vana skärmläsaranvändare visar problem som ingen checklista fångar. Funktionsrättsorganisationer kan ofta hjälpa till att hitta testpersoner.
Vill du att nästa app fungerar för alla?
Berätta om er app eller idé och vilka användarna är. På femton minuter pekar vi ut de största tillgänglighetsriskerna och hur de designas bort från början.
Boka ett kostnadsfritt 15-minuterssamtal