Hoppa till huvud innehåll

Allt om LPTT

Allt om LPTT
Meny

Skapa tillgängliga appar för Android

Android erbjuder kraftfulla verktyg och ramverk för att skapa tillgängliga appar. Här får du en översikt över Googles tillgänglighetsfunktioner, Material Design riktlinjer, och praktisk vägledning för att bygga Android-appar som uppfyller LPTT:s krav.

Googles tillgänglighetsfunktioner

Google har byggt in omfattande tillgänglighetsfunktioner direkt i Android, från skärmläsare och röststyrning till anpassningsbara gester och visuella inställningar. Dessa funktioner är inte efterkonstruktioner utan fundamentala delar av operativsystemet som miljoner användare världen över förlitar sig på.

TalkBack – Skärmläsare för Android

TalkBack är Googles inbyggda skärmläsare som läser upp innehåll på skärmen och låter användare navigera genom gester och röstkommandon. TalkBack finns förinstallerat på de flesta Android-enheter och är djupt integrerat med systemet.

När TalkBack är aktiverat ändras interaktionsmönstret helt. Användare navigerar genom att svepa åt höger eller vänster mellan element, och dubbelklickar för att aktivera det fokuserade elementet. Din app måste vara byggd för att fungera med dessa gester och ge tydlig feedback genom TalkBack.

TalkBack läser upp contentDescription, labels och annan tillgänglighetsinformation du definierar för varje element. Om dessa saknas eller är felaktiga blir appen förvirrande eller helt oanvändbar. Till skillnad från iOS VoiceOver kan TalkBack uppföra sig lite olika på enheter från olika tillverkare eller med olika Android-versioner, vilket gör testning på flera enheter extra viktigt.

Voice Access – Röststyrd navigation

Voice Access låter användare styra sin Android-enhet helt med röstkommandon. Användare kan säga ”Klicka på Skicka”, ”Scrolla ner” eller ”Gå tillbaka” för att navigera utan att röra skärmen.

För att din app ska fungera väl med Voice Access behöver alla interaktiva element ha tydliga labels som användare kan uttala. Voice Access visar automatiskt nummer på element som saknar labels, men det är mycket bättre om användare kan säga ”Klicka på Spara” istället för att behöva komma ihåg ”Nummer fjorton”.

Voice Access är särskilt viktigt för användare med motoriska begränsningar som inte kan använda touchscreen effektivt. Det kräver ingen specialhårdvara – bara en mikrofon och fungerar på alla moderna Android-enheter.

Switch Access – Styrning med switchar

Switch Access gör det möjligt för användare att styra sin enhet med externa switchar – fysiska knappar som kan anslutas via USB eller Bluetooth. Systemet går igenom interaktiva element i sekvens och användaren aktiverar dem genom att trycka på sin switch.

Din app måste ha korrekt fokusordning och alla element måste vara tillgängliga via tangentbordsnavigation för att Switch Access ska fungera. Användare kan behöva lång tid för att navigera genom många element, så effektiv struktur och möjlighet att hoppa mellan sektioner blir extra viktig.

Font Size och Display Size

Android låter användare justera både textstorlek och hela UI-skalan. Font Size ändrar storleken på text medan Display Size påverkar alla UI-element inklusive knappar, ikoner och spacing.

Din app måste stödja textskalning genom att använda scalable units (sp för text) och anpassa layouter när text blir större. Vid maximala inställningar kan text bli tre-fyra gånger större än standard, vilket kräver att layouter är flexibla och innehåll kan bryta till flera rader eller omorganiseras.

Color Correction och Color Inversion

Android erbjuder flera färgjusteringar för användare med synnedsättningar. Color Correction simulerar olika typer av färgblindhet och justerar färger automatiskt. Color Inversion vänder på färgerna på skärmen, vilket kan hjälpa användare med ljuskänslighet.

Din app bör respektera dessa inställningar eller åtminstone fungera acceptabelt när de är aktiverade. Testa med olika Color Correction-lägen för att säkerställa att viktiga distinktioner förblir synliga.

