Testa Android-appar för tillgänglighet

Innehållsförteckning

Systematisk testning är avgörande för att säkerställa att din Android-app verkligen är tillgänglig. Här får du en praktisk guide till verktyg, metoder och processer för att testa tillgänglighet från utveckling till produktion.

Varför tillgänglighetstestning är kritisk

Automatiserade verktyg kan hitta många tekniska problem, men de fångar bara en del av bilden. En knapp kan ha perfekt contentDescription men fortfarande vara oanvändbar om färgkontrasten är för låg eller om den är placerad där användare inte kan nå den. Verklig tillgänglighet uppnås genom kombination av automatiserade verktyg, manuell testning med hjälpmedel och feedback från användare med funktionsnedsättningar.

LPTT kräver att digitala tjänster uppfyller EN 301 549-standarden, vilket innebär att din app måste fungera för användare med olika funktionsnedsättningar. Det räcker inte att appen ”mest” fungerar – den måste vara fullt användbar. Systematisk testning genom hela utvecklingsprocessen är enda sättet att säkerställa detta.

Android-ekosystemet är också mycket mer fragmenterat än iOS. Din app kan uppföra sig olika på Samsung, Google Pixel, OnePlus och andra enheter, även med samma Android-version. TalkBack och andra hjälpmedel kan ha subtila skillnader mellan tillverkare. Detta gör testning på flera enheter extra viktigt.

Testning i utvecklingsprocessen

Tillgänglighet ska inte vara något du kontrollerar i slutet av projektet. Integrera tillgänglighetstestning i varje fas av utvecklingen från design till lansering.

Under design och prototyping

Tillgänglighetstestning börjar redan i designfasen. Använd Material Theme Builder för att validera färgpaletter och säkerställa att alla kombinationer uppfyller kontrastkrav. Använd plugins som Stark för Figma för att testa färgkontrast och simulera färgblindhet direkt i designverktygen.

Kontrollera att alla touch targets är minst 48×48 dp i dina designer. Mät faktiska storlekar och avstånd mellan element. Material Design-komponenter uppfyller detta automatiskt, men custom element måste verifieras manuellt.

Skapa interaktiva prototyper och testa dem med olika Font Size-inställningar. Många design-verktyg låter dig simulera större text. Går layouten sönder? Försvinner viktig information? Knappar för nära varandra? Dessa problem är mycket billigare att fixa nu än efter implementation.

Under utveckling

Varje feature eller komponent ska testas för tillgänglighet innan den markeras som klar. Utvecklare bör köra Accessibility Scanner och Lint checks regelbundet, inte bara vid slutet av varje sprint. Gör det till en vana att testa med TalkBack när du implementerar nya UI-element.

Code reviews bör inkludera tillgänglighetskontroller. Har alla interaktiva element contentDescription? Är custom views korrekt konfigurerade? Fungerar fokusordningen logiskt? Dessa frågor ska vara lika naturliga som att kontrollera för bugs eller prestandaproblem.

Android Studio’s lint-varningar för tillgänglighet ska respekteras. Många vanliga problem som saknade contentDescriptions eller för små touch targets kan fångas automatiskt under kompilering. Konfigurera projektet så att kritiska tillgänglighetsvarningar behandlas som errors.

Under QA och testing

Dedikerade testfaser ska inkludera omfattande tillgänglighetstestning. QA-team behöver utbildning i hur man testar med TalkBack, Voice Access och andra hjälpmedel. Skapa testfall specifikt för tillgänglighetsscenarier som täcker alla kritiska användarflöden.

Testa på fysiska enheter från olika tillverkare, inte bara i emulatorn. TalkBack kan bete sig annorlunda på Samsung-enheter jämfört med Google Pixel. Testa på minst tre olika enheter: en från Samsung, en Google Pixel och en från en annan tillverkare.

Inkludera edge cases i testningen. Vad händer vid största Font Size? Fungerar appen i landscape mode? Vad händer när användaren har både TalkBack och Magnification aktiverade samtidigt? Dessa kombinationer används av riktiga användare.

Innan lansering

En slutlig tillgänglighetsaudit bör genomföras innan varje större release. Detta är ett systematiskt genomgång av hela appen med alla testmetoder – automatiserade verktyg, manuell testning och helst även testning med riktiga användare som har funktionsnedsättningar.

Dokumentera alla identifierade problem och prioritera dem. Blockerande problem som gör viktiga funktioner oanvändbara måste fixas före lansering. Mindre problem kan noteras för framtida releases, men bör inte ignoreras helt.

