Sådan auditerer du farvekontrast uden at installere noget
En praktisk browser-først-arbejdsgang til at kontrollere tekst, knapper, fokustilstande, diagrammer og billedoverlays op mod WCAG-krav til kontrast.
Indholdsfortegnelse
- De kontrastregler, du faktisk har brug for
- Start med den renderede side, ikke designfilen
- Lav først en lille auditliste
- Inspicér tekstkontrast i DevTools
- Tjek den reelle baggrund, inklusive opacitet
- Glem ikke tilstande
- Brug Lighthouse, men outsource ikke din dømmekraft til det
- Auditér også ikke-tekstlig kontrast
- Registrér fund i et format, udviklere kan bruge
- Gør fixes lidt stærkere end minimum
- En no-install-tjekliste til kontrastaudit
Audits af farvekontrast bliver ofte behandlet som en specialiseret tilgængelighedsopgave: Åbn en designfil, installer et plugin, eksportér skærmbilleder, kør en rapport, diskutér brandfarver. Det kan være nyttigt, men det er ikke dér, de fleste teams bør starte.
For et produktionswebsite udføres den hurtigste pålidelige audit som regel i den browser, du allerede har åben. Moderne browser-DevTools kan inspicere beregnede farver, vise kontrastforhold, afsløre styles for tilstande og hjælpe dig med at teste de besværlige tilfælde, som automatiserede rapporter overser.
Denne guide antager, at du ikke installerer noget. Ingen browserudvidelser. Ingen designplugins. Ingen betalt auditpakke. Kun siden, browseren og en enkel metode.
De kontrastregler, du faktisk har brug for
For det meste webarbejde handler WCAG-kontrast om nogle få grænseværdier:
- Normal tekst: mindst 4.5:1 kontrast mod baggrunden.
- Stor tekst: mindst 3:1. WCAG definerer dette som omtrent 24 CSS-pixels, eller cirka 18,66 CSS-pixels hvis teksten er fed.
- UI-komponenter og grafiske objekter: mindst 3:1 for meningsbærende afgrænsninger, ikoner, tilstande og dele af diagrammer, der er nødvendige for at forstå interfacet.
- Forbedret kontrast: 7:1 for normal tekst og 4.5:1 for stor tekst, hvis du sigter højere end baseline.
Der er undtagelser, såsom inaktive kontroller, dekorative elementer og logoer. Brug disse undtagelser sparsomt. “Det er en del af brandet” er ikke en undtagelse; det er en designbegrænsning.
Husk også, at kontrast kun er én del af tilgængelig farvebrug. Hvis en rød fejltilstand har tilstrækkelig kontrast, men ingen tekst, ikonlabel eller programmatisk angivelse, kan den stadig svigte brugere, der ikke kan skelne rød fra nærliggende farver.
Start med den renderede side, ikke designfilen
Designfiler er nyttige, men de indeholder ikke alle virkelighedens variabler: CSS-overrides, opacitet, hover-tilstande, browserens skriftrendering, brugerzoom, dark mode, nedarvede styles, CMS-indhold og marketing-embeds.
Auditér siden, som brugerne modtager den.
Åbn siden i en aktuel desktopbrowser. Chrome, Edge, Firefox og Safari har alle nyttige inspektionsværktøjer. De præcise labels varierer, men arbejdsgangen er den samme:
- Højreklik på teksten eller UI-elementet.
- Vælg Inspect.
- Find den beregnede
colorogbackground-color. - Brug browserens farveprøve eller accessibility-panel til at aflæse kontrastforholdet.
- Registrér bestået, fejlet og usikkerhed.
I Chromium-baserede browsere viser farvevælgeren ofte et kontrastforhold og WCAG-vejledning om bestået/fejlet for tekst. Firefox DevTools viser også tilgængelighedsoplysninger og farveværktøjer. Safari’s Web Inspector kan vise beregnede styles og tilgængelighedsoplysninger, selv om arbejdsgangen er lidt anderledes.
Det afgørende er ikke den konkrete browser. Det afgørende er at aflæse det beregnede resultat, ikke den værdi, nogen mener, komponenten bruger.
Lav først en lille auditliste
Inspicér ikke tilfældig tekst, indtil du bliver træt. Lav en kort oversigt over mønstre:
- Brødtekst på sidens primære baggrund.
- Nedtonet tekst, billedtekster, metadata og placeholders.
- Links i normal-, hover-, visited- og focus-tilstande.
- Primære, sekundære og destruktive knapper.
- Formularlabels, hjælpetekst, fejl og succesbeskeder.
- Navigationselementer, breadcrumbs og faner.
- Kort, badges, pills og tags.
- Ikoner, der kommunikerer betydning.
- Diagrammer, kort, progress bars og statusfarver.
- Tekst over billeder, video, gradienter eller gennemsigtige overlays.
Det er nok til at finde de fleste fejl på et typisk site. Det holder også auditten knyttet til komponenter, ikke enkeltstående pixels.
Hvis din audit omfatter knapper, så kombinér kontrasttjekket med grundpunkterne i vores tjekliste for tilgængelige webknapper. Kontrastproblemer i knapper ligger ofte side om side med manglende fokustilstande, uklare labels eller ødelagt tastaturadfærd.
Inspicér tekstkontrast i DevTools
For almindelig tekst på en ensfarvet baggrund kan browseren som regel beregne kontrasten for dig.
Inspicér elementet, og find egenskaben color. Åbn farvevælgeren fra farveprøven. Hvis browseren kan fastslå baggrunden, viser den et kontrastforhold. Nogle værktøjer tegner også en linje i farvevælgeren, der viser, hvor farven ville bestå 3:1, 4.5:1 eller 7:1.
Når browseren rapporterer en fejl, så tro på den, indtil du kan bevise noget andet. Når den rapporterer bestået, så brug stadig dømmekraft. Lille, tynd skrift, skærme af lav kvalitet, kraftig anti-aliasing og urolige baggrunde kan få tekst, der teknisk set består, til at føles svag.
En praktisk regel: Hvis brødtekst kun lige akkurat består ved 4.55:1, er der ikke noget at fejre. Giv den mere luft. Kontrastkrav er minimumskrav, ikke ideelle mål.
Typografi betyder også noget. Et større og klarere typesystem reducerer belastningen, før du overhovedet justerer farver. Hvis siden føles svær at læse på trods af bestået kontrast, så genbesøg linjelængde, størrelse, vægt og afstand med et bredere læsbarhedsblik som i denne praktiske guide til læsbar typografi.
Tjek den reelle baggrund, inklusive opacitet
Mange kontrastfejl opstår, fordi den synlige baggrund ikke er den deklarerede baggrund.
Almindelige fælder omfatter:
- Tekst inde i et semitransparent kort.
- Tekst på en parent med
opacityanvendt. - Overlays, der bruger
rgba()ellercolor-mix(). - Gradienter bag overskrifter.
- Baggrundsbilleder, der varierer på tværs af tekstområdet.
- Theme-variabler, der ændrer sig i dark mode.
Hvis DevTools ikke sikkert kan beregne kontrasten, så identificér de renderede forgrunds- og baggrundsfarver manuelt. Brug panelet med beregnede styles, deaktivér lag midlertidigt, eller sample den synlige farve med den indbyggede farvevælger, hvis din browser understøtter det.
For tekst over billeder skal du ikke sample den pæneste del af billedet. Sample det værst tænkelige plausible område bag teksten. Hvis billedet ændrer sig via CMS-uploads, karruseller eller responsive beskæringer, er det ikke et stabilt kontrastsystem. Tilføj et pålideligt overlay, en tekstskygge, en solid container eller en gradientbehandling, der beskytter teksten uanset billedet.
Et godt system til billedoverlays er kedeligt: samme overlaystyrke, forudsigeligt beskæringsområde, nok kontrast selv med lyse fotos. Kedeligt er fint. Brugerne prøver at læse.
Glem ikke tilstande
Statiske skærmbilleder overser mange kontrastfejl. Auditér interaktionstilstande direkte i browseren.
I DevTools kan du fremtvinge pseudo-klasser som:
:hover:focus:focus-visible:active:visited:disabled:checked:invalid
Inspicér derefter de beregnede farver igen.
Fokusindikatorer fortjener særlig opmærksomhed. WCAG 2.2 skærpede forventningerne til fokusudseende, og en bleg blå outline på et lysegråt kort er stadig en almindelig fejl. Fokusindikatoren skal have tilstrækkelig kontrast mod tilstødende farver og tilstrækkeligt areal til at blive bemærket.
For disabled-kontroller har WCAG-kontrastreglerne en undtagelse for inaktive komponenter. Det betyder ikke, at disabled-kontroller som udgangspunkt bør være ulæselige. Hvis disabled-tilstanden formidler nyttig information, så gør den læsbar. Hvis den ikke gør, så overvej, om den overhovedet bør være til stede.
Brug Lighthouse, men outsource ikke din dømmekraft til det
Browseraudits som Lighthouse kan hurtigt fange nogle kontrastfejl. Kør den indbyggede audit, hvis din browser tilbyder den, og behandl derefter resultaterne som et udgangspunkt.
Automatiserede tjek er gode til at finde tekstnoder med åbenlyse beregnede kontrastfejl. De er svagere til:
- Tekst indlejret i billeder.
- Labels renderet i canvas.
- SVG-edge cases.
- Fejl, der kun opstår ved hover.
- Kvaliteten af fokusindikatorer.
- Diagrammer, hvor farverelationer bærer betydning.
- Komponenter skjult bag autentificering, menuer eller formulartrin.
Hvis en rapport kommer tilbage grøn, skal du stadig inspicere repræsentative komponenter. Hvis en rapport kommer tilbage rød, så undgå panik, og triagér fejlene efter brugerimpact. Det samme princip gælder generelt for performance- og tilgængelighedsrapporter: Læs værktøjets output som evidens, ikke som en dom. Vi bruger den tankegang i vores guide til at læse en Lighthouse-rapport uden panik, og den passer rent ind her.
Auditér også ikke-tekstlig kontrast
Tekst får det meste af opmærksomheden, men WCAG dækker også ikke-tekstligt indhold, der er nødvendigt for at forstå eller betjene interfacet.
Tjek som minimum disse tilfælde:
- Inputkanter mod sidens baggrund.
- Checkbox- og radio-outlines.
- Toggle-tilstande.
- Knapper kun med ikon.
- Fejlikoner og advarselssymboler.
- Diagramlinjer, søjler og labels.
- Fremdriftsindikatorer.
- Valgt fane eller indikatorer for aktiv navigation.
Målet er normalt 3:1 mod tilstødende farver. For eksempel kan en lysegrå inputkant på en hvid baggrund være næsten usynlig. Et diagram med fem pastelfarvede linjer kan se elegant ud og stadig være ubrugeligt.
For diagrammer er kontrast ikke nok i sig selv. Brug labels, mønstre, linjestile, direkte annotation eller afstand, så informationen ikke kun afhænger af farve. Det hjælper farveblinde brugere, svagsynede brugere, personer, der ser skærmen i genskin, og alle, der læser et skærmbillede i et dokument.
Registrér fund i et format, udviklere kan bruge
En nyttig kontrastaudit siger ikke “nogle gråtoner fejler.” Den identificerer komponenten, tilstanden, de aktuelle værdier, den forventede grænseværdi og et foreslået fix.
Et kompakt format fungerer godt:
| Komponent | Tilstand | Forgrund | Baggrund | Forhold | Mål | Resultat | Foreslået fix | |---|---:|---:|---:|---:|---:|---|---| | Kortmetadata | Standard | #8A8F98 | #FFFFFF | 3.2:1 | 4.5:1 | Fejler | Brug --color-text-muted-strong | | Primær knap | Hover | #FFFFFF | #2F6FEA | 4.8:1 | 4.5:1 | Består | Behold | | Inputkant | Standard | #D7DCE2 | #FFFFFF | 1.4:1 | 3:1 | Fejler | Gør border-token mørkere |
Knyt fixes til design tokens, hvis sitet har dem. Ret ikke tyve individuelle komponenter, hvis ét svagt token er det egentlige problem.
Gør fixes lidt stærkere end minimum
Kontrastfejl er ofte lette at rette dårligt. Teams justerer en farve, indtil tjekkeren siger 4.51:1, og går videre. Det efterlader ingen margin til skriftrendering, transparens, browserforskelle, theming, billedvariation eller fremtidige brandændringer.
Foretræk komfortable mål:
- Brødtekst: tættere på 7:1, når det er praktisk muligt.
- Nedtonet tekst: stadig over 4.5:1, hvis det er reelt indhold.
- UI-kanter og ikoner: komfortabelt over 3:1.
- Tekst over billeder: brug et kontrolleret overlay frem for gætteri pr. billede.
Webbet ses på billige laptops, dunkle telefoner, lyse fortove, tonede skærme og aldrende displays. Minimumsoverholdelse er ikke det samme som komfortabel læsning.
<!-- tool-cta:start -->
💡 Prøv dette: Når du tjekker kontrastpar, du har hentet fra DevTools, hjælper Color Converter med at konvertere mellem hex, RGB og HSL, så værdierne stemmer overens med dine auditnoter.
<!-- tool-cta:end -->
En no-install-tjekliste til kontrastaudit
Brug denne rækkefølge, når du har brug for en hurtig, men troværdig audit:
- Åbn produktionssiden i en moderne browser.
- List de vigtigste tekst-, UI- og tilstandsmønstre.
- Inspicér beregnede forgrunds- og baggrundsfarver i DevTools.
- Brug den indbyggede farvevælger eller accessibility-panel til at aflæse kontrast.
- Fremtving hover-, focus-, active-, visited- og invalid-tilstande.
- Tjek tekst over billeder og gradienter mod den værst tænkelige plausible baggrund.
- Tjek ikke-tekstlige UI-dele mod 3:1-kravet.
- Kør en indbygget automatiseret audit som sikkerhedsnet, ikke som hele auditten.
- Registrér fejl efter komponent og token.
- Ret med margin, ikke ved kun lige at krydse grænseværdien.
Det er nok til at fange størstedelen af kontrastproblemer uden at føje endnu et værktøj til din stack. Mere avancerede audits har stadig deres plads, især for store design systems, regulerede produkter eller kompleks datavisualisering. Men for mange websites giver browseren dig allerede den evidens, du har brug for. Den svære del er at være systematisk nok til at bruge den.