Magnification – Förstoring

Magnification låter användare zooma in delar av skärmen med gestern. Detta är kritiskt för användare med nedsatt syn som behöver förstora innehåll för att läsa det.

All funktionalitet måste vara tillgänglig när användare har zoomat in. Knappar får inte hamna utanför synligt område, och användare måste kunna scrolla för att nå alla delar av appen när de är zoomade.

Material Design och tillgänglighet

Material Design är Googles designsystem för Android och innehåller omfattande riktlinjer för tillgänglighet. Att följa Material Design ger dig inte bara en professionell, modern app utan också en solid grund för tillgänglighet.

Designa med Material Components

Android erbjuder Material Components – färdiga UI-komponenter som Button, TextField, Card och många fler. Dessa komponenter har inbyggd tillgänglighetsfunktionalitet och följer Material Design principer automatiskt.

När du använder Material Components får du mycket tillgänglighet gratis. En MaterialButton har rätt fokushantering, touch target-storlek och TalkBack-beskrivningar out of the box. Problem uppstår oftast när utvecklare bygger custom komponenter utan att tänka på tillgänglighet.

Custom komponenter är ibland nödvändiga för unik funktionalitet eller varumärkesidentitet, men de kräver betydligt mer arbete för att bli lika tillgängliga som Material Components. Om du måste bygga något custom, studera hur Material Components implementerar tillgänglighet och följ samma mönster.

Touch Targets och spacing

Material Design rekommenderar minst 48×48 dp (density-independent pixels) för alla klickbara element. Detta är inte en rekommendation du kan ignorera – det är en fundamental tillgänglighetsprincip som påverkar miljoner användare.

48 dp motsvarar cirka 9mm fysiskt på de flesta enheter, vilket är tillräckligt stort för de flesta att träffa med fingret. För användare med motoriska begränsningar eller som använder appen enhänt är större targets ännu bättre. Material Design-komponenter uppfyller detta automatiskt, men custom views måste dimensioneras explicit.

Avstånd mellan klickbara element är också viktigt. Minst 8 dp mellan interaktiva element rekommenderas för att användare inte ska råka trycka på fel sak. I täta gränssnitt som listor eller formulär måste spacing balanseras mellan effektiv användning av skärmutrymme och tillräckligt mellanrum för träffsäkerhet.

Färg och kontrast i Material Design

Material Design har tydliga riktlinjer för färgkontrast. Text måste ha minst 4,5:1 kontrast mot bakgrund för normal text och 3:1 för stor text. Dessa krav matchar WCAG 2.1 AA som LPTT refererar till.

Material Theme Builder hjälper dig skapa färgpaletter som automatiskt uppfyller kontrastkrav i både ljust och mörkt tema. Verktyget genererar en hel färgpalett baserad på din varumärkesfärg och säkerställer att alla kombinationer är läsbara.

Dark Theme är inte bara en estetisk preferens – många användare med ljuskänslighet eller synnedsättningar är beroende av det. Din app måste stödja både ljust och mörkt tema, och övergången mellan dem ska vara sömlös utan att bryta funktionalitet eller läsbarhet.

Typografi och skalning

Material Design använder en typografisk skala med föredefinierade text styles som Headline, Body, Caption och flera andra. Dessa styles ska användas konsekvent och måste skala när användare ändrar Font Size i systeminställningar.

Definiera text styles i sp (scale-independent pixels) inte i dp eller px. Detta låter Android automatiskt skala text baserat på användarens preferenser. Layouter måste anpassa sig när text blir större – innehåll får inte klippas av eller bli oläsbart.

Material Design betonar läsbarhet genom generösa radavstånd och teckenavstånd. Dessa proportioner måste bibehållas även när text skalar upp, vilket Material Components hanterar automatiskt om du använder rätt text styles.

Elevation och visuell hierarki

Material Design använder elevation (skuggor och depth) för att skapa visuell hierarki. Detta hjälper alla användare förstå struktur och navigation, men måste kompletteras med andra signaler för användare som inte kan se depth.

