Kontrast kolorów w projektowaniu stron internetowych: jak testować i naprawiać problemy z kontrastem

Wyobraź sobie osobę odwiedzającą Twoją stronę z osłabionym wzrokiem, siedzącą w zalanej słońcem kawiarni, z jasnością telefonu ustawioną na maksimum. Jeśli Twoje jasnoszare teksty akapitów znajdują się na białym tle, ta osoba po prostu nie jest w stanie przeczytać treści — niezależnie od tego, jak starannie dopracowałeś każde słowo. Ten scenariusz nie jest hipotetyczny: tekst o zbyt niskim kontraście wykryto na 83.9% spośród miliona najpopularniejszych stron głównych na początku 2026 roku, co czyni go najczęściej identyfikowaną barierą dostępności w sieci już siódmy rok z rzędu, przy czym każda problematyczna strona główna miała średnio 34 odrębne przypadki tego błędu.

Dlaczego kontrast kolorów ma większe znaczenie, niż myślisz

Większość osób zakłada, że problemy z kontrastem dotyczą wyłącznie użytkowników całkowicie niewidomych lub korzystających z czytników ekranu. Rzeczywistość jest znacznie szersza. Na świecie jest około 300 milionów osób z jakąś formą zaburzeń widzenia barw, a znacznie więcej doświadcza niskiego kontrastu jako codziennego źródła frustracji — osoby korzystające z tanich monitorów, ludzie ze starzejącym się wzrokiem czy każdy, kto przewija stronę na zewnątrz w słoneczny dzień. Słabowidzenie jest znacznie częstsze niż całkowita ślepota: prawie trzykrotnie więcej osób ma osłabiony wzrok niż całkowity jego brak.

Badania stojące za progami kontrastu WCAG czynią to bardzo konkretnym. Minimalny współczynnik 4.5:1 dla standardowego tekstu został skalibrowany tak, aby kompensować utratę czułości na kontrast typowo doświadczaną przez osobę o ostrości wzroku około 20/40 — wartości często raportowanej u osób w wieku około osiemdziesięciu lat. Bardziej rygorystyczny próg 7:1 na poziomie AAA w WCAG został skalibrowany podobnie: jest ukierunkowany na użytkowników o ostrości wzroku 20/80, kompensując utratę czułości na kontrast u osób słabowidzących, które nie korzystają z technologii asystujących.

Istnieją też bardzo realne konsekwencje prawne i biznesowe. Pozwy dotyczące dostępności w Stanach Zjednoczonych osiągnęły 4 605 zgłoszeń związanych z cyfrową dostępnością ADA w 2024 roku, a European Accessibility Act wszedł w życie w czerwcu 2025, rozszerzając obowiązek spełniania wymogów na szeroką gamę komercyjnych stron i aplikacji. Błędy kontrastu kolorów są wykrywalne, dokumentowane i rutynowo przywoływane w postępowaniach sądowych. Dla osób odpowiedzialnych za zgodność oznacza to, że ich naprawa jest priorytetem, a nie miłym dodatkiem.

Wreszcie, dostępny kontrast to po prostu dobry design. Tekst o wysokim kontraście jest łatwiejszy do skanowania dla wszystkich, zmniejsza obciążenie poznawcze i poprawia szybkość czytania w całym spektrum użytkowników — czyniąc z tego zarówno usprawnienie wyników biznesowych, jak i obowiązek zgodności.

Reguły kontrastu WCAG, które naprawdę musisz znać

WCAG 2 definiuje kontrast jako miarę różnicy w postrzeganej luminancji między dwoma kolorami. Wzór porównuje względną jasność koloru pierwszego planu z jego tłem i wyraża wynik jako współczynnik w zakresie od 1:1 (brak różnicy — biel na bieli) do 21:1 (maksymalna różnica — czerń na bieli). Nie musisz liczyć tego ręcznie; kluczowe jest zrozumienie, jakie współczynniki są wymagane i kiedy mają zastosowanie.

W ramach WCAG 2.x poziom AA — poziomu przywoływanego w większości przepisów i standardów dostępności — wymagania rozkładają się następująco:

