Digital Accessibility w e-commerce: Audyt WCAG, wtyczki czy dedykowany front?

Na początku 2025 r. każdy sklep internetowy staje przed wyborem: wdrożyć proste rozwiązania na gotowym szablonie, zainwestować w dedykowany frontend czy skorzystać tymczasowo z wtyczek-overlay? Ten artykuł przedstawia trzy ścieżki adaptacji dostępności cyfrowej, wyjaśnia ograniczenia „magicznych” wtyczek, wskazuje odpowiedzialności zespołów i opisuje, jak przeprowadzić rzetelny audyt WCAG – z analogią do znanego procesu SEO. Omówimy też kluczowe zapisy Ustawy z 26 kwietnia 2024 r. (zwłaszcza zwolnienie mikroprzedsiębiorców i okres przejściowy do 2030 r.) oraz zaprezentujemy rekomendowany workflow i harmonogram wdrożeń.

Trzy ścieżki wdrożenia dostępności

Ścieżka „prosta” na gotowym szablonie

Dla małych e-commerce’ów, które nie modyfikowały znacząco domyślnego frontendu, a korzystają z ICEberg CMS 5 najlepszą opcją jest migracja na najnowszą, dostępnościową wersję szablonu („default”) – to rozwiązanie tańsze i najszybsze, bo obejmuje gotowe poprawki i moduły oraz przyszłe aktualizacje.

Ścieżka „trudna” – dedykowany frontend

Sklepy z mocno zmodyfikowanym lub niestandardowym frontendem wymagają pełnego audytu WCAG i ręcznej implementacji zmian według checklisty. Proces przypomina audit SEO:

1. Analiza kluczowych stron – wybór najważniejszych widoków (strona główna, kategoria, produkt, koszyk) i weryfikacja pod kątem wszystkich success criteria WCAG 2.1 

2. Lista zadań dla developerów – opracowanie backlogu uwzględniającego role ARIA, semantyczną strukturę HTML, kontrast, obsługę klawiatury itp. na podstawie checklisty WCAG  

3. Implementacja i retest – deweloperzy wdrażają zmiany, a następnie przeprowadza się ponowny audyt automatyczny (axe, WAVE, Lighthouse) oraz testy manualne 

Ścieżka hybrydowa – wtyczka jako zabezpieczenie

Gdy budżet lub czas nie pozwala na pełne wdrożenie od razu, można zainstalować overlay-plugin jako krótkoterminową ochronę prawną i dowód regulatorom istnienia planu działań.

• Czym są nakładki? To wtyczki JavaScript, które w locie modyfikują styl i strukturę strony (rozmiar czcionki, kontrast, opcje „tylko tekst”), lub nawet próbują automatycznie naprawiać niezgodności w kodzie  

• Zalety: szybka instalacja, poprawa czytelności, demonstracja zamiaru dostosowania się do standardów.

• Ograniczenia: nie edytują źródłowego kodu, więc nie usuwają faktycznych barier; często generują nowe problemy (ukrywanie elementów przed czytnikami ekranu, konflikty z nawigacją klawiaturową)  

• Krytyka ekspertów: overlaye wykrywają zaledwie ~30% błędów WCAG; reszta zostaje niezaadresowana, co utrzymuje ryzyko pozwów i niezgodności

Dobór ścieżki

• Mały budżet i prosty frontend → migracja na gotowy szablon-demo.

• Pełna kontrola nad kodem → własny audyt WCAG i manualna implementacja.

• Tymczasowe zabezpieczenie → overlay-plugin + równoległe prace nad pełną dostępnością.

Każda z dróg powinna uwzględniać dalsze monitorowanie i utrzymanie, aby e-commerce pozostało zgodne z WCAG oraz przepisami (np. European Accessibility Act).

Wtyczki-overlay: zalety i pułapki

Overlaye reklamują automatyczne naprawy kontrastu, alt-tekstów czy focus managementu bez ingerencji w kod źródłowy, jednak w praktyce wychwytują jedynie około 20–30 % problemów dostępności, podczas gdy pozostałe bariery użytkownicy nadal napotykają   Dodatkowo mogą zakłócać nawigację klawiaturą i działanie czytników ekranowych, ponieważ modyfikują front-end w locie, często ukrywając lub zmieniając znaczenie interaktywnych elementów . Skrypty overlayów, hostowane na zewnętrznych serwerach, wpływają też na wydajność strony, co obniża SEO i doświadczenie użytkownika  . Z tego powodu overlaye warto traktować wyłącznie jako tymczasowe „plastry” do czasu pełnego, manualnego wdrożenia poprawek zgodnych z WCAG.

