Jak audytować kontrast kolorów bez instalowania czegokolwiek

Audyty kontrastu kolorów często traktuje się jak specjalistyczne zadanie z zakresu dostępności: otworzyć plik projektowy, zainstalować wtyczkę, wyeksportować zrzuty ekranu, uruchomić raport, spierać się o kolory marki. To może być przydatne, ale nie od tego większość zespołów powinna zaczynać.

W przypadku produkcyjnej strony internetowej najszybszy wiarygodny audyt zwykle wykonuje się w przeglądarce, którą i tak masz już otwartą. Nowoczesne browser DevTools potrafią sprawdzać obliczone kolory, pokazywać współczynniki kontrastu, ujawniać style stanów i pomagać testować kłopotliwe przypadki, które umykają automatycznym raportom.

Ten poradnik zakłada, że niczego nie instalujesz. Żadnych rozszerzeń przeglądarki. Żadnych wtyczek projektowych. Żadnego płatnego pakietu audytowego. Tylko strona, przeglądarka i prosta metoda.

Reguły kontrastu, których naprawdę potrzebujesz

W większości prac webowych kontrast WCAG sprowadza się do kilku progów:

• Zwykły tekst: co najmniej 4.5:1 kontrastu względem tła.
• Duży tekst: co najmniej 3:1. WCAG definiuje to mniej więcej jako 24 piksele CSS albo około 18,66 piksela CSS, jeśli tekst jest pogrubiony.
• Komponenty UI i obiekty graficzne: co najmniej 3:1 dla znaczących granic, ikon, stanów i części wykresów potrzebnych do zrozumienia interfejsu.
• Podwyższony kontrast: 7:1 dla zwykłego tekstu i 4.5:1 dla dużego tekstu, jeśli celujesz powyżej poziomu bazowego.

Istnieją wyjątki, takie jak nieaktywne kontrolki, elementy dekoracyjne i logotypy. Korzystaj z tych wyjątków oszczędnie. „To część marki” nie jest wyjątkiem; to ograniczenie projektowe.

Pamiętaj też, że kontrast to tylko jedna część dostępnego użycia koloru. Jeśli czerwony stan błędu ma wystarczający kontrast, ale nie ma tekstu, etykiety ikony ani wskazania programistycznego, nadal może zawodzić użytkowników, którzy nie odróżniają czerwieni od pobliskich kolorów.

Zacznij od wyrenderowanej strony, nie od pliku projektowego

Pliki projektowe są przydatne, ale nie obejmują wszystkich zmiennych z rzeczywistego świata: nadpisań CSS, opacity, stanów hover, renderowania fontów przez przeglądarkę, powiększenia użytkownika, trybu ciemnego, stylów dziedziczonych, treści z CMS i osadzeń marketingowych.

Audytuj stronę taką, jaką otrzymują użytkownicy.

Otwórz stronę w aktualnej przeglądarce desktopowej. Chrome, Edge, Firefox i Safari mają użyteczne narzędzia inspekcji. Dokładne etykiety się różnią, ale workflow jest taki sam:

1. Kliknij tekst lub element UI prawym przyciskiem.
2. Wybierz Inspect.
3. Znajdź obliczone color i background-color.
4. Użyj próbnika koloru lub panelu dostępności w przeglądarce, aby odczytać współczynnik kontrastu.
5. Zanotuj: zaliczone, niezaliczone i niepewne.

W przeglądarkach opartych na Chromium selektor kolorów często pokazuje współczynnik kontrastu oraz wskazówki pass/fail WCAG dla tekstu. Firefox DevTools również udostępnia informacje o dostępności i narzędzia kolorów. Safari’s Web Inspector może pokazywać obliczone style i informacje o dostępności, choć workflow jest nieco inny.

Kluczowa nie jest konkretna przeglądarka. Kluczowe jest odczytanie obliczonego wyniku, a nie wartości, której ktoś spodziewa się po komponencie.

Najpierw zbuduj krótką listę audytową

