EAA 2025: Jak naprawić kontrasty w CSS, by uniknąć kar i dostosować polski e-commerce do wymogów dostępności?

Meta: Dowiedz się, jak dostosować kontrasty CSS do norm WCAG 2.1 i EAA 2025. Praktyczny przewodnik dla programistów e-commerce: kod, narzędzia i szybki audyt.

Wielu właścicieli sklepów internetowych w Polsce traktuje dostępność cyfrową (accessibility) jako „miły dodatek” lub coś, co dotyczy tylko stron rządowych. To ogromny błąd, który w 2025 roku może kosztować Was realne pieniądze. Mowa o European Accessibility Act (EAA), czyli Europejskim Akcie o Dostępności, który w polskim prawie zostanie zaimplementowany tak, by od czerwca 2025 roku większość podmiotów e-commerce musiała spełniać rygorystyczne normy dostępności.

Jeśli Twoim zdaniem „szary tekst na białym tle wygląda nowocześnie”, to z perspektywy EAA i WCAG 2.1 Twoja strona jest po prostu nieczytelna dla milionów użytkowników, a Ty ryzykujesz kary finansowe. Nie będę Was straszył teoretycznymi paragrafami – jako konsultant compliance widziałem już wystarczająco dużo decyzji UODO, by wiedzieć, że organy kontrolne nie lubią ignorancji. Choć EAA to inny akt prawny niż RODO, logika jest ta sama: brak zgodności = ryzyko kary.

W tym artykule przejdziemy od teorii do konkretnego kodu CSS. Pokażę Wam, jak naprawić kontrasty w 5-10 osobowym zespole deweloperskim, bez przepisywania całego front-endu i bez wydawania budżetu na zewnętrznych audytorów, którzy każą Wam zmienić każdy kolor w brandbooku.

EAA 2025: Co to właściwie oznacza dla polskiego dewelopera?

Zacznijmy od konkretów. EAA to dyrektywa unijna, która nakłada na firmy obowiązek zapewnienia dostępności produktów i usług. W praktyce oznacza to, że Twój sklep internetowy musi być zgodny z normą EN 301 549, która de facto opiera się na wytycznych WCAG 2.1 (Web Content Accessibility Guidelines).

Najczęstszym błędem w polskim e-commerce jest ignorowanie poziomu AA w zakresie kontrastu. Dlaczego to ważne? Ponieważ osoby niedowidzące, starsze lub po prostu osoby korzystające z telefonu w pełnym słońcu nie są w stanie przeczytać Waszych „estetycznych” jasnoszarych napisów.

Pragmatyczne podejście: Nie musicie dążyć do perfekcji poziomu AAA (który jest zarezerwowany dla specjalistycznych serwisów). Celujcie w poziom AA. To złoty środek między estetyką a zgodnością prawną.

Matematyka kontrastu: Stosunek 4.5:1 i 3:1

Zgodnie z WCAG 2.1, aby przejść audyt dostępności, musicie spełnić dwa główne kryteria kontrastu:

1. Tekst standardowy (poniżej 18pt/24px): Stosunek kontrastu tekstu do tła musi wynosić co najmniej 4.5:1.
2. Duży tekst (powyżej 18pt lub 14pt bold): Stosunek kontrastu musi wynosić co najmniej 3:1.
3. Elementy nietekstowe (ikony, obramowania pól formularzy): Również wymagają stosunku 3:1.

Jeśli Wasz przycisk „Dodaj do koszyka” ma jasnoszary tekst na białym tle, prawdopodobnie macie kontrast rzędu 2:1. Z punktu widzenia EAA to błąd krytyczny.

Jak naprawić kontrasty w CSS? Praktyczne rozwiązania

Zamiast zgadywać, wprowadźcie systematyczne podejście. Oto jak możecie to wdrożyć w swoim projekcie.

1. Wykorzystanie zmiennych CSS (CSS Variables)

Nie wpisujcie kolorów „na sztywno” w każdym pliku .scss czy .css. To przepis na katastrofę przy aktualizacji compliance. Stwórzcie paletę kolorów, która jest już zweryfikowana pod kątem kontrastu.

:root {
  /* ❌ BŁĄD: Jasnoszary tekst (Kontrast ok. 2.5:1) - Nie przejdzie audytu */
  /* --color-text-muted: #9ca3af; */

  /* ✅ POPRAWKA: Ciemniejszy szary (Kontrast ok. 4.6:1 na białym tle) */
  --color-text-muted: #71717a; 

  /* Główny kolor marki - upewnijcie się, że biały tekst na nim ma 4.5:1 */
  --color-primary: #1d4ed8; 
  --color-on-primary: #ffffff;

  /* Kolor tła dla pól formularzy - musi być wyraźnie oddzielony od tła strony */
  --color-input-border: #a1a1aa;
}

.product-description {
  color: var(--color-text-muted);
  font-size: 14px;
}

2. Problem z "ghost buttons" i linkami w tekście

Wielu programistów stosuje tzw. ghost buttons (przezroczyste przyciski z cienką ramką). Jeśli ramka jest zbyt jasna, przycisk jest niewidoczny dla osób słabowidzących.

Zła praktyka:

.btn-outline {
  border: 1px solid #d1d5db; /* Zbyt jasne! */
  color: #6b7280;
}

Dobra praktyka:
Zastosujcie ciemniejszą ramkę i upewnijcie się, że stan :hover oraz :focus są wyraźnie zaznaczone. Pamiętajcie, że obramowanie pola aktywnego (focus ring) jest absolutnie kluczowe dla osób korzystających z klawiatury.

