Kolorystyka a dostępność cyfrowa – jak projektować dla wszystkich?

Autor: Krzysztof Ścira

Kontrast to liczba, nie wrażenie. Jak mierzyć kontrast wg WCAG 2.2, jakich narzędzi używać i dlaczego kolor nie może być jedynym nośnikiem informacji w interfejsie.

Projektant zmieniający kolory interfejsu z uwzględnieniem kontrastu i zasad dostępności cyfrowej — Ilustracja pokazująca, jak dobór kolorów wpływa na dostępność – przykład projektowania przyjaznego osobom z różnymi potrzebami wzrokowymi

Kolory budują interfejs — ale mogą też wykluczać

Kolory pełnią w interfejsie kilka funkcji jednocześnie: budują hierarchię informacji, wzmacniają komunikaty (czerwony = błąd, zielony = sukces), kształtują nastrój i rozpoznawalność marki. Problem w tym, że nie każdy użytkownik widzi te kolory tak samo. Osoby z zaburzeniami widzenia barw (ok. 8% mężczyzn i 0,5% kobiet w populacji europejskiej), osoby słabowidzące, seniorzy z osłabionym wzrokiem, a nawet zdrowy człowiek pracujący na laptopie w pełnym słońcu — wszyscy mogą mieć kłopot z interfejsem, który nie był projektowany z myślą o dostępności kolorystycznej.

W tym artykule omawiamy konkretne wymagania, narzędzia i decyzje projektowe, które pomagają tworzyć dostępne interfejsy bez rezygnowania z estetyki.

Kontrast — liczba, nie wrażenie

Kontrast to stosunek luminancji (jasności odbieranej) między kolorem tekstu a kolorem tła. WCAG 2.2 definiuje minimalne wartości na dwóch poziomach:

Minimalne kontrasty wg WCAG 2.2 (kryteria 1.4.3 i 1.4.11)
Element	Poziom AA	Poziom AAA
Tekst zwykły (<18 pt / <14 pt pogrubiony)	4,5:1	7:1
Tekst duży (≥18 pt / ≥14 pt pogrubiony)	3:1	4,5:1
Elementy interfejsu (przyciski, ikony, obramowania)	3:1	—

Warto wiedzieć, że te wartości to algorytm oparty na luminancji względnej, nie na „wzrokowym wrażeniu". Szary tekst (#767676) na białym tle daje kontrast dokładnie 4,54:1 — przechodzi AA, choć wielu osobom wydaje się nieczytelny. To pokazuje, że spełnienie formalnych wymagań to minimum, nie cel sam w sobie.

Trwają prace nad nowym algorytmem oceny kontrastu — APCA (Accessible Perceptual Contrast Algorithm), opracowanym w ramach prac nad WCAG 3.0. APCA lepiej oddaje rzeczywistą percepcję kontrastu, uwzględniając m.in. efekt polarity (ciemny tekst na jasnym tle jest czytelniejszy niż odwrotnie przy tych samych wartościach luminancji). Na razie APCA nie jest jeszcze standardem, ale warto śledzić postępy.

Narzędzia do sprawdzania kontrastu

Ręczne obliczanie kontrastów nie ma sensu — są do tego narzędzia, z których korzystam na co dzień:

WebAIM Contrast Checker (webaim.org) — wpisujesz dwa kolory, dostajesz wynik i ocenę AA/AAA. Proste, szybkie, bez instalacji.
Color Contrast Analyzer (TPGi) — aplikacja desktopowa z pipetą, pozwala sprawdzić kontrast dowolnych elementów na ekranie, nie tylko w przeglądarce.
Stark (getstark.co) — wtyczka do Figmy, Sketcha i Adobe XD. Sprawdza kontrast i symuluje zaburzenia widzenia barw bezpośrednio w makiecie.
Color Oracle (colororacle.org) — darmowe narzędzie desktopowe, które nakłada filtr symulujący protanopię, deuteranopię i tritanopię na cały ekran.

Jeśli pracujesz w Figmie, Stark pozwala sprawdzić kontrast jeszcze na etapie projektowania — zanim cokolwiek trafi do kodu. To oszczędza czas i pieniądze.

Kolor nie może być jedynym nośnikiem informacji

To jedno z najczęściej łamanych wymagań WCAG (kryterium 1.4.1 — Use of Color). Typowe problemy:

Formularze: błędne pole oznaczone tylko czerwoną ramką, bez ikony ani tekstu „Pole wymagane".
Wykresy: legendy oparte wyłącznie na kolorze — osoba z deuteranopią nie odróżni zielonej linii od czerwonej.
Statusy: „aktywny" = zielony, „nieaktywny" = szary — bez dodatkowego tekstu, ikony lub wzoru.

