EAA w polskim e-commerce: Dlaczego „div-soup” to teraz ryzyko biznesowe i jak semantyka HTML ratuje Twój budżet

Czym właściwie jest EAA i dlaczego polski e-commerce ma teraz problem?

Europejski Akt Dostępności (EAA) to dyrektywa UE, która zmusza dostawców produktów i usług do zapewnienia dostępności cyfrowej. W polskim kontekście oznacza to, że od czerwca 2025 roku większość sklepów internetowych będzie musiała spełniać określone standardy dostępności (oparte głównie na WCAG 2.1).

Dla przeciętnego developera w 10-osobowym zespole oznacza to jedno: koniec z budowaniem interfejsów „na oko”. Jeśli Twoja nawigacja to zestaw <div> z odpowiednimi klasami CSS, a nie <nav> z listą <ul> i <li>, to z punktu widzenia czytnika ekranu (screen reader) Twój sklep jest w zasadzie czarną dziurą.

Dlaczego to ważne teraz? Bo UODO i organy nadzorcze coraz częściej łączą dostępność z prawem do informacji. Jeśli osoba niewidoma nie może przejść procesu zakupowego z powodu braku semantyki, możecie zostać oskarżeni o dyskryminację lub utrudnianie dostępu do informacji o produktach i cenach, co w połączeniu z rygorystycznym podejściem do ochrony konsumenta w Polsce, jest prostą drogą do kontroli.

Semantyka HTML vs. „Div-Soup”: Walka o dostępność (i portfel)

Przejdźmy do konkretów. Wyobraźmy sobie typowy koszyk w polskim sklepie e-commerce. Jak to wygląda w „div-soup” (BŁĄD):

<!-- To jest koszmar każdego użytkownika czytnika ekranu -->
<div class="btn-checkout" onclick="processPayment()">Kup teraz</div>
<div class="product-price">
  <span class="label">Cena:</span>
  <span class="value">199 PLN</span>
</div>

Dla osoby widzącej to jest przycisk. Dla czytnika ekranu to „tekst: Kup teraz”. Brak informacji, że to element interaktywny. Brak roli. Brak stanu.

Jak to powinno wyglądać semantycznie (POPRAWNIE):

<!-- To jest standard, który chroni Cię przed karami -->
<button type="button" class="btn-checkout" onclick="processPayment()">Kup teraz</button>
<div class="product-price">
  <span id="price-label">Cena:</span>
  <span aria-labelledby="price-label">199 PLN</span>
</div>

Tutaj mamy button – czytnik od razu mówi: „Przycisk: Kup teraz”. Jest jasna hierarchia, jasna rola. To nie jest tylko kwestia „bycia miłym”. To jest kwestia tego, czy osoba z niepełnosprawnością może sfinalizować transakcję. Jeśli nie może, a konkurencja pozwala na to dzięki WCAG, masz problem biznesowy.

Czy EAA wymusza semantykę? Tak, i to w sposób bezlitosny

Jeśli Wasz kod jest zbudowany z divów, to aby spełnić wymogi EAA, musielibyście do każdego elementu dodawać atrybuty ARIA (role="button", aria-label, aria-expanded itd.). Moja rada: Nie róbcie tego. ARIA jest jak cukier – w małych ilościach pomaga, ale nadmiar psuje wszystko. Najlepsza ARIA to brak ARIA, ponieważ użycie natywnych elementów HTML5 zapewnia dostępność „z pudełka”.

Zamiast tracić 20 godzin na łatanie divów atrybutami, poświęćcie 4 godziny na refaktoryzację na semantyczny HTML. To jest ROI (zwrot z inwestycji), którego szukacie. Mniej kodu, mniejsza szansa na błędy i pełna zgodność z EAA.

EAA a RODO: Gdzie te dwa światy się przecinają?

Możecie zapytać: „Piotr, co ma dostępność do ochrony danych osobowych?”. Odpowiedź jest prosta: Przejrzystość. Zgodnie z RODO (GDPR), informacje o przetwarzaniu danych muszą być dostarczone w formie „zwięzłej, przejrzystej, zrozumiałej i łatwo dostępnej”.

Jeśli Twoja polityka prywatności lub zgody marketingowe są zamknięte w nieczytelnych, niesemantycznych modalach, których czytnik ekranu nie potrafi obsłużyć, to de facto nie dostarczasz informacji w sposób dostępny. UODO w swoich decyzjach (choć rzadziej w kontekście samego HTML, a częściej w kontekście procesów) podkreśla, że brak dostępu do informacji jest naruszeniem praw podmiotu danych.

Jeśli ktoś nie może „odklikać” zgody na marketing, bo Twój checkbox jest zrobiony z diva i nie ma fokusu klawiatury, to właśnie złamałeś zasadę Privacy by Design.

Ryzyko finansowe: Kary z RODO mogą sięgać milionów euro, ale w polskich realiach MŚP częściej spotykamy kary w przedziale od kilku do kilkudziesięciu tysięcy złotych za rażące uchybienia w informowaniu użytkownika. Brak dostępności w kluczowych punktach styku (checkout, zgody RODO) to ogromna luka w Waszym compliance.