• Normalny tekst (treść akapitów, etykiety, tekst UI poniżej 18pt lub 14pt pogrubiony): minimalny współczynnik kontrastu 4.5:1 względem tła.
• Duży tekst (co najmniej 18pt / 24px lub 14pt / ~18.66px pogrubiony): minimalny współczynnik kontrastu 3:1. Logika jest taka, że większe kształty liter są z natury łatwiejsze do rozróżnienia, więc uzasadniony jest łagodniejszy próg.
• Nietekstowe komponenty UI i grafiki informacyjne (Kryterium sukcesu 1.4.11, wprowadzone w WCAG 2.1): minimalny współczynnik kontrastu 3:1 względem sąsiadujących kolorów. Obejmuje to takie elementy jak obramowania pól formularzy, wskaźniki fokusu, przyciski z samą ikoną oraz części wykresów niezbędne do zrozumienia danych.

Na poziomie AAA poprzeczka jest wyżej: 7:1 dla normalnego tekstu i 4.5:1 dla dużego tekstu. Choć pełny poziom AAA rzadko jest wymagany, warto traktować go jako cel projektowy dla stron i interfejsów mocno tekstowych, gdzie dokładność czytania jest krytyczna.

Ważna subtelność: WCAG definiuje „duży tekst” przez rozmiar renderowany w przeglądarce, a nie przez wartość w Twoim CSS. Czcionka ustawiona na 1.2rem może kwalifikować się jako duży tekst lub nie — w zależności od bazowego rozmiaru czcionki w przeglądarce użytkownika. W razie wątpliwości stosuj próg 4.5:1 i używaj narzędzi do weryfikacji faktycznego rozmiaru renderowanego.

Niewielka liczba elementów jest wyraźnie wyłączona z wymogów kontrastu. Czysto dekoracyjne obrazy, nieaktywne (disabled) kontrolki formularzy, logotypy i prawdziwe fotografie nie podlegają kryterium sukcesu 1.4.3. To sensowny wyjątek — tło z znakiem wodnym czy zdjęcie produktu nie powinny być zmuszane do spełniania tego samego progu co etykieta nawigacyjna — ale zespoły często nadużywają go, by usprawiedliwić leniwe decyzje projektowe. Jeśli obraz lub grafika są niezbędne do zrozumienia treści strony, nadal muszą spełniać wymóg kontrastu nietekstowego 3:1.

Na uwagę zasługuje jeszcze jedna ważna reguła: WCAG 1.4.1 (Użycie koloru). Jeśli odróżniasz linki od otaczającego tekstu akapitów wyłącznie kolorem — bez podkreślenia, różnicy w grubości, czy innej wizualnej wskazówki — linki te muszą osiągać współczynnik kontrastu 3:1 względem sąsiadującego tekstu akapitów, oprócz spełnienia standardowego współczynnika 4.5:1 między tekstem a tłem. Jednoczesne spełnienie wszystkich trzech wymogów jest naprawdę trudne; najprostszym rozwiązaniem jest pozostawienie podkreśleń linków.

Jak testować błędy kontrastu

Testowanie kontrastu jest jednym z najbardziej „narzędziowych” obszarów pracy nad dostępnością. Podstawowe obliczenie jest matematyczne i deterministyczne, co oznacza, że narzędzia automatyczne mogą wykrywać je niezawodnie — w przeciwieństwie do wielu innych problemów dostępności, które wymagają oceny człowieka. Niemniej istnieją przypadki brzegowe, w których automatyzacja zawodzi, a zrozumienie całego stosu narzędzi testowych sprawi, że Twoje audyty będą znacznie bardziej kompletne.

Krok 1: Uruchom automatyczne skanowanie strony

WAVE (narzędzie WebAIM do oceny dostępności stron) i axe DevTools to dwa najczęściej używane skanery przeglądarkowe. Oba są dostępne jako rozszerzenia do Chrome i Firefoksa. Skanują renderowany DOM — czyli oceniają kolory tak, jak faktycznie rysuje je przeglądarka, po zastosowaniu CSS i JavaScript — i oznaczają elementy tekstowe, które nie spełniają progu kontrastu WCAG AA. Axe DevTools idzie dalej, raportując wagę każdego problemu, wiążąc go z odpowiednim kryterium sukcesu WCAG i dostarczając wskazówki dotyczące naprawy. Dla zespołów korporacyjnych axe-core można zintegrować bezpośrednio z pipeline’ami CI/CD, aby regresje kontrastu były wychwytywane przed wdrożeniem.