Nie sprawdzaj losowego tekstu, aż się zmęczysz. Przygotuj krótki spis wzorców:

• Tekst główny na podstawowym tle strony.
• Tekst przygaszony, podpisy, metadane i placeholdery.
• Linki w stanach normalnym, hover, visited i focus.
• Przyciski primary, secondary i destructive.
• Etykiety formularzy, tekst pomocy, błędy i komunikaty sukcesu.
• Elementy nawigacji, breadcrumbs i tabs.
• Karty, badges, pills i tags.
• Ikony przekazujące znaczenie.
• Wykresy, mapy, paski postępu i kolory statusów.
• Tekst na obrazach, wideo, gradientach lub półprzezroczystych nakładkach.

To wystarczy, aby znaleźć większość problemów na typowej stronie. Utrzymuje to też audyt przywiązany do komponentów, a nie pojedynczych pikseli.

Jeśli audyt obejmuje przyciski, połącz sprawdzanie kontrastu z podstawami z naszej listy kontrolnej dostępnych przycisków webowych. Problemy z kontrastem przycisków często występują obok brakujących stanów fokusu, niejasnych etykiet lub zepsutej obsługi klawiatury.

Sprawdź kontrast tekstu w DevTools

W przypadku zwykłego tekstu na jednolitym tle przeglądarka zwykle potrafi obliczyć kontrast za Ciebie.

Sprawdź element i poszukaj właściwości color. Otwórz selektor kolorów z próbki. Jeśli przeglądarka potrafi określić tło, pokaże współczynnik kontrastu. Niektóre narzędzia rysują też linię w selektorze kolorów pokazującą, gdzie kolor spełniłby 3:1, 4.5:1 lub 7:1.

Gdy przeglądarka zgłasza niepowodzenie, uwierz jej, dopóki nie możesz udowodnić inaczej. Gdy zgłasza zaliczenie, nadal używaj oceny. Mały cienki krój pisma, słabej jakości wyświetlacze, mocny antyaliasing i ruchliwe tła mogą sprawić, że tekst technicznie spełniający wymagania będzie wydawał się słaby.

Praktyczna zasada: jeśli tekst główny ledwo przechodzi przy 4.55:1, nie świętuj. Daj mu więcej zapasu. Wymagania kontrastu to minima, nie idealne cele.

Typografia również ma znaczenie. Większy, czytelniejszy system typograficzny zmniejsza wysiłek, zanim w ogóle sięgniesz po korekty kolorów. Jeśli strona sprawia wrażenie trudnej do czytania mimo zaliczonego kontrastu, wróć do długości wiersza, rozmiaru, grubości i odstępów, używając szerszego spojrzenia na czytelność, takiego jak ten praktyczny przewodnik po czytelnej typografii.

Sprawdź rzeczywiste tło, w tym opacity

Wiele błędów kontrastu pojawia się dlatego, że widoczne tło nie jest tłem zadeklarowanym.

Typowe pułapki obejmują:

• Tekst w półprzezroczystej karcie.
• Tekst na rodzicu z zastosowanym opacity.
• Nakładki używające rgba() lub color-mix().
• Gradienty za nagłówkami.
• Obrazy tła zmieniające się w obszarze tekstu.
• Zmienne motywu, które zmieniają się w trybie ciemnym.

Jeśli DevTools nie potrafią pewnie obliczyć kontrastu, ręcznie ustal wyrenderowane kolory pierwszego planu i tła. Użyj panelu obliczonych stylów, tymczasowo wyłącz warstwy albo pobierz próbkę widocznego koloru wbudowanym selektorem kolorów, jeśli Twoja przeglądarka to obsługuje.

W przypadku tekstu na obrazach nie pobieraj próbki z najładniejszej części obrazu. Pobierz próbkę z najgorszego wiarygodnego obszaru za tekstem. Jeśli obraz zmienia się przez przesyłanie w CMS, karuzele lub responsywne kadrowanie, nie jest to stabilny system kontrastu. Dodaj niezawodną nakładkę, cień tekstu, stały kontener lub gradient, który chroni tekst niezależnie od obrazu.