Obietnice vs. rzeczywistość

Obietnice vs. rzeczywistość

Obietnice overlayów

Overlaye obiecują:

• pełną automatyzację naprawy problemów z kontrastem, alt-tekstami i zarządzania fokusowaniem bez zmiany kodu źródłowego

• natychmiastowe usuwanie barier dostępności poprzez skanowanie i autopoprawki elementów HTML za pomocą AI  

Rzeczywistość

• Większość ekspertów zgadza się, że overlaye wykrywają i naprawiają tylko 20–30 % rzeczywistych problemów dostępności na stronie  

• Pozostałe 70–80 % błędów pozostaje niezauważonych i nieusuniętych, co utrzymuje istotne przeszkody dla osób z niepełnosprawnościami  

Główne ograniczenia overlayów

Brak merytorycznych alt-tekstów

Overlaye mogą wykryć brak atrybutu alt, lecz nie wygenerują wartościowego opisu funkcji obrazka – AI nie zastąpi ludzkiego osądu i wiedzy kontekstowej 

Zakłócenia nawigacji klawiaturą i czytnikami ekranu

• Overlays często wprowadzają konflikty z natywnymi ustawieniami przeglądarki i AT, przerywając lub utrudniając tab-order czy odczyt elementów przez screen reader  

• Mogą ukrywać przyciski i inne interaktywne obiekty, przez co użytkownicy nie są w stanie ich zlokalizować za pomocą czytnika ekranu  

Obciążenie wydajności strony

• • Zewnętrzne skrypty overlay często są ładowane z serwerów dostawcy, co wydłuża czas ładowania i zwiększa ryzyko przerw w dostępności w razie awarii lub ataku na te serwery  

  • Wolniejsze strony mają gorsze wyniki SEO i wyższy współczynnik odrzuceń: 40 % użytkowników opuszcza stronę, jeśli załadowanie trwa dłużej niż 3 sekundy 

Rekomendowane użycie

• Tymczasowe „plastry”: stosować overlaye wyłącznie jako krótkoterminowe rozwiązanie pokazujące regulatorom, że prowadzony jest plan działań  

• Równoległe wdrożenie trwałych poprawek: od razu uruchomić manualny audyt WCAG i harmonogram prac deweloperskich, by usunąć bariery u źródła zamiast polegać jedynie na auto-narzędziach  

• Monitorowanie i testy: nawet przy użyciu overlayów konieczne są regularne testy automatyczne (axe, WAVE) i manualne z udziałem osób z niepełnosprawnościami

Odpowiedzialność zespołów i proces ciągły

Dostawca systemu (np. Krakweb, ICEberg CMS 5) odpowiada za udostępnienie gotowego, zgodnego z WCAG AA szablonu frontendowego wraz z modułami do zarządzania alt-tekstami i rolami ARIA, co zapewnia techniczną możliwość spełnienia większości kryteriów dostępności  . Zespół marketingu i właściciel sklepu przygotowują banery, landingi i rich content z merytorycznymi alt-tekstami, logiczną strukturą nagłówków oraz czytelnymi komunikatami walidacyjnymi, dbając jednocześnie o testowanie każdej nowej treści pod kątem dostępności  . Dostępność to proces ciągły: regularne audyty automatyczne i manualne, wdrożenie poprawek, testy regresyjne oraz szkolenia nowych członków zespołu gwarantują długofalowe utrzymanie standardów

Co robi dostawca systemu (np. Krakweb i ICEberg CMS 5)

Odpowiedzialność dostawcy systemu

Dostępnościowy szablon frontendowy i moduły

Dostawca CMS udostępnia prekonfigurowany szablon front-endowy, w którym zaimplementowano semantyczne znaczniki HTML, odpowiednie poziomy kontrastu oraz role ARIA w panelu administracyjnym . W pakiecie znajdują się także moduły do definiowania alt-tekstów dla grafik i banerów oraz mechanizmy wspierające zarządzanie fokusowaniem .

Techniczna możliwość spełnienia kryteriów WCAG AA

Standardowe demo CMS-a spełnia wytyczne WCAG 2.1 poziomu AA, włączając w to strukturę nagłówków, opisy linków oraz mechanizmy obsługi klawiatury. Dostawca zapewnia również wbudowane narzędzia do testów kontrastu kolorów i walidacji kodu pod kątem sukces‐kryteriów WCAG