Skapa en tillgänglighetschecklista specifik för din app som går igenom alla kritiska flows och funktioner. Denna checklist används vid varje release för att säkerställa konsekvent kvalitet.

Accessibility Scanner

Accessibility Scanner är Googles officiella verktyg för att identifiera tillgänglighetsproblem direkt på Android-enheten. Det är ett av dina viktigaste verktyg för snabb feedback.

Installera och aktivera Scanner

Installera Accessibility Scanner från Google Play Store. Efter installation aktiverar du den från Quick Settings eller Settings → Accessibility → Accessibility Scanner. En flytande knapp visas på skärmen som du kan trycka för att scanna aktuell vy.

Scanner är inte-invasiv och kan användas på vilken app som helst, inklusive din egen under utveckling. Detta gör det perfekt för snabb testning under development utan att behöva bygga om eller deploya.

Vad Scanner hittar

Accessibility Scanner identifierar flera typer av problem:

ContentDescription-brister – Element som saknar beskrivningar för TalkBack. Scanner markerar bilder, ikoner och interaktiva element utan contentDescription.

Touch target-problem – Element mindre än 48×48 dp markeras. Scanner visar exakt hur stora touch targets är och hur mycket de behöver öka.

Färgkontrast – Text och UI-element med för låg kontrast mot bakgrund. Scanner visar kontrastförhållandet och vad som krävs enligt WCAG.

Klickbara element för nära – När interaktiva element ligger för tätt varnar Scanner för potentiella miss-clicks.

Text som inte skalar – Text med hårdkodade storlekar som inte följer Font Size-inställningar.

Tolka Scanner-resultat

Scanner ger resultat i tre severity-nivåer:

Red (Kritisk) – Blockerande problem som gör funktioner oanvändbara. Måste fixas omedelbart. Exempel: Kritisk knapp utan contentDescription, touch target under 24dp.

Orange (Varning) – Viktiga problem som bör åtgärdas. Försämrar användarupplevelsen men blockerar inte helt. Exempel: Touch target 40dp (under 48dp men inte helt otillgänglig), kontrast 4:1 (under 4,5:1 men inte oläslig).

Blue (Förslag) – Förbättringsmöjligheter. Appen fungerar men kan bli bättre. Exempel: Ikoner utan contentDescription som redan har medföljande text.

För varje problem ger Scanner konkreta förslag på hur det fixas. ”Increase touch target size to 48×48 dp” eller ”Add contentDescription to ImageButton” med exakt referens till vilket element i koden.

Integrera Scanner i utveckling

Gör Accessibility Scanner till en del av din definition of done. Innan en feature markeras som klar ska Scanner köras och alla red/orange-problem åtgärdas. Blue-förslag utvärderas case-by-case.

Ta screenshots av Scanner-resultat för dokumentation och tracking. Detta hjälper dig se förbättring över tid och kommunicera med teamet om återstående problem.

Lint checks i Android Studio

Android Studio har inbyggda lint checks som varnar för tillgänglighetsproblem direkt under utveckling. Detta ger omedelbar feedback innan du ens kör appen.

Aktivera tillgänglighetslints

Lint checks för tillgänglighet är aktiverade by default men kan konfigureras i build.gradle:

android {
    lintOptions {
        // Behandla vissa accessibility issues som errors
        error 'ContentDescription'
        warning 'ClickableViewAccessibility'
        
        // Generera HTML-rapport
        htmlReport true
        htmlOutput file("$project.buildDir/reports/lint-results.html")
    }
}

Detta gör att saknade contentDescriptions blockerar builds, vilket tvingar utvecklare att åtgärda problemen direkt.

Vanliga lint-varningar

ContentDescription – ImageView, ImageButton och liknande saknar contentDescription. Lint föreslår att lägga till beskrivning eller markera som decorative med importantForAccessibility="no".

ClickableViewAccessibility – Views som hanterar touch events men inte är märkta som clickable. Kan göra dem oåtkomliga för TalkBack.

HardcodedText – Text hårdkodad i XML istället för string resources. Försvårar lokalisering och kan skapa tillgänglighetsproblem.

SmallSp – Text mindre än 12sp som är svår att läsa. Lint rekommenderar större storlekar för läsbarhet.

TouchTargetSizeCheck – Klickbara element mindre än 48dp. Lint markerar exakt vilka views som är för små.

Konfigurera och anpassa lints

