WCAG 1.4.11: Kontrast elementów nietekstowych

Co Oznacza Ta Zasada

WCAG 1.4.11 Kontrast elementów nietekstowych to kryterium na poziomie AA wprowadzone w WCAG 2.1 i przeniesione do WCAG 2.2. Wymaga ono minimalnego współczynnika kontrastu 3:1 pomiędzy wizualną prezentacją następujących dwóch kategorii treści a ich sąsiadującym kolorem (kolorami):

• Komponenty interfejsu użytkownika (UI): Wizualne granice lub wskaźniki identyfikujące elementy interaktywne, takie jak pola tekstowe, pola wyboru (checkbox), przyciski opcji (radio), przełączniki (toggle), listy rozwijane i przyciski. Obejmuje to zarówno sam komponent, jak i wszelkie wizualne zmiany stanu (np. najechanie kursorem, fokus, zaznaczenie, błąd).
• Obiekty graficzne: Części ikon, wykresów, diagramów i innych znaczących obrazów, które są niezbędne do zrozumienia treści. Każda część grafiki przekazująca informacje musi spełniać próg 3:1 względem otaczającego ją koloru.

Współczynnik kontrastu jest mierzony pomiędzy elementem pierwszoplanowym a kolorem bezpośrednio z nim sąsiadującym — zazwyczaj kolorem tła, kolorem obramowania lub sąsiednim segmentem wykresu. Obliczenia wykorzystują tę samą formułę luminancji względnej zdefiniowaną w WCAG 1.4.3, ale próg wynosi 3:1 zamiast 4.5:1, ponieważ elementy nietekstowe mogą mieć nieco niższy kontrast, pozostając nadal rozróżnialne.

Zaliczenie oznacza, że każdy wizualny wskaźnik identyfikujący komponent UI lub przekazujący informacje w grafice osiąga co najmniej współczynnik 3:1. Niezaliczenie występuje, gdy obramowanie, obrys ikony, segment wykresu lub wskaźnik stanu spada poniżej tego współczynnika i komponent lub grafika nie mogą zostać zidentyfikowane lub zrozumiane bez tej informacji wizualnej.

Specyfikacja WCAG definiuje kilka istotnych wyjątków:

• Nieaktywne komponenty: Komponenty UI, które są wyłączone i niedostępne do interakcji, są zwolnione z wymogu. Wyszarzony przycisk, którego nie można kliknąć, nie musi spełniać wymogu kontrastu.
• Wygląd kontrolowany przez user agent: Komponenty, których wizualna prezentacja jest w całości kontrolowana przez domyślne style przeglądarki (nie nadpisane przez CSS autora), są zwolnione, ponieważ odpowiedzialność spoczywa na dostawcy przeglądarki.
• Grafiki istotne lub dekoracyjne: Obiekty graficzne, w których konkretna prezentacja jest niezbędna do przekazania informacji (np. flagi państw reprezentujące kraje) lub które są czysto dekoracyjne, są zwolnione. Logotypy są również zazwyczaj zwolnione na mocy tego punktu.
• Tekst: Tekst i obrazy tekstu są już objęte kryteriami 1.4.3 i 1.4.6 i nie podlegają 1.4.11.

Wskaźniki fokusu zasługują na szczególną uwagę w WCAG 2.2. Kryterium 2.4.11 (Focus Appearance) dodaje bardziej rygorystyczne wymagania dotyczące widoczności fokusu, ale 1.4.11 nadal ma zastosowanie do kontrastu dowolnego niestandardowego pierścienia fokusu względem jego tła. Niestandardowy outline lub box-shadow użyty jako wskaźnik fokusu musi osiągać 3:1 względem sąsiadującego koloru, aby niezależnie spełnić to kryterium.

Dlaczego To Ma Znaczenie

