WCAG 1.4.11: Icke-textkontrast

Vad den här regeln innebär

WCAG 1.4.11 Kontrast för icke‑text är ett kriterium på nivå AA som introducerades i WCAG 2.1 och förts vidare till WCAG 2.2. Det kräver ett minimikontrastförhållande på 3:1 mellan den visuella presentationen av följande två innehållskategorier och deras intilliggande färg(er):

• Användargränssnittskomponenter (UI‑komponenter): De visuella gränserna eller indikatorerna som identifierar interaktiva kontroller såsom textfält, kryssrutor, alternativknappar, växlingsknappar (toggle switches), rullgardinsmenyer och knappar. Detta inkluderar både själva komponenten och alla visuella tillståndsändringar (t.ex. hover, fokus, markerad, fel).
• Grafiska objekt: Delar av ikoner, diagram, scheman och andra meningsbärande bilder som krävs för att förstå innehållet. Varje del av grafiken som förmedlar information måste uppfylla tröskelvärdet 3:1 mot sin omgivande färg.

Kontrastförhållandet mäts mellan förgrundselementet och färgen som ligger direkt intill det — vanligtvis dess bakgrundsfärg, kantfärg eller ett angränsande segment i ett diagram. Beräkningen använder samma formel för relativ luminans som definieras i WCAG 1.4.3, men tröskeln är 3:1 i stället för 4,5:1 eftersom icke‑textelement kan ha något lägre kontrast och ändå vara urskiljbara.

Ett godkänt resultat innebär att varje visuell indikator som identifierar en UI‑komponent eller kommunicerar information i en grafik uppnår minst 3:1. Ett underkänt resultat uppstår när en kant, ikonlinje, diagramsegment eller tillståndsindikator hamnar under detta förhållande och komponenten eller grafiken inte kan identifieras eller förstås utan den visuella informationen.

WCAG‑specifikationen definierar flera viktiga undantag:

• Inaktiva komponenter: UI‑komponenter som är inaktiverade och inte tillgängliga för interaktion är undantagna. En nedtonad knapp som inte kan klickas behöver inte uppfylla kontrastkravet.
• Utseende som styrs av användaragenten: Komponenter vars visuella presentation helt styrs av webbläsarens standardstil (inte överskriven av författarens CSS) är undantagna, eftersom ansvaret ligger hos webbläsarleverantören.
• Väsentlig eller dekorativ grafik: Grafiska objekt där den specifika presentationen är väsentlig för den information som förmedlas (t.ex. nationsflaggor som representerar länder) eller som är rent dekorativa är undantagna. Logotyper är också i allmänhet undantagna enligt denna punkt.
• Text: Text och textbilder omfattas redan av 1.4.3 och 1.4.6 och faller inte under 1.4.11.

Fokusindikatorer förtjänar särskild uppmärksamhet i WCAG 2.2. Kriterium 2.4.11 (Fokusutseende) lägger till striktare krav på fokusens synlighet, men 1.4.11 gäller fortfarande för kontrasten hos alla anpassade fokusringar mot deras bakgrund. En anpassad outline eller box‑shadow som används som fokusindikator måste uppnå 3:1 mot den intilliggande färgen för att uppfylla detta kriterium oberoende.

Varför det är viktigt

Enligt Världshälsoorganisationen har cirka 2,2 miljarder människor världen över någon form av synnedsättning. En betydande andel av dessa personer — inklusive de uppskattningsvis 253 miljoner människor som lever med måttlig till svår synförlust — är beroende av tillräcklig kontrast för att uppfatta och interagera med digitala gränssnitt utan att nödvändigtvis använda skärmläsare. Användare med nedsatt syn som surfar med förstoringsprogram, högkontrastlägen eller helt enkelt i utmanande ljusförhållanden är bland dem som påverkas mest direkt av brister i 1.4.11.

