Så granskar du färgkontrast utan att installera något

Granskningar av färgkontrast behandlas ofta som en specialistuppgift inom tillgänglighet: öppna en designfil, installera ett tillägg, exportera skärmbilder, köra en rapport, diskutera varumärkesfärger. Det kan vara användbart, men det är inte där de flesta team bör börja.

För en produktionswebbplats görs den snabbaste tillförlitliga granskningen oftast i webbläsaren du redan har öppen. Moderna DevTools i webbläsare kan inspektera beräknade färger, visa kontrastförhållanden, synliggöra stilar för olika tillstånd och hjälpa dig testa de besvärliga fall som automatiserade rapporter missar.

Den här guiden utgår från att du inte installerar något. Inga webbläsartillägg. Inga designtillägg. Ingen betald granskningssvit. Bara sidan, webbläsaren och en enkel metod.

Kontrastreglerna du faktiskt behöver

För det mesta webbarbetet handlar WCAG-kontrast om några få tröskelvärden:

• Normal text: minst 4.5:1 kontrast mot bakgrunden.
• Stor text: minst 3:1. WCAG definierar detta som ungefär 24 CSS-pixlar, eller cirka 18,66 CSS-pixlar om texten är fet.
• UI-komponenter och grafiska objekt: minst 3:1 för meningsbärande avgränsningar, ikoner, tillstånd och delar av diagram som behövs för att förstå gränssnittet.
• Förhöjd kontrast: 7:1 för normal text och 4.5:1 för stor text om du siktar högre än basnivån.

Det finns undantag, till exempel inaktiva kontroller, dekorativa element och logotyper. Använd de undantagen sparsamt. ”Det är en del av varumärket” är inte ett undantag; det är en designbegränsning.

Kom också ihåg att kontrast bara är en del av tillgänglig färganvändning. Om ett rött felläge har tillräcklig kontrast men saknar text, ikonetikett eller programmatisk indikering kan det fortfarande bli ett hinder för användare som inte kan skilja rött från närliggande färger.

Börja med den renderade sidan, inte designfilen

Designfiler är användbara, men de innehåller inte alla verkliga variabler: CSS-åsidosättningar, opacitet, hovringstillstånd, webbläsarens typsnittsrendering, användarens zoom, mörkt läge, ärvda stilar, CMS-innehåll och marknadsföringsinbäddningar.

Granska sidan så som användarna får den.

Öppna sidan i en aktuell skrivbordswebbläsare. Chrome, Edge, Firefox och Safari har alla användbara inspektionsverktyg. De exakta etiketterna skiljer sig åt, men arbetsflödet är detsamma:

1. Högerklicka på texten eller UI-elementet.
2. Välj Inspect.
3. Hitta beräknad color och background-color.
4. Använd webbläsarens färgruta eller tillgänglighetspanel för att läsa av kontrastförhållandet.
5. Dokumentera godkänt, underkänt och osäkerhet.

I Chromium-baserade webbläsare visar färgväljaren ofta ett kontrastförhållande och WCAG-vägledning för godkänt/underkänt för text. Firefox DevTools visar också tillgänglighetsinformation och färgverktyg. Safaris Web Inspector kan visa beräknade stilar och tillgänglighetsinformation, även om arbetsflödet är något annorlunda.

Det viktiga är inte den specifika webbläsaren. Det viktiga är att läsa det beräknade resultatet, inte det värde som någon tror att komponenten använder.

Skapa först en liten granskningslista

Inspektera inte slumpmässig text tills du tröttnar. Gör en kort inventering av mönster:

• Brödtext mot huvudsidans bakgrund.
• Dämpad text, bildtexter, metadata och platshållare.
• Länkar i normalt läge samt vid hovring, besökt läge och fokus.
• Primära, sekundära och destruktiva knappar.
• Formuläretiketter, hjälptext, fel och framgångsmeddelanden.
• Navigationsobjekt, brödsmulor och flikar.
• Kort, märken, pills och taggar.
• Ikoner som förmedlar betydelse.
• Diagram, kartor, förloppsindikatorer och statusfärger.
• Text ovanpå bilder, video, gradienter eller genomskinliga överlägg.

Det räcker för att hitta de flesta brister på en typisk webbplats. Det håller också granskningen knuten till komponenter, inte enstaka pixlar.

Om din granskning omfattar knappar, kombinera kontrastkontrollen med grunderna i vår checklista för tillgängliga webbknappar. Kontrastproblem i knappar finns ofta bredvid saknade fokuslägen, otydliga etiketter eller trasigt tangentbordsbeteende.

Inspektera textkontrast i DevTools

För vanlig text på en enfärgad bakgrund kan webbläsaren vanligtvis beräkna kontrasten åt dig.

