Należy sprawdzić kontrast każdej kombinacji tekstowej i funkcjonalnej w rzeczywistym stanie, a znaczenie koloru zawsze uzupełniać tekstem, ikoną, kształtem lub wzorem.
Kolor pomaga budować hierarchię i markę, ale nie może być jedynym nośnikiem znaczenia. Czerwone pole bez tekstu, zielony punkt bez opisu czy szary link bez podkreślenia mogą być niejasne przy zaburzeniach widzenia barw, na słabym wyświetlaczu, a także w pełnym słońcu. Kontrast należy oceniać między konkretnymi sąsiadującymi kolorami i w rzeczywistym stanie elementu.
Dostępny projekt nie oznacza ograniczenia strony do czerni i bieli. Wymaga zdefiniowanych par tekstowych i nietekstowych, dodatkowego wyróżnika stanu oraz testowania motywów, focusu, obrazów i wykresów. Aktualne wymagania WCAG i sposób obliczeń weryfikuj w oficjalnych źródłach; samo wrażenie wizualne czy nazwa koloru nie są pomiarem.
Tekst mierzy się względem rzeczywistego tła
Należy sprawdzać zwykły tekst, nagłówki, linki, etykiety, placeholdery, komunikaty o błędach oraz tekst na przyciskach. Tłem może być jednolity kolor, gradient, zdjęcie lub półprzezroczysta warstwa. W przypadku obrazu trzeba przetestować najsłabsze miejsce lub dodać stabilne podłoże. Cień tekstu nie jest niezawodnym zamiennikiem odpowiedniego zestawienia kolorów.
Rozmiar i grubość czcionki wpływają na kryterium, ale nie warto polegać na projekcie na granicy wymagań. Własny font może renderować się cieniej, a użytkownik może zmienić skalę. Proszę zdefiniować kolory jako tokeny z określonym dozwolonym zastosowaniem, aby redaktor przypadkowo nie wybrał jasnego tekstu dla małych podpisów lub linków.
Elementy sterujące i focus wymagają kontrastu nietekstowego
Obramowanie pola, ikona, zaznaczenie, graficzny przełącznik i wskaźnik fokusu niosą znaczenie funkcjonalne także bez tekstu. Proszę zweryfikować ich kontrast względem otoczenia i między stanami zgodnie z aktualnymi kryteriami. Jeśli pole zlewa się z tłem, użytkownik może nie zorientować się, gdzie pisać, choć jego etykieta ma doskonały kontrast.
Focus musi być odróżnialny od stanu bez fokusu, a także od sąsiednich kolorów. Hover nie zastępuje focusu, a selected nie zastępuje disabled. Proszę testować komponent na różnych powierzchniach, ponieważ ten sam niebieski obrys może działać na białej karcie i zniknąć na niebieskim banerze. System projektowy powinien określać dozwolone kombinacje.
- granice pól i aktywne elementy sterujące
- ikony niezbędne do zrozumienia funkcji
- widoczny fokus na każdej powierzchni
- rozróżnienie stanów active, selected, error i disabled
Stan musi mieć odpowiednik tekstowy lub w postaci kształtu
Błąd należy oznaczyć tekstem i powiązać z polem, sukces potwierdzić komunikatem, a obowiązkowość wyjaśnić słowem lub symbolem z legendą. W tabeli nie należy używać wyłącznie zielonych i czerwonych komórek. Warto dodać tekst, ikonę z dostępną nazwą lub wzór, który pozostanie zrozumiały także bez koloru.
Link w tekście ciągłym wyróżnij w sposób, który nie opiera się wyłącznie na odcieniu, na przykład podkreśleniem. Przy hover i focus wzmacniaj zmianę, a nie ją usuwaj. Sama ikona potrzebuje nazwy tekstowej, jeśli wykonuje akcję. Ikona dekoracyjna natomiast nie powinna być niepotrzebnie ogłaszana technologiom wspomagającym.
Wykresy, mapy i obrazy wymagają osobnego projektu danych
Na wykresie łącz kolor z kształtem punktu, rodzajem linii, wzorem lub bezpośrednim opisem. Legenda oddalona od danych zwiększa wysiłek. Zapewnij podsumowanie tekstowe, a w razie potrzeby dostępną tabelę. Nie zwiększaj liczby kolorowych serii ponad możliwość ich wiarygodnego rozróżnienia tylko dlatego, że narzędzie oferuje paletę.
Tekst umieszczony na obrazku trudno powiększyć i przetłumaczyć. Jeśli jest niezbędny, wymaga alternatywy i sprawdzonego kontrastu w ostatecznej wersji. Mapa nie powinna przekazywać stanu wyłącznie kolorem pinezek; lista miejsc lub filtry z tekstem umożliwią wykonanie tego samego zadania także użytkownikowi, który nie widzi kodu wizualnego.
- bezpośrednie opisy serii i wartości
- kształt lub wzór obok koloru
- tekstowe podsumowanie głównego wniosku
- alternatywna tabela dla szczegółowych danych
- kontrast sprawdzony we wszystkich motywach
- znaczenie statusu czytelne również bez koloru
- hover, focus i selected jako odrębne stany
- kontrola wynikowego koloru po zastosowaniu przezroczystości
- dozwolone pary kolorów w systemie projektowym
Testowanie obejmuje tokeny, treść i ustawienia użytkownika
Typowe kombinacje sprawdzaj automatycznie, ale ręcznie przejdź przez stany hover, focus, error, disabled, modal i treść dynamiczną. Testuj jasny i ciemny motyw, systemowy wysoki kontrast oraz wyłączone obrazy tła. Pipeta musi mierzyć kolor wynikowy po uwzględnieniu przezroczystości, a nie tylko wartość tokena w pliku źródłowym.
Do procesu publikacji warto dodać dozwolone style i kontrolę nowych komponentów. Zmiana palety barw marki wymaga audytu regresji, ponieważ może wpłynąć na dziesiątki stanów. Testy z użytkownikami ujawnią pomylenie znaczeń, którego sam współczynnik kontrastu nie pokaże. Spełnienie technicznego minimum nie gwarantuje komfortowego czytania.
Najczęstsze pytania
Czy wystarczy sprawdzić kontrast tekstu podstawowego?
Nie. Należy sprawdzić linki, opisy, placeholdery, przyciski, obramowania pól, ikony, focus i wszystkie stany interaktywne na ich rzeczywistym tle.
Czy możemy oznaczyć błąd kolorem czerwonym?
Tak, jako uzupełnienie, a nie jedyny sygnał. Należy dodać zrozumiały tekst, programowe powiązanie oraz w razie potrzeby ikonę lub inny znak wizualny.
Czy automatyczny test kontrastu jest wyczerpujący?
Nie. Może nie wychwycić wszystkich stanów, gradientów, obrazów ani znaczenia przekazywanego kolorem. Należy uzupełnić go kontrolą ręczną i testami z użytkownikami.
Źródła i dalsza lektura
Adam Antoni vyvíja weby, aplikácie a softvér na mieru. Prepája firemné systémy, automatizuje procesy a vytvára AI agentov. Pôsobí v Spišskej Novej Vsi a spolupracuje s firmami na celom Slovensku.