Föreställ dig ett praktiskt scenario: en användare med glaukom fyller i en skadeanmälan på ett sjukhus webbplats. Formulärfälten använder en ljusgrå kant (#cccccc) på vit bakgrund (#ffffff), vilket ger ett kontrastförhållande på endast 1,6:1 — långt under kravet 3:1. Användaren kan inte se var inmatningsfälten börjar och slutar, så hen kan varken pålitligt klicka i dem eller förstå formulärets struktur. Hen avbryter formuläret helt, vilket både innebär en personlig kostnad och en juridisk risk för institutionen.

Utöver synnedsättning kan kognitiva funktionsnedsättningar också göra UI‑komponenter med låg kontrast svårare att tolka. Användare med uppmärksamhetsstörningar eller bearbetningssvårigheter är beroende av tydlig visuell åtskillnad mellan interaktiva och icke‑interaktiva element för att snabbt förstå sidans struktur. På samma sätt behöver användare med skakningar eller motoriska funktionsnedsättningar som använder stora pekmål tydligt se kontrollernas gränser för att kunna sikta korrekt.

Ur ett affärsperspektiv förbättrar uppfyllandet av 1.4.11 användbarheten för alla användare i suboptimala förhållanden — starkt solljus på en mobilskärm, lågkvalitativa bildskärmar eller äldre skärmar med dålig färgåtergivning. Det minskar supportkostnader, breddar målgruppen och stärker SEO indirekt genom att sänka avvisningsfrekvenser som är kopplade till dålig användbarhet. För organisationer som omfattas av juridiska tillgänglighetskrav innebär underlåtenhet att uppfylla detta kriterium på nivå AA en direkt regelefterlevnadsrisk.

Relaterade Axe‑core‑regler

• color-contrast (delvis täckning): Axe‑core‑regeln color-contrast riktar sig främst mot textkontrast enligt WCAG 1.4.3, men utför också delvisa kontroller för icke‑textelement i vissa sammanhang. Axe flaggar UI‑komponenter som knappar och formulärkontroller när den programmatiskt kan avgöra att komponentens visuella gräns eller bakgrund inte uppfyller 3:1‑förhållandet. Men regelns täckning är uttryckligen markerad som delvis för 1.4.11 eftersom många kontrastfel för icke‑textelement är osynliga för automatiserad analys. Till exempel kan kontrasten för en SVG‑ikons linje mot dess bakgrund, eller kanten på en specialstylad kryssruta som implementerats med CSS‑pseudo‑element, inte pålitligt hämtas från DOM:en utan renderingskontext. Den beräknade stilen för en CSS‑kant kan finnas i tillgänglighetsträdet men den intilliggande bakgrunden — särskilt när den är en gradient, bild eller överlappande element — är inte alltid programmatiskt beräkningsbar. Därför rapporterar axe överträdelser av 1.4.11 under regeln color-contrast med beteckningen needs review i många fall, vilket betyder att verktyget har upptäckt ett potentiellt problem men att en människa måste bekräfta det genom att visuellt inspektera elementet och använda ett verktyg för färgkontrastanalys för att sampla de faktiskt renderade pixlarna.

Eftersom automatiska verktyg bara kan upptäcka en bråkdel av kontrastfel för icke‑text är manuell testning avgörande. Verktyg som Colour Contrast Analyser (TPGi), webbläsarens DevTools‑färgväljare eller verktyget Accessible Colors måste användas för att sampla förgrunds- och bakgrundsfärger direkt från det renderade gränssnittet. Automatiska skanningar bör ses som ett första steg, inte en heltäckande granskning.

Hur man testar

1. Kör en automatisk skanning med axe DevTools eller Lighthouse: Installera webbläsartillägget axe DevTools och kör en helsidesskanning. I resultatpanelen filtrerar du efter problem taggade med WCAG 1.4.11 eller granskar eventuella color-contrast-överträdelser. Notera alla poster som flaggats som Needs Review under kategorin icke‑textkontrast — dessa kräver manuell uppföljning. I Lighthouse (Chrome DevTools > fliken Lighthouse) kör du en Accessibility‑granskning och går igenom kontrastrelaterade fynd, med vetskap om att även Lighthouse har delvis täckning för icke‑textelement.
2. Manuell inspektion med ett verktyg för färgkontrastanalys: Ladda ner och öppna skrivbordsapplikationen TPGi Colour Contrast Analyser. Använd dess pipettverktyg för att sampla förgrundsfärgen för varje UI‑komponents gräns (t.ex. kanten på ett textfält, linjen i en ikon, fyllningen i en stapel i ett diagram) och sampla sedan den intilliggande bakgrundsfärgen. Verktyget visar det beräknade kontrastförhållandet. Alla förhållanden under 3:1 är underkända. Gå systematiskt igenom alla interaktiva formulärkontroller, ikon‑endast‑knappar, fokusindikatorer och datavisualiseringar.
3. Tangentbordsnavigering och test av fokusindikator: Tabba genom hela sidan med enbart tangentbordet. För varje interaktivt element som får fokus, kontrollera att fokusindikatorn (ring, kontur eller bakgrundsändring) är synlig. Använd kontrastanalysverktyget för att bekräfta att fokusindikatorns färg uppnår 3:1 mot elementets bakgrund. Testa i NVDA + Firefox och JAWS + Chrome för att bekräfta att elementet får fokus i förväntad ordning och att den visuella indikatorn inte undertrycks av CSS outline: none utan en likvärdig ersättning.
4. Testa i högkontrast- och forced‑color‑lägen: Aktivera Högkontrastläge i Windows (Inställningar > Hjälpmedel > Högkontrast) och ladda om sidan. I Chromium‑baserade webbläsare öppnar du DevTools, går till Rendering och aktiverar alternativet Emulate CSS media feature forced-colors: active. Kontrollera att UI‑komponenternas gränser förblir synliga. Även om efterlevnad av forced‑color‑läge inte strikt krävs av 1.4.11 avslöjar testning i detta läge element som enbart förlitar sig på färg med låg kontrast.
5. Verifiera grafiska objekt i sitt sammanhang: Identifiera för varje diagram, ikon, schema eller informativ bild varje segment eller bana som förmedlar betydelse. Använd pipettverktyget för att sampla intilliggande färger inom själva grafiken (t.ex. två angränsande segment i ett cirkeldiagram) och mot den omgivande sidbakgrunden. Varje distinkt del som kommunicerar information måste individuellt uppnå 3:1.
6. Kontrollera alla komponenttillstånd: Interaktiva element har flera tillstånd — standard, hover, fokus, aktivt, markerat, ikryssat, fel och lyckat. Testa varje tillstånd separat. En knappkant som klarar kravet i standardläge kan underkännas i hover‑läge om färgen ändras till en variant med låg kontrast.

Hur man åtgärdar

Formulärfältets kant — felaktigt

<!-- Fails: light grey border (#cccccc) on white (#ffffff) = 1.6:1 ratio -->
<style>
  .form-input {
    border: 1px solid #cccccc;
    background-color: #ffffff;
    padding: 8px 12px;
  }
</style>
<label for='email'>Email Address</label>
<input type='email' id='email' class='form-input' />

Formulärfältets kant — korrekt

<!-- Passes: darker border (#767676) on white (#ffffff) = 4.54:1 ratio, exceeds 3:1 -->
<style>
  .form-input {
    border: 1px solid #767676; /* Darkened to achieve sufficient contrast */
    background-color: #ffffff;
    padding: 8px 12px;
  }
  .form-input:focus {
    outline: 3px solid #005fcc; /* Focus ring at 5.9:1 against white */
    outline-offset: 2px;
  }
</style>
<label for='email'>Email Address</label>
<input type='email' id='email' class='form-input' />

Ikon‑endast‑knapp — felaktig

<!-- Fails: light grey icon (#aaaaaa) on white (#ffffff) = 2.32:1 ratio -->
<style>
  .icon-btn { background: none; border: none; color: #aaaaaa; }
</style>
<button class='icon-btn' aria-label='Delete item'>
  <svg aria-hidden='true' focusable='false' width='24' height='24'>
    <path d='M3 6h18M8 6V4h8v2M19 6l-1 14H6L5 6' stroke='currentColor' stroke-width='2' fill='none'/>
  </svg>
</button>

Ikon‑endast‑knapp — korrekt

<!-- Passes: dark icon (#595959) on white (#ffffff) = 7:1 ratio, well above 3:1 -->
<style>
  .icon-btn { background: none; border: none; color: #595959; cursor: pointer; }
  .icon-btn:focus-visible {
    outline: 3px solid #005fcc;
    outline-offset: 2px;
    border-radius: 4px;
  }
</style>
<button class='icon-btn' aria-label='Delete item'>
  <svg aria-hidden='true' focusable='false' width='24' height='24'>
    <!-- Darker stroke ensures the icon shape is perceivable -->
    <path d='M3 6h18M8 6V4h8v2M19 6l-1 14H6L5 6' stroke='currentColor' stroke-width='2' fill='none'/>
  </svg>
</button>

Anpassad kryssruta — felaktig

<!-- Fails: custom checkbox uses a light border (#d0d0d0) on white background -->
<style>
  .custom-checkbox-box {
    width: 18px; height: 18px;
    border: 2px solid #d0d0d0; /* 1.3:1 ratio against white — fails */
    border-radius: 3px;
    display: inline-block;
  }
</style>
<label>
  <input type='checkbox' style='position:absolute;opacity:0;width:0;height:0' />
  <span class='custom-checkbox-box'></span>
  I agree to the terms
</label>

Anpassad kryssruta — korrekt

<!-- Passes: border (#5a5a5a) on white = 7.2:1. Checked state tick also uses sufficient contrast -->
<style>
  .custom-checkbox-input {
    position: absolute; opacity: 0; width: 0; height: 0;
  }
  .custom-checkbox-box {
    width: 18px; height: 18px;
    border: 2px solid #5a5a5a; /* Sufficient contrast against white background */
    border-radius: 3px;
    display: inline-flex;
    align-items: center;
    justify-content: center;
    background-color: #ffffff;
  }
  .custom-checkbox-input:checked + .custom-checkbox-box {
    background-color: #005fcc; /* Blue fill on checked */
    border-color: #005fcc;
  }
  .custom-checkbox-input:checked + .custom-checkbox-box::after {
    content: '';
    display: block;
    width: 10px; height: 6px;
    border-left: 2px solid #ffffff; /* White tick on blue = 5.9:1 */
    border-bottom: 2px solid #ffffff;
    transform: rotate(-45deg) translateY(-2px);
  }
  .custom-checkbox-input:focus-visible + .custom-checkbox-box {
    outline: 3px solid #005fcc;
    outline-offset: 2px;
  }
</style>
<label class='custom-label'>
  <input type='checkbox' class='custom-checkbox-input' />
  <span class='custom-checkbox-box' aria-hidden='true'></span>
  I agree to the terms
</label>

Datadiagram — felaktigt

<!-- Fails: two adjacent pie chart segments use similar light hues with <3:1 contrast -->
<svg viewBox='0 0 200 200' aria-label='Market share chart' role='img'>
  <!-- Segment A: #f5c6cb (light pink) adjacent to Segment B: #ffeeba (light yellow) -->
  <!-- Contrast ratio between these two colors is approximately 1.1:1 — fails -->
  <path d='M100,100 L100,10 A90,90 0 0,1 190,100 Z' fill='#f5c6cb' />
  <path d='M100,100 L190,100 A90,90 0 0,1 100,190 Z' fill='#ffeeba' />
</svg>

Datadiagram — korrekt

<!-- Passes: use high-contrast segment fills OR add a visible border between segments -->
<svg viewBox='0 0 200 200' aria-label='Market share chart: Segment A 50%, Segment B 25%' role='img'>
  <!-- Option 1: Use a dark stroke between segments to separate them at 3:1 against both fills -->
  <path d='M100,100 L100,10 A90,90 0 0,1 190,100 Z' fill='#d63384' stroke='#ffffff' stroke-width='2' />
  <path d='M100,100 L190,100 A90,90 0 0,1 100,190 Z' fill='#0d6efd' stroke='#ffffff' stroke-width='2' />
  <!-- The white (#ffffff) stroke separates the two segments; each fill also has 3:1 against white bg -->
</svg>

Vanliga misstag

• Att använda en kant på en pixel som uppfyller 3:1 men blir osynlig vid låg DPI: Även en färg som uppfyller kraven kan bli svår att uppfatta om kanten bara är 1 px bred på en lågupplöst skärm. Använd border: 2px solid eller en synlig box‑shadow tillsammans med en färg som uppfyller kraven för att säkerställa att gränsen är fysiskt uppfattbar.
• Att anta att bakgrunden alltid är vit: När ett formulärfält eller en ikon visas inuti ett kort eller en sidopanel med ljusgrå bakgrund (#f5f5f5) måste kontrasten mätas mot den grå, inte mot vitt. En kant som klarar kravet på vitt kan underkännas på en tonad bakgrund.
• Att ta bort standardfokuskonturen med outline: none utan att tillhandahålla en motsvarighet: Detta är ett av de vanligaste felen för 1.4.11. Att globalt sätta :focus { outline: none; } förstör fokussynligheten för tangentbordsanvändare. Ersätt den alltid med en anpassad fokusstil som uppnår minst 3:1 mot sin bakgrund.
• Att behandla inaktiverat tillstånd som en ursäkt för att hoppa över alla kontrastkontroller: Inaktiverade komponenter är undantagna, men utvecklare markerar ibland element som visuellt inaktiverade via styling med låg kontrast utan att faktiskt lägga till attributet disabled eller aria-disabled='true'. Ett element som ser inaktiverat ut men fortfarande är interaktivt måste fortfarande uppfylla 1.4.11.
• Att enbart förlita sig på färg för att skilja diagramsegment utan en separerande linje: Två angränsande diagramsegment där den enda skillnaden är nyans (t.ex. ljusblått vs. ljusgrönt) kan underkännas om deras kontrastförhållande är under 3:1. Att lägga till en 2 px vit eller mörk separerande linje mellan segmenten är en tillförlitlig lösning.
• Att bara tillämpa kontrastfixar på standardtillståndet och glömma hover-, fokus-, fel- och lyckade tillstånd: Varje interaktivt tillstånd har sin egen visuella presentation. En knappkant som klarar kravet i standardläge kan skifta till en färg med låg kontrast vid hover. Alla tillstånd måste testas oberoende.
• Att bädda in ikoner som bakgrundsbilder och förlita sig på CSS‑färg för kontrast: SVG‑ikoner som är inlinade i HTML svarar på color och currentColor, men ikoner som används som CSS‑background-image kan inte färgändras via CSS. Om själva ikonbildfilen har otillräcklig kontrast kan ingen CSS‑fix lösa problemet utan att byta ut resursen.
• Att glömma att platshållartext i inmatningsfält inte omfattas av 1.4.11 men ändå regleras: Platshållartext omfattas av 1.4.3 (textkontrast på 4,5:1), inte 1.4.11. Utvecklare tillämpar ibland tröskeln 3:1 på platshållartext av misstag, vilket skapar ett separat, oupptäckt fel mot 1.4.3.
• Att använda CSS‑övergångar som animerar genom en icke‑godkänd mellanliggande färg: Ett element kan animeras från en godkänd färg genom en underkänd mellanliggande färg till en annan godkänd färg. Även om start- och slutlägena klarar kraven är den visuella komponenten tekniskt sett icke‑kompatibel under övergången. Använd media queries för prefers-reduced-motion på ett genomtänkt sätt och undvik att låta övergångar gå genom tillstånd med låg kontrast.
• Att ignorera förloppsindikatorer, reglage (range inputs) och växlingsknappar: Dessa anpassade UI‑komponenter stylas ofta utan hänsyn till 1.4.11. Den fyllda delen av en förloppsindikator måste ha 3:1‑kontrast mot sin bana; en växlingsknapps ratt måste kontrastera mot växlingens bakgrund; ett reglagets tumme måste kontrastera mot banan.

Relation till Turkiets tillgänglighetsreglering

Turkiets Presidential Circular No. 2025/10, publicerad i Official Gazette nr 32933 den 21 juni 2025, fastställer obligatoriska krav på webb- och mobiltillgänglighet för ett brett spektrum av offentliga och privata aktörer som är verksamma i Turkiet. Cirkuläret antar WCAG 2.2 som sin normativa tekniska standard, och nivå AA‑överensstämmelse är den tröskel som krävs för efterlevnad.

WCAG 1.4.11 Kontrast för icke‑text, som ett kriterium på nivå AA, är därför direkt verkställbart enligt cirkuläret. Organisationer som omfattas av regleringen måste säkerställa att alla UI‑komponentgränser, interaktiva kontrolltillstånd och meningsbärande grafiska objekt på deras digitala egendomar uppfyller kravet på 3:1‑kontrast för icke‑text.

De aktörer som omfattas av Presidential Circular 2025/10 inkluderar offentliga institutioner och myndigheter på alla förvaltningsnivåer, e‑handelsplattformar, banker och finansiella institutioner, sjukhus och privata vårdgivare, teleoperatörer med 200 000 eller fler abonnenter, resebyråer, privata transportföretag och privatskolor som auktoriserats av Ministry of National Education (MoNE). För dessa organisationer är underlåtenhet att implementera 1.4.11 inte bara en brist i bästa praxis utan en regulatorisk avvikelse.

Accessibility Logo (Erişilebilirlik Logosu), som utfärdas av Ministry of Family and Social Services, fungerar som ett offentligt synligt certifieringsmärke för digitala tjänster som uppfyller kraven. För att få och visa denna logotyp måste en organisation uppvisa full överensstämmelse på nivå AA för alla tillämpliga WCAG 2.2‑kriterier, inklusive 1.4.11. Eftersom många turkiska e‑förvaltningsportaler, bankgränssnitt och vårdformulär använder omfattande specialstylade formulärkontroller och datavisualiseringar är kontrast för icke‑text ett kriterium som revisorer särskilt sannolikt kommer att utvärdera under certifieringsprocessen.

Organisationer som använder Accsible‑overlay‑widgeten bör vara medvetna om att overlay‑teknik kan hjälpa till att åtgärda vissa kontrastjusteringar vid körning — såsom att låta användare aktivera ett högkontrasttema — men bestående strukturella fel, såsom ett formulärfält som renderas med en kantkontrast på 1,6:1, måste korrigeras på källkodsnivå för att uppnå verklig överensstämmelse och kvalificera sig för Erişilebilirlik Logosu. Att kombinera korrigeringar på källnivå med en tillgänglighetswidgets användarorienterade förbättringsfunktioner utgör den mest försvarbara efterlevnadshållningen enligt turkisk lag.