Google Lighthouse, wbudowany w Chrome DevTools, również wykonuje testy kontrastu w ramach audytu dostępności. To wygodny pierwszy krok — szczególnie przydatny, ponieważ jest już częścią workflow większości deweloperów — ale działa na podzbiorze reguł axe-core, więc nie jest tak kompleksowy jak pełne rozszerzenie axe DevTools.

Ważne ograniczenie: skanery automatyczne nie są w stanie wiarygodnie ocenić kontrastu tekstu umieszczonego na tle gradientowym, na obrazie tła, na półprzezroczystej warstwie lub na elemencie złożonym z wielu warstw CSS. Te przypadki wymagają ręcznej inspekcji.

Krok 2: Użyj selektora kolorów w Chrome DevTools do celowanej inspekcji

W Chrome DevTools, otwarcie panelu Styles dla dowolnego elementu i kliknięcie próbki koloru obok wartości koloru uruchamia wbudowany selektor, który pokazuje aktualny współczynnik kontrastu względem obliczonego tła elementu. Gdy kolor nie spełnia wymogów, DevTools oferuje funkcję autokorekty: podpowiada najbliższe kolory spełniające poziomy AA i AAA, dzięki czemu możesz przyjąć zgodną wartość jednym kliknięciem. Jest to nieocenione przy szybkim iterowaniu w trakcie developmentu. DevTools zawiera też emulator zaburzeń widzenia w panelu Rendering, pozwalający symulować rozmyty wzrok, protanopię, deuteranopię, achromatopsję i inne stany, aby uzyskać jakościowe wyczucie tego, jak osoby z zaburzeniami widzenia barw odbierają Twoją paletę.

Krok 3: Przetestuj konkretne pary kolorów dedykowanym narzędziem

Do walidacji pojedynczych kombinacji kolorów w oderwaniu od kontekstu — na przykład podczas przeglądu projektu w Figma, zanim cokolwiek zostanie zbudowane — branżowym standardem jest WebAIM Contrast Checker (webaim.org/resources/contrastchecker). Wprowadzasz wartości hex dla pierwszego planu i tła, a narzędzie natychmiast zwraca współczynnik kontrastu oraz ocenę zaliczone/niezaliczone dla AA i AAA przy normalnym i dużym rozmiarze tekstu. Aplikacja desktopowa Colour Contrast Analyser (CCA) dla Windows i macOS jest równie przydatna i obsługuje złożone przypadki, takie jak półprzezroczyste kolory pierwszego planu oraz próbkowanie koloru z ekranu z dowolnej aplikacji — nie tylko z przeglądarki.

Krok 4: Testuj w kontekście — tryb ciemny, stany hover i wskaźniki fokusu

W tym miejscu wiele zespołów popełnia błędy. Para kolorów, która przechodzi test w domyślnym jasnym motywie, może całkowicie zawieść w trybie ciemnym. Kolory akcentów marki, które wyglądają żywo na białym tle, często stają się błotniste lub rażące na ciemnej powierzchni. Każdy stan interakcji — hover, focus, active, visited — jest potencjalnym źródłem nowych błędów kontrastu. Podobnie wskaźniki fokusu (widoczna obwódka pojawiająca się, gdy użytkownik klawiatury przechodzi do kontrolki) muszą osiągać kontrast 3:1 względem sąsiadujących kolorów zgodnie z Kryterium sukcesu 1.4.11 WCAG 2.1. Zawsze testuj oba motywy przed wydaniem; tryb ciemny nie jest automatycznie dostępny tylko dlatego, że wygląda na dopracowany.

Najczęstsze błędy kontrastu — i jak je naprawić

Zrozumienie wzorców błędów, które najczęściej pojawiają się w audytach, pozwala lepiej priorytetyzować prace naprawcze. Większość problemów z kontrastem mieści się w przewidywalnym zestawie kategorii.

Szary tekst na białym tle

Średnie odcienie szarości, takie jak #767676 czy #999999 na białym tle, są wszechobecne we współczesnym płaskim designie. Dla projektantów z dobrze skalibrowanymi monitorami wydają się lekkie i wyrafinowane. Często nie spełniają progu 4.5:1 i są niewidoczne dla osób słabowidzących. Naprawa zwykle sprowadza się do prostej zmiany wartości koloru — przesunięcie #767676 (który ledwo przechodzi z wynikiem 4.54:1) na #595959 daje współczynnik 7.0:1 i znacząco lepszą czytelność, przy minimalnej różnicy wizualnej dla większości widzących użytkowników.