Rozwiązanie jest proste: do koloru zawsze dodajemy drugi kanał informacji — tekst, ikonę, wzór (kreskowany, kropkowany) lub zmianę kształtu. Nawet osoby bez zaburzeń widzenia barw skorzystają na takiej redundancji, bo kolor może być zniekształcony przez ustawienia monitora, filtr nocny czy pracę na słabym wyświetlaczu.

Dobieranie palet — teoria kolorów w praktyce dostępności

Dobra paleta kolorystyczna to kompromis między estetyką, identyfikacją marki i kontrastem. Kilka zasad, które sprawdzają się w naszych projektach:

Kolory analogiczne (sąsiadujące na kole barw, np. niebieski + turkusowy) tworzą harmonijne zestawienia, ale mogą mieć zbyt niski kontrast między sobą — nie nadają się do oznaczania odrębnych kategorii.
Kolory komplementarne (przeciwstawne, np. niebieski + pomarańczowy) dają wysoki kontrast, ale mogą być męczące wizualnie przy dużych powierzchniach. Sprawdzają się w akcentach (przyciski, ikony), nie w tle.
Test monochromatyczny — przefiltruj interfejs do skali szarości. Jeśli elementy nadal są rozróżnialne, paleta działa niezależnie od percepcji barw użytkownika.

Tryby wyświetlania i preferencje użytkownika

Projektowanie palety to nie jednorazowa decyzja — trzeba ją przetestować w różnych trybach wyświetlania. Użytkownik może korzystać z trybu ciemnego, trybu wysokiego kontrastu albo filtra światła niebieskiego, a każdy z nich zmienia odbiór kolorów.

W CSS możemy reagować na preferencje systemowe użytkownika:

@media (prefers-color-scheme: dark) { /* kolory dla trybu ciemnego */
}
@media (prefers-contrast: more) { /* kolory dla trybu wysokiego kontrastu */
}
@media (prefers-reduced-motion: reduce) { /* redukcja animacji */
}

Więcej o trybach wyświetlania pisaliśmy w artykule o Light Mode, Dark Mode, Sepia i Hi-Contrast.

Wskazówki dla programistów

Stosuj semantyczny HTML i atrybuty ARIA — role="alert", aria-live, aria-label — żeby komunikaty nie polegały wyłącznie na kolorze.
Zadbaj o widoczność focusa — użytkownik klawiatury musi widzieć, który element jest aktywny. :focus-visible pozwala ostylować focus bez irytowania użytkowników myszy.
Deklaruj obsługę trybów kontrastowych za pomocą @media (forced-colors: active) — to media query dla Windows High Contrast Mode, które nadpisuje Twoje kolory systemowymi. Testuj, czy interfejs nadal działa w tym trybie.

Co sprawdzić w swoim projekcie

Zmierz kontrasty — przynajmniej dla tekstu na głównych tłach, przycisków i komunikatów błędów. Cel: AA (4,5:1 dla tekstu, 3:1 dla elementów UI).
Przefiltruj do szarości — włącz Color Oracle lub filtr monochromatyczny w systemie. Czy rozróżniasz statusy, kategorie, przyciski?
Dodaj drugi kanał informacji — wszędzie tam, gdzie kolor niesie znaczenie, dodaj tekst, ikonę lub wzór.
Przetestuj w trybie ciemnym i hi-contrast — włącz motyw kontrastowy w Windows lub prefers-contrast: more w DevTools.
Zapytaj użytkowników — jeśli masz dostęp do osób z zaburzeniami widzenia barw (szacunkowo co 12. mężczyzna w Twoim zespole), poproś o feedback.

Kolory w interfejsie to nie dekoracja — to warstwa informacyjna, która musi działać dla wszystkich. Jeśli chcesz sprawdzić, czy Twoja aplikacja spełnia wymagania dostępności kolorystycznej, zamów audyt WCAG lub skontaktuj się z nami.

Źródła

W3C WCAG 2.2 — Understanding Contrast (Minimum) — wyjaśnienie kryterium 1.4.3 dotyczącego minimalnego kontrastu.
W3C WCAG 2.2 — Understanding Use of Color — kryterium 1.4.1 zabraniające polegania wyłącznie na kolorze.
WebAIM Contrast Checker — narzędzie online do sprawdzania współczynnika kontrastu.
Color Oracle — symulator zaburzeń widzenia barw (protanopia, deuteranopia, tritanopia).
Stark — Accessibility Tools — wtyczka do Figmy i Sketcha do analizy kontrastu i symulacji wad wzroku.
APCA — Why APCA — dokumentacja nowego algorytmu kontrastu rozwijanego w ramach WCAG 3.0.