Inspektera elementet och leta efter egenskapen color. Öppna färgväljaren från färgrutan. Om webbläsaren kan fastställa bakgrunden visar den ett kontrastförhållande. Vissa verktyg ritar också en linje i färgväljaren som visar var färgen skulle klara 3:1, 4.5:1 eller 7:1.

När webbläsaren rapporterar ett fel, tro på det tills du kan bevisa motsatsen. När den rapporterar godkänt, använd ändå omdöme. Liten tunn text, skärmar av låg kvalitet, kraftig kantutjämning och röriga bakgrunder kan göra att text som tekniskt sett klarar kraven ändå känns svag.

En praktisk regel: om brödtext precis nätt och jämnt klarar 4.55:1, fira inte. Ge den mer marginal. Kontrastkrav är miniminivåer, inte idealmål.

Typografi spelar också roll. Ett större och tydligare typsystem minskar belastningen redan innan du börjar justera färger. Om sidan känns svårläst trots godkänd kontrast, se över radlängd, storlek, vikt och avstånd med ett bredare läsbarhetsperspektiv, till exempel den här praktiska guiden till läsbar typografi.

Kontrollera den verkliga bakgrunden, inklusive opacitet

Många kontrastmisstag uppstår eftersom den synliga bakgrunden inte är den deklarerade bakgrunden.

Vanliga fallgropar är:

• Text i ett halvtransparent kort.
• Text på en förälder med opacity applicerad.
• Överlägg som använder rgba() eller color-mix().
• Gradienter bakom rubriker.
• Bakgrundsbilder som varierar över textytan.
• Temavariabler som ändras i mörkt läge.

Om DevTools inte säkert kan beräkna kontrasten, identifiera de renderade förgrunds- och bakgrundsfärgerna manuellt. Använd panelen för beräknade stilar, stäng tillfälligt av lager eller provta den synliga färgen med den inbyggda färgväljaren om din webbläsare stöder det.

För text ovanpå bilder ska du inte provta den finaste delen av bilden. Provta den sämsta rimliga ytan bakom texten. Om bilden ändras genom CMS-uppladdningar, karuseller eller responsiva beskärningar är detta inte ett stabilt kontrastsystem. Lägg till ett tillförlitligt överlägg, en textskugga, en solid behållare eller en gradientbehandling som skyddar texten oavsett bild.

Ett bra system för bildöverlägg är tråkigt: samma överläggsstyrka, förutsägbar beskärningsyta, tillräcklig kontrast även med ljusa foton. Tråkigt är okej. Användarna försöker läsa.

Glöm inte tillstånden

Statiska skärmbilder missar många kontrastbrister. Granska interaktionstillstånd direkt i webbläsaren.

I DevTools, tvinga pseudoklasser som:

• :hover
• :focus
• :focus-visible
• :active
• :visited
• :disabled
• :checked
• :invalid

Inspektera sedan de beräknade färgerna igen.

Fokusindikatorer förtjänar särskild uppmärksamhet. WCAG 2.2 skärpte förväntningarna på fokusutseende, och en blekblå kontur på ett ljusgrått kort är fortfarande ett vanligt fel. Fokusindikatorn behöver tillräcklig kontrast mot intilliggande färger och tillräcklig yta för att märkas.

För inaktiverade kontroller har WCAG:s kontrastregler ett undantag för inaktiva komponenter. Det betyder inte att inaktiverade kontroller som standard bör vara oläsliga. Om det inaktiverade tillståndet förmedlar användbar information, gör det läsbart. Om det inte gör det, överväg om det alls bör finnas där.

Använd Lighthouse, men lägg inte ut omdömet på det

Webbläsargranskningar som Lighthouse kan snabbt fånga vissa kontrastbrister. Kör den inbyggda granskningen om din webbläsare erbjuder den, och behandla sedan resultaten som en startpunkt.

Automatiserade kontroller är bra på att hitta textnoder med uppenbara brister i beräknad kontrast. De är svagare på:

• Text inbäddad i bilder.
• Etiketter renderade i canvas.
• Kantfall i SVG.
• Brister som bara syns vid hovring.
• Fokusindikatorns kvalitet.
• Diagram där färgrelationer bär betydelse.
• Komponenter dolda bakom autentisering, menyer eller formulärsteg.

Om en rapport kommer tillbaka grön behöver du fortfarande inspektera representativa komponenter. Om en rapport kommer tillbaka röd, undvik panik och prioritera bristerna efter användarpåverkan. Samma princip gäller prestanda- och tillgänglighetsrapporter generellt: läs verktygets output som evidens, inte som en dom. Vi använder det synsättet i vår guide till att läsa en Lighthouse-rapport utan panik, och det fungerar lika bra här.