Pracując w HSL — bardziej intuicyjnym modelu kolorów do regulowania kontrastu — musisz zmodyfikować tylko komponent Lightness, aby zmienić współczynnik kontrastu, zachowując wybrany odcień (Hue) i nasycenie (Saturation). Na białym tle zmniejszenie wartości Lightness przyciemnia tekst i poprawia kontrast; na ciemnym tle jej zwiększenie rozjaśnia tekst. Niewielkie zmiany Lightness (2–5 punktów procentowych) często wystarczą, by przejść od wyniku negatywnego do wyraźnego zaliczenia AA bez zauważalnej zmiany projektu.

/* Przed: nie spełnia WCAG AA (współczynnik ~3.9:1 na bieli) */
.body-text {
  color: #888888;
}

/* Po: spełnia WCAG AA i AAA (współczynnik ~7.0:1) */
.body-text {
  color: #595959;
}

Tekst zastępczy (placeholder) w polach formularzy

Tekst zastępczy renderowany domyślnym stylem przeglądarki — zazwyczaj jasnoszary około #AAAAAA lub #BBBBBB — niemal zawsze nie spełnia WCAG AA na białym tle pola. Wielu projektantów celowo utrzymuje niski kontrast placeholderów, aby wizualnie odróżnić je od treści wprowadzanej przez użytkownika, ale nie jest to dozwolony wyjątek. Tekst zastępczy jest tekstem interfejsu użytkownika i musi spełniać standard 4.5:1. Użyj ciemniejszego odcienia i oprzyj się na kursywie, pozycjonowaniu lub animacji, aby stworzyć wizualne odróżnienie zamiast na jasności.

::placeholder {
  /* Nie spełnia: #AAAAAA to około 2.3:1 na bieli */
  color: #AAAAAA;
}

::placeholder {
  /* Spełnia: #767676 to około 4.54:1 na bieli */
  color: #767676;
  font-style: italic; /* Alternatywna wskazówka wizualna */
}

Biały lub jasny tekst na średnio nasyconym kolorze marki

Kolory marki w średnim zakresie nasycenia — typowe błękity, zielenie i fiolety w zakresie jasności #5–6 w HSL — często nie zapewniają wystarczającego kontrastu dla białego tekstu nałożonego na nie. Intensywny niebieski kolor marki, który świetnie wygląda w logo, może dawać jedynie współczynnik 2.8:1 względem bieli, znacznie poniżej minimum 4.5:1 dla tekstu akapitów. Rozwiązaniem jest albo przyciemnienie koloru tła (przesunięcie odcienia marki do tokena 800 lub 900 w systemie projektowym), przejście na ciemny tekst na tym tle, albo zarezerwowanie średniego odcienia dla elementów czysto dekoracyjnych, do których reguły kontrastu nie mają zastosowania.

Tekst na obrazach tła lub gradientach

Tekst umieszczony bezpośrednio na fotografii lub gradiencie jest jednym z najtrudniejszych przypadków, ponieważ luminancja tła nie jest jednolita — współczynnik kontrastu zmienia się w różnych częściach obrazu. Najbardziej niezawodną naprawą jest półprzezroczysta ciemna lub jasna nakładka w CSS, zastosowana jako pseudo-element, tak aby obraz pozostał widoczny pod spodem. Czarna nakładka o kryciu około 50–60% zazwyczaj podnosi biały tekst z marginalnego kontrastu do solidnego poziomu AAA.

.hero {
  position: relative;
}

.hero::after {
  content: '';
  position: absolute;
  inset: 0;
  background: rgba(0, 0, 0, 0.55);
}

.hero__text {
  position: relative;
  z-index: 1;
  color: #ffffff;
}

Elementy UI w stanie disabled i drugorzędne

WCAG wyraźnie wyłącza nieaktywne (disabled) komponenty UI z wymogów kontrastu — nieaktywny przycisk nie musi spełniać progu 4.5:1. Jednak wiele zespołów nadmiernie stosuje ten wyjątek do tekstu drugorzędnego, podpisów, tekstów pomocniczych i etykiet, które w rzeczywistości nie są nieaktywne. Jeśli element przekazuje informacje, których użytkownik potrzebuje, aby zrozumieć lub wykonać działanie, musi spełniać odpowiedni standard kontrastu niezależnie od swojej pozycji w hierarchii wizualnej. Sprawdź każdy odcień w neutralnej skali kolorów systemu projektowego względem teł, na których się pojawia.