Co robi właściciel sklepu / zespół marketingu

Odpowiedzialność właściciela sklepu / zespołu marketingu

Przygotowanie banerów z alt-tekstami

Zespół marketingu przygotowuje banery reklamowe z merytorycznymi alt-tekstami, które opisują nie tylko wygląd, ale przede wszystkim cel i funkcję obrazu, co jest kluczowe dla użyteczności osób korzystających z czytników ekranowych  

Tworzenie landingów i rich content

Podczas tworzenia stron docelowych (landing pages) oraz materiałów typu rich content należy stosować poprawne etykiety formularzy, logiczną hierarchię nagłówków (<h1>–<h6>) i wyraźne komunikaty walidacyjne, zgodnie z wytycznymi ARIA i WCAG  

Testowanie nowej treści

Każdy nowy moduł, szablon lub wpis w sklepie musi przejść testy pod kątem dostępności: zarówno automatyczne skanery (np. axe-core, WAVE, Lighthouse), jak i testy manualne z użyciem klawiatury i czytników ekranowych

Proces ciągłych audytów

Audyt automatyczny

Automatyczne narzędzia (axe-core, Lighthouse, WAVE) pozwalają szybko wykryć podstawowe błędy: brak alt-tekstów, niewystarczający kontrast, brak etykiet formularzy 

Audyt ręczny

Manualne testy obejmują nawigację klawiaturą (Tab, Shift+Tab, Enter) oraz sprawdzenie działania z najpopularniejszymi czytnikami ekranowymi (VoiceOver, NVDA, JAWS)

Wdrożenie poprawek i testy regresyjne

Po identyfikacji problemów zespół wprowadza poprawki w kodzie i treści, po czym przeprowadza testy regresyjne, aby upewnić się, że nowe wydania nie wprowadziły regresji w obszarze dostępności

Szkolenia i utrzymanie kompetencji

Szkolenia dla nowych członków zespołu

Organizacja regularnych szkoleń – zarówno onboardingowych, jak i okresowych – pozwala utrzymać świadomość zasad dostępności wśród deweloperów, projektantów i marketingu  

Dokumentacja i kultura dostępności

Tworzenie i aktualizacja wewnętrznych wytycznych, checklist WCAG oraz procedur postępowania w razie wątpliwości buduje kulturę dostępności, w której każdy zna swoje obowiązki

Przebieg audytu WCAG (analogicznie do SEO)

Audyt WCAG, wzorowany na procesie SEO, składa się z czterech etapów:

1. Analiza („crawl”) – wykorzystanie narzędzi automatycznych (Axe, WAVE, Lighthouse) do wykrycia podstawowych błędów oraz manualne testy klawiaturą i czytnikami (NVDA, VoiceOver, JAWS)  

2. Raport i check-lista – sporządzenie dokumentu zawierającego listę stron priorytetowych, opis błędów, odniesienia do konkretnych Success Criterion WCAG oraz rekomendowane poprawki  

3. Wdrożenie poprawek – implementacja zmian w front-endzie (np. aria-live dla dynamicznych komunikatów, role alert dla błędów formularzy) oraz w strukturze formularzy (label for, aria-invalid, opisy błędów przed wysłaniem) zgodnie z wytycznymi SC 3.2.2, 3.3.1 i 3.3.2  

4. Retest i certyfikacja – ponowne uruchomienie „crawlów” i manualnych testów, potwierdzenie usunięcia błędów, zamknięcie check-listy oraz dokumentacja procesu jako dowód spełnienia wymogów prawnych  

Etap 1: Analiza („crawl”)

• Narzędzia automatyczne

  • Axe (Deque University) – wykrywa problemy z semantyką HTML, atrybutami ARIA i kontrastem kolorów dequeuniversity.com.

  • WAVE (WebAIM) – umożliwia szybką wizualizację błędów w kodzie i wytycznych WCAG 2.1 webaim.org.

  • Lighthouse (Google) – raportuje m.in. kontrast, rozmiary czcionek i obsługę focus-ring  

• Testy manualne

  • Nawigacja klawiaturą (Tab, Shift+Tab, Enter) bez użycia myszy – sprawdza logiczny porządek focusu i widoczność wskaźnika focus 

  • Czytniki ekranu: NVDA (Windows) oraz VoiceOver (macOS/iOS) – weryfikacja, czy elementy są prawidłowo komunikowane użytkownikowi  