Granska även kontrast för icke-text

Text får mest uppmärksamhet, men WCAG omfattar också icke-textinnehåll som behövs för att förstå eller använda gränssnittet.

Kontrollera åtminstone dessa fall:

• Inmatningsfälts kanter mot sidbakgrunden.
• Konturer för kryssrutor och radioknappar.
• Växlingslägen.
• Knappar med endast ikon.
• Felikoner och varningssymboler.
• Diagramlinjer, staplar och etiketter.
• Förloppsindikatorer.
• Indikatorer för vald flik eller aktiv navigation.

Målet är vanligtvis 3:1 mot intilliggande färger. Till exempel kan en ljusgrå kant på ett inmatningsfält mot vit bakgrund vara nästan osynlig. Ett diagram med fem pastellfärgade linjer kan se elegant ut och ändå vara oanvändbart.

För diagram räcker kontrast inte i sig. Använd etiketter, mönster, linjestilar, direkt annotering eller avstånd så att informationen inte enbart beror på färg. Det hjälper färgblinda användare, användare med nedsatt syn, personer som tittar i bländande ljus och alla som läser en skärmbild i ett dokument.

Dokumentera fynd i ett format som utvecklare kan använda

En användbar kontrastgranskning säger inte ”vissa gråtoner underkänns”. Den identifierar komponenten, tillståndet, aktuella värden, förväntat tröskelvärde och föreslagen åtgärd.

Ett kompakt format fungerar bra:

| Komponent | Tillstånd | Förgrund | Bakgrund | Förhållande | Mål | Resultat | Föreslagen åtgärd | |---|---:|---:|---:|---:|---:|---|---| | Kortmetadata | Standard | #8A8F98 | #FFFFFF | 3.2:1 | 4.5:1 | Underkänd | Använd --color-text-muted-strong | | Primär knapp | Hovring | #FFFFFF | #2F6FEA | 4.8:1 | 4.5:1 | Godkänd | Behåll | | Inmatningskant | Standard | #D7DCE2 | #FFFFFF | 1.4:1 | 3:1 | Underkänd | Mörka kant-token |

Knyt åtgärder till designtokens om webbplatsen har sådana. Lappa inte tjugo enskilda komponenter om en svag token är det verkliga problemet.

Gör åtgärderna något starkare än miniminivån

Kontrastbrister är ofta lätta att åtgärda dåligt. Team justerar en färg tills kontrollverktyget säger 4.51:1 och går sedan vidare. Det lämnar ingen marginal för typsnittsrendering, transparens, webbläsarskillnader, teman, bildvariation eller framtida varumärkesändringar.

Föredra bekväma mål:

• Brödtext: närmare 7:1 när det är praktiskt möjligt.
• Dämpad text: fortfarande över 4.5:1 om det är verkligt innehåll.
• UI-kanter och ikoner: bekvämt över 3:1.
• Text ovanpå bilder: använd ett kontrollerat överlägg i stället för gissningar per bild.

Webben visas på billiga laptops, dämpade telefoner, ljusa trottoarer, tonade skärmar och åldrande displayer. Minimikrav är inte samma sak som bekväm läsning.

<!-- tool-cta:start -->

💡 Prova detta: När du kontrollerar kontrastpar som du har hämtat från DevTools hjälper Color Converter till att konvertera mellan hex, RGB och HSL så att värdena stämmer överens med dina granskningsanteckningar.

<!-- tool-cta:end -->

En checklista för kontrastgranskning utan installation

Använd den här ordningen när du behöver en snabb men trovärdig granskning:

1. Öppna produktionssidan i en modern webbläsare.
2. Lista de viktigaste mönstren för text, UI och tillstånd.
3. Inspektera beräknade förgrunds- och bakgrundsfärger i DevTools.
4. Använd den inbyggda färgväljaren eller tillgänglighetspanelen för att läsa av kontrast.
5. Tvinga tillstånden hover, focus, active, visited och invalid.
6. Kontrollera text ovanpå bilder och gradienter mot den sämsta rimliga bakgrunden.
7. Kontrollera UI-delar som inte är text mot kravet 3:1.
8. Kör en inbyggd automatiserad granskning som skyddsnät, inte som hela granskningen.
9. Dokumentera brister per komponent och token.
10. Åtgärda med marginal, inte genom att precis passera tröskeln.

Det räcker för att fånga majoriteten av kontrastproblem utan att lägga till ännu ett verktyg i din stack. Mer avancerade granskningar har fortfarande sin plats, särskilt för stora designsystem, reglerade produkter eller komplex datavisualisering. Men för många webbplatser ger webbläsaren redan den evidens du behöver. Det svåra är att vara tillräckligt systematisk för att använda den.