Du kan skapa custom lint rules för projektspecifika tillgänglighetskrav. Exempel: om ditt designsystem kräver minimum 56dp för primära knappar kan du skapa en lint rule som varnar när Button är mindre.

Använd lint.xml för att konfigurera vilka checks som ska köras och deras severity:

<?xml version="1.0" encoding="UTF-8"?>
<lint>
    <!-- Gör ContentDescription till error -->
    <issue id="ContentDescription" severity="error" />
    
    <!-- Öka severity för touch targets -->
    <issue id="TouchTargetSizeCheck" severity="error" />
    
    <!-- Ignorera specifika issues i vissa filer -->
    <issue id="HardcodedText">
        <ignore path="src/debug/**" />
    </issue>
</lint>

Manuell testning med TalkBack

Automatiserade verktyg är hjälpsamma men kan aldrig ersätta manuell testning med faktiska hjälpmedel. Du måste testa med TalkBack för att förstå den verkliga användarupplevelsen.

Aktivera och konfigurera TalkBack

Aktivera TalkBack i Settings → Accessibility → TalkBack. För snabbare åtkomst, konfigurera Volume Key Shortcut som låter dig aktivera/deaktivera TalkBack genom att hålla båda volymknapparna i 3 sekunder.

Första gången känns TalkBack ovant och förvirrande. Det är normalt. Ge dig själv tid att lära dig gesterna och bli bekväm med navigation. Försök använda din telefon med TalkBack i 15 minuter dagligen för att bygga förståelse.

Grundläggande TalkBack-gester

Navigera:

Svep höger: Nästa element
Svep vänster: Föregående element
Svep ned sedan höger: Första element
Svep upp sedan vänster: Sista element

Aktivera:

Dubbeltryck var som helst: Aktivera fokuserat element
Dubbeltryck och håll: Long press på element

Scrolla:

Två-finger svep upp/ner: Scrolla sidan
Två-finger svep höger/vänster: Byt sida/tab

TalkBack-menyn:

Svep ner sedan upp: Öppna local context menu
Svep upp sedan ner: Öppna global context menu

Rotor (ändra navigationsläge):

Vrid två fingrar som en ratt: Byt navigationsläge (rubriker, länkar, kontroller etc.)

Testa kritiska användarflöden

Identifiera de viktigaste användarflödena i din app och testa dem systematiskt med TalkBack. För en e-handelsapp:

Bläddra produkter
Söka efter specifik produkt
Läsa produktdetaljer
Lägga produkt i varukorg
Genomföra köp
Logga in/skapa konto

Varje steg ska vara möjligt att genomföra enbart med TalkBack utan att någonsin titta på skärmen. Täck över skärmen eller blunda för att verkligen uppleva begränsningen. Om du fastnar, notera exakt var och varför.

Vanliga problem att leta efter

Tomma eller generiska contentDescriptions: Om TalkBack säger ”Button” eller ”ImageView” utan att förklara vad elementet gör är contentDescription otillräcklig eller saknas.

Ologisk navigationsordning: Om fokus hoppar fram och tillbaka över skärmen istället för att följa logisk läsordning förvirrar det användare. Ordningen ska matcha visuell eller logisk struktur.

Oåtkomliga element: Om viktiga knappar eller information aldrig får fokus när du navigerar är de dolda från TalkBack. Kontrollera importantForAccessibility settings.

Förvirrande formulär: Textfält utan tydliga labels, felmeddelanden som inte läses upp, eller obligatoriska fält som inte kommuniceras tydligt skapar frustration och blockerar användare.

Dynamiska uppdateringar som missas: Om innehåll laddas eller ändras utan att TalkBack meddelar det vet användaren inte att något hänt. Använd announcements eller live regions för viktiga ändringar.

Custom actions som saknas: Om funktionalitet bara är tillgänglig via gester eller visuella knappar utan TalkBack custom actions blir den oanvändbar. Testa att alla funktioner finns i TalkBack-menyn.

Testning med andra hjälpmedel

TalkBack är viktigast men inte det enda hjälpmedlet du behöver testa med. Android erbjuder flera tillgänglighetsfunktioner som dina användare kan vara beroende av.

Voice Access

Voice Access låter användare styra enheten helt med röstkommandon. Installera Voice Access från Play Store och aktivera det. Säg ”Show labels” för att visa nummer på alla klickbara element, eller ”Click [button name]” för att aktivera en specifik knapp.