Wbudowywanie kontrastu w system projektowy

Reaktywne naprawianie pojedynczych błędów kontrastu jest powolne i podatne na pomyłki. Trwalszym podejściem jest wbudowanie zgodności kontrastu w system projektowy, tak aby dostępne pary kolorów były domyślnym wynikiem, a nie dodatkiem na końcu.

Fundamentem jest odpowiednio stopniowana skala tokenów. Każdy kolor w palecie powinien mieć udokumentowane współczynniki kontrastu, wstępnie obliczone względem standardowych kolorów tła. Rozsądną konwencją jest etykietowanie tokenów według ich zachowania w kontrastach: token --color-text-primary powinien zawsze spełniać AA na --color-surface-default, a ta gwarancja powinna być udokumentowana, przetestowana i egzekwowana. Gdy projektant sięga po token do pokolorowania tekstu, powinien móc ufać, że spełnia on minimum, bez konieczności każdorazowego ręcznego sprawdzania.

Niestandardowe właściwości CSS czynią to szczególnie wykonalnym. Możesz zdefiniować całą paletę jako zmienne i użyć zapytań medialnych, aby podmieniać je w trybie ciemnym bez twardego kodowania par kolorów — utrzymując zarządzanie zgodnością kontrastu w jednym miejscu.

:root {
  --color-surface-default: #ffffff;
  --color-text-primary: #1a1a1a;   /* ~16:1 na bieli */
  --color-text-secondary: #595959; /* ~7.0:1 na bieli */
  --color-text-subtle: #767676;    /* ~4.54:1 na bieli */
  --color-accent: #0052cc;         /* ~8.0:1 na bieli */
}

@media (prefers-color-scheme: dark) {
  :root {
    --color-surface-default: #121212;
    --color-text-primary: #ededed;   /* ~14.5:1 na #121212 */
    --color-text-secondary: #c0c0c0; /* ~9.4:1 na #121212 */
    --color-text-subtle: #909090;    /* ~5.1:1 na #121212 */
    --color-accent: #6fa8ff;         /* ~6.5:1 na #121212 */
  }
}