Etap 2: Raport i check-lista

• Strony priorytetowe – wyodrębnić kluczowe widoki (home, kategorie, produkt, koszyk) i przypisać im wagę biznesową 

• Opis błędów – dla każdej strony opisać znalezione problemy (np. „brak alt-tekstów przy obrazkach produktowych”) wraz z odniesieniem do Success Criterion WCAG (np. 1.1.1 Non-text Content)  

• Rekomendowana poprawka – konkretne instrukcje dla deweloperów/zespółu marketingu (np. „dodać alt="Opis funkcji produktu"”, „poprawić kontrast przy przycisku CTA do min. 4.5:1”)

Etap 3: Wdrożenie poprawek

Frontend

• ARIA Live Regions (SC 3.2.2) – wykorzystanie aria-live="polite" lub assertive dla komunikatów dynamicznych (np. „Dodano do koszyka”) 

• Role alert (SC 3.3.1) – oznaczanie błędów walidacji formularzy przez role="alert", by screen reader natychmiast je odczytał  

Formularze

Etykiety i atrybuty

• label for="pole" dla każdego pola, unikanie placeholderów jako jedynej etykiety (SC 3.3.2)  
• aria-invalid="true" dla pól z błędami oraz opis błędu wyświetlany pod polem przed próbką wysłania (SC 3.3.2)  

Etap 4: Retest i certyfikacja

• Ponowny „crawl” – uruchomić Axe, WAVE i Lighthouse ponownie, by zweryfikować usunięcie automatycznie wykrytych błędów 

• Manualne testy regresyjne – powtórzyć testy klawiaturą i czytnikiem, upewnić się, że nie wprowadzono nowych problemów 

• Zamknięcie check-listy – odfajkować wszystkie punkty, wygenerować ostateczny raport zgodności.

• Dokumentacja – przechowywać logi z narzędzi, zrzuty ekranu i notatki z testów manualnych jako dowód spełnienia wymogów prawnych (np. European Accessibility Act 2019)

Kontekst prawny: ustawa z 26 kwietnia 2024

Zakres i terminy

• Ustawa o dostępności cyfrowej obowiązuje od 26 czerwca 2025 r. dla nowych i zaktualizowanych usług online  
• Okres przejściowy do 28 czerwca 2030 r. dla serwisów „w formie niezmienionej” przed 2025 r. – bez oficjalnej definicji, wymaga interpretacji organów Sejm Orka.

Zwolnienia mikroprzedsiębiorców

Mikroprzedsiębiorcy (zatrudnienie < 10 osób, obrót < 2 mln EUR) są zwolnieni z obowiązku dostosowania produktów i usług cyfrowych  

Prawa użytkownika i kary

• Użytkownik może zażądać dostępności; firma ma 7 dni na odpowiedź (max. 2 miesiące).
• Kary do 10 % rocznego obrotu, do 5 000 PLN za brak deklaracji dostępności  

Rekomendowany harmonogram wdrożenia WCAG z Krakweb

Wnioski

• Wybór ścieżki zależy od stopnia modyfikacji frontendu i budżetu.
• Overlaye to tylko doraźne rozwiązanie – zawsze planuj pełny audyt.
• Proces jest ciągły, jak SEO – audyt, wdrożenie, retest, szkolenia.
• Prawo daje czas i zwolnienia, ale unikanie dostosowań to ryzyko kar i utraty klientów.

Źródła

1. Overlay Fact Sheet – ograniczenia overlayów i opinie ekspertów overlayfactsheet.com
2. Readspeaker: „Accessibility overlays can’t guarantee full compliance” ReadSpeaker
3. Silktide: „Accessibility overlays are evil and they need to die” Silktide
4. Colorado Virtual Library: overlay nie daje pełnej zgodności WCAG coloradovirtuallibrary.org
5. WebAIM WCAG 2 Checklist – przykładowa checklista audytu webaim.org 
6. Sitebulb: SEO vs Accessibility Audit analogy Sitebulb
7. MDL Kancelaria: zwolnienie mikroprzedsiębiorców z obowiązków dostępności Kancelaria Prawna MDL 
8. Orka Sejm: tekst Ustawy z 26 kwietnia 2024 r. (art. 2, ust. 2) Sejm Orka
9. W3C ARIA live regions – aria-live dla dynamicznych zmian webaim.org  
10. A11Y Project: WCAG checklist summary (POUR) Home - The A11Y Project