Testa att navigera genom hela appen med röstkommandon. Kan användare säga namn på knappar för att aktivera dem? Om knappar bara har ikoner utan contentDescription blir de svåra att styra med röst – Voice Access visar nummer istället vilket är mycket mindre intuitivt.

Alla funktioner ska vara tillgängliga via röst. ”Scroll down”, ”Go back”, ”Click save” måste fungera smidigt. Om användare måste säga ”Click number seventeen” istället av beskrivande namn är något fel med labeling.

Switch Access

Switch Access är för användare med motoriska begränsningar som använder externa switchar. Aktivera i Settings → Accessibility → Switch Access och konfigurera en switch (kan vara volymknappen för testning).

Systemet går igenom interaktiva element i sekvens och användaren trycker på sin switch för att aktivera det markerade. Detta kräver att fokusordning är logisk och att alla element kan nås via navigation.

Testa att navigera genom din app med enbart Switch Access. Hur lång tid tar det att nå viktiga funktioner? Kan användare enkelt gå tillbaka om de råkar navigera för långt? Finns det shortcuts eller custom actions som gör navigation effektivare?

Magnification – Förstoring

Aktivera Magnification i Settings → Accessibility → Magnification. Du kan zooma in hela skärmen eller en del av den. Testa din app när användare har zoomat in till 200% eller 400%.

Fungerar all funktionalitet när skärmen är zoomad? Försvinner viktiga knappar utanför viewport? Kan användare scrolla för att nå alla element? Text och knappar får inte klippas av eller bli oåtkomliga vid förstoring.

Testa även Display Size på maximum (Settings → Display → Display Size). Detta förstorer hela UI:t. Din app ska anpassa sig och behålla all funktionalitet även när allt är mycket större.

Font Size vid extrema storlekar

Även om du testat med större text under utveckling, testa explicit med Font Size på absolut maximum (Settings → Display → Font Size). Många appar går sönder först vid de största storlekarna.

Går layouten sönder? Klipps text av? Överlappar element varandra? Försvinner viktig information? Alla dessa är blockerande problem. Vid maximal Font Size kan text vara fyra gånger större än standard vilket kräver mycket flexibla layouts.

Testa även kombinationer som maximal Font Size plus bold text plus increased contrast. Vissa användare kör alla dessa samtidigt och appen måste fortfarande fungera.

Automatiserade tester

Automatiserade tester kan inte fånga allt, men de är ovärderliga för att förhindra regressions och säkerställa konsistent kvalitet över tid.

Espresso tillgänglighetstester

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

@Test
fun testLoginScreenAccessibility() {
    // Verifiera att alla element är tillgängliga
    onView(withId(R.id.email_field))
        .check(matches(isDisplayed()))
        .check(matches(withContentDescription()))
    
    onView(withId(R.id.password_field))
        .check(matches(withContentDescription()))
    
    // Verifiera touch target storlekar
    onView(withId(R.id.login_button))
        .check(matches(hasMinimumSize(48, 48)))
        .check(matches(withEffectiveVisibility(ViewMatchers.Visibility.VISIBLE)))
    
    // Testa interaktion
    onView(withId(R.id.email_field))
        .perform(typeText("[email protected]"))
    
    onView(withId(R.id.login_button))
        .perform(click())
    
    // Verifiera att success-meddelande är tillgängligt
    onView(withText("Inloggning lyckades"))
        .check(matches(isDisplayed()))
        .check(matches(withContentDescription()))
}

Custom matchers för tillgänglighet

Skapa återanvändbara matchers för vanliga tillgänglighetskontroller:

fun withContentDescription(): Matcher<View> {
    return object : TypeSafeMatcher<View>() {
        override fun describeTo(description: Description) {
            description.appendText("has contentDescription")
        }
        
        override fun matchesSafely(view: View): Boolean {
            val desc = view.contentDescription
            return desc != null && desc.isNotEmpty()
        }
    }
}

fun hasMinimumSize(minDp: Int): Matcher<View> {
    return object : TypeSafeMatcher<View>() {
        override fun describeTo(description: Description) {
            description.appendText("has minimum size ${minDp}dp")
        }
        
        override fun matchesSafely(view: View): Boolean {
            val density = view.context.resources.displayMetrics.density
            val minPx = (minDp * density).toInt()
            return view.width >= minPx && view.height >= minPx
        }
    }
}