Dobry system nakładek na obrazy jest nudny: ta sama siła nakładki, przewidywalny obszar kadru, wystarczający kontrast nawet przy jasnych zdjęciach. Nuda jest w porządku. Użytkownicy próbują czytać.

Nie zapominaj o stanach

Statyczne zrzuty ekranu pomijają wiele problemów z kontrastem. Audytuj stany interakcji bezpośrednio w przeglądarce.

W DevTools wymuś pseudoklasy takie jak:

• :hover
• :focus
• :focus-visible
• :active
• :visited
• :disabled
• :checked
• :invalid

Następnie ponownie sprawdź obliczone kolory.

Wskaźniki fokusu zasługują na szczególną uwagę. WCAG 2.2 zaostrzyło oczekiwania dotyczące wyglądu fokusu, a jasnoniebieski obrys na jasnoszarej karcie nadal jest częstym błędem. Wskaźnik fokusu potrzebuje wystarczającego kontrastu względem sąsiednich kolorów i wystarczającej powierzchni, aby był zauważalny.

Dla wyłączonych kontrolek reguły kontrastu WCAG przewidują wyjątek dla komponentów nieaktywnych. Nie oznacza to, że stany wyłączone domyślnie powinny być nieczytelne. Jeśli stan wyłączony przekazuje użyteczną informację, spraw, aby był czytelny. Jeśli nie, zastanów się, czy w ogóle powinien być obecny.

Używaj Lighthouse, ale nie zlecaj mu osądu

Audyty przeglądarkowe, takie jak Lighthouse, mogą szybko wychwycić niektóre problemy z kontrastem. Uruchom wbudowany audyt, jeśli Twoja przeglądarka go udostępnia, a następnie traktuj wyniki jako punkt wyjścia.

Automatyczne kontrole dobrze znajdują węzły tekstowe z oczywistymi problemami obliczonego kontrastu. Słabiej radzą sobie z:

• Tekstem osadzonym w obrazach.
• Etykietami renderowanymi na canvas.
• Przypadkami brzegowymi SVG.
• Problemami widocznymi tylko w hover.
• Jakością wskaźnika fokusu.
• Wykresami, na których relacje kolorów niosą znaczenie.
• Komponentami ukrytymi za uwierzytelnianiem, menu lub krokami formularza.

Jeśli raport wraca na zielono, nadal musisz sprawdzić reprezentatywne komponenty. Jeśli raport wraca na czerwono, unikaj paniki i segreguj problemy według wpływu na użytkownika. Ta sama zasada dotyczy ogólnie raportów wydajności i dostępności: czytaj wynik narzędzia jako dowód, nie jako wyrok. Stosujemy takie podejście w naszym przewodniku po czytaniu raportu Lighthouse bez paniki, i tutaj pasuje ono równie dobrze.

Audytuj też kontrast elementów nietekstowych

Tekst przyciąga większość uwagi, ale WCAG obejmuje też treści nietekstowe potrzebne do zrozumienia lub obsługi interfejsu.

Sprawdź co najmniej te przypadki:

• Obramowania pól input względem tła strony.
• Obrysy checkbox i radio.
• Stany przełączników.
• Przyciski tylko z ikoną.
• Ikony błędów i symbole ostrzeżeń.
• Linie, słupki i etykiety wykresów.
• Wskaźniki postępu.
• Wskaźniki wybranej karty lub aktywnej nawigacji.

Cel to zwykle 3:1 względem sąsiednich kolorów. Na przykład jasnoszare obramowanie input na białym tle może być niemal niewidoczne. Wykres z pięcioma pastelowymi liniami może wyglądać elegancko, a nadal być bezużyteczny.

W przypadku wykresów sam kontrast nie wystarcza. Używaj etykiet, wzorów, stylów linii, bezpośrednich adnotacji lub odstępów, aby informacja nie zależała wyłącznie od koloru. Pomaga to użytkownikom z zaburzeniami widzenia barw, osobom słabowidzącym, ludziom patrzącym w odblasku i każdemu, kto czyta zrzut ekranu w dokumencie.

