Innehållsförteckning
Systematisk testning är avgörande för att säkerställa att din iOS-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 accessibility label men fortfarande vara oanvändbar om den är placerad där användare inte kan nå den, eller om färgkontrasten är för låg. 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.
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 verktyg som Stark plugin för Figma eller Sketch för att validera färgkontrast direkt medan du designar. Kontrollera att touch targets är minst 44×44 punkter. Verifiera att text styles följer Dynamic Type principer.
Skapa interaktiva prototyper och testa dem med färgblindhetssimulationer. Aktivera iOS Color Filters på din enhet och navigera genom prototypen. Kan du fortfarande förstå alla states och skillnader? Om röd/grön distinktioner försvinner måste designen ändras innan utveckling påbörjas.
Testa även prototyper med olika textstorlekar. Många design-verktyg låter dig simulera större text. Går layouten sönder? Försvinner viktig information? 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 Inspector regelbundet, inte bara vid slutet av varje sprint. Gör det till en vana att testa med VoiceOver när du implementerar nya UI-element.
Code reviews bör inkludera accessibility-kontroller. Har alla bilder accessibility labels? Är custom controls korrekt märkta? Fungerar fokusordningen logiskt? Dessa frågor ska vara lika naturliga som att kontrollera för bugs eller dålig prestanda.
Använd accessibility lint-varningar i Xcode. Många vanliga problem som saknade labels eller för små touch targets kan fångas automatiskt under kompilering. Behandla dessa varningar som errors som måste åtgärdas.
Under QA och testing
Dedikerade testfaser ska inkludera omfattande tillgänglighetstestning. QA-team behöver utbildning i hur man testar med VoiceOver, Voice Control och andra hjälpmedel. Skapa testfall specifikt för accessibility-scenarios.
Testa på fysiska enheter, inte bara i simulatorn. VoiceOver kan bete sig annorlunda på riktiga iPhones, särskilt äldre modeller eller vid olika iOS-versioner. Testa på minst tre olika enheter: en mindre iPhone (SE), en standard storlek och en Pro Max.
Inkludera edge cases i testningen. Vad händer vid största textstorlek? Fungerar appen i landscape mode? Vad händer när användaren har både VoiceOver och Zoom aktiverade samtidigt? Dessa kombinationer används av riktiga användare.
Innan lansering
En slutlig accessibility audit 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 accessibility checklist 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 Inspector i Xcode
Accessibility Inspector är ditt primära utvecklarverktyg för tillgänglighetstestning. Det är inbyggt i Xcode och ger dig direkt insyn i hur iOS hjälpmedel ser din app.
Starta och använda Inspector
Öppna Accessibility Inspector från Xcode menyn: Xcode → Open Developer Tool → Accessibility Inspector. Du kan även öppna det direkt på enheten via Settings → Developer → Accessibility Inspector.
Inspector visar accessibility-trädet för din app – den hierarki av element som VoiceOver och andra hjälpmedel ser. Detta trädet är inte alltid identiskt med view-hierarkin, vilket är varför inspektionen är så värdefull. En view kan vara synlig men dold från accessibility-trädet, eller tvärtom.
Hover-mode låter dig peka på element i simulatorn eller på ansluten enhet och se deras accessibility properties direkt. Klicka på ett element för att se detaljerad information: label, hint, traits, frame, och om elementet är faktiskt accessible.
Köra automatiserade audits
Inspector’s audit-funktion scannar din app och identifierar vanliga tillgänglighetsproblem. Klicka på audit-ikonen (en cirkel med bock) för att starta en scan av aktuell skärm.
Audits hittar problem som:
- Element utan accessibility labels
- Bilder som saknar beskrivningar
- Färgkontrast under WCAG-kraven
- Touch targets mindre än 44×44 punkter
- Klickbara element för nära varandra
- Text som inte skalar med Dynamic Type
Varje identifierat problem får en severity-nivå och en förklaring. Kritiska problem markeras rött och bör åtgärdas omedelbart. Varningar i gult är viktiga men kanske inte blockerande. Informativa meddelanden ger suggestions för förbättringar.
Inspektera specifika element
När auditen identifierar problem eller när du själv vill granska ett specifikt element, använd element-inspektorn. Välj ett element och se alla dess accessibility properties i detalj.
Kontrollera att label är beskrivande och meningsfull. Om labeln är ”Button” eller ”Image” utan vidare information är något fel. Traits ska matcha elementets funktion – en knapp ska ha .button trait, en header ska ha .header trait.
Frame-information visar elementets storlek och position. Använd detta för att verifiera att touch targets är tillräckligt stora och att element inte överlappar på olämpliga sätt.
Simulera VoiceOver-navigation
Inspector kan simulera hur VoiceOver navigerar genom din app utan att du behöver aktivera VoiceOver. Använd pilknapparna i Inspector för att navigera till nästa/föregående element precis som VoiceOver-användare skulle göra med svep-gester.
Detta visar dig fokusordningen – den ordning element presenteras till VoiceOver-användare. Om ordningen är ologisk eller hoppar runt oförutsägbart behöver du justera accessibility-hierarkin eller använda accessibilityElements array för att definiera rätt ordning.
Lyssna på vad Inspector ”läser upp” för varje element. Även om det är text istället för faktiskt tal, ger det dig en känsla för hur VoiceOver-användare upplever din app. Är informationen tillräcklig? Är något förvirrande eller överflödigt?
Manuell testning med VoiceOver
Automatiserade verktyg är hjälpsamma men kan aldrig ersätta manuell testning med faktiska hjälpmedel. Du måste testa med VoiceOver för att förstå den verkliga användarupplevelsen.
Aktivera och använda VoiceOver
Komplett guide: Testa med VoiceOver på iOS
VoiceOver aktiveras i Settings → Accessibility → VoiceOver, eller snabbare via accessibility shortcut (tryck sidknappen tre gånger). Lär dig de grundläggande gesterna:
- Svep höger/vänster: Navigera till nästa/föregående element
- Dubbeltryck: Aktivera det fokuserade elementet
- Två-finger svep upp/ner: Scrolla sidan
- Rotor (vrida två fingrar): Ändra navigationsläge (rubriker, länkar, formulär etc.)
Första gången du använder VoiceOver känns det ovant och långsamt. Det är normalt. Övning gör mästare. Försök använda din telefon med VoiceOver i 15 minuter dagligen för att bygga förståelse för upplevelsen.
Testa kritiska användarflöden
Identifiera de viktigaste användarflödena i din app och testa dem systematiskt med VoiceOver. För en e-handelsapp kan det vara:
- 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 VoiceOver utan att någonsin titta på skärmen. Om du fastnar, notera exakt var och varför. Är det ett saknat label? Ologisk fokusordning? Oklara instruktioner?
Vanliga problem att leta efter
När du testar med VoiceOver, var uppmärksam på dessa vanliga problem:
Tomma eller generiska labels: Om VoiceOver säger ”Button” utan att förklara vad knappen gör är labeln otillräcklig. Varje element ska ha en beskrivande label.
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 VoiceOver. Kontrollera isAccessibilityElement 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.
Dynamiska uppdateringar som missas: Om innehåll laddas eller ändras utan att VoiceOver meddelar det, vet användaren inte att något hänt. Använd accessibility notifications för viktiga ändringar.
Testning med andra hjälpmedel
VoiceOver är viktigast men inte det enda hjälpmedlet du behöver testa med. iOS erbjuder flera tillgänglighetsfunktioner som dina användare kan vara beroende av.
Voice Control
Voice Control låter användare styra enheten helt med röstkommandon. Aktivera det i Settings → Accessibility → Voice Control och testa din app.
Kan användare säga namn på knappar för att aktivera dem? Om knappar bara har ikoner utan labels blir de svåra att styra med röst. Voice Control visar nummer på element utan talbara namn, men det är mycket bättre om användare kan säga ”Tryck Spara” istället för ”Tryck Fem”.
Testa att navigera genom hela appen med röstkommandon. ”Show grid” visar nummer på klickbara element. ”Tap [number]” aktiverar ett element. ”Scroll down” scrollar innehållet. Alla funktioner ska vara tillgängliga via röst.
Switch Control
Switch Control är för användare med motoriska begränsningar som använder externa switchar (knappar) för att styra enheten. Aktivera i Settings → Accessibility → Switch Control.
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 Control. 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 genvägar för vanliga actions?
Zoom och förstoringsfunktioner
Många användare med synnedsättningar använder Zoom för att förstora delar av skärmen. Aktivera Zoom i Settings → Accessibility → Zoom och testa din app.
Fungerar all funktionalitet när skärmen är zoomad? Försvinner viktiga knappar utanför viewport? Kan användare scrolla åt alla håll för att nå alla element?
Testa även med Display Zoom (Settings → Display & Brightness → Display Zoom → Zoomed), som gör hela UI större. Din app ska anpassa sig och behålla all funktionalitet.
Dynamic Type vid maximala storlekar
Även om du testat med större text under utveckling, testa explicit med de absolut största textstorlekarna (Accessibility sizes XXXL). Aktivera i Settings → Display & Brightness → Text Size och dra reglaget helt till höger.
Går layouten sönder? Klipps text av? Överlappar element varandra? Försvinner viktig information? Alla dessa är blockerande problem som måste fixas.
Testa även kombinationer som maximal textstorlek 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.
XCTest för accessibility
XCTest, Apples test-ramverk, kan användas för att skriva automatiserade accessibility-tester som körs i din CI/CD pipeline.
func testLoginButtonAccessibility() {
let app = XCUIApplication()
app.launch()
let loginButton = app.buttons["Logga in"]
// Verifiera att knappen existerar och är accessible
XCTAssertTrue(loginButton.exists)
XCTAssertTrue(loginButton.isHittable)
// Verifiera label
XCTAssertEqual(loginButton.label, "Logga in")
// Verifiera att knappen kan aktiveras
loginButton.tap()
// Verifiera resultat av interaktion
XCTAssertTrue(app.textFields["E-post"].exists)
}
func testFormFieldLabels() {
let app = XCUIApplication()
app.launch()
// Navigera till formulär
app.buttons["Registrera"].tap()
// Verifiera att alla fält har labels
let nameField = app.textFields["Namn"]
XCTAssertTrue(nameField.exists)
XCTAssertEqual(nameField.label, "Namn")
let emailField = app.textFields["E-post"]
XCTAssertTrue(emailField.exists)
XCTAssertEqual(emailField.label, "E-post")
}
func testDynamicTypeSupport() {
// Simulera olika textstorlekar
let app = XCUIApplication()
app.launchArguments = ["-UIPreferredContentSizeCategoryName", "UICTContentSizeCategoryAccessibilityXL"]
app.launch()
// Verifiera att viktig text fortfarande syns
let headline = app.staticTexts["Välkommen"]
XCTAssertTrue(headline.exists)
XCTAssertTrue(headline.isHittable)
}
Dessa tester körs automatiskt vid varje build och fångar regressions direkt. Om någon av misstag tar bort en accessibility label eller bryter fokusordning kommer testet att misslyckas.
Unit tester för accessibility properties
Utöver UI-tester kan du skriva unit tester för enskilda komponenter och deras accessibility properties.
func testCustomButtonAccessibility() {
let button = CustomButton(frame: .zero)
button.configure(title: "Spara", action: {})
// Verifiera att elementet är accessible
XCTAssertTrue(button.isAccessibilityElement)
// Verifiera properties
XCTAssertEqual(button.accessibilityLabel, "Spara")
XCTAssertTrue(button.accessibilityTraits.contains(.button))
XCTAssertNotNil(button.accessibilityHint)
// Verifiera touch target storlek
XCTAssertGreaterThanOrEqual(button.frame.width, 44)
XCTAssertGreaterThanOrEqual(button.frame.height, 44)
}
func testArticleCellAccessibility() {
let cell = ArticleCell()
let article = Article(title: "Test", author: "Author", date: Date())
cell.configure(with: article)
// Verifiera att cellen har rätt accessibility
XCTAssertTrue(cell.isAccessibilityElement)
XCTAssertTrue(cell.accessibilityLabel!.contains("Test"))
XCTAssertTrue(cell.accessibilityLabel!.contains("Author"))
}
Unit tester körs snabbare än UI-tester och kan köras oftare. De ger snabb feedback under utveckling.
Integration i CI/CD
Automatiserade accessibility-tester ska vara en del av din CI/CD pipeline. Varje pull request ska automatiskt testas och misslyckas om accessibility-krav inte uppfylls.
Konfigurera GitHub Actions, Jenkins eller din CI-plattform att köra accessibility-tester tillsammans med vanliga tester. Sätt upp så att kritiska accessibility-failures blockerar merges till main branch.
Använd code coverage för att säkerställa att accessibility-kod faktiskt testas. Hög test coverage för vanlig funktionalitet men noll coverage för accessibility properties är ett varningssignal.
Färgkontrast-testning
WCAG 2.1 AA kräver specifika kontrastförhållanden mellan text och bakgrund. Detta måste testas systematiskt.
Verktyg för kontrast-testning
Color Contrast Analyzer är en desktop-app från TPGi som låter dig mäta kontrast mellan två färger. Du kan antingen välja färger manuellt eller använda pipetten för att plocka färger direkt från skärmen.
Verktyget visar omedelbart om kontrasten uppfyller WCAG AA och AAA krav 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.
Stark plugin för Figma och Sketch integrerar kontrast-testning direkt i designverktyg. Välj ett textelement och verktyget visar automatiskt om kontrasten är tillräcklig. Det kan även simulera färgblindhet och andra synnedsättningar.
Accessibility Inspector i Xcode kan också testa kontrast när du kör audits. Den identifierar text-element med otillräcklig kontrast, men verktyget är bättre för att hitta problem än för att fixa dem.
Testa i olika lägen och conditions
Kontrast måste testas i alla färglägen din app stödjer. En färgkombination som fungerar i ljust läge kanske inte fungerar i Dark Mode. Testa explicit:
- Light mode, normal contrast
- Light mode, increased contrast
- Dark mode, normal contrast
- Dark mode, increased contrast
Många appar glömmer increased contrast mode. iOS kan öka kontraster ytterligare för användare som behöver det, och din app måste ha kontrastförstärkta färgvarianter för detta läge.
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 ute, som navigation eller transport-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 knappram 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 (för tangentbord, Switch Control etc.) 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. Många har testprogram eller kan hjälpa dig hitta lämpliga testdeltagare. Betala deltagare för deras tid – deras expertis är värdefull.
Inkludera både erfarna VoiceOver-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.
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.
Testchecklista för iOS-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 accessibility
- [ ] Alla interaktiva element har beskrivande accessibility labels
- [ ] Bilder som förmedlar information har alt-text
- [ ] Dekorativa bilder är dolda från accessibility-trädet
- [ ] Alla knappar, länkar och kontroller har rätt traits
- [ ] Touch targets är minst 44×44 punkter
- [ ] 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)
- [ ] Interaktiva element har 3:1 kontrast
- [ ] Information förmedlas inte enbart med färg
- [ ] Appen fungerar i både ljust och mörkt läge
- [ ] Increased contrast mode fungerar korrekt
- [ ] Färgblindhetssimulationer visar inga problem
Typografi och text
- [ ] Appen stödjer Dynamic Type fullt ut
- [ ] Text skalas korrekt upp till Accessibility XXXL
- [ ] 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 VoiceOver
- [ ] Voice Control kan styra alla funktioner
- [ ] Switch Control fungerar i hela appen
- [ ] Fokus flyttas korrekt vid navigation
- [ ] Modaler fångar fokus korrekt
- [ ] 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 accessibility notifications
- [ ] Loading states kommuniceras till VoiceOver
- [ ] Fel och bekräftelser läses upp
- [ ] Live-uppdaterande innehåll hanteras korrekt
Testning och dokumentation
- [ ] Appen testad med VoiceOver på fysisk enhet
- [ ] Accessibility Inspector audits körs utan errors
- [ ] Automatiserade tester för accessibility finns
- [ ] Appen testad vid olika textstorlekar
- [ ] Testning med riktiga användare genomförd
- [ ] Accessibility-dokumentation är uppdaterad
Kontinuerlig förbättring
Tillgänglighetstestning är inte en engångsaktivitet. iOS uppdateras regelbundet med nya funktioner och krav, användarbehov förändras och din app utvecklas. Etablera en process för kontinuerlig testning och förbättring.
Inkludera accessibility i varje sprint eller release-cykel. Sätt accessibility-mål för varje iteration och följ upp dem. Mät förbättring över tid med metriker som antal accessibility-buggar, audit-poäng eller användarnöjdhet.
Utbilda hela teamet i accessibility. Designers, utvecklare, projektledare och testers ska alla förstå grundläggande tillgänglighetsprinciper och hur de påverkar deras arbete. Regelbundna workshops eller lunch-and-learns håller kunskapen fräsch.
Följ utvecklingen i accessibility-världen. Prenumerera på Apples WWDC-sessioner om accessibility. Läs bloggar och artiklar från experter. Nya verktyg och tekniker utvecklas ständigt som kan förbättra din testprocess.
Relaterade resurser
För mer information om iOS-tillgänglighet och testning:
Testa med VoiceOver på iOS – Detaljerad guide för VoiceOver-testning med alla gester och tekniker.
iOS-tillgänglighet för utvecklare – Teknisk implementation av accessibility i kod.
iOS-tillgänglighet för designers – Designriktlinjer för tillgängliga iOS-appar.
iOS tillgänglighet översikt – Allmän översikt över iOS accessibility-funktioner.
Apple’s officiella resurser:
Med systematisk testning och rätt verktyg kan du säkerställa att din iOS-app uppfyller LPTT:s krav och fungerar utmärkt för alla användare, oavsett funktionsförmåga.