Zwróć uwagę na wartości tokenów w trybie ciemnym powyżej. Kolory, które spełniają AA na białym tle, często nie przechodzą testu na ciemnych powierzchniach i odwrotnie. Projektując tryb ciemny, unikaj prostego odwracania wartości z trybu jasnego. W pełni nasycony lub czysto biały tekst na czystej czerni (#000000) może powodować halację — efekt rozmycia przy ekstremalnie wysokim kontraście, który jest trudny dla części użytkowników. Powierzchnia #121212 i tekst #ededed to bardziej komfortowe połączenie, które nadal zapewnia doskonały kontrast.

Automatyczne testy kontrastu można również zintegrować z pipeline’em komponentów. Biblioteki takie jak axe-core można wywoływać w testach Jest lub Playwright, aby oznaczać błędy kontrastu jako część standardowego zestawu testów, wychwytując regresje w momencie ich wprowadzenia, a nie dopiero przy zewnętrznym audycie.

Czego narzędzia automatyczne nie wykryją — i co z tym zrobić

Automatyczne skanowanie to potężny punkt wyjścia, ale ma realne ograniczenia. Testy automatyczne są w stanie wykryć zazwyczaj od 20 do 30 procent potencjalnych naruszeń WCAG, jeśli uwzględnić pełne spektrum kryteriów dostępności — choć kontrast kolorów jest jedną z kategorii wykrywanych najpewniej. Mimo to kilka scenariuszy błędów kontrastu regularnie wymyka się narzędziom automatycznym.

Tekst na gradientach i obrazach tła to najczęstsza „ślepa plamka”. Axe i WAVE potrafią identyfikować pary kolorów, gdy zarówno pierwszy plan, jak i tło mają pojedynczą, deterministyczną wartość koloru. Gdy tłem jest gradient CSS lub fotografia JPEG, narzędzie często nie jest w stanie obliczyć sensownego współczynnika i oznacza element jako „wymaga przeglądu”, a nie jednoznaczny błąd. Te przypadki wymagają inspekcji człowieka, najlepiej z użyciem narzędzia z próbkowaniem pikseli, takiego jak Colour Contrast Analyser, aby pobrać rzeczywiste wartości pierwszego planu i tła w wielu punktach obszaru nakładania.

Półprzezroczyste i złożone kolory tworzą podobne wyzwania. Biały napis na niebieskim przycisku renderowanym na zielonym tle strony ma obliczony kontrast zależny od wszystkich trzech warstw koloru — obliczenie, którego narzędzia oparte na DOM nie zawsze potrafią dokonać dokładnie. Spłaszcz wartości alfa ręcznie lub użyj narzędzia opartego na zrzucie ekranu, aby pobrać kolor renderowanego piksela.

Dynamicznie generowane stany — podpowiedzi (tooltips) sterowane JavaScriptem, okna modalne, menu rozwijane, komunikaty o błędach — są renderowane w locie i mogą nie być widoczne w momencie uruchamiania skanu automatycznego. Narzędzia, którymi można sterować skryptowo (jak axe-core w teście Playwright), mogą przechodzić do tych stanów i oceniać je, ale skonfigurowanie takiego pokrycia wymaga świadomego wysiłku. Wbuduj to w swój workflow QA i uwzględnij kontrast w definicji ukończenia (definition of done) dla każdego nowego komponentu, który wprowadza nowe pary kolorów.

Wreszcie, matematyczny wzór kontrastu w WCAG, choć dobrze ugruntowany, nie jest doskonałym zastępstwem dla postrzeganej czytelności. Wzór nie uwzględnia grubości czcionki, odstępów między literami ani antyaliasingu. Krój o cienkiej grubości przy 4.5:1 będzie odczuwalnie trudniejszy do czytania niż ten sam współczynnik osiągnięty przy większej grubości. Traktuj próg WCAG jako podłogę — minimum, które musisz osiągnąć — a nie cel optymalizacyjny. Dąż do 7:1 wszędzie tam, gdzie pozwalają na to typografia, czytelność i marka, i przeprowadzaj testy z udziałem osób słabowidzących, aby potwierdzić, że Twoje wybory kolorystyczne działają w realnym świecie.

Najważniejsze wnioski

• Kontrast kolorów to najczęstsza bariera dostępności w sieci. Tekst o niskim kontraście pojawił się na 83.9% spośród miliona najpopularniejszych stron głównych w 2026 roku. Niezależnie od dojrzałości programu dostępności w Twojej organizacji, kontrast jest miejscem, w którym najprawdopodobniej masz obecnie nierozwiązane problemy — i jednocześnie jednym z najłatwiejszych do naprawienia.
• Poznaj progi, które mają zastosowanie do Twoich treści. WCAG AA wymaga 4.5:1 dla normalnego tekstu, 3:1 dla dużego tekstu (18pt+ lub 14pt+ pogrubiony) oraz 3:1 dla nietekstowych komponentów UI, takich jak obramowania pól i kontrolki z samą ikoną. Wymogi te obowiązują niezależnie od tego, czy interfejs używa trybu jasnego, czy ciemnego.
• Testuj warstwowo: skan automatyczny, inspekcja w DevTools, osobne narzędzie i przegląd ręczny. Uruchom axe DevTools lub WAVE dla szybkiego skanowania całej strony; użyj wbudowanego selektora kolorów w Chrome DevTools do szybkiej iteracji; użyj WebAIM Contrast Checker lub CCA do walidacji konkretnych par; ręcznie sprawdź gradienty, obrazy i stany dynamiczne, których narzędzia automatyczne nie są w stanie wiarygodnie ocenić.
• Naprawiaj kontrast na poziomie systemu projektowego, a nie pojedynczych komponentów. Zbuduj skalę tokenów z wstępnie zweryfikowanymi współczynnikami kontrastu, udokumentuj, które tokeny tekstu przechodzą na których tokenach powierzchni, i egzekwuj zgodność poprzez testy automatyczne w CI. To eliminuje całe klasy błędów, zanim trafią do produkcji.
• Traktuj WCAG jako minimum, a nie cel. Osiągnięcie 4.54:1 ledwie przechodzi test — ale nadal pozostawia wielu użytkowników w trudnej sytuacji. Tam, gdzie pozwalają na to typografia, czytelność i marka, dąż do 7:1 i używaj grubości czcionki, rozmiaru i odstępów jako dodatkowych dźwigni, aby tekst był naprawdę komfortowy w odbiorze, a nie tylko technicznie zgodny.