fun hasTextContrast(minRatio: Float): Matcher<View> {
    return object : TypeSafeMatcher<View>() {
        override fun describeTo(description: Description) {
            description.appendText("has text contrast of at least $minRatio:1")
        }
        
        override fun matchesSafely(view: View): Boolean {
            if (view !is TextView) return true
            
            val textColor = view.currentTextColor
            val background = view.background
            // Implementera kontrastberäkning
            val contrast = calculateContrast(textColor, background)
            return contrast >= minRatio
        }
    }
}

Integration i CI/CD

Automatiserade tillgänglighetstester ska vara en del av din CI/CD pipeline. Varje pull request ska automatiskt testas och misslyckas om tillgänglighetskrav inte uppfylls.

Konfigurera GitHub Actions, Jenkins eller din CI-plattform att köra tillgänglighetstester tillsammans med vanliga tester:

# GitHub Actions exempel
name: Accessibility Tests
on: [pull_request]

jobs:
  accessibility-tests:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      
      - name: Run accessibility lint checks
        run: ./gradlew lintDebug
      
      - name: Run Espresso accessibility tests
        run: ./gradlew connectedAndroidTest
      
      - name: Upload test results
        if: failure()
        uses: actions/upload-artifact@v2
        with:
          name: test-results
          path: app/build/reports/

Sätt upp så att kritiska tillgänglighetsfel blockerar merges till main branch. Detta tvingar utvecklare att åtgärda problem innan de når produktion.

Färgkontrast-testning

WCAG 2.1 AA kräver specifika kontrastförhållanden mellan text och bakgrund. Detta måste testas systematiskt både under design och implementation.

Verktyg för kontrast-testning

Color Contrast Analyzer (CCA) från TPGi är en desktop-app som låter dig mäta kontrast mellan två färger. Välj färger manuellt eller använd pipetten för att plocka färger direkt från skärmen.

Verktyget visar omedelbart om kontrasten uppfyller WCAG AA och AAA för både normal och stor text. Det räknar även bakåt – om du har en bakgrundsfärg kan det visa vilka textfärger som skulle fungera.

Material Theme Builder har inbyggd kontrastkontroll som säkerställer att alla genererade färgkombinationer uppfyller WCAG-krav. Använd detta verktyg för att skapa hela färgpaletten från start.

Accessibility Scanner testar kontrast i running apps direkt på enheten. Detta är perfekt för att verifiera faktisk implementation, inte bara design-specifikationer.

Testa i olika lägen

Kontrast måste testas i alla färglägen din app stödjer:

Light theme, normal contrast
Light theme, high contrast
Dark theme, normal contrast
Dark theme, high contrast

Android’s High Contrast Text-inställning kan öka kontraster ytterligare. Din app måste ha kontrast-förstärkta färgvarianter för detta läge som aktiveras automatiskt.

Testa även på faktiska enheter i olika ljusförhållanden. En skärm i direkt solljus ser helt annorlunda ut än inomhus. Text som är läslig på kontoret kan vara oläslig utomhus. Detta är särskilt viktigt för appar som förväntas användas utomhus som navigation, transport eller sport-appar.

Icke-text kontrast

WCAG kräver även 3:1 kontrast för grafiska element som ikoner, knappramar och viktiga UI-komponenter. Detta testas på samma sätt som text men med lägre krav.

En knappsträng måste ha 3:1 kontrast mot bakgrunden. En ikon måste ha 3:1 kontrast. Men dekorativa element som bara är där för estetik behöver inte uppfylla kontrastkrav om de inte förmedlar information.

Fokusindikatorer är särskilt viktiga. När ett element har fokus måste indikatorn vara tydligt synlig med minst 3:1 kontrast mot både elementet och bakgrunden runt det.

Testning med riktiga användare

Ingen kombination av automatiserade verktyg och experttestning kan ersätta feedback från personer som faktiskt är beroende av tillgänglighetsfunktioner för att använda din app.

Rekrytera testdeltagare

Sök testdeltagare med olika funktionsnedsättningar: synnedsättningar, hörselnedsättningar, motoriska begränsningar och kognitiva funktionsnedsättningar. Varje grupp har unika behov och upptäcker olika typer av problem.

Kontakta organisationer som företräder personer med funktionsnedsättningar som Synskadades Riksförbund, DHR (Delaktighet, Handlingskraft, Rörelsefrihet) eller specialiserade testfirmor. Många har testprogram eller kan hjälpa dig hitta lämpliga deltagare.

Betala deltagare för deras tid – deras expertis är värdefull. Budgetera minst 500-1000 kr per timme för användartester med personer med funktionsnedsättningar.