Około 2,2 miliarda osób na świecie ma jakąś formę zaburzeń widzenia, według Światowej Organizacji Zdrowia. Znaczna część tych osób — w tym szacowane 253 miliony ludzi żyjących z umiarkowaną do ciężkiej utratą wzroku — polega na wystarczającym kontraście, aby postrzegać i obsługiwać interfejsy cyfrowe bez konieczności używania czytnika ekranu. Użytkownicy słabowidzący, którzy przeglądają treści z użyciem oprogramowania powiększającego, trybów wysokiego kontrastu lub po prostu w trudnych warunkach oświetleniowych, należą do tych, których najbardziej bezpośrednio dotykają naruszenia 1.4.11.

Rozważ praktyczny scenariusz: użytkownik z jaskrą wypełnia formularz zgłoszenia roszczenia ubezpieczeniowego na stronie internetowej szpitala. Pola formularza używają jasnoszarej ramki (#cccccc) na białym tle (#ffffff), co daje współczynnik kontrastu jedynie 1.6:1 — znacznie poniżej wymaganego 3:1. Użytkownik nie widzi, gdzie zaczynają się i kończą pola wprowadzania, więc nie może wiarygodnie w nie kliknąć ani zrozumieć struktury formularza. Całkowicie porzuca formularz, co ma zarówno osobisty koszt, jak i tworzy odpowiedzialność prawną dla instytucji.

Poza zaburzeniami widzenia, niepełnosprawności poznawcze również mogą utrudniać interpretację komponentów UI o niskim kontraście. Użytkownicy z zaburzeniami uwagi lub trudnościami w przetwarzaniu informacji polegają na wyraźnym wizualnym odróżnieniu elementów interaktywnych od nieinteraktywnych, aby szybko zrozumieć strukturę strony. Podobnie użytkownicy z drżeniem rąk lub niepełnosprawnościami motorycznymi, którzy korzystają z dużych celów wskaźnika, muszą wyraźnie widzieć granice kontrolek, aby celować precyzyjnie.

Z perspektywy biznesowej spełnienie 1.4.11 poprawia użyteczność dla wszystkich użytkowników w suboptymalnych warunkach — jasne światło słoneczne na ekranie telefonu, monitory niskiej jakości lub starsze wyświetlacze o słabej dokładności kolorów. Zmniejsza koszty wsparcia, poszerza zasięg odbiorców i pośrednio wzmacnia SEO poprzez obniżenie współczynników odrzuceń związanych ze słabą użytecznością. Dla organizacji podlegających prawnym wymogom dostępności niespełnienie tego kryterium na poziomie AA stanowi bezpośrednie ryzyko braku zgodności.

Powiązane Reguły Axe-core

• color-contrast (częściowe pokrycie): Reguła axe-core color-contrast koncentruje się głównie na kontraście tekstu zgodnie z WCAG 1.4.3, ale wykonuje również częściowe sprawdzenia elementów nietekstowych w określonych kontekstach. Axe oznacza komponenty UI, takie jak przyciski i kontrolki formularzy, gdy może programowo ustalić, że wizualna granica lub tło komponentu nie spełnia współczynnika 3:1. Jednak zakres tej reguły jest wyraźnie oznaczony jako częściowy dla 1.4.11, ponieważ wiele naruszeń kontrastu dla elementów nietekstowych jest niewidocznych dla automatycznej analizy. Na przykład kontrast obrysu ikony SVG względem jej tła lub obramowania niestandardowo ostylowanego pola wyboru zaimplementowanego za pomocą pseudoelementów CSS nie może być wiarygodnie wyodrębniony z DOM bez kontekstu renderowania. Obliczony styl obramowania CSS może być obecny w drzewie dostępności, ale sąsiadujące tło — zwłaszcza gdy jest gradientem, obrazem lub nakładającym się elementem — nie zawsze jest programowo obliczalne. Dlatego axe raportuje naruszenia 1.4.11 w ramach reguły color-contrast z oznaczeniem needs review w wielu przypadkach, co oznacza, że narzędzie wykryło potencjalny problem, ale człowiek musi go potwierdzić, wizualnie inspekcjonując element i używając narzędzia do analizy kontrastu kolorów, aby pobrać próbki faktycznie renderowanych pikseli.

Ponieważ narzędzia automatyczne mogą wykryć jedynie część naruszeń kontrastu elementów nietekstowych, testy manualne są niezbędne. Narzędzia takie jak Colour Contrast Analyser (TPGi), próbnik kolorów w DevTools przeglądarki czy narzędzie Accessible Colors muszą być używane do pobierania próbek kolorów pierwszego planu i tła bezpośrednio z renderowanego interfejsu. Skanowanie automatyczne należy traktować jako pierwszy etap, a nie kompleksowy audyt.

Jak Testować

1. Uruchom skan automatyczny za pomocą axe DevTools lub Lighthouse: Zainstaluj rozszerzenie przeglądarki axe DevTools i uruchom skan całej strony. W panelu wyników przefiltruj problemy oznaczone jako WCAG 1.4.11 lub przejrzyj wszelkie naruszenia color-contrast. Zanotuj elementy oznaczone jako Needs Review w kategorii kontrastu elementów nietekstowych — wymagają one ręcznej weryfikacji. W Lighthouse (Chrome DevTools > zakładka Lighthouse) uruchom audyt Accessibility i przejrzyj wyniki związane z kontrastem, pamiętając, że zakres Lighthouse jest również częściowy dla elementów nietekstowych.
2. Ręczna inspekcja za pomocą analizatora kontrastu kolorów: Pobierz i otwórz aplikację desktopową TPGi Colour Contrast Analyser. Użyj narzędzia pipety, aby pobrać próbkę koloru pierwszego planu każdej granicy komponentu UI (np. obramowania pola tekstowego, obrysu ikony, wypełnienia słupka wykresu), a następnie pobierz próbkę sąsiadującego koloru tła. Narzędzie wyświetli obliczony współczynnik kontrastu. Każdy współczynnik poniżej 3:1 jest niezgodny. Pracuj systematycznie przez wszystkie interaktywne kontrolki formularzy, przyciski zawierające wyłącznie ikony, wskaźniki fokusu i wizualizacje danych.
3. Nawigacja klawiaturą i test wskaźnika fokusu: Przejdź przez całą stronę za pomocą samej klawiatury, używając klawisza Tab. Dla każdego elementu interaktywnego, który otrzymuje fokus, sprawdź, czy wskaźnik fokusu (pierścień, obrys lub zmiana tła) jest widoczny. Użyj analizatora kontrastu, aby potwierdzić, że kolor wskaźnika fokusu osiąga 3:1 względem tła elementu. Przetestuj w NVDA + Firefox oraz JAWS + Chrome, aby potwierdzić, że element otrzymuje fokus w oczekiwanej kolejności i że wskaźnik wizualny nie jest usuwany przez CSS outline: none bez równoważnego zamiennika.
4. Test w trybach wysokiego kontrastu i forced-color: W systemie Windows włącz tryb High Contrast (Ustawienia > Ułatwienia dostępu > Wysoki kontrast) i przeładuj stronę. W przeglądarkach opartych na Chromium otwórz DevTools, przejdź do zakładki Rendering i włącz opcję Emulate CSS media feature forced-colors: active. Sprawdź, czy granice komponentów UI pozostają widoczne. Choć zgodność z trybem forced-color nie jest ściśle wymagana przez 1.4.11, testowanie w tym trybie ujawnia elementy, które polegają wyłącznie na niskokontrastowych wskazówkach kolorystycznych.
5. Zweryfikuj obiekty graficzne w kontekście: Dla każdego wykresu, ikony, diagramu lub obrazu informacyjnego zidentyfikuj każdy segment lub ścieżkę, która przekazuje znaczenie. Użyj narzędzia pipety, aby pobrać próbki sąsiadujących kolorów wewnątrz samej grafiki (np. dwóch sąsiadujących segmentów wykresu kołowego) oraz względem otaczającego tła strony. Każda odrębna część przekazująca informacje musi indywidualnie osiągać 3:1.
6. Sprawdź wszystkie stany komponentów: Elementy interaktywne mają wiele stanów — domyślny, hover, focus, active, selected, checked, error i success. Przetestuj każdy stan osobno. Obramowanie przycisku, które spełnia wymogi w stanie domyślnym, może nie spełniać ich w stanie hover, jeśli kolor zmienia się na wariant o niskim kontraście.

Jak Naprawić

Obramowanie pola formularza — Nieprawidłowe

<!-- 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' />

Obramowanie pola formularza — Prawidłowe

<!-- 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' />

Przycisk zawierający wyłącznie ikonę — Nieprawidłowe

<!-- 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>

Przycisk zawierający wyłącznie ikonę — Prawidłowe

<!-- 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>

Niestandardowy checkbox — Nieprawidłowe

<!-- 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>

Niestandardowy checkbox — Prawidłowe

<!-- 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>

Wykres danych — Nieprawidłowe

<!-- 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>

Wykres danych — Prawidłowe

<!-- 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>

Typowe Błędy

• Używanie obramowania o szerokości jednego piksela, które spełnia 3:1, ale staje się niewidoczne przy niskim DPI: Nawet zgodny kolor może stać się niedostrzegalny, jeśli obramowanie ma tylko 1 px szerokości na ekranie o niskiej rozdzielczości. Użyj border: 2px solid lub widocznego box-shadow wraz ze zgodnym kolorem, aby zapewnić fizyczną dostrzegalność granicy.
• Założenie, że tło jest zawsze białe: Gdy pole formularza lub ikona pojawia się wewnątrz karty lub panelu bocznego z jasnoszarym tłem (#f5f5f5), kontrast musi być mierzony względem tej szarości, a nie względem bieli. Obramowanie, które spełnia wymogi na białym tle, może ich nie spełniać na tle z odcieniem.
• Usuwanie domyślnego obrysu fokusu za pomocą outline: none bez zapewnienia odpowiednika: To jeden z najczęstszych przypadków naruszenia 1.4.11. Ustawienie globalnie :focus { outline: none; } niszczy widoczność fokusu dla użytkowników klawiatury. Zawsze zastępuj je niestandardowym stylem fokusu, który osiąga co najmniej 3:1 względem tła.
• Traktowanie stanu wyłączonego jako pretekstu do pominięcia wszystkich sprawdzeń kontrastu: Komponenty wyłączone są zwolnione, ale deweloperzy czasem oznaczają elementy jako wizualnie wyłączone poprzez stylizację o niskim kontraście, nie dodając faktycznie atrybutu disabled ani aria-disabled='true'. Element, który wygląda na wyłączony, ale nadal jest interaktywny, musi nadal spełniać 1.4.11.
• Poleganie wyłącznie na kolorze w celu odróżnienia segmentów wykresu bez oddzielającego obrysu: Dwa sąsiadujące segmenty wykresu, gdzie jedynym wyróżnikiem jest odcień (np. jasnoniebieski vs. jasnozielony), mogą nie spełniać wymogów, jeśli ich współczynnik kontrastu jest poniżej 3:1. Dodanie 2‑pikselowego białego lub ciemnego obrysu pomiędzy segmentami jest niezawodnym rozwiązaniem.
• Stosowanie poprawek kontrastu wyłącznie do stanu domyślnego i zapominanie o stanach hover, focus, error i success: Każdy stan interaktywny ma własną prezentację wizualną. Obramowanie przycisku, które spełnia wymogi w stanie domyślnym, może przechodzić w kolor o niskim kontraście w stanie hover. Wszystkie stany muszą być testowane niezależnie.
• Osadzanie ikon jako obrazów tła i poleganie na kolorze CSS dla kontrastu: Ikony SVG wstawione inline w HTML reagują na color i currentColor, ale ikony użyte jako background-image w CSS nie mogą być zmieniane kolorystycznie za pomocą CSS. Jeśli sam plik ikony ma niewystarczający kontrast, żadna poprawka CSS nie rozwiąże problemu bez zastąpienia zasobu.
• Zapominanie, że tekst zastępczy (placeholder) w polach wprowadzania nie jest objęty 1.4.11, ale nadal podlega regulacjom: Tekst zastępczy podlega 1.4.3 (kontrast tekstu 4.5:1), a nie 1.4.11. Deweloperzy czasem błędnie stosują próg 3:1 do tekstu zastępczego, tworząc odrębne, niezauważone naruszenie 1.4.3.
• Używanie przejść CSS, które animują przez niezgodny kolor pośredni: Element może animować z koloru spełniającego wymogi przez kolor pośredni niespełniający wymogów do innego koloru spełniającego wymogi. Nawet jeśli stany początkowy i końcowy są zgodne, komponent wizualny jest technicznie niezgodny podczas trwania przejścia. Używaj zapytań medialnych prefers-reduced-motion rozważnie i unikaj prowadzenia przejść przez stany o niskim kontraście.
• Ignorowanie pasków postępu, suwaków zakresu (range inputs) i przełączników (toggle switches): Te niestandardowe komponenty UI są często stylizowane bez uwzględnienia 1.4.11. Wypełniona część paska postępu musi mieć kontrast 3:1 względem toru; pokrętło przełącznika musi kontrastować z tłem przełącznika; suwak zakresu musi kontrastować z torem.

Związek z Tureckimi Regulacjami Dotyczącymi Dostępności

Turecka Okrężnica Prezydencka nr 2025/10, opublikowana w Dzienniku Urzędowym nr 32933 w dniu 21 czerwca 2025 r., ustanawia obowiązkowe wymagania dotyczące dostępności stron internetowych i aplikacji mobilnych dla szerokiego zakresu podmiotów publicznych i prywatnych działających w Turcji. Okrężnica przyjmuje WCAG 2.2 jako normatywny standard techniczny, a zgodność na poziomie AA jest wymaganym progiem.

WCAG 1.4.11 Kontrast elementów nietekstowych, jako kryterium na poziomie AA, jest zatem bezpośrednio egzekwowalne na mocy Okrężnicy. Organizacje objęte regulacją muszą zapewnić, że wszystkie granice komponentów UI, stany kontrolek interaktywnych oraz znaczące obiekty graficzne w ich zasobach cyfrowych spełniają wymóg kontrastu 3:1 dla elementów nietekstowych.

Podmioty objęte Okrężnicą Prezydencką 2025/10 obejmują instytucje i agencje publiczne na wszystkich szczeblach administracji, platformy e‑commerce, banki i instytucje finansowe, szpitale i prywatnych świadczeniodawców opieki zdrowotnej, operatorów telekomunikacyjnych z 200 000 lub większą liczbą abonentów, biura podróży, prywatne firmy transportowe oraz szkoły prywatne upoważnione przez Ministerstwo Edukacji Narodowej (MoNE). Dla tych organizacji brak wdrożenia 1.4.11 nie jest jedynie brakiem dobrych praktyk, lecz stanowi niezgodność regulacyjną.

Logo Dostępności (Erişilebilirlik Logosu), wydawane przez Ministerstwo Rodziny i Usług Społecznych, służy jako publicznie widoczny znak certyfikacji dla zgodnych usług cyfrowych. Aby uzyskać i wyświetlać to logo, organizacja musi wykazać pełną zgodność na poziomie AA we wszystkich mających zastosowanie kryteriach WCAG 2.2, w tym 1.4.11. Ponieważ wiele tureckich portali e‑administracji, interfejsów bankowych i formularzy medycznych szeroko wykorzystuje niestandardowo stylizowane kontrolki formularzy i wizualizacje danych, kontrast elementów nietekstowych jest kryterium, które audytorzy szczególnie często oceniają podczas procesu certyfikacji.

Organizacje korzystające z nakładki Accsible powinny być świadome, że technologia overlay może pomóc w korygowaniu niektórych zmian kontrastu w czasie rzeczywistym — na przykład umożliwiając użytkownikom aktywację motywu wysokiego kontrastu — ale trwałe błędy strukturalne, takie jak pole formularza renderowane z kontrastem obramowania 1.6:1, muszą zostać naprawione na poziomie kodu źródłowego, aby osiągnąć rzeczywistą zgodność i kwalifikować się do Erişilebilirlik Logosu. Połączenie poprawek na poziomie źródła z funkcjami ulepszającymi widocznymi dla użytkownika, oferowanymi przez widżet dostępności, stanowi najbardziej obronną postawę zgodności z prawem tureckim.