Kryteria sukcesu WCAG · Level A
WCAG 1.4.1: Użycie koloru
WCAG 1.4.1 wymaga, aby kolor nigdy nie był jedynym środkiem przekazywania informacji, wskazywania działania, wywoływania reakcji lub rozróżniania elementu wizualnego. To kryterium zapewnia, że użytkownicy, którzy nie są w stanie dostrzec różnic kolorów — w tym osoby z daltonizmem lub słabowidzące — nadal mogą uzyskać dostęp do wszystkich treści i funkcjonalności.
Co Oznacza Ta Zasada
WCAG 1.4.1 Use of Color (Użycie koloru) jest kryterium poziomu A w ramach zasady Postrzegalność. Stanowi, że kolor nie może być używany jako jedyny wizualny środek przekazywania informacji, wskazywania działania, wywoływania reakcji lub rozróżniania elementu wizualnego. Kluczowe słowo to „jedyny”: kolor nie jest zabroniony, ale zawsze musi mu towarzyszyć co najmniej jedna dodatkowa wizualna wskazówka — taka jak etykiety tekstowe, wzory, kształty, obramowania, ikony lub zabiegi typograficzne — tak aby ta sama informacja była dostępna niezależnie od tego, czy użytkownik potrafi rozróżniać kolory.
To kryterium obejmuje szeroki zakres elementów interfejsu. Pola formularza, które stają się czerwone, aby wskazać błąd, naruszają to kryterium, jeśli czerwony kolor jest jedynym wskaźnikiem. Wykresy i grafy, które używają wyłącznie koloru do rozróżniania serii danych, naruszają to kryterium. Linki stylowane wyłącznie innym kolorem (bez podkreślenia, pogrubienia lub innego wyróżnika niezwiązanego z kolorem) naruszają to kryterium, gdy pojawiają się w bloku tekstu głównego. W zakresie są stany nawigacji, odznaki statusu, wskaźniki postępu, oznaczenia pól wymaganych oraz interaktywne elementy sugerujące możliwość działania.
Poprawna implementacja zapewnia co najmniej jeden mechanizm niezwiązany z kolorem obok koloru. Na przykład: pole błędu obrysowane na czerwono i opatrzone ikoną błędu oraz opisową etykietą tekstową; wykres kołowy używający zarówno odrębnych kolorów, jak i wypełnień wzorami; linki w tekście głównym, które są zarówno w innym kolorze, jak i podkreślone. Niepoprawna implementacja opiera się wyłącznie na zmianie koloru — nie ma kształtu, obramowania, wzoru, etykiety ani różnicy w tekście, które przekazywałyby to samo znaczenie.
W specyfikacji WCAG znajduje się ważne doprecyzowanie zakresu: to kryterium dotyczy konkretnie koloru jako wizualnego środka przekazywania informacji. Nie wymaga usunięcia wszystkich kolorów ani nie odnosi się do współczynników kontrastu — to jest uregulowane w 1.4.3 i 1.4.11. Nie ma też zastosowania do logotypów ani obrazów dekoracyjnych, w których kolor nie niesie znaczenia informacyjnego. Kryterium dotyczy ściśle sytuacji, w których użytkownik, który nie potrafi rozróżnić dwóch lub więcej kolorów, utraciłby dostęp do informacji lub funkcjonalności.
Dlaczego To Ma Znaczenie
Około 300 milionów osób na całym świecie żyje z jakąś formą zaburzeń widzenia barw (ślepota barw), a 2,2 miliarda osób globalnie ma upośledzenie widzenia bliży lub dali według Światowej Organizacji Zdrowia. Ślepota barw dotyka około 1 na 12 mężczyzn i 1 na 200 kobiet pochodzenia północnoeuropejskiego, co oznacza, że w typowej grupie 100 osób około 5–8 z nich nie jest w stanie wiarygodnie rozróżnić czerwieni od zieleni — jednej z najczęściej używanych w interfejsach kombinacji kolorów do sygnalizowania sukcesu versus błędu.
Dla użytkowników z deuteranopią lub protanopią (czerwono-zielona ślepota barw), formularz, który wyróżnia nieprawidłowe pola tylko na czerwono, jest funkcjonalnie niewidoczny jako wskaźnik błędu. Wysyłają formularz, nie widzą oczywistej zmiany i dochodzą do wniosku, że system jest zepsuty lub że ich zgłoszenie zostało przyjęte. Nie jest to drobna niedogodność — może skutkować nieudanymi transakcjami finansowymi, przegapionymi wizytami lekarskimi, nieudanymi wnioskami o usługi publiczne lub brakiem możliwości dokończenia zakupów w e-commerce.
Użytkownicy słabowidzący, którzy polegają na wyświetlaczach o wysokim kontraście lub niestandardowych schematach kolorów, mogą mieć aktywne systemowe nadpisywanie kolorów. W takich środowiskach kolory określone przez autora mogą zostać całkowicie zastąpione, co sprawia, że każda wskazówka oparta wyłącznie na kolorze staje się bez znaczenia, niezależnie od zdolności użytkownika do postrzegania barw. Podobnie użytkownicy, którzy drukują dokumenty w czerni i bieli lub korzystają z treści na monochromatycznych wyświetlaczach e-ink, tracą wszelkie zróżnicowanie kolorystyczne.
Poza niepełnosprawnością, to kryterium przynosi korzyści szerokiej populacji: użytkownikom mobilnym na zewnątrz w jasnym słońcu, użytkownikom na ekranach niskiej jakości z kiepskim odwzorowaniem kolorów oraz osobom starszym, których postrzeganie barw naturalnie pogarsza się z wiekiem. Dostępne użycie koloru pośrednio poprawia też SEO — opisowe etykiety tekstowe dodane w celu spełnienia tego kryterium dostarczają dodatkowej treści semantycznej, którą wyszukiwarki mogą indeksować. Z punktu widzenia użyteczności, jednoznaczne etykiety tekstowe i wizualne wskazówki obok koloru zmniejszają obciążenie poznawcze wszystkich użytkowników, czyniąc znaczenie interfejsu redundantnym i wzmocnionym.
Powiązane Reguły Axe-core
WCAG 1.4.1 wymaga testów manualnych, ponieważ narzędzia automatyczne nie są w stanie wiarygodnie określić, czy kolor jest używany jako jedyny środek przekazywania informacji. Jest to osąd semantyczny i wizualny: narzędzie automatyczne może wykryć, że dwa elementy mają różne kolory, ale nie może ustalić, czy te kolory są jedynym czynnikiem różnicującym, ani czy informacja niesiona przez tę różnicę kolorów jest również przekazywana innym mechanizmem. Narzędzie musiałoby rozumieć zamysł projektowy i pełny kontekst wizualnego renderowania, aby dokonać takiej oceny.
- Wymagane testy manualne — wyróżnienie koloru linku: Axe-core nie może automatycznie zweryfikować, czy linki w tekście głównym są odróżnialne od otaczającego tekstu nielinkowego za pomocą środków innych niż sam kolor. Tester ludzki musi wizualnie obejrzeć stronę i potwierdzić, że linki mają dodatkową wskazówkę niezwiązaną z kolorem (taką jak podkreślenie, pogrubienie lub widoczna ikona), gdy pojawiają się w linii w akapitach tekstu. Narzędzia automatyczne mogą wykryć, że link istnieje, ale nie to, czy jego prezentacja wizualna opiera się wyłącznie na różnicy odcienia.
- Wymagane testy manualne — stany błędów formularza: Gdy pole formularza przechodzi w stan błędu, narzędzia automatyczne nie mogą określić, czy zmiana wizualna (taka jak czerwone obramowanie lub tło) jest jedynym wskaźnikiem błędu, czy też towarzyszy jej ikona błędu, komunikat tekstowy lub inna wskazówka niezwiązana z kolorem. Tester musi wejść w interakcję z formularzem, wywołać błędy walidacji i sprawdzić, jak błąd jest komunikowany wizualnie.
- Wymagane testy manualne — wizualizacje danych: Wykresy, grafy, mapy i diagramy, które używają koloru do rozróżniania kategorii, serii danych lub regionów, nie mogą być automatycznie ocenione pod kątem zgodności z 1.4.1. Tester ludzki musi ocenić, czy obecne są również wzory, etykiety lub tekstury, które różnicują elementy zakodowane kolorami.
- Wymagane testy manualne — wskaźniki statusu: Odznaki, tagi i wskaźniki statusu (takie jak wskaźniki online/offline lub etykiety statusu zamówienia), które polegają na kolorze do komunikowania stanu, nie mogą być automatycznie oznaczone. Tester musi potwierdzić, że każdy status jest również przekazywany przez etykietę tekstową, ikonę lub zmianę kształtu.
Jak Testować
- Automatyczne skanowanie bazowe: Uruchom axe DevTools, Lighthouse lub sprawdzarkę dostępności Accsible na stronie. Choć te narzędzia nie wskażą bezpośrednio naruszeń 1.4.1, mogą ujawnić powiązane problemy, takie jak brakujące alternatywy tekstowe, niewystarczający kontrast lub brakujące etykiety formularzy, które korelują z użyciem wyłącznie koloru. Zanotuj wszystkie zgłoszone problemy i wykorzystaj je jako punkty wyjścia do inspekcji manualnej. W axe DevTools otwórz rozszerzenie przeglądarki, kliknij „Analyze” i przejrzyj kategorię „Needs Review” oprócz listy naruszeń, ponieważ niektóre problemy związane z kolorem mogą być tam uwidocznione.
- Symulacja skali szarości: Użyj rozszerzenia przeglądarki lub funkcji dostępności systemu operacyjnego, aby wyświetlić stronę w skali szarości (zerowe nasycenie). W macOS przejdź do Ustawienia systemowe > Dostępność > Wyświetlacz i włącz „Używaj skali szarości”. W Windows przejdź do Ustawienia > Ułatwienia dostępu > Filtry kolorów i wybierz „Skala szarości”. Alternatywnie użyj narzędzi deweloperskich przeglądarki: w Chrome otwórz DevTools, naciśnij Ctrl+Shift+P (lub Cmd+Shift+P na Mac), wpisz „Emulate vision deficiencies” i wybierz „Achromatopsia”. Przejrzyj każdy element interaktywny, wskaźnik statusu, pole formularza, wykres i link w skali szarości i potwierdź, że wszystkie informacje pozostają zrozumiałe bez koloru.
- Symulacja ślepoty barw: Użyj emulatora zaburzeń widzenia w Chrome DevTools (ta sama ścieżka co powyżej), aby zasymulować deuteranopię, protanopię i tritanopię. Dla każdej symulacji przejdź przez wszystkie ścieżki użytkownika — wysyłanie formularza z błędami, interpretację danych na wykresach, nawigację między stanami aktywnymi i nieaktywnymi — i zweryfikuj, że żadna informacja nie jest utracona. Narzędzia takie jak Coblis Color Blindness Simulator lub Colour Oracle (aplikacja desktopowa) mogą być również użyte do symulacji ślepoty barw na całym ekranie.
- Linki w tekście głównym — kontrola manualna: Zidentyfikuj wszystkie hiperłącza, które pojawiają się w akapitach tekstu głównego (w odróżnieniu od menu nawigacyjnych lub samodzielnych list linków). Dla każdego takiego linku potwierdź, że jest wizualnie odróżnialny od otaczającego tekstu nielinkowego za pomocą co najmniej jednego mechanizmu niezwiązanego z kolorem. Najczęstszym akceptowalnym mechanizmem jest podkreślenie. Jeśli link opiera się wyłącznie na różnicy koloru, jest to naruszenie.
- Walidacja formularza — kontrola manualna: Używając nawigacji klawiaturą (Tab do przenoszenia fokusu, Enter lub Spacja do aktywowania elementów), wypełnij formularz i celowo pozostaw wymagane pola puste lub wprowadź nieprawidłowe dane. Wyślij formularz. Wizualnie sprawdź, jak komunikowane są błędy. Potwierdź, że wskazanie błędu nie jest przekazywane wyłącznie przez kolor — każdy błąd musi mieć widoczny opis tekstowy, ikonę lub oba te elementy oprócz zmiany koloru.
- Weryfikacja czytnikiem ekranu (NVDA + Firefox): Otwórz stronę w Firefox z uruchomionym NVDA. Przejdź przez wszystkie pola formularzy, wykresy i wskaźniki statusu, używając kursora wirtualnego. Potwierdź, że komunikaty o błędach, etykiety statusu i opisy danych są odczytywane przez czytnik ekranu. To weryfikuje warstwę programistyczną, choć sam dostęp przez czytnik ekranu nie spełnia wizualnego wymogu 1.4.1 dla widzących użytkowników z ślepotą barw.
- Przegląd wykresów i grafów: Dla każdej wizualizacji danych spróbuj zinterpretować dane, używając wyłącznie kształtu, wzoru lub etykiet tekstowych, celowo ignorując kolor. Jeśli wizualizacja staje się nieinterpretowalna bez koloru, jest to naruszenie. Potwierdź, że dostępna jest alternatywa tekstowa (tabela danych, legenda z wzorami, bezpośrednie etykiety danych).
Jak Naprawić
Link w tekście głównym — Niepoprawnie
<!-- Link jest odróżnialny od otaczającego tekstu tylko kolorem.
Użytkownik z ślepotą barw nie może zidentyfikować go jako linku. -->
<p>
Please review our
<a href='/privacy' style='color: #0057b8; text-decoration: none;'>privacy policy</a>
before continuing.
</p>
Link w tekście głównym — Poprawnie
<!-- Link jest podkreślony oprócz tego, że ma inny kolor.
Podkreślenie zapewnia wizualną wskazówkę niezwiązaną z kolorem, która identyfikuje go jako link. -->
<p>
Please review our
<a href='/privacy' style='color: #0057b8; text-decoration: underline;'>privacy policy</a>
before continuing.
</p>
Stan błędu formularza — Niepoprawnie
<!-- Błąd jest komunikowany wyłącznie przez czerwone obramowanie.
Użytkownik z ślepotą barw nie może odróżnić tego od normalnego pola. -->
<label for='email'>Email address</label>
<input
type='email'
id='email'
name='email'
class='input-error'
aria-label='Email address'
/>
<!-- .input-error { border: 2px solid #cc0000; } -->
Stan błędu formularza — Poprawnie
<!-- Błąd jest komunikowany przez czerwone obramowanie ORAZ widoczną ikonę błędu ORAZ komunikat tekstowy.
Komunikat tekstowy jest również powiązany przez aria-describedby dla technologii asystujących. -->
<label for='email'>Email address</label>
<input
type='email'
id='email'
name='email'
class='input-error'
aria-describedby='email-error'
aria-invalid='true'
/>
<p id='email-error' class='error-message'>
<svg aria-hidden='true' focusable='false' class='error-icon'>
<!-- dane ścieżki SVG ikony błędu -->
</svg>
Please enter a valid email address.
</p>
Legenda wykresu oparta wyłącznie na kolorze — Niepoprawnie
<!-- Wykres słupkowy, w którym kategorie są rozróżniane wyłącznie kolorem wypełnienia.
Użytkownicy z ślepotą barw nie mogą rozróżnić kategorii. -->
<svg role='img' aria-label='Quarterly sales by region'>
<rect x='10' y='50' width='40' height='100' fill='#e63946' />
<rect x='60' y='20' width='40' height='130' fill='#2a9d8f' />
<rect x='110' y='70' width='40' height='80' fill='#e9c46a' />
</svg>
<ul class='chart-legend'>
<li><span class='swatch red'></span> North</li>
<li><span class='swatch green'></span> South</li>
<li><span class='swatch yellow'></span> West</li>
</ul>
Legenda wykresu oparta wyłącznie na kolorze — Poprawnie
<!-- Słupki używają zarówno odrębnych kolorów, JAK I odrębnych wypełnień wzorami (przez wzory SVG).
Elementy legendy zawierają etykietę tekstową. Dostarczona jest również dostępna tabela danych. -->
<svg role='img' aria-label='Quarterly sales by region — data table below'>
<defs>
<pattern id='pattern-north' patternUnits='userSpaceOnUse' width='6' height='6'>
<line x1='0' y1='6' x2='6' y2='0' stroke='#e63946' stroke-width='1.5'/>
</pattern>
<pattern id='pattern-south' patternUnits='userSpaceOnUse' width='6' height='6'>
<circle cx='3' cy='3' r='2' fill='#2a9d8f'/>
</pattern>
<pattern id='pattern-west' patternUnits='userSpaceOnUse' width='6' height='6'>
<rect x='0' y='0' width='3' height='3' fill='#e9c46a'/>
</pattern>
</defs>
<rect x='10' y='50' width='40' height='100' fill='url(#pattern-north)' />
<rect x='60' y='20' width='40' height='130' fill='url(#pattern-south)' />
<rect x='110' y='70' width='40' height='80' fill='url(#pattern-west)' />
</svg>
<ul class='chart-legend'>
<li><span class='swatch swatch-north' aria-hidden='true'></span> North (diagonal lines)</li>
<li><span class='swatch swatch-south' aria-hidden='true'></span> South (dots)</li>
<li><span class='swatch swatch-west' aria-hidden='true'></span> West (squares)</li>
</ul>
<table>
<caption>Quarterly sales by region (data table)</caption>
<thead><tr><th>Region</th><th>Sales (units)</th></tr></thead>
<tbody>
<tr><td>North</td><td>100</td></tr>
<tr><td>South</td><td>130</td></tr>
<tr><td>West</td><td>80</td></tr>
</tbody>
</table>
Odznaka statusu — Niepoprawnie
<!-- Status zamówienia komunikowany wyłącznie kolorem tła.
"Pending" (żółty), "Shipped" (niebieski) i "Delivered" (zielony) są
wizualnie identyczne dla wielu użytkowników z ślepotą barw. -->
<span class='badge badge-pending'></span>
<span class='badge badge-shipped'></span>
<span class='badge badge-delivered'></span>
Odznaka statusu — Poprawnie
<!-- Status jest komunikowany kolorem ORAZ widoczną etykietą tekstową.
Etykieta tekstowa jest głównym nośnikiem znaczenia. -->
<span class='badge badge-pending'>Pending</span>
<span class='badge badge-shipped'>Shipped</span>
<span class='badge badge-delivered'>Delivered</span>
Typowe Błędy
- Usuwanie podkreśleń z linków w tekście i poleganie wyłącznie na kolorze: Ustawienie
text-decoration: nonena elementach anchor wewnątrz akapitów tekstu głównego jest jednym z najczęstszych naruszeń 1.4.1. Podkreślenie jest domyślną wskazówką niezwiązaną z kolorem dla linków; usunięcie go bez dodania innego wyróżnika niezwiązanego z kolorem (takiego jak pogrubienie lub ikona) powoduje natychmiastowe naruszenie za każdym razem, gdy taki link pojawia się w otaczającym tekście o innym kolorze. - Używanie par kolorów czerwony/zielony dla stanów zaliczone/niezaliczone bez dodatkowych ikon lub tekstu: Czerwony dla błędu i zielony dla sukcesu jest kulturowo intuicyjne, ale niedostępne dla użytkowników z deuteranopią lub protanopią, które są właśnie najczęstszymi formami ślepoty barw. Zawsze łącz te kolory z odrębnymi ikonami (znak wyboru versus X) i jednoznacznymi etykietami tekstowymi („Valid” versus „Error”).
- Oznaczanie wymaganych pól formularza wyłącznie kolorową gwiazdką: Czerwona gwiazdka (*) obok etykiety pola komunikuje status wymagany poprzez kolor, jeśli sama gwiazdka nie ma towarzyszącej legendy lub widocznego wyjaśnienia tekstowego. Naprawą jest dodanie widocznej notatki, takiej jak „* indicates required field” w pobliżu formularza, zapewniając, że sama gwiazdka niesie znaczenie wykraczające poza jej kolor.
- Używanie wyłącznie koloru dla stanów aktywny/wybrany w menu nawigacyjnych: Wyróżnianie aktualnie aktywnego elementu nawigacji wyłącznie przez zmianę koloru tekstu lub tła — bez zmiany grubości czcionki, dodania podkreślenia lub wskaźnika obramowania — oznacza, że użytkownicy z ślepotą barw nie mogą zidentyfikować, na której stronie się znajdują.
- Dymki narzędziowe wykresów, które powtarzają wskazówkę koloru bez dodawania etykiet: Niektóre biblioteki wykresów wyświetlają dymki narzędziowe pokazujące próbkę koloru odpowiadającą serii danych, ale bez etykiety tekstowej nazwy serii. Jeśli dymek jest jedynym miejscem, w którym dane są rozróżniane, a opiera się wyłącznie na próbce koloru, jest to naruszenie.
- Kroki postępu, które zmieniają się tylko kolorem, aby wskazać ukończenie: Wieloetapowe kreatory formularzy często stylizują ukończone kroki zielonym tłem, a nadchodzące kroki szarym tłem. Jeśli zmianie koloru nie towarzyszy tekst („Completed”, „Current”, „Upcoming”) lub ikona (znak wyboru), stan kroku jest komunikowany wyłącznie kolorem.
- Poleganie na kolorze tekstu zastępczego (placeholder) do wskazywania walidacji danych wejściowych: Zmiana koloru tekstu zastępczego (np. na czerwony w przypadku błędu) jest zarówno wskazówką opartą wyłącznie na kolorze, jak i niedostępną z dodatkowych powodów (tekst zastępczy nie jest substytutem etykiet ani komunikatów o błędach). Stan walidacji musi być komunikowany poprzez trwały, widoczny element komunikatu o błędzie.
- Założenie, że same etykiety ARIA spełniają 1.4.1: Dodanie
aria-labellubaria-describedbydo elementu udostępnia informację użytkownikom czytników ekranu, ale 1.4.1 jest kryterium wizualnym. Wymaga wizualnej wskazówki niezwiązanej z kolorem dla widzących użytkowników z ślepotą barw, a nie tylko programistycznej alternatywy tekstowej. Oba są potrzebne, ale samo ARIA nie spełnia 1.4.1. - Różnicowanie wierszy lub komórek tabeli wyłącznie za pomocą naprzemiennych kolorów tła: Choć naprzemienne kolory wierszy (zebra striping) są na ogół dekoracyjne i same w sobie nie stanowią problemu 1.4.1, każda tabela, która używa wyłącznie koloru tła do grupowania, kategoryzowania lub wyróżniania konkretnych wierszy lub komórek jako informacyjnie odrębnych, musi zapewnić etykietę tekstową, ikonę lub nagłówek przekazujący to samo grupowanie lub rozróżnienie.
- Traktowanie wskazówek opartych wyłącznie na kolorze jako zwolnionych, ponieważ są „tylko dekoracyjne”: Deweloperzy czasem argumentują, że kolorowa kropka statusu lub kolorowa etykieta kategorii jest dekoracyjna, a nie informacyjna. Jeśli usunięcie koloru (lub oglądanie w skali szarości) spowodowałoby, że użytkownik utraci dostęp do jakiejkolwiek informacji potrzebnej do zrozumienia lub użycia interfejsu, z definicji jest to informacyjne i musi być zgodne z 1.4.1.
Związek z Przepisami Dotyczącymi Dostępności w Turcji
Prezydencki Okólnik Turcji 2025/10, opublikowany w Dzienniku Urzędowym nr 32933 w dniu 21 czerwca 2025 r., ustanawia obowiązkowe wymagania dostępności stron internetowych i aplikacji mobilnych zgodne z WCAG 2.2. WCAG 1.4.1 Use of Color jest kryterium poziomu A, co oznacza, że wchodzi w skład obowiązkowego podstawowego poziomu zgodności na mocy tego okólnika.
Okólnik nakłada obowiązek osiągnięcia zgodności z WCAG 2.2 na poziomie A w ciągu jednego roku dla instytucji publicznych i dwóch lat dla podmiotów sektora prywatnego. Następujące kategorie organizacji są wyraźnie objęte: instytucje publiczne i organy rządowe, platformy e-commerce, banki i instytucje finansowe, szpitale i świadczeniodawcy opieki zdrowotnej, operatorzy telekomunikacyjni z 200,000 lub większą liczbą abonentów, licencjonowane biura podróży, prywatne firmy transportowe oraz szkoły prywatne upoważnione przez Ministerstwo Edukacji Narodowej (MoNE).
Dla tych podmiotów brak zgodności z WCAG 1.4.1 stanowi naruszenie regulacyjne. W praktyce turecka instytucja publiczna, której portal internetowy używa wyłącznie koloru do wskazywania błędów formularza, lub bank, którego interfejs bankowości internetowej używa wskaźników statusu opartych wyłącznie na kolorze dla stanów transakcji, byłby w sprzeczności z wymaganiami okólnika. Platformy e-commerce — duży i szybko rosnący sektor w Turcji — powszechnie używają kolorowych wskaźników dostępności produktów, odznak promocyjnych i komunikatów o błędach koszyka, z których wszystkie muszą zapewniać alternatywy niezwiązane z kolorem zgodnie z wymaganiami okólnika.
Zgodność z 1.4.1 ma szczególne znaczenie w tureckim kontekście, biorąc pod uwagę znaczną bazę użytkowników korzystających z usług publicznych, bankowości i e-commerce na urządzeniach mobilnych, gdzie jakość ekranu i warunki oświetlenia otoczenia dodatkowo zmniejszają niezawodność koloru jako jedynego nośnika informacji. Organizacjom objętym okólnikiem zaleca się audyt całego użycia koloru jako mechanizmu informacyjnego we wszystkich ich zasobach cyfrowych, priorytetowe dodawanie etykiet tekstowych i wskazówek ikonograficznych obok stanów zakodowanych kolorem oraz uwzględnienie 1.4.1 zarówno w zautomatyzowanych procesach skanowania dostępności, jak i w ustrukturyzowanych protokołach testów manualnych jako części programu zgodności.
