EAA w polskim e-commerce: Dlaczego „div-soup” to teraz ryzyko biznesowe i jak semantyka HTML ratuje Twój budżet
Meta: Dowiedz się, jak Europejski Akt Dostępności (EAA) wpływa na polskie sklepy internetowe. Sprawdź, dlaczego semantyczny HTML to klucz do zgodności i uniknięcia kar.
Słuchajcie, powiedzmy to sobie szczerze: większość z nas, programistów, przez lata budowała interfejsy w stylu „div-soup”. Jeden div w drugim, div w trzecim, a na koniec dodajemy onclick do elementu, który wcale nie jest przyciskiem. Działało? Tak. Wyglądało dobrze w Chrome? Oczywiście. Ale teraz wchodzi EAA (European Accessibility Act), a wraz z nim polskie przepisy o dostępności, i nagle ten „sposób na szybkie dowożenie ficzerów” staje się ogromnym ryzykiem prawnym i finansowym.
Jako ktoś, kto przez lata siedział w compliance w eBayu i teraz doradza polskim MŚP, widzę ten sam wzorzec: właściciele sklepów myślą, że dostępność to „miły dodatek” lub kwestia etyki. Błąd. EAA to twarde prawo. Jeśli Twój sklep nie będzie dostępny dla osób niewidomych czy słabowidzących, nie tylko tracisz klientów, ale narażasz się na kary, które mogą sprawić, że Twój marżowy zysk z całego kwartału zniknie w jeden dzień.
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 zdivó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.
Top comments (0)