Inkludera både erfarna TalkBack-användare och nybörjare. Erfarna användare hittar subtila problem som experter missar. Nybörjare upptäcker om din app är lättförståelig för någon som just börjat med hjälpmedel.

Genomföra användartester

Förbered specifika scenarios eller uppgifter du vill att deltagare ska utföra. För en e-handelsapp: ”Hitta en blå t-shirt i storlek M och lägg den i varukorgen”. Observera hur deltagare närmar sig uppgiften och var de stöter på problem.

Använd think-aloud metoden där deltagare beskriver vad de gör och tänker medan de utför uppgifter. Detta ger ovärderlig insikt i deras mentala modell och förväntningar.

Var inte rädd för tystnad. Låt deltagare jobba i sin egen takt och avbryt inte omedelbart när de fastnar. Observera hur de försöker lösa problem själva – det avslöjar mycket om var designen kan förbättras.

Testa med olika Android-enheter. En Samsung-användare kan ha helt andra förväntningar och vanor än en Google Pixel-användare. TalkBack kan uppföra sig olika på olika enheter vilket påverkar användarupplevelsen.

Dokumentera och agera på feedback

Ta anteckningar under testerna eller (med tillstånd) spela in sessioner. Notera inte bara vad som gick fel utan också vad som fungerade bra. Positiv feedback validerar att du är på rätt väg.

Kategorisera identifierade problem efter severity: blockerande (användaren kan inte slutföra uppgiften), stor (användaren kan slutföra men med stor svårighet), liten (irritation men inte blockerande).

Prioritera fixes baserat på severity och hur ofta problemet uppstår. Ett blockerande problem som påverkar huvudfunktionen måste fixas omedelbart. Små irritationer i sällan använda funktioner kan vänta till nästa iteration.

Dela feedback med hela teamet. Videoklipp från användartester där verkliga användare kämpar med din app är mycket mer övertygande än rapporter eller metrics. Detta bygger empati och motivation för tillgänglighetsarbete.

Testchecklista för Android-tillgänglighet

En systematisk checklist hjälper säkerställa att inget glöms bort. Anpassa denna mall efter din apps specifika behov:

Grundläggande tillgänglighet

Alla interaktiva element har beskrivande contentDescription
Bilder som förmedlar information har contentDescription
Dekorativa element är dolda med importantForAccessibility=”no”
Touch targets är minst 48×48 dp
Avstånd mellan interaktiva element är minst 8 dp
Fokusordning är logisk och följer visuell struktur

Färg och visuell design

All text har minst 4,5:1 kontrast (3:1 för stor text)
UI-komponenter har 3:1 kontrast
Information förmedlas inte enbart med färg
Appen fungerar i både ljust och mörkt tema
High Contrast mode fungerar korrekt
Färgblindhetssimulationer visar inga problem

Typografi och text

Text definieras i sp (scale-independent pixels)
Appen stödjer Font Size upp till maximum
Layout anpassas vid olika textstorlekar
Viktig text trunkeras aldrig
Radavstånd och läsbarhet är god vid alla storlekar

Navigation och interaktion

Hela appen kan navigeras med TalkBack
Voice Access kan styra alla funktioner
Switch Access fungerar i hela appen
Fokus hanteras korrekt vid navigation
Modaler och dialogs fångar fokus
Alla funktioner tillgängliga utan komplexa gester

Formulär och input

Alla textfält har tydliga, synliga labels
Felmeddelanden är specifika och hjälpsamma
Obligatoriska fält kommuniceras tydligt
Autofill stöds för relevanta fält
Validation ger omedelbar, tydlig feedback

Dynamiskt innehåll

Viktiga ändringar meddelas med announcements
Loading states kommuniceras till TalkBack
Fel och bekräftelser läses upp
Live-uppdaterande innehåll hanteras korrekt

Relaterade resurser

För mer information om Android-tillgänglighetstestning:

Skapa tillgängliga appar för Android – Översikt över Android-tillgänglighetsfunktioner.

Android-tillgänglighet för utvecklare – Teknisk implementation av tillgängliga appar.

Android-tillgänglighet för designers – Designriktlinjer för tillgängliga Android-appar.

Generell mobilapp-guide – Jämförelse mellan iOS och Android.

Google’s officiella resurser:

Med systematisk testning och rätt verktyg kan du säkerställa att din Android-app uppfyller LPTT:s krav och fungerar utmärkt för alla användare, oavsett funktionsförmåga. Testning är investeringen som säkerställer att ditt tillgänglighetsarbete faktiskt levererar värde till användare.