Innehållsförteckning
Tillgänglig design handlar inte bara om att följa regler – det handlar om att skapa appar som fungerar för alla. Här får du praktisk vägledning för designers om färg, typografi, layout och interaktionsmönster som gör iOS-appar tillgängliga enligt LPTT.
Human Interface Guidelines som grund
Apples Human Interface Guidelines (HIG) är utgångspunkten för all iOS-design. Att följa HIG ger dig inte bara en app som känns native och professionell, utan också en solid grund för tillgänglighet. Apple har byggt in tillgänglighetsprinciper direkt i sina designriktlinjer, vilket betyder att god iOS-design naturligt leder till bättre tillgänglighet.
Designa med systemkomponenter
iOS erbjuder ett omfattande bibliotek av designkomponenter – knappar, textfält, segmented controls, pickers och mycket mer. Dessa komponenter är inte bara visuellt konsekventa utan har också inbyggd tillgänglighetsfunktionalitet. När du använder standard iOS-komponenter i dina designer får utvecklare rätt beteende gratis.
Custom komponenter kan se vackra ut, men de kräver betydligt mer arbete för att bli lika tillgängliga som standardkomponenterna. Innan du designar en helt ny typ av kontroll, fundera på om du kan uppnå samma mål med befintliga komponenter stylad på ditt sätt. En custom-designad knapp kan behålla UIButtons struktur och accessibility samtidigt som den får ditt varumärkes utseende.
Konsekvens skapar förståelse
Användare lär sig hur iOS fungerar genom att använda många olika appar. När din app beter sig annorlunda än förväntningar skapar det förvirring, särskilt för användare som förlitar sig på hjälpmedel. En knapp ska se ut som en knapp och bete sig som en knapp. Navigation ska fungera som användare förväntar sig.
Detta betyder inte att alla appar måste se identiska ut, men grundläggande interaktionsmönster ska vara bekanta. Tillbaka-knappen i navigationsfältet ska alltid finnas där användare förväntar sig den. Modala vyer ska kunna stängas på standardsätt. Tab bars ska fungera konsekvent.
Färg och kontrast
Färgval påverkar tillgängligheten enormt. Många användare har synnedsättningar, färgblindhet eller använder sin enhet i utmanande ljusförhållanden. Din färgpalett måste fungera för alla dessa situationer.
Kontrastkrav enligt WCAG 2.1 AA
LPPT kräver att appar följer WCAG 2.1 nivå AA, vilket innebär specifika kontrastkrav. Normal text (under 18 punkter eller 14 punkter fet) måste ha minst 4,5:1 kontrast mot bakgrunden. Större text (18 punkter eller större, eller 14 punkter fet eller större) behöver minst 3:1 kontrast.
För interaktiva komponenter som knappar och ikoner krävs 3:1 kontrast mot intilliggande färger. Detta gäller även fokusindikatorer och viktiga grafiska element.
Testa dina färgval tidigt i designprocessen. Det är mycket lättare att justera färgpaletten innan hela designsystemet är byggt än att behöva ändra hundratals skärmar senare. Verktyg som Stark plugin för Figma eller Color Contrast Analyzer kan hjälpa dig validera kontrast direkt medan du designar.
Färgblindhet och färganvändning
Cirka åtta procent av män och en halv procent av kvinnor har någon form av färgblindhet, med röd-grön färgblindhet som vanligast. Detta betyder att du aldrig kan förlita dig på enbart färg för att förmedla information.
Om felmeddelanden är röda måste det även finnas en ikon eller text som tydligt säger ”fel”. Om status visas med grönt/rött/gult ljus måste varje tillstånd även ha en textbeskrivning eller unik ikon. Grafer och diagram måste använda mönster eller former utöver färg för att skilja olika dataserier.
iOS har inbyggda färgblindhetssimulationer som du kan aktivera i Accessibility-inställningar under Display & Text Size → Color Filters. Testa din app med olika filter för att se hur färgblinda användare upplever den. Om viktiga distinktioner försvinner, omarbeta designen.
Stöd för Dark Mode
Dark Mode är inte bara en estetisk preferens – många användare med ljuskänslighet eller vissa synnedsättningar är beroende av det. Din app måste fungera lika bra i båda lägen, och övergången mellan dem ska vara sömlös.
Designa med semantiska färger istället för hårdkodade värden. Definiera ”Primary Background”, ”Secondary Text” och ”Accent Color” som kan ha olika värden i ljust och mörkt läge. iOS system colors anpassar sig automatiskt, så använd dem där det är möjligt.
Kontrast kan vara mer utmanande i Dark Mode eftersom många färger behöver justeras för att behålla läsbarhet mot mörk bakgrund. En blå som fungerar perfekt mot vit bakgrund kan behöva bli ljusare för att fungera mot svart. Testa alltid båda lägena.
Increased Contrast mode
Utöver standard ljust och mörkt läge måste din app även fungera när användare aktiverar Increased Contrast i accessibility-inställningar. Detta förstärker kontraster ytterligare för personer med nedsatt syn.
I Increased Contrast mode kan systemfärger ändras för att möta högre kontrastkrav. Dina custom färger måste också ha alternativ för detta läge. Många designers skapar tre versioner av sin färgpalett: ljus, mörk och increased contrast för vardera.
Typografi och Dynamic Type
Text är fundamentalt för nästan alla appar, och hur du hanterar typografi påverkar tillgängligheten drastiskt. iOS Dynamic Type är systemet för att ge användare kontroll över textstorlek, och din app måste stödja det fullt ut.
Text Styles och skalning
iOS erbjuder föredefinierade text styles som Title, Headline, Body, Caption och flera andra. Dessa styles skalar automatiskt när användaren ändrar sin prefererade textstorlek i systeminställningar. Använd alltid dessa styles istället för hårdkodade punktstorlekar.
När du designar i Figma eller Sketch, definiera dina text styles motsvarande iOS text styles. Headline är inte bara ”20pt SF Pro Bold” – det är en semantisk definition som kan vara 20pt för en användare men 34pt för en annan beroende på deras inställningar.
Dynamic Type skalar inte bara texten utan kan påverka hela layouten. En knapp med texten ”Fortsätt” kan vara smal vid normal textstorlek men behöva bli mycket bredare vid maximal skalning. Planera för detta i dina designer.
Läsbarhet och radavstånd
Textstorlek är bara en del av läsbarhet. Radavstånd (line height), teckenavstånd (letter spacing) och radlängd påverkar också hur lätt text är att läsa. iOS hanterar mycket av detta automatiskt för standard text styles, men om du customizar typografi måste du tänka på detta.
Långa textrader är svåra att läsa. Optimal radlängd är cirka 50-75 tecken. På iPhone betyder detta att body text sällan ska sträcka sig helt från kant till kant – använd padding för att hålla rader på en bekväm längd.
Radavstånd ska öka proportionellt med textstorlek. Text vid Accessibility size XXXL behöver mer luft mellan rader än text vid normal storlek. iOS text styles hanterar detta, men custom typografi måste göra det manuellt.
Viktiga textelement och hierarki
Visuell hierarki hjälper användare förstå strukturen i ditt innehåll. Rubriker ska vara tydligt större och fetare än body text. Viktiga element ska sticka ut. Men denna hierarki måste också fungera när texten skalas.
Vid större textstorlekar kan skillnaden mellan nivåer bli enorm. En H1 som är dubbelt så stor som body text vid normal storlek kan bli tre-fyra gånger så stor vid accessibility sizes. Se till att layouten kan hantera detta utan att gå sönder.
Färg ensam räcker inte för att skapa hierarki – det måste finnas storlek- och viktskillnader också. Detta hjälper färgblinda användare och de som använder skärmläsare som kommunicerar strukturnivåer verbalt.
Truncation och multi-line text
När text inte får plats finns två alternativ: trunkera med ellipsis (…) eller låt den bryta till flera rader. Välj strategin baserat på kontext och hur kritisk informationen är.
Knappar med långa texter bör oftast bryta till flera rader vid större textstorlekar istället för att trunkera, eftersom användare måste förstå vad knappen gör. Navigation titles kan trunkeras eftersom användare redan vet var de är. Men kritisk information som felmeddelanden eller produkt-beskrivningar får aldrig trunkeras.
Designa alltid med extremfall i åtanke. Vad händer med din layout om en produkt har ett namn på 80 tecken och användaren har maximal textstorlek? Din design måste ha en plan för detta.
Touch Targets och interaktiva element
Storlek och placering av interaktiva element är avgörande för tillgänglighet, särskilt för användare med motoriska begränsningar eller nedsatt syn.
Minsta touch target-storlek
Apple rekommenderar minst 44×44 punkter 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.
44 punkter är den fysiska storleken på ett fingertopp, vilket gör det möjligt för de flesta att träffa element utan precision. För användare med darrningar, begränsad motorik eller som använder appen enhänt är större mål ännu bättre. Sikta på 48-50 punkter där det är möjligt.
Den visuella storleken behöver inte vara 44×44 punkter – det är den interaktiva ytan som räknas. En 24×24 punkter ikon kan ha 44×44 punkter klickbart område genom padding. Men var försiktig med detta för tydlighetens skull är det ofta bättre om det visuella och interaktiva matchar.
Avstånd mellan touch targets
Knappar som ligger för nära varandra skapar frustration när användare av misstag trycker på fel element. Minst 8 punkters avstånd mellan klickbara element rekommenderas, men 16-24 punkter är bättre för viktigare actions.
Detta blir särskilt kritiskt i täta gränssnitt som tabeller eller formulär. Om varje rad i en tabell har en radera-knapp måste dessa knappar ha tillräckligt avstånd vertikalt för att användare inte råkar ta bort fel rad. Överväg att placera destruktiva actions bakom en swipe-gest eller bekräftelsedialog istället.
Öka target-storlek vid viktiga actions
Primära knappar och ofta använda kontroller kan och bör vara större än minimikravet. En ”Köp nu”-knapp i en e-handelsapp kan vara 56 eller 60 punkter hög, vilket både gör den lättare att träffa och visuellt betonar dess betydelse.
Destruktiva actions som ”Radera konto” eller ”Avbryt” bör däremot inte göras extra stora – gör dem tillräckligt stora för tillgänglighet men inte så stora att de uppmuntrar oavsiktliga klick.
Placering och ergonomi
Tänk på var på skärmen element placeras. På större iPhones är övre hörnen svåra att nå med en hand. Placera viktiga, ofta använda kontroller inom ”thumb zone” – det område som är lätt att nå med tummen när man håller telefonen i en hand.
Tab bars längst ner är perfekta för ofta använda navigationsknappar. Floating action buttons i nedre högra hörnet funkar för primära actions. Viktigare är att destruktiva eller mindre viktiga knappar placeras längre bort från den bekväma zonen.
Layout och anpassning
En app som bara fungerar i ett fast layout vid en specifik textstorlek är inte tillgänglig. Din design måste vara flexibel och anpassa sig efter användarens behov.
Responsiv layout för olika skärmstorlekar
iPhones finns i många storlekar från iPhone SE:s 4,7 tum till iPhone Pro Max:s 6,7 tum. Din design måste fungera på alla. Men det räcker inte att bara skala – du kan behöva ändra layout fundamentalt mellan storlekar.
På mindre skärmar kan horisontella rader av knappar behöva bli vertikala staplar. Sidopaneler kan behöva döljas bakom menyer. Innehåll som visas i två spalter på större enheter kan behöva bli en spalt på mindre.
Använd Apples size classes (Compact, Regular) för att definiera olika layouter för olika skärmstorlekar. Designa explicit för minst tre breakpoints: iPhone SE (liten skärm), standard iPhone (medium) och iPhone Pro Max (stor).
Hantera textökning och layout-kollaps
När användare ökar textstorlek måste layouten anpassa sig, men det finns gränser för hur mycket du kan trycka in på en liten skärm. Vid de allra största textstorlekarna (Accessibility sizes) måste du ofta göra radikala layoutändringar.
Horisontella toolbar-knappar med text kan behöva förlora sina texter och bara visa ikoner vid stora textstorlekar, med labels tillgängliga via långtryck. Komplex information som tabeller kan behöva förenklas eller reorganiseras helt. Sök inspiration i hur Apple’s egna appar hanterar extrema textstorlekar.
Testa alltid dina designer med textstorlek satt till maximum. Går layouten sönder? Försvinner information? Blir knappar oåtkomliga? Dessa problem måste lösas i designfasen, inte som efterkonstruktioner.
Scrolling och viewport-höjd
Innehåll som inte får plats vertikalt måste kunna scrollas. Detta låter självklart men många designer glömmer att kontrollera att scrolling faktiskt fungerar i alla scenarios, särskilt när tangentbord är synligt eller vid stora textstorlekar.
När tangentbordet visas för textinmatning minskar tillgänglig skärmhöjd dramatiskt. Se till att formulär kan scrollas så användare når alla fält även när tangentbordet tar halva skärmen. Det aktiva fältet ska scrollas till synligt område automatiskt.
Modal dialoger och popups måste också kunna scrollas om deras innehåll blir för långt vid större textstorlekar. En ”Terms of Service”-dialog som är tre skärmlängder lång måste ha tydliga scrollindikatorer.
Landscape och portrait orientations
Om din app stödjer både landscape och portrait måste all funktionalitet vara tillgänglig i båda orienteringarna. Vissa användare med hjälpmedel kan vara begränsade till en specifik orientering.
Layout i landscape mode är fundamentalt annorlunda än portrait. Du har mer horisontellt utrymme men mindre vertikalt. Tab bars flyttas ofta till sidan, navigation stacks kan visa master-detail layouts, och content kan visas i flera kolumner.
Designa explicit för landscape mode – anta inte att portrait-layouten bara kan roteras. Testa på faktiska enheter i båda orienteringar för att verifiera att allt fungerar.
Visuell feedback och states
Användare måste få omedelbar, tydlig feedback på sina interaktioner. Detta gäller alla användare men är särskilt kritiskt för de med synnedsättningar eller kognitiva funktionsnedsättningar.
Knapptillstånd och hover effects
Även om iOS inte har mus-hover som desktop, finns det fortfarande states som måste designas: normal, pressed, disabled och selected. Varje state måste vara visuellt distinkt.
En pressed state ska ge omedelbar feedback när användaren trycker på en knapp. Detta kan vara en färgändring, shadow-effekt eller subtle animation. Feedback ska komma inom millisekunder av touchet – försening skapar osäkerhet.
Disabled states måste vara tydliga men fortfarande läsbara. Ofta görs disabled-knappar för ljusa, vilket gör texten oläslig. Sikta på minst 3:1 kontrast även för disabled elements så användare förstår vad knappen gör även om de inte kan trycka på den just nu.
Fokusindikatorer
När användare navigerar med tangentbord, Switch Control eller andra alternativa input-metoder måste de kunna se vilket element som har fokus. Fokusindikatorer måste vara tydliga och ha tillräcklig kontrast mot både elementet och bakgrunden.
Standard iOS fokusindikatorer fungerar ofta bra, men om du har mörka element mot mörk bakgrund kan de behöva förstärkas. En blå outline kan behöva bli vit eller ha en extra shadow för att synas tydligt.
Fokusindikatorn ska röra sig logiskt genom gränssnittet i en ordning som matchar visuell och logisk struktur. Användare ska inte behöva hoppa fram och tillbaka över skärmen på oförutsägbara sätt.
Loading states och progress
Långsamma operationer måste kommuniceras tydligt. Användare behöver veta att något händer och hur lång tid det kan ta. Detta är särskilt viktigt för kognitiv tillgänglighet – osäkerhet skapar stress.
För operationer under ett par sekunder räcker en spinner. För längre operationer behövs en progress bar med procent eller tidsuppskattning. För mycket långa operationer (över 30 sekunder) överväg att låta användaren göra något annat medan de väntar.
Errors måste kommuniceras tydligt med både visuella indikatorer och text som förklarar vad som gick fel och hur användaren kan åtgärda det. En röd bakgrund ensam är inte tillräckligt – berätta vad problemet är.
Ikoner och symboler
Ikoner kan göra gränssnitt mer intuitivt och kompakt, men de måste användas korrekt för att inte skapa förvirring.
SF Symbols och konsekvens
Apple’s SF Symbols är ett omfattande bibliotek av ikoner designade specifikt för iOS. De skalar automatiskt med text, stödjer olika vikter och är optimerade för alla skärmstorlekar. Använd dem där det är möjligt.
SF Symbols har också accessibility-versioner med förenklad design som är lättare att känna igen vid små storlekar eller för användare med synnedsättningar. Systemet väljer automatiskt rätt variant baserat på kontext.
Custom ikoner ska följa samma designprinciper som SF Symbols: enkla, tydliga former utan onödiga detaljer. En ikon ska vara igenkännbar även vid 20×20 punkter. Testa dina ikoner vid olika storlekar och med blur-filter för att simulera nedsatt syn.
Ikoner utan text
Ikoner utan medföljande text är riskabla eftersom deras betydelse kan vara oklar, särskilt för nya användare eller personer från andra kulturer. När du måste använda ikoner utan text, välj universellt förstådda symboler.
En hamburger-meny (tre horisontella linjer) är relativt väl förstådd nu, men en ikon för ”dela” kan vara en upp-pil, tre sammankopplade punkter eller något helt annat beroende på plattform och kontext. Överväg att alltid ha text under ikoner i navigation-elements som tab bars.
För toolbar-ikoner utan text, använd tooltips eller long-press för att visa labels. Detta hjälper nya användare lära sig vad ikoner betyder utan att permanent ta upp plats med text.
Färg i ikoner
Ikoner som använder färg för att förmedla betydelse måste också ha form- eller text-skillnader. En röd varnings-ikon måste ha en distinkt form (som en triangel med utropstecken) som skiljer den från en grön bekräftelse-ikon även när färg saknas.
Monokroma ikoner är ofta säkrare än färgglada eftersom de inte förlitar sig på färg för betydelse. Men de måste fortfarande ha tillräcklig kontrast mot bakgrunden – minst 3:1 enligt WCAG.
Formulär och input
Formulär är ofta den viktigaste delen av appar omfattade av LPTT – e-handel, bank, bokningar kräver alla användarinput. Dåligt designade formulär kan göra dessa tjänster fullständigt oanvändbara.
Labels och placeholder text
Varje input-fält måste ha en tydlig, permanent synlig label som förklarar vad användaren ska fylla i. Placeholder text som ”Ange din e-post” räcker inte eftersom den försvinner när användaren börjar skriva.
Labels ska placeras ovanför fält, inte till vänster. Detta fungerar bättre vid olika skärmstorlekar och textskalningar. Vänster-placerade labels kan tvingas till flera rader eller trunkeras vid större textstorlekar.
För komplexa fält, ge extra instruktioner eller exempel under labeln. ”Födelsedatum” är en label, men ”Format: YYYY-MM-DD” hjälper användaren ge rätt input från start.
Felhantering och validation
Felmeddelanden måste vara specifika, hjälpsamma och visuellt tydliga. ”Ogiltigt format” är för vagt – ”E-postadressen måste innehålla @” är mycket bättre.
Visa fel i direkt anslutning till det fel fältet, inte bara överst i formuläret. Användare med stora textstorlekar eller skärmläsare kanske inte ser eller hör fel som är långt från där de förekommer.
Använd inte bara röd färg för att markera fel – lägg till en ikon (som ett utropstecken i triangel) och tydlig feltext. Detta hjälper färgblinda användare och de som använder skärmläsare.
Gruppering och progression
Långa formulär ska delas upp i logiska sektioner med tydliga rubriker. Detta hjälper alla användare men är särskilt värdefullt för kognitiv tillgänglighet och skärmläsaranvändare som navigerar via rubriker.
Progress indicators för multi-step formulär är viktiga. Användare behöver veta att de är på steg 2 av 4, inte undra hur mycket längre de måste fylla i. Visuella progress bars ska kompletteras med text som ”Steg 2 av 4: Leveransinformation”.
Gruppera relaterade fält visuellt med whitespace eller subtle bakgrunder. ”Kontaktinformation” ska vara tydligt separerad från ”Betalningsinformation”.
Autofill och hjälp
Stöd för iOS autofill gör formulär mycket snabbare att fylla i och minskar fel. Använd rätt content types för fält (emailAddress, telephoneNumber, postalCode) så systemet kan erbjuda autofill.
För känsliga fält som lösenord eller kreditkort, berätta tydligt varför informationen behövs och hur den skyddas. ”Ditt lösenord lagras krypterat och delas aldrig med tredje part” ger trygghet.
Hjälp-ikoner eller info-bubblor kan förklara komplexa fält, men de måste vara tillgängliga för skärmläsare och inte bara synliga vid hover (som inte finns på touch-enheter). Använd long-press eller separat info-knapp.