.btn-outline:focus {
  outline: 3px solid var(--color-primary);
  outline-offset: 2px;
}

3. Naprawianie kontrastu w formularzach i inputach

To tutaj UODO i audytorzy EAA najczęściej znajdują błędy. Polskie sklepy często mają inputy z bardzo bladym obramowaniem, które „wtapia się” w tło.

.form-input {
  border: 1px solid #71717a; /* Zgodne z normą 3:1 dla elementów graficznych */
  padding: 8px;
  border-radius: 4px;
}

.form-input:focus {
  border-color: var(--color-primary);
  box-shadow: 0 0 0 2px rgba(29, 78, 216, 0.2);
}

Automatyzacja zamiast zgadywania

Nie możecie sprawdzać każdego elementu ręcznie. W zespole 5-10 osób najlepiej wdrożyć automatyczne testy w pipeline CI/CD. Polecam narzędzia takie jak axe-core lub Lighthouse.

Jeśli chcecie szybko sprawdzić cały serwis bez konfigurowania środowiska testowego, możecie skorzystać z zewnętrznych skanerów. Tutaj wchodzi moje podejście: zamiast spędzać godziny na ręcznym sprawdzaniu każdego odcienia w Chrome DevTools, używajcie narzędzi, które robią „Deep Scan” i wypluwają gotową listę błędów.

Dla moich klientów zawsze rekomenduję narzędzia, które nie tylko mówią „jest źle”, ale wskazują dokładnie, który element i który kolor łamie normy WCAG. To skraca czas naprawy z kilku dni do kilku godzin.

Szybka rekomendacja: Jeśli chcecie w 5 minut sprawdzić, gdzie Wasz sklep „wycieka” w kwestii dostępności i bezpieczeństwa, wejdźcie na https://inspect-my-site.com. To narzędzie od Tessera, które pozwala szybko zidentyfikować luki, zanim zrobi to kontroler lub złośliwy konkurent.

Case Study: 5-minutowy audyt kontra 2 tygodnie poprawek

Ostatnio pracowałem z polskim sklepem odzieżowym. Designer uparł się na minimalistyczną paletę barw (beże i jasne szarości). Po uruchomieniu skanera w inspect-my-site.com okazało się, że 40% opisów produktów oraz wszystkie komunikaty o błędach w koszyku mają kontrast na poziomie 2.1:1.

Koszt naprawy:

• Czas dewelopera: 3 godziny na zmianę zmiennych w CSS.
• Koszt: ok. 600-1000 zł (stawka godzinowa seniora).
• Wynik: Pełna zgodność z WCAG AA w obszarze kontrastu i zero ryzyka kary z tytułu EAA w tym zakresie.

Gdyby firma czekała na oficjalną kontrolę i musiała wdrażać poprawki w trybie awaryjnym, koszt byłby 10-krotnie wyższy, nie licząc potencjalnej kary finansowej.

Strategia wdrożenia dla małych zespołów (Step-by-step)

Jeśli nie macie budżetu na pełnoetatowego specjalistę od accessibility, zróbcie to w ten sposób:

1. Inwentaryzacja kolorów: Wyciągnijcie wszystkie kolory używane do tekstu i tła.
2. Weryfikacja kontrastu: Użyjcie darmowych narzędzi (np. WebAIM Contrast Checker) lub skanera automatycznego, by sprawdzić, które pary kolorów nie spełniają normy 4.5:1.
3. Aktualizacja palety: Zmieńcie kolory w jednym miejscu (zmienne CSS), aby poprawić kontrast globalnie.
4. Testy klawiaturą: Przejdźcie przez cały proces zakupowy, używając tylko klawisza Tab. Jeśli nie widzicie, gdzie jest kursor, macie problem z kontrastem obramowań :focus.
5. Weryfikacja końcowa: Ponowny skan strony, aby potwierdzić poprawki.

Podsumowanie: ROI z dostępności

Dostępność to nie tylko kwestia prawna i unikanie kar. To czysty biznes. Zwiększenie kontrastu to:

• Wyższa konwersja: Więcej osób starszych (które mają coraz większą siłę nabywczą w polskim e-commerce) może bez problemu dokonać zakupu.
• Lepsze SEO: Google premiuje strony dostępne i przyjazne dla użytkownika.
• Wizerunek: Firma, która dba o dostępność, jest postrzegana jako etyczna i nowoczesna.

Nie czekajcie do czerwca 2025 roku. EAA nie pojawi się nagle – to proces, który już trwa. Naprawa kontrastów w CSS to najtańsza i najszybsza rzecz, jaką możecie zrobić teraz, by zabezpieczyć swój biznes.

Kluczowe wnioski dla deweloperów:

• Norma dla tekstu: 4.5:1.
• Norma dla ikon/obramowań: 3:1.
• Używajcie zmiennych CSS do zarządzania kolorami.
• Automatyzujcie audyty za pomocą narzędzi takich jak inspect-my-site.com.

Zapraszam do dyskusji w komentarzach: Czy w Waszych projektach accessibility jest traktowane jako priorytet, czy raczej jako „coś, co zrobimy na koniec”? Jakie macie doświadczenia z wdrażaniem WCAG w polskich realiach?

javascript #webdev #ecommerce #accessibility

O autorze:
Piotr Wiśniewski jest konsultantem ds. e-commerce i ochrony danych z siedzibą w Warszawie. Specjalizuje się w przekładaniu skomplikowanych regulacji unijnych (RODO, EAA) na konkretne zadania dla zespołów technicznych, pomagając polskim MŚP optymalizować koszty compliance.