Färg, storlek och placering måste också indikera hierarki, inte bara elevation. En viktig knapp ska vara större och ha en accent-färg, inte bara ha djupare skugga. Detta hjälper användare med synnedsättningar och de som använder skärmläsare som inte förmedlar visuell depth.

Android Accessibility API

Android Accessibility API låter dig göra appar tillgängliga för hjälpmedel som TalkBack och Switch Access. API:et är omfattande och täcker allt från basic contentDescriptions till komplex custom tillgänglighetslogik.

ContentDescription – Grundläggande beskrivningar

ContentDescription är den viktigaste egenskapen för tillgänglighet. Den beskriver vad ett element är eller gör för TalkBack-användare. Varje interaktiv view och varje view som förmedlar information måste ha en contentDescription.

// Kotlin
button.contentDescription = "Spara dokument"
imageView.contentDescription = "Produktbild: Blå t-shirt"

// XML
<Button
    android:contentDescription="Spara dokument"
    android:text="Spara" />
    
<ImageView
    android:contentDescription="Produktbild: Blå t-shirt"
    android:src="@drawable/product_image" />

Skriv contentDescriptions som korta, beskrivande fraser. Inkludera inte element-typen eftersom TalkBack redan meddelar ”Knapp” eller ”Bild”. För ikoner utan text, beskriv funktionen inte ikonen – ”Dela artikel” inte ”Dela-ikon”.

Dekorativa element som bakgrundsmönster eller dividers ska markeras med importantForAccessibility="no" så TalkBack hoppar över dem. Detta minskar brus och låter användare fokusera på viktigt innehåll.

Accessibility Actions – Tillgänglighetsåtgärder

Custom actions låter användare utföra flera operationer på ett element utan att navigera till separata knappar. Detta är särskilt användbart i listor där varje rad kan ha flera möjliga actions.

view.accessibilityDelegate = object : View.AccessibilityDelegate() {
    override fun onInitializeAccessibilityNodeInfo(
        host: View,
        info: AccessibilityNodeInfo
    ) {
        super.onInitializeAccessibilityNodeInfo(host, info)
        
        val replyAction = AccessibilityNodeInfo.AccessibilityAction(
            AccessibilityNodeInfo.AccessibilityAction.ACTION_CLICK.id,
            "Svara"
        )
        info.addAction(replyAction)
        
        val deleteAction = AccessibilityNodeInfo.AccessibilityAction(
            R.id.action_delete,
            "Radera"
        )
        info.addAction(deleteAction)
    }
    
    override fun performAccessibilityAction(
        host: View,
        action: Int,
        args: Bundle?
    ): Boolean {
        return when (action) {
            AccessibilityNodeInfo.AccessibilityAction.ACTION_CLICK.id -> {
                replyToMessage()
                true
            }
            R.id.action_delete -> {
                deleteMessage()
                true
            }
            else -> super.performAccessibilityAction(host, action, args)
        }
    }
}

TalkBack-användare får tillgång till custom actions genom TalkBack-menyn. Detta håller gränssnittet rent medan du ger kraftfull funktionalitet.

Live Regions för dynamiskt innehåll

När innehåll ändras dynamiskt måste TalkBack informeras så användare blir medvetna om förändringen. Live regions är sätt att markera innehåll som kan uppdateras och som ska meddelas till användaren.

<TextView
    android:id="@+id/status_message"
    android:accessibilityLiveRegion="polite"
    android:text="Laddar..." />

accessibilityLiveRegion kan ha tre värden:

  • none: Standard, ändringar meddelas inte
  • polite: Ändringar meddelas när TalkBack är ledig
  • assertive: Ändringar avbryter pågående tal (använd sparsamt)

Använd polite för de flesta uppdateringar som statusmeddelanden eller nya meddelanden. Använd assertive endast för kritiska varningar som användaren måste höra omedelbart.

Fokusordning och navigation

