Innehållsförteckning
iOS erbjuder kraftfulla verktyg och ramverk för att skapa tillgängliga appar. Här får du en översikt över Apples tillgänglighetsfunktioner, Human Interface Guidelines, och praktisk vägledning för att bygga iOS-appar som uppfyller LPPT:s krav.
Apples tillgänglighetsfunktioner
Apple har länge varit en ledare inom digital tillgänglighet och har byggt in omfattande tillgänglighetsfunktioner direkt i iOS. Dessa funktioner är inte efterkonstruktioner utan integrerade delar av operativsystemet som miljontals användare världen över förlitar sig på dagligen.
VoiceOver – Skärmläsare för iOS
VoiceOver är Apples inbyggda skärmläsare som läser upp innehåll på skärmen och låter användare navigera genom gester. VoiceOver finns på alla iOS-enheter utan extra kostnad och är djupt integrerat med systemet.
När VoiceOver är aktiverat ändras hur användare interagerar med enheten helt. Istället för att trycka direkt på element navigerar användare genom att svepa åt höger eller vänster mellan element, och dubbeltrycker för att aktivera det markerade elementet. Din app måste vara byggd för att fungera med dessa interaktionsmönster.
VoiceOver läser upp accessibility labels, hints och traits som du definierar för varje element. Om dessa saknas eller är felaktiga blir appen förvirrande eller oanvändbar. Att testa med VoiceOver är absolut nödvändigt för att säkerställa att din app verkligen är tillgänglig.
Voice Control – Röststyrd navigation
Voice Control låter användare styra sin iPhone eller iPad helt med röstkommandon. Användare kan säga namn på knappar, numrera element på skärmen och utföra komplexa kommandon utan att röra enheten.
För att din app ska fungera väl med Voice Control behöver alla interaktiva element ha tydliga accessibility labels som användare kan uttala. Voice Control visar automatiskt nummer på klickbara element om de saknar labels, men det är mycket bättre om användare kan säga ”tryck Skicka” istället för ”tryck fyra”.
Switch Control – Styrning med switchar
Switch Control gör det möjligt för användare med motoriska begränsningar att styra sin enhet med externa switchar – fysiska knappar som kan anslutas via 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 Control ska fungera bra. Tänk på att användare kan behöva lång tid för att navigera genom många element, så gruppering och effektiv struktur blir extra viktig.
Dynamic Type – Anpassad textstorlek
Dynamic Type är Apples system för textskalning. Användare kan ställa in sin föredragna textstorlek i systeminställningar och alla appar som stödjer Dynamic Type anpassar sig automatiskt.
Din app ska använda systemets text styles som Headline, Body och Caption, som automatiskt skalas när användaren ändrar inställningar. Undvik att hårdkoda textstorlekar i punkter. Layouten måste anpassa sig när text blir större så att innehåll inte klipps av eller blir oläsbart.
Display Accommodations – Visuella anpassningar
iOS erbjuder flera visuella anpassningar som inverterade färger, ökad kontrast, reducerad transparens och färgfilter för olika typer av färgblindhet. Din app bör respektera dessa inställningar eller åtminstone fungera acceptabelt när de är aktiverade.
Testa din app med olika Display Accommodations aktiverade för att säkerställa att färgscheman, kontraster och visuella hierarkier fortfarande fungerar. Många användare kombinerar flera inställningar samtidigt.
AssistiveTouch – Alternativa gester
AssistiveTouch visar en flytande meny på skärmen som gör komplexa gester och knappar tillgängliga genom enkla tryck. Detta hjälper användare som har svårt att utföra multitouch-gester eller nå fysiska knappar.
Om din app använder komplexa gester som pinch-to-zoom, rotation eller trefinger-svep, måste dessa funktioner även vara tillgängliga genom vanliga knappar eller menyer som AssistiveTouch-användare kan nå.
Human Interface Guidelines för tillgänglighet
Apples Human Interface Guidelines (HIG) innehåller omfattande riktlinjer för hur du designar och utvecklar tillgängliga iOS-appar. Att följa HIG ger dig inte bara bättre tillgänglighet utan också en app som känns native och bekant för iOS-användare.
Använd standardkomponenter när det är möjligt
UIKit och SwiftUI innehåller färdiga komponenter som UIButton, UILabel, UITextField och många fler. Dessa komponenter har redan inbyggd tillgänglighetsfunktionalitet. En UIButton har automatiskt rätt accessibility traits, kan aktiveras med VoiceOver och fungerar med Switch Control.
När du använder standardkomponenter får du mycket tillgänglighet gratis. Problem uppstår oftast när utvecklare bygger custom komponenter utan att tänka på tillgänglighet. Om du måste bygga något custom, studera hur standardkomponenten fungerar med hjälpmedel och replikera det beteendet.
Tydliga fokusindikatorer och visuell feedback
När användare navigerar med tangentbord, Switch Control eller andra hjälpmedel måste de kunna se vilket element som har fokus. iOS hanterar mycket av detta automatiskt, men du kan behöva justera färger och stilar för att fokusindikatorn är tydlig mot din apps bakgrund.
Varje interaktion ska ge omedelbar visuell eller taktil feedback. Knapptryck ska visa en highlight-state, längre operationer ska visa progress-indikatorer, och tillståndsändringar ska kommuniceras tydligt både visuellt och till hjälpmedel.
Touch targets och spacing
HIG rekommenderar minst 44×44 punkter för alla klickbara element. Detta gäller även om det visuella elementet är mindre – du kan utöka den interaktiva ytan utan att ändra utseendet. Avstånd mellan klickbara element ska vara tillräckligt för att användare inte råkar trycka fel.
På mindre skärmar som iPhone SE eller vid stora textstorlekar kan layouter behöva anpassa sig radikalt. Horisontella rader av knappar kan behöva bli vertikala staplar, och vissa sekundära element kanske behöver döljas eller flyttas till undermenyer.
Färg och kontrast
Använd inte enbart färg för att förmedla information. Om felmeddelanden är röda måste det även finnas en ikon eller text som förklarar felet. Detta hjälper färgblinda användare men också personer som använder skärmläsare.
Textkontrast ska vara minst 4.5:1 för normal text och 3:1 för stor text enligt WCAG 2.1 AA. Testa din app i både ljust och mörkt läge, och med ökad kontrast aktiverad för att säkerställa att text förblir läsbar.
Stöd för landskaps- och porträttläge
Om din app stödjer både landskaps- och porträttläge måste all funktionalitet fungera i båda orienteringarna. Vissa användare med motoriska begränsningar eller hjälpmedel kan behöva hålla enheten i ett specifikt läge.
Layouter måste anpassa sig intelligent när orientering ändras. Innehåll får inte klipps av, funktioner får inte bli oåtkomliga, och fokusordning måste förbli logisk.
UIAccessibility API och SwiftUI
iOS erbjuder kraftfulla API:er för att göra dina appar tillgängliga. Beroende på om du använder UIKit eller SwiftUI finns lite olika approaches, men principerna är desamma.
Accessibility Labels
En accessibility label beskriver vad ett element är. För en knapp som visar ett plusikon skulle labeln kunna vara ”Lägg till objekt”. Labels ska vara korta, beskrivande och på samma språk som resten av appen.
Undvik att inkludera elementtypen i labeln – säg inte ”Knapp: Lägg till objekt” eftersom VoiceOver redan berättar att det är en knapp. Fokusera på vad elementet gör eller representerar.
I UIKit sätter du accessibilityLabel på view-objektet. I SwiftUI använder du .accessibilityLabel() modifieren. Dekorativa bilder som inte förmedlar information ska markeras som dolda från tillgänglighetsträdet med isAccessibilityElement = false eller .accessibilityHidden(true).
Accessibility Hints
En hint ger extra information om vad som händer när användaren interagerar med ett element. För en knapp med labeln ”Dela” skulle hinten kunna vara ”Öppnar delningsalternativ”.
Hints är valfria och ska användas sparsamt. De är mest användbara när resultatet av en interaktion inte är uppenbart från labeln ensam. VoiceOver läser upp hints efter en kort paus, så användare kan välja att inte vänta på dem.
Skriv hints som kompletta meningar som börjar med ett verb: ”Öppnar inställningar”, ”Spelar upp video”, ”Skickar meddelande”.
Accessibility Traits
Traits beskriver vad ett element är för typ – knapp, länk, header, bild, etc. UIKit-komponenter har automatiskt rätt traits, men när du bygger custom views måste du sätta dem explicit.
I UIKit använder du accessibilityTraits som kan kombinera flera traits, till exempel .button och .selected för en markerad knapp. SwiftUI har liknande modifiers som .accessibilityAddTraits() och .accessibilityRemoveTraits().
Rätt traits är kritiska för att VoiceOver ska kommunicera elementets roll korrekt. En custom view som fungerar som en knapp måste ha .button trait för att VoiceOver ska säga ”knapp” och användare ska veta att de kan dubbeltrycka för att aktivera den.
Accessibility Actions
Custom actions låter dig exponera flera operationer för ett enda element till VoiceOver-användare. Till exempel kan en lista-rad ha actions för ”Redigera”, ”Dela” och ”Radera” som användare kan välja från en rotor-meny.
Detta är mycket mer effektivt än att ha separata knappar för varje action, vilket skulle kräva att användare navigerar genom många element. Custom actions håller gränssnittet rent medan du fortfarande ger kraftfull funktionalitet till hjälpmedelsanvändare.
Dynamiska uppdateringar och notifications
När innehåll ändras dynamiskt i din app måste du meddela VoiceOver om förändringen. Om du laddar nya meddelanden eller uppdaterar en räknare ska VoiceOver kunna berätta det för användaren.
Använd UIAccessibility.post(notification:argument:) för att skicka notifications. Layout changed notification används när element flyttas runt, screen changed notification när hela skärmen ändras, och announcement notification för att läsa upp ett meddelande utan att ändra fokus.
Testverktyg för iOS-tillgänglighet
Apple tillhandahåller flera verktyg för att testa och felsöka tillgänglighet i iOS-appar. Dessa verktyg ska användas kontinuerligt under utvecklingen, inte bara i slutet av projektet.
Accessibility Inspector i Xcode
Accessibility Inspector är ditt primära utvecklarverktyg för tillgänglighet. Det visar tillgänglighetsträdet för din app, låter dig inspektera enskilda element och köra automatiserade audits.
Inspektorn visar exakt vad VoiceOver ser – labels, hints, traits, och position i hierarkin. Om något ser fel ut här kommer det också fungera fel i VoiceOver. Du kan även simulera VoiceOver-navigation direkt i Inspektorn utan att aktivera VoiceOver på enheten.
Audit-funktionen hittar många vanliga problem som saknade labels, för låg kontrast och för små touch targets. Kör audits regelbundet och åtgärda problem innan de växer sig för stora.
Manuell testning med VoiceOver
Automatiserade verktyg är hjälpsamma men kan aldrig ersätta manuell testning med faktiska hjälpmedel. Du måste testa din app med VoiceOver aktiverat för att förstå den verkliga användarupplevelsen.
Aktivera VoiceOver i Inställningar → Tillgänglighet → VoiceOver, eller använd accessibility shortcut genom att trycka sidknappen tre gånger. Lär dig de grundläggande VoiceOver-gesterna: svep höger/vänster för att navigera, dubbeltryck för att aktivera, två-finger scrolla för att scrollea.
Testa din app från början till slut med VoiceOver. Kan du logga in, navigera till huvudfunktionerna, utföra viktiga uppgifter och logga ut igen? Är varje steg logiskt och begripligt? Hörs informationen korrekt och i rätt ordning?
Simulator och riktiga enheter
Xcode Simulator har VoiceOver och andra tillgänglighetsfunktioner, vilket gör det enkelt att testa under utvecklingen. Men simulatorn fungerar inte alltid exakt som riktiga enheter, särskilt för gester och prestanda.
Testa alltid på fysiska enheter också, helst flera olika modeller och iOS-versioner. En app som fungerar perfekt på iPhone 15 Pro kan ha problem på en äldre iPhone SE med mindre skärm. Olika enheter har olika skärmstorlekar, prestanda och tillgänglighetsfunktioner.
Automatiserade UI-tester
XCTest kan användas för att skriva automatiserade tillgänglighetstester. Du kan verifiera att specifika accessibility labels finns, att fokusordning är korrekt och att viktiga element är tillgängliga.
Automatiserade tester fångar regressions – om någon av misstag tar bort en accessibility label eller bryter fokusordning kommer testet att misslyckas. Detta ger trygghet när du refaktorerar kod eller lägger till nya funktioner.
Vanliga tillgänglighetsutmaningar på iOS
Även erfarna iOS-utvecklare stöter på återkommande tillgänglighetsutmaningar. Här är några av de vanligaste problemen och hur du löser dem.
Custom controls utan accessibility
När du bygger custom UI-komponenter är det lätt att glömma tillgänglighet. En custom knapp som bara är en UIView med en tap gesture recognizer kommer inte fungera med VoiceOver utan explicit accessibility-implementation.
Lösningen är att alltid sätta isAccessibilityElement = true, definiera accessibilityLabel, accessibilityTraits och accessibilityHint. Implementera även accessibilityActivate() om komponenten kan aktiveras.
Bilder utan beskrivningar
Bilder som inte är rent dekorativa måste ha accessibility labels som beskriver innehållet. En produktbild i en e-handelsapp behöver en beskrivning som ”Blå t-shirt med vit text” inte bara ”produkt.jpg”.
Dekorativa bilder som bara är där för estetik ska markeras med isAccessibilityElement = false så VoiceOver hoppar över dem. Detta minskar onödigt brus för skärmläsaranvändare.
Komplex navigation som förvirrar VoiceOver
Tab bars, navigation controllers och modala dialoger kan skapa förvirrande upplevelser om de inte hanteras korrekt. VoiceOver-användare kan fastna i en vy, inte förstå var de är i navigeringshierarkin eller missa viktiga element.
Se till att fokus flyttas till rätt ställe när nya vyer presenteras. När en modal öppnas ska fokus gå till modalens första element. När den stängs ska fokus returnera till elementet som öppnade modalen. Använd UIAccessibility.post(notification: .screenChanged, argument: newView) för att guida fokus korrekt.
Dynamiskt innehåll som inte uppdaterar hjälpmedel
Om innehåll laddas asynkront eller uppdateras baserat på användarinteraktion måste VoiceOver meddelas. Nya meddelanden som bara dyker upp på skärmen kommer inte VoiceOver-användare att märka om de inte får en notification.
Använd .announcement notification för att läsa upp viktiga uppdateringar, och .layoutChanged när element läggs till eller tas bort från vyn. För live-uppdaterande innehåll som timers eller räknare, använd accessibility traits .updatesFrequently eller .causesPageTurn beroende på typ av uppdatering.
Textfält utan tydliga labels
Textfält måste ha tydliga labels som förklarar vad användaren ska fylla i. Att bara ha placeholder-text är inte tillräckligt eftersom den försvinner när användaren börjar skriva.
Använd UILabel ovanför textfältet eller sätt accessibilityLabel explicit på UITextField. För formulär är det bra att även inkludera om fältet är obligatoriskt och vilket format som förväntas.
Kom igång med tillgänglighet i dina iOS-appar
Att bygga tillgängliga iOS-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 standardkomponenter och HIG
Om du är ny på iOS-tillgänglighet är det bästa sättet att börja att använda UIKit och SwiftUI standardkomponenter och följa Human Interface Guidelines noga. Dessa komponenter har redan mycket av tillgängligheten implementerad.
Läs Apples officiella dokumentation om accessibility och gå igenom WWDC-sessions om ämnet. Apple uppdaterar sina riktlinjer regelbundet med nya best practices och tekniker.
Testa med VoiceOver från dag ett
Vänta inte tills appen är ”färdig” för att börja testa med VoiceOver. Aktivera VoiceOver och testa varje ny vy och funktion 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 de vanligaste VoiceOver-gesterna och använd dem dagligen. Ju mer bekväm du blir med VoiceOver desto snabbare kan du identifiera och lösa problem.
Integrera accessibility audits i din workflow
Använd Accessibility Inspector regelbundet för att köra audits på din app. Åtgärda warnings och errors innan du mergar kod. Överväg att lägga till automatiserade accessibility-tester i din CI/CD-pipeline.
Involvera användare med funktionsnedsättningar
Om möjligt, testa din app med verkliga användare som är beroende av hjälpmedel. Deras feedback är ovärderlig och avslöjar ofta problem som ingen automatiserad process eller utvecklare kan hitta.
Det kan vara användare med synnedsättningar som använder VoiceOver, personer med motoriska begränsningar som använder Switch Control, eller användare med kognitiva funktionsnedsättningar som behöver enklare gränssnitt.
Fördjupning och nästa steg
Nu när du har fått en översikt över iOS-tillgänglighet kan du fördjupa dig i specifika områden:
VoiceOver på Mac OS och VoiceOver på IOS: Lär dig allt om att testa och optimera för VoiceOver, Apples skärmläsare.
UIAccessibility API för utvecklare: Teknisk fördjupning i hur du implementerar tillgänglighet i kod.
Design tillgängliga iOS-appar: Riktlinjer för designers om färg, typografi, layout och interaktionsmönster.
Testverktyg för iOS: Komplett guide till Accessibility Inspector, automatiserade tester och manuella testmetoder.