Zapisuj ustalenia w formacie użytecznym dla developerów

Użyteczny audyt kontrastu nie mówi „niektóre szarości nie przechodzą”. Wskazuje komponent, stan, bieżące wartości, oczekiwany próg i sugerowaną poprawkę.

Dobrze działa zwarty format:

| Komponent | Stan | Pierwszy plan | Tło | Współczynnik | Cel | Wynik | Sugerowana poprawka | |---|---:|---:|---:|---:|---:|---|---| | Metadane karty | Domyślny | #8A8F98 | #FFFFFF | 3.2:1 | 4.5:1 | Fail | Użyj --color-text-muted-strong | | Przycisk primary | Hover | #FFFFFF | #2F6FEA | 4.8:1 | 4.5:1 | Pass | Zostaw | | Obramowanie input | Domyślny | #D7DCE2 | #FFFFFF | 1.4:1 | 3:1 | Fail | Przyciemnij token obramowania |

Powiąż poprawki z design tokens, jeśli strona ich używa. Nie łataj dwudziestu pojedynczych komponentów, jeśli prawdziwym problemem jest jeden słaby token.

Wprowadzaj poprawki nieco mocniejsze niż minimum

Problemy z kontrastem często łatwo naprawić źle. Zespoły przesuwają kolor, aż checker pokaże 4.51:1, i idą dalej. To nie zostawia marginesu na renderowanie fontów, przezroczystość, różnice między przeglądarkami, motywy, zmienność obrazów ani przyszłe zmiany marki.

Preferuj komfortowe cele:

• Tekst główny: bliżej 7:1, gdy to praktyczne.
• Tekst przygaszony: nadal powyżej 4.5:1, jeśli jest rzeczywistą treścią.
• Obramowania i ikony UI: wyraźnie powyżej 3:1.
• Tekst na obrazach: użyj kontrolowanej nakładki zamiast zgadywania dla każdego obrazu.

Web jest oglądany na tanich laptopach, przygaszonych telefonach, jasnych chodnikach, zabarwionych monitorach i starzejących się wyświetlaczach. Minimalna zgodność to nie to samo co komfortowe czytanie.

<!-- tool-cta:start -->

💡 Wypróbuj to: Gdy sprawdzasz pary kontrastu pobrane z DevTools, Color Converter pomaga konwertować między hex, RGB i HSL, aby wartości zgadzały się z notatkami z audytu.

<!-- tool-cta:end -->

Lista kontrolna audytu kontrastu bez instalacji

Użyj tej sekwencji, gdy potrzebujesz szybkiego, ale wiarygodnego audytu:

1. Otwórz stronę produkcyjną w nowoczesnej przeglądarce.
2. Wypisz główne wzorce tekstu, UI i stanów.
3. Sprawdź w DevTools obliczone kolory pierwszego planu i tła.
4. Użyj wbudowanego selektora kolorów lub panelu dostępności, aby odczytać kontrast.
5. Wymuś stany hover, focus, active, visited i invalid.
6. Sprawdź tekst na obrazach i gradientach względem najgorszego wiarygodnego tła.
7. Sprawdź nietekstowe części UI względem wymagania 3:1.
8. Uruchom wbudowany automatyczny audyt jako siatkę bezpieczeństwa, nie jako cały audyt.
9. Zapisuj problemy według komponentu i tokenu.
10. Naprawiaj z marginesem, a nie przez ledwie przekroczenie progu.

To wystarczy, aby wychwycić większość problemów z kontrastem bez dodawania kolejnego narzędzia do stacku. Bardziej zaawansowane audyty nadal mają swoje miejsce, szczególnie przy dużych design systems, produktach regulowanych lub złożonych wizualizacjach danych. Ale dla wielu stron internetowych przeglądarka już daje dowody, których potrzebujesz. Najtrudniej jest być wystarczająco systematycznym, aby z nich skorzystać.