Praktyczny plan działania dla zespołu 5-10 deweloperów

Nie możecie przepisać całego sklepu w jeden weekend. Rozumiem to, budżety są napięte, a backlog pęka w szwach. Zastosujcie strategię „Krytycznych Ścieżek”.

• Ścieżka zakupowa (The Golden Path): Od strony produktu, przez koszyk, aż po stronę podziękowania. Tutaj semantyka musi być perfekcyjna. Każdy przycisk musi być <button>, każde pole formularza musi mieć <label>.
• Zgody i Prawniki: Banery cookies, checkboxy RODO, regulaminy. To są miejsca, gdzie ryzyko prawne jest największe.
• Nawigacja główna: Używajcie <nav>, <ul>, <li>. Nie budujcie menu z divów.

Szybka checklista weryfikacyjna

• [ ] Czy mogę przejść przez cały proces zakupu używając tylko klawisza TAB?
• [ ] Czy każdy element interaktywny ma wyraźny stan :focus?
• [ ] Czy formularze mają powiązane etykiety <label for="...">?
• [ ] Czy obrazy mają atrybuty alt (szczególnie te, które niosą informację o produkcie)?
• [ ] Czy nagłówki (h1 - h6) są użyte w logicznej kolejności, a nie dla „stylu wielkości tekstu”?

Jak nie zwariować przy audycie? (Case Study 5-minutowe)

Wielu z moich klientów próbowało zatrudniać drogich konsultantów od dostępności, którzy dostarczali 100-stronicowe raporty w PDF, z których nic nie wynikało. To strata pieniędzy. Podejście pragmatyczne wygląda tak: używamy narzędzi do automatycznego skanowania, aby wyłapać 80% błędów w 5 minut, a potem ręcznie sprawdzamy tylko krytyczne ścieżki.

Przykład z jednego z moich projektów dla sklepu z branży beauty (obroty ok. 2 mln PLN rocznie). Klient miał typowy „div-soup”. Skany wykazały 450 błędów dostępności. Zamiast panikować, skupiliśmy się na 12 krytycznych punktach w procesie checkoutu. Koszt: 2 dni pracy jednego front-endowca. Efekt: Wyeliminowanie ryzyka prawnego związanego z EAA i zwiększenie konwersji u osób starszych o ok. 3% (bo nagle mogli łatwiej nawigować).

Do takich szybkich audytów polecam narzędzia, które nie tylko mówią „jest błąd”, ale pokazują dokładnie, gdzie on jest i jak go naprawić. Jeśli chcecie szybko sprawdzić, gdzie Wasz sklep „leży” w kwestii bezpieczeństwa i podstawowej zgodności, polecam narzędzia od Tessera. Ich skaner pozwala w kilka minut zidentyfikować luki, które mogłyby przyciągnąć uwagę nie tylko audytora EAA, ale i hakerów. Sprawdźcie to tutaj: https://inspect-my-site.com.

Podsumowanie: Dostępność to nie tylko prawo, to ROI

W świecie e-commerce wygrywa ten, kto usuwa tarcie. EAA wymusza na nas usunięcie tarcia dla osób z niepełnosprawnościami, ale przy okazji poprawia UX dla wszystkich. Semantyczny HTML to lepsze SEO, szybsze ładowanie i mniejszy dług techniczny. Nie traktujcie EAA jako kolejnego obowiązku z Brukseli. Traktujcie to jako darmowy impuls do uporządkowania kodu, który i tak powinniście uporządkować dwa lata temu.

Najważniejsze wnioski dla Twojego zespołu

• EAA to prawo, nie sugestia. Od 2025 roku brak dostępności może skutkować karami.
• Semantyka > ARIA. Używaj natywnych elementów HTML5, aby zminimalizować pracę i ryzyko błędów.
• Związek z RODO. Brak dostępności w procesie informowania o danych osobowych to naruszenie zasad przejrzystości RODO.
• Strategia małych kroków. Zacznijcie od „Golden Path” – procesu zakupu i zgód prawnych.
• Automatyzuj weryfikację. Nie róbcie wszystkiego ręcznie; używajcie skanerów, aby szybko wyłapać niskowiszące owoce.

A jak to wygląda u Was? Dalej budujecie wszystko na divach, czy przeszliście już na semantykę? Czy w Waszych zespołach ktoś w ogóle słyszał o EAA, czy temat zostanie „załatwiony” na tydzień przed deadlinem w 2025 roku? Zapraszam do dyskusji w komentarzach.

O autorze: Piotr Wiśniewski to konsultant ds. e-commerce i ochrony danych z 12-letnim doświadczeniem, w tym w operacjach eBay w Warszawie. Specjalizuje się w przekładaniu skomplikowanych regulacji UE (RODO, EAA) na konkretne zadania dla zespołów deweloperskich. Pomógł ponad 40 polskim sklepom zoptymalizować procesy compliance bez rozbijania banku.

#javascript #webdev #ecommerce #accessibility