TalkBack navigerar genom element i ordning baserat på deras position och hierarki i view-trädet. Ibland matchar inte denna ordning den logiska läsordningen, särskilt i komplexa layouter.

// Definiera explicit fokusordning
view1.accessibilityTraversalBefore = view3.id
view3.accessibilityTraversalAfter = view1.id

// Eller gruppera relaterade views
parentView.accessibilityTraversalBefore = otherSection.id

Fokusordning ska följa logisk läsordning, inte nödvändigtvis visuell layout. Tänk på hur en skärmläsaranvändare vill konsumera informationen – titel först, sedan innehåll, sedan actions.

Rubriker och strukturell navigation

Att markera rubriker hjälper TalkBack-användare navigera snabbt genom innehåll. De kan hoppa mellan rubriker med gestern istället för att gå genom varje element.

textView.isAccessibilityHeading = true

// XML
<TextView
    android:accessibilityHeading="true"
    android:text="Avsnitt 1"
    android:textSize="24sp" />

Använd headings för sektionsrubriker, inte för varje textelement. En tydlig rubrikstruktur (H1 → H2 → H3) hjälper användare förstå innehållets hierarki och hitta snabbt till rätt sektion.

Jetpack Compose och tillgänglighet

Jetpack Compose är Androids moderna UI-toolkit med deklarativ syntax. Compose har inbyggt tillgänglighetsstöd men kräver att du använder rätt modifiers och semantics.

Semantics i Compose

Compose använder Semantics för att beskriva UI-element till hjälpmedel. Många composables har automatic semantics, men du behöver ofta anpassa eller lägga till mer information.

Button(
    onClick = { saveDocument() },
    modifier = Modifier.semantics {
        contentDescription = "Spara dokument till molnet"
    }
) {
    Icon(Icons.Default.Save, contentDescription = null)
    Text("Spara")
}

// För element som inte är buttons
Box(
    modifier = Modifier
        .clickable { onItemClick() }
        .semantics {
            contentDescription = "Produktkort: Blå t-shirt, 299 kr"
            role = Role.Button
        }
) {
    // Content
}

När en Button har både ikon och text behöver ikonen inte egen contentDescription eftersom texten räcker. Men om Button bara har ikon måste contentDescription sättas.

Slå samman semantics för gruppering

När flera element bör läsas som en enhet kan du slå samman deras semantics.

Row(
    modifier = Modifier.semantics(mergeDescendants = true) {}
) {
    Text("Temperatur:")
    Text("22°C", style = MaterialTheme.typography.headlineMedium)
}
// TalkBack läser: "Temperatur: 22°C"

MergeDescendants kombinerar alla barns semantics till en beskrivning, vilket gör navigationen snabbare och mer naturlig.

Custom tillgänglighetsåtgärder i Compose

Card(
    modifier = Modifier.semantics {
        customActions = listOf(
            CustomAccessibilityAction("Svara") {
                replyToMessage()
                true
            },
            CustomAccessibilityAction("Vidarebefordra") {
                forwardMessage()
                true
            },
            CustomAccessibilityAction("Arkivera") {
                archiveMessage()
                true
            }
        )
    }
) {
    // Message content
}

Custom actions i Compose är enklare att implementera än i View-systemet och integreras sömlöst med TalkBack.

Tillståndsbeskrivningar

För element vars tillstånd ändras, använd stateDescription för att kommunicera aktuellt tillstånd.

Switch(
    checked = isEnabled,
    onCheckedChange = { isEnabled = it },
    modifier = Modifier.semantics {
        stateDescription = if (isEnabled) "På" else "Av"
    }
)

Slider(
    value = volume,
    onValueChange = { volume = it },
    valueRange = 0f..100f,
    modifier = Modifier.semantics {
        stateDescription = "${volume.toInt()}%"
    }
)

State descriptions uppdateras automatiskt när state ändras, vilket ger TalkBack-användare omedelbar feedback.

Testning på Android

Testning är kritisk för att säkerställa att tillgänglighet faktiskt fungerar. Android erbjuder flera verktyg för både automatiserad och manuell testning.

Accessibility Scanner

Accessibility Scanner är en app från Google som scannar din app och identifierar tillgänglighetsproblem direkt på enheten. Installera den från Play Store och aktivera den från Quick Settings.

Scanner hittar problem som:

  • Element utan contentDescription
  • Touch targets mindre än 48×48 dp
  • Färgkontrast under WCAG-krav
  • Text för liten eller utan möjlighet att skala
  • Klickbara element för nära varandra

Scanner ger förslag för varje problem och låter dig spara rapporter för senare review. Använd Scanner regelbundet under utveckling, inte bara i slutet.

Lint checks i Android Studio

Android Studio har inbyggda lint checks för tillgänglighet som varnar för vanliga problem direkt i koden. Dessa inkluderar contentDescription-varningar, hårdkodade textstorlekar och andra anti-patterns.

Aktivera och respektera dessa varningar. Behandla tillgänglighetsrelaterade lint errors som bugs som måste fixas, inte som förslag du kan ignorera. Konfigurera din build så att kritiska tillgänglighetsproblem blockerar kompilering.

Espresso UI-tester

Espresso kan användas för automatiserade UI-tester som inkluderar tillgänglighetsverifieringar.

@Test
fun testLoginButtonAccessibility() {
    onView(withId(R.id.login_button))
        .check(matches(isDisplayed()))
        .check(matches(hasContentDescription()))
        .check(matches(isClickable()))
    
    // Verifiera touch target storlek
    onView(withId(R.id.login_button))
        .check(matches(hasMinimumTouchTargetSize()))
}

@Test
fun testFormAccessibility() {
    // Verifiera att alla fields har labels
    onView(withId(R.id.email_field))
        .check(matches(hasContentDescription()))
    
    onView(withId(R.id.password_field))
        .check(matches(hasContentDescription()))
}

Automatiserade tester fångar regressions och säkerställer att tillgänglighet inte bryts när ny kod läggs till.

Manuell testning med TalkBack

Ingen automatiserad testning kan ersätta manuell testning med TalkBack. Aktivera TalkBack i Settings → Accessibility → TalkBack och navigera genom din app.

Lär dig grundläggande TalkBack-gester:

  • Svep höger/vänster för att navigera
  • Dubbeltryck för att aktivera
  • Två-finger svep för att scrolla
  • TalkBack-menyn för custom actions

Testa hela användarflöden från början till slut. Kan du logga in, hitta innehåll, göra köp eller utföra andra kritiska uppgifter enbart med TalkBack? Dokumentera var du fastnar och varför.

Vanliga tillgänglighetsutmaningar på Android

Även erfarna Android-utvecklare stöter på återkommande problem. Här är några av de vanligaste och hur du löser dem.

Fragmentering och enhetsvariation

Android körs på tusentals olika enheter från många tillverkare. Tillgänglighetsfunktioner kan uppföra sig olika mellan Samsung, Google Pixel, OnePlus och andra enheter, även vid samma Android-version.

Testa på enheter från flera tillverkare om möjligt. Google Pixel representerar ”stock Android” medan Samsung-enheter har One UI med extra tillgänglighetsfunktioner. Vissa tillverkare modifierar TalkBack eller andra hjälpmedel vilket kan påverka hur din app fungerar.

Android-versioner varierar också enormt på marknaden. Medan nya features finns i senaste Android måste du stödja äldre versioner där många användare fortfarande finns. Testa backward compatibility för tillgänglighetsfunktioner.

Custom Views utan tillgänglighet

Custom Views är en vanlig källa till tillgänglighetsproblem. En custom Button byggd från scratch har ingen inbyggd tillgänglighet – du måste implementera allt manuellt.

Om du måste bygga custom Views, override onInitializeAccessibilityNodeInfo() för att sätta rätt properties, implementera performAccessibilityAction() för interaktion, och skicka tillgänglighetshändelser när innehåll ändras.

Ofta är det bättre att extendera befintliga Views eller komponenter istället för att bygga helt från grunden. En custom Button som extends MaterialButton ärver dess tillgänglighetsimplementation.

RecyclerView och dynamiskt innehåll

RecyclerViews med många items kan skapa tillgänglighetsproblem om inte hanterade korrekt. Varje item måste ha tydlig contentDescription och fokusordning måste vara logisk.

När items läggs till eller tas bort dynamiskt, skicka tillgänglighetshändelser så TalkBack-användare blir medvetna. Använd notifyItemInserted() och liknande metoder istället för notifyDataSetChanged() för att ge specifik feedback om vad som ändrats.

För långa listor, överväg att gruppera items med headers så användare kan hoppa mellan sektioner istället för att gå genom alla items en och en.

WebViews och hybrid-innehåll

Om din app använder WebView för att visa webbinnehåll måste webben också vara tillgänglig. TalkBack kan navigera HTML-innehåll, men det kräver att webben följer WCAG-standarder.

Aktivera JavaScript-tillgänglighetsfunktioner i WebView och säkerställ att webbinnehåll har semantisk HTML, alt-text för bilder och ARIA-labels där nödvändigt. Testa navigation mellan native app-content och WebView-content för att säkerställa sömlös upplevelse.

Kom igång med tillgänglighet i dina Android-appar

Att bygga tillgängliga Android-appar kräver både teknisk kunskap och ett mindset där tillgänglighet är en naturlig del av utvecklingsprocessen från start.

Börja med Material Components

Om du är ny på Android-tillgänglighet, börja med att använda Material Components och följa Material Design guidelines noga. Dessa komponenter har redan mycket tillgänglighet implementerad och ger dig en solid grund.

Läs Googles officiella dokumentation om tillgänglighet och gå igenom Google I/O-sessions om ämnet. Google uppdaterar sina riktlinjer regelbundet med nya best practices och tekniker.

Testa med TalkBack från dag ett

Vänta inte till slutet av projektet för att börja testa med TalkBack. Aktivera TalkBack och testa varje ny feature när du bygger den. Det är mycket lättare att fixa problem direkt än att behöva omarbeta stora delar senare.

Lär dig använda TalkBack dagligen. Ju mer bekväm du blir med det desto snabbare kan du identifiera och lösa problem. Försök använda din telefon med TalkBack i 10-15 minuter per dag för att bygga förståelse.

Integrera i utvecklingsprocessen

Gör tillgänglighet till en del av din definition of done. En feature är inte klar förrän den fungerar med TalkBack, har rätt contentDescriptions, uppfyller touch target-krav och har testats på olika enheter.

Code reviews ska inkludera tillgänglighetskontroller. Har alla interaktiva element contentDescriptions? Använder koden sp för text sizes? Är custom komponenter tillgängliga? Dessa frågor ska vara lika naturliga som performance eller säkerhet.

Involvera användare med funktionsnedsättningar

Om möjligt, testa din app med verkliga användare som är beroende av tillgänglighetsfunktioner. Deras feedback är ovärderlig och avslöjar ofta problem som ingen automatiserad process eller utvecklare kan hitta.

Kontakta organisationer som företräder personer med funktionsnedsättningar eller använd tjänster som specialiserar sig på tillgänglighetstestning med riktiga användare.

Fördjupning och nästa steg

Nu när du har fått en översikt över Android-tillgänglighet kan du fördjupa dig i specifika områden:

Android-tillgänglighet för utvecklare: Teknisk deep-dive i Accessibility API, Compose semantics och implementation patterns.

Android-tillgänglighet för designers: Designriktlinjer för Material Design, färg, typografi och layout.

Android-testning för tillgänglighet: Detaljerad guide till Accessibility Scanner, TalkBack-testning och automatiserade tester.

Google’s officiella resurser:

Kom ihåg att tillgänglighet inte är en feature du lägger till – det är kvalitet på din app som gynnar alla användare och är ett krav enligt LPTT för appar som riktar sig till konsumenter.