Färgkontrast: bortom grunderna
4,5:1 är golvet, inte målet. Förstå varför kontrastkraven finns, vad non-text contrast innebär och hur APCA förändrar spelplanen.
De flesta utvecklare och designers vet att text behöver tillräcklig kontrast mot sin bakgrund. WCAG 2.2 sätter gränsen vid 4,5:1 för normal text, och de flesta kontrastverktyg ger ett grönt eller rött ljus baserat på den siffran. Men kontrast handlar om mer än att klara ett tal. Det handlar om hur en människa faktiskt uppfattar text på en skärm, i en viss storlek, i ett visst typsnitt, i solljus på en buss. Och där börjar det bli intressant.
Vad kontrastkraven faktiskt säger
WCAG 2.2 innehåller tre kriterier som rör kontrast, och de täcker olika saker.
Kriterium 1.4.3, Contrast Minimum, kräver minst 4,5:1 för normal text och 3:1 för stor text. Stor text definieras som minst 18 punkter (pt) i normal vikt eller 14 punkter i fetstil. En viktig detalj: WCAG anger storleken i punkter, inte pixlar. 18pt motsvarar ungefär 24px på de flesta skärmar, inte 18px. Det är en teknisk fälla som många utvecklare går i, och resultatet är att text som ser tillräckligt stor ut i CSS inte nödvändigtvis kvalificerar som “stor text” enligt WCAG. Det här är nivå AA och det krav som de flesta tillgänglighetslagar, inklusive EAA, refererar till.
Kriterium 1.4.6, Contrast Enhanced, höjer ribban till 7:1 för normal text och 4,5:1 för stor text. Det är nivå AAA och inte ett juridiskt krav i de flesta sammanhang, men ett mål som gör stor skillnad för personer med måttlig synnedsättning.
Kriterium 1.4.11, Non-text Contrast, utvidgar kontrastkraven bortom text. Gränssnittskomponenter och grafiska objekt som bär information ska ha minst 3:1 kontrast mot angränsande färger. Det gäller saker som formulärfält, knappar, ikoner och diagramlinjer. Det gäller också de olika tillstånden hos en komponent: en checkbox som ändrar utseende vid hover eller fokus måste uppfylla 3:1 i varje tillstånd.
Varför 4,5:1 inte alltid räcker
Kontrastförhållandet 4,5:1 är ett minimum, inte ett mål. W3C valde siffran för att kompensera för måttligt nedsatt synskärpa, men den tar inte hänsyn till allt som påverkar läsbarhet i verkligheten.
Typsnittets vikt spelar roll. En tunn font, exempelvis 300 i vikt, behöver högre kontrast än en normal eller halvfet font för att vara lika läsbar. Tecknen är smalare, linjerna tunnare, och det finns helt enkelt mindre yta som kontrasterar mot bakgrunden. En text som tekniskt klarar 4,5:1 i en tunn font kan fortfarande vara ansträngande att läsa.
Omgivningen spelar roll. En person som läser på sin telefon i solljus förlorar en stor del av den upplevda kontrasten. Reflexer och ljusförhållanden minskar den faktiska kontrast som når ögat, och det är inget som kontrastkontrollverktyget i Figma kan simulera.
Ålder spelar roll. Kontrastkänsligheten minskar naturligt med åldern. En 60-åring behöver generellt högre kontrast än en 25-åring för att uppfatta samma text lika tydligt. WHO uppskattar att över 2,2 miljarder människor globalt lever med någon form av synnedsättning, och åldersrelaterade förändringar som grå starr och makuladegeneration är bland de vanligaste orsakerna.
Allt detta innebär att 4,5:1 är golvet. Att sikta på 7:1 eller högre för brödtext ger en marginal som gör texten robust i fler situationer och för fler användare.
Non-text contrast: det glömda kravet
Kriterium 1.4.11 kom med WCAG 2.1 och täcker allt som inte är text men ändå bär information. Det är här många sajter faller igenom, ofta för att det inte testas lika systematiskt som textkontrast.
Tänk dig ett formulär med inmatningsfält som enbart markeras med en tunn, ljusgrå kantlinje mot en vit bakgrund. Om den kantlinjen inte når 3:1 kontrast kan en användare med nedsatt syn missa att fältet finns. Samma sak gäller en knapp vars gräns smälter in i bakgrunden, eller ett linjediagram där en av linjerna har för lite kontrast mot diagrammets bakgrund.
Tillståndsförändringar hör också hit. Om en flik markeras som aktiv genom att dess textfärg ändras måste den nya färgen ha 3:1 kontrast mot den inaktiva färgen, eller så behöver det finnas en annan visuell indikator som inte enbart förlitar sig på färg. Hover-tillstånd och valda objekt i listor är andra exempel där non-text contrast ofta brister.
Fokusindikatorer förtjänar särskild uppmärksamhet. WCAG 2.2 introducerade kriterium 2.4.11, Focus Appearance, på nivå AA. Det nöjer sig inte med att fokusindikatorn har tillräcklig kontrast. Indikatorn måste också ha en tillräcklig area: minst lika stor som en 2px tjock ram runt hela elementet. En tunn 1px-linje runt en knapp kan alltså uppfylla kontrastkraven men ändå underkännas för att den är för smal. Det är en skärpning som tvingar designers att tänka på fokusindikatorer som ett riktigt designelement, inte bara en teknisk detalj som hanteras med outline: 1px solid blue.
APCA: nästa generations kontrastmätning
WCAG 2:s kontrastformel baseras på relativ luminans och ger ett förhållande mellan förgrund och bakgrund. Den fungerar hyfsat för de flesta fall, men den har kända brister. Den behandlar ljus text på mörk bakgrund och mörk text på ljus bakgrund identiskt, trots att mänsklig perception fungerar annorlunda. Den tar inte hänsyn till typsnittets storlek eller vikt i själva beräkningen, utan hanterar det genom separata trösklar.
APCA, Accessible Perceptual Contrast Algorithm, är Andrew Somers alternativ som utvecklas för WCAG 3. I stället för ett förhållande ger APCA ett perceptuellt kontrastvärde (Lc) på en skala upp till ungefär 106. Resultatet beror på polarity, alltså om texten är ljus eller mörk jämfört med bakgrunden, och kan kopplas direkt till typsnittets storlek och vikt genom en uppslagstabell. Det innebär att samma färgkombination kan vara godkänd för en rubrik i 24 punkter men underkänd för brödtext i 14 punkter.
APCA hanterar också ett fenomen som WCAG 2:s formel missar helt: halation. Ljus text på en väldigt mörk bakgrund kan “blöda” visuellt, särskilt för personer med astigmatism, som utgör ungefär en tredjedel av befolkningen. Ren vit text (#FFFFFF) på kolsvart bakgrund (#000000) ger maximalt kontrastförhållande enligt WCAG 2, men kan vara svårare att läsa än ljusgrå text på mörkgrå bakgrund. Det är relevant för alla som bygger dark mode: att sänka kontrasten något, exempelvis #E0E0E0 på #1A1A1A i stället för vitt på svart, ger ofta en bekvämare läsupplevelse utan att tumma på tillgängligheten.
WCAG 3 är fortfarande under utveckling, och i det publicerade utkastet från 2025 ingår inte APCA som färdig standard ännu. Men verktyg som använder APCA finns redan tillgängliga, och flera designsystem har börjat använda det som komplement. Att testa sina färgval mot både WCAG 2:s formel och APCA ger en bättre bild av hur kontrasterna faktiskt upplevs.
Kontrast i praktiken: vad du kan göra i dag
Att testa kontrast tar sekunder med rätt verktyg. WebAIM Contrast Checker och Stark i Figma ger direkt svar på om en färgkombination klarar WCAG 2.2. Men verktygen testar bara de färger du matar in. De fångar inte kontrast som försvinner i kontexten: text ovanpå en bild, text som ändrar färg vid hover, eller fokusindikatorer som knappt syns mot en färgstark bakgrund.
En praktisk vana är att alltid definiera kontrastpar i sitt designsystem snarare än enskilda färger. I stället för att säga “vår primärfärg är #2563EB” säger man “vår primärfärg #2563EB ska alltid användas mot #FFFFFF eller #F8FAFC, aldrig mot #93C5FD”. Det gör kontrastbesluten till en del av systemet i stället för något varje designer och utvecklare behöver kontrollera manuellt varje gång.
Att bygga in kontrastkontroller i CI-pipelinen, exempelvis genom axe-core eller Lighthouse, fångar regressioner. Om någon ändrar en färgvariabel i designsystemet och kontrasten sjunker under tröskeln rapporterar testet det innan koden når produktion. Det är shift left tillämpad på kontrast: problemet upptäcks där det uppstår, inte tre månader senare i en tillgänglighetsrevision.