Dostosowanie sklepu internetowego do WCAG – jak wygląda wdrożenie i ile kosztuje?

Dostosowanie sklepu internetowego do WCAG nie powinno polegać na dodaniu widżetu zmieniającego kontrast lub wielkość tekstu. W e-commerce dostępność dotyczy całej ścieżki zakupowej: od menu i wyszukiwarki, przez kartę produktu i wybór wariantu, aż po koszyk, formularze, płatność i potwierdzenie zamówienia. Jeżeli klient nie może samodzielnie przejść któregoś z tych etapów za pomocą klawiatury, czytnika ekranu albo powiększenia, problem jest funkcjonalny, a nie kosmetyczny.

Od 28 czerwca 2025 roku temat ma również wymiar prawny. Polski Akt o Dostępności obejmuje określone usługi handlu elektronicznego świadczone konsumentom. Jednocześnie nie oznacza to, że każdy sklep podlega identycznym obowiązkom ani że sama zgodność z WCAG automatycznie wyczerpuje wszystkie wymagania ustawy.

W tym poradniku pokazujemy, jak podejść do dostępności sklepu profesjonalnie: od ustalenia zakresu i audytu, przez wdrożenie zmian, po re-audyt, dokumentację i utrzymanie dostępności po kolejnych aktualizacjach.

Informacje prawne w artykule mają charakter informacyjny i nie stanowią porady prawnej. Stan prawny i techniczny opisany w materiale odpowiada informacjom dostępnym we wrześniu 2026 roku.

Co oznacza dostosowanie sklepu internetowego do WCAG?

WCAG, czyli Web Content Accessibility Guidelines, to wytyczne W3C opisujące, jak projektować i tworzyć treści internetowe dostępne dla osób z różnymi niepełnosprawnościami. Aktualną rekomendacją W3C jest WCAG 2.2.

Wytyczne opierają się na czterech zasadach. Interfejs powinien być:

• postrzegalny – informacje muszą być dostępne w formie możliwej do odebrania przez użytkownika,
• funkcjonalny – z elementów interfejsu musi dać się korzystać różnymi metodami obsługi,
• zrozumiały – działanie interfejsu, treści i komunikaty powinny być przewidywalne i czytelne,
• kompatybilny – kod powinien współpracować z przeglądarkami i technologiami asystującymi.

W sklepie internetowym oznacza to znacznie więcej niż odpowiedni kontrast. Dostępność trzeba uwzględnić w strukturze HTML, obsłudze klawiatury, fokusie, formularzach, komunikatach błędów, modalach, filtrach, galerii produktu, wariantach, koszyku, checkoutcie i integracjach.

W praktycznych wdrożeniach w Travi jako cel techniczny przyjmujemy WCAG 2.2 na poziomie AA. Jest to aktualny standard rekomendowany przez W3C i obejmuje również kryteria dodane względem WCAG 2.1, między innymi dotyczące zasłonięcia fokusa, minimalnego rozmiaru celu dotykowego, przeciągania oraz dostępnego uwierzytelniania.

Czy każdy sklep internetowy musi spełniać WCAG?

Nie. To jedno z najważniejszych rozróżnień, ponieważ w uproszczonych materiałach często można spotkać stwierdzenie, że od 28 czerwca 2025 roku każda firmowa strona i każdy sklep muszą być zgodne z WCAG. Tak sformułowana teza jest nieprawidłowa.

Polski Akt o Dostępności, czyli ustawa z 26 kwietnia 2024 roku wdrażająca Europejski Akt o Dostępności, obejmuje między innymi usługi handlu elektronicznego. Gov.pl definiuje je jako usługi oferowane lub świadczone na odległość przez strony internetowe i urządzenia mobilne, drogą elektroniczną i na indywidualne żądanie konsumenta w celu zawarcia umowy.

W praktyce typowy sklep B2C, w którym konsument może kupić produkt online, może więc znajdować się w zakresie PAD. Ustawa przewiduje jednak wyłączenia. Jedno z najważniejszych dotyczy usług oferowanych lub świadczonych przez mikroprzedsiębiorców.

Dlatego przed rozpoczęciem projektu warto rozdzielić dwa pytania:

1. Czy firma podlega obowiązkom wynikającym z PAD?
2. Jaki poziom dostępności chcemy zapewnić niezależnie od obowiązku prawnego?

Nawet sklep, którego usługa jest wyłączona z obowiązków wynikających z PAD, może wdrożyć dostępność jako standard jakości, element UX i sposób poszerzenia grupy klientów.

Szerzej zakres podmiotów i wyjątków opisujemy w artykule WCAG – kogo obowiązuje i kto musi dostosować stronę lub sklep?.

WCAG, Polski Akt o Dostępności i EN 301 549 – co jest czym?

Te pojęcia często są używane zamiennie, ale nie oznaczają tego samego.

Oznacza to, że WCAG 2.2 jest właściwym, aktualnym celem technicznym dla nowych wdrożeń, natomiast przy ocenie zgodności prawnej trzeba jednocześnie uwzględniać formalnie obowiązujący standard referencyjny.

To rozróżnienie jest ważne przy ofertach typu „certyfikat zgodności z EAA po wdrożeniu WCAG”. Spełnienie kryteriów WCAG jest bardzo ważnym elementem technicznej dostępności, ale nie należy automatycznie utożsamiać deklaracji zgodności z WCAG 2.2 AA z pełnym spełnieniem wszystkich obowiązków Polskiego Aktu o Dostępności.

PAD zawiera także obowiązki organizacyjne i informacyjne. Usługodawca objęty ustawą powinien między innymi oceniać zgodność usługi z wymaganiami dostępności oraz podawać do publicznej wiadomości informacje o tym, w jaki sposób usługa spełnia te wymagania. Gov.pl wskazuje, że taka informacja powinna znaleźć się w regulaminie świadczenia usług lub równoważnym dokumencie.

Nie należy tego mylić z „deklaracją dostępności” znaną z ustawy dotyczącej stron i aplikacji podmiotów publicznych. W przypadku przedsiębiorców objętych PAD obowiązek informacyjny ma inną podstawę prawną i formę.

Co trzeba sprawdzić w sklepie internetowym?

Audyt sklepu nie powinien polegać na sprawdzeniu kilku reprezentacyjnych podstron i pominięciu procesu zakupowego. Kluczowe jest zweryfikowanie całej ścieżki, którą klient przechodzi od wejścia do serwisu do złożenia zamówienia.

Najważniejsze obszary to:

• nagłówek i główna nawigacja,
• menu mobilne,
• wyszukiwarka produktów,
• kategorie, paginacja, sortowanie i filtry,
• karta produktu,
• galeria zdjęć i multimedia,
• wybór wariantu, konfiguratora lub dodatków,
• informacje o cenie, promocji, dostępności i dostawie,
• dodawanie produktu do koszyka,
• koszyk i zmiana ilości produktów,
• checkout,
• formularze i walidacja błędów,
• wybór dostawy i płatności,
• logowanie, rejestracja i odzyskiwanie hasła,
• konto klienta,
• komunikaty systemowe, modale i powiadomienia,
• treści regulaminów, polityk i dokumentów do pobrania,
• integracje zewnętrzne widoczne dla użytkownika.

W rozbudowanym e-commerce dochodzą do tego funkcje specyficzne dla biznesu, na przykład konfiguratory, listy życzeń, porównywarki, programy lojalnościowe, systemy B2B, formularze wyceny czy procesy ratalne.

Najczęstsze problemy WCAG w sklepach internetowych

Problemy z dostępnością często nie są widoczne podczas standardowego przeglądania strony myszką. Ujawniają się dopiero przy obsłudze klawiaturą, większym powiększeniu albo z użyciem czytnika ekranu.

W sklepach najczęściej spotykamy między innymi:

• brak pełnej obsługi klawiaturą – np. nie można otworzyć menu, filtrów albo wybrać wariantu,
• niewidoczny lub zasłonięty fokus, przez co użytkownik nie wie, który element jest aktywny,
• nieprawidłową kolejność fokusa w modalach, menu i checkoutcie,
• niski kontrast tekstu, ikon, obramowań pól i stanów interfejsu,
• brak etykiet formularzy albo poleganie wyłącznie na placeholderach,
• komunikaty błędów przekazywane tylko kolorem,
• brak informacji dla technologii asystujących po zmianie ilości, dodaniu produktu lub aktualizacji koszyka,
• nieprawidłowe nazwy przycisków i linków, np. wiele elementów odczytywanych jako „więcej”,
• obrazy produktowe bez odpowiednich alternatyw tekstowych, gdy obraz przekazuje istotną informację,
• błędną hierarchię nagłówków i semantykę HTML,
• interaktywne elementy zbudowane z niewłaściwych znaczników,
• problemy z powiększeniem i reflow,
• zbyt małe cele dotykowe,
• przeciąganie jako jedyny sposób wykonania działania,
• niedostępne mechanizmy logowania i uwierzytelniania.

Nie każda grafika potrzebuje opisowego tekstu alternatywnego. Elementy czysto dekoracyjne powinny być możliwe do pominięcia przez technologie asystujące, natomiast grafika przekazująca informację potrzebuje równoważnej alternatywy. Takie decyzje wymagają analizy kontekstu, dlatego automatyczne uzupełnianie każdego pola ALT nazwą pliku nie jest prawidłowym wdrożeniem dostępności.

Jak wygląda wdrożenie WCAG w sklepie krok po kroku?

Najbezpieczniejszy proces rozdziela diagnozę od napraw. Dzięki temu wiadomo, co jest rzeczywistym problemem, jak duży jest jego wpływ i czy poprawka może oddziaływać na inne elementy sklepu.

1. Ustalenie zakresu

Na początku trzeba poznać technologię sklepu, rodzaje użytkowników, kluczowe szablony, funkcje niestandardowe, integracje oraz proces zakupowy. Przy dużym katalogu nie bada się ręcznie każdego produktu osobno. Dobiera się reprezentatywne widoki i stany, ale wszystkie unikalne mechanizmy muszą znaleźć się w zakresie.

2. Audyt dostępności

Audyt powinien łączyć testy automatyczne i manualne. Narzędzia pomagają znaleźć część problemów w kodzie, ale nie ocenią wiarygodnie na przykład sensu nazwy przycisku, logicznej kolejności fokusa, jakości komunikatu błędu czy tego, czy proces zakupowy da się rzeczywiście ukończyć.

W praktyce testujemy między innymi:

• obsługę wyłącznie za pomocą klawiatury,
• fokus i kolejność przechodzenia po elementach,
• czytniki ekranu,
• powiększenie i reflow,
• kontrasty,
• strukturę semantyczną,
• formularze i komunikaty,
• interakcje dynamiczne,
• najważniejsze scenariusze zakupowe.

3. Priorytetyzacja błędów

Raport powinien być dokumentem wdrożeniowym, a nie tylko listą kryteriów WCAG. Dla każdego problemu warto określić lokalizację, wpływ na użytkownika, kryterium, sposób odtworzenia oraz rekomendowaną naprawę.

Najwyższy priorytet powinny mieć bariery blokujące wykonanie kluczowego zadania, na przykład brak możliwości wyboru dostawy bez myszy, niedostępny modal koszyka albo błąd formularza, którego czytnik ekranu nie komunikuje.

4. Wdrożenie zmian w kodzie, UI i treści

Poprawki mogą obejmować HTML, CSS, JavaScript, komponenty szablonu, treści i konfigurację platformy. Część problemów wymaga niewielkiej korekty, a część przebudowy komponentu.

Przykładowo:

• zmiana kontrastu może wymagać tylko korekty design systemu,
• poprawa etykiety formularza może być zmianą w HTML,
• dostępny modal wymaga poprawnego zarządzania fokusem i zachowania po zamknięciu,
• dostępny filtr AJAX może wymagać przebudowy komunikatów i stanów dynamicznych,
• niedostępny konfigurator produktu może wymagać znacznie większej ingerencji w frontend.

Zmiany najlepiej wdrażać najpierw na środowisku testowym, szczególnie gdy dotyczą koszyka, checkoutu albo elementów współdzielonych przez cały sklep.

5. Re-audyt po wdrożeniu

Naprawienie kodu na podstawie raportu nie kończy procesu. Po zmianach trzeba ponownie przejść przez kryteria i scenariusze zakupowe. Poprawka jednego elementu może wprowadzić nowy problem albo działać inaczej na urządzeniu mobilnym.

6. Informacja o dostępności i procedury

Jeżeli firma podlega PAD, warstwa techniczna to tylko część projektu. Trzeba również zadbać o wymagane informacje dotyczące sposobu spełniania wymagań dostępności oraz proces reagowania na wykryte niezgodności.

Gov.pl wskazuje także obowiązek poinformowania Ministra Cyfryzacji, gdy objęta ustawą usługa handlu elektronicznego nie spełnia wymagań dostępności, wraz z informacją o działaniach naprawczych.

Czy automatyczny test WCAG wystarczy?

Nie. Automatyczne narzędzia są bardzo przydatne, ale nie mogą samodzielnie potwierdzić pełnej zgodności sklepu z WCAG.

W3C wskazuje, że ocena dostępności obejmuje zarówno testy automatyczne, jak i ocenę człowieka. Jest to szczególnie istotne w e-commerce, ponieważ wiele problemów dotyczy znaczenia, kontekstu i zachowania całego procesu.

Automatyczny skaner potrafi wykryć na przykład część problemów z kontrastem, brakujące nazwy dostępnościowe lub niektóre błędy struktury. Nie odpowie jednak wiarygodnie na pytanie, czy:

• użytkownik rozumie komunikat błędu,
• kolejność fokusa jest logiczna,
• tekst alternatywny rzeczywiście oddaje znaczenie obrazu,
• filtry da się efektywnie obsługiwać czytnikiem ekranu,
• checkout można zakończyć bez używania myszy,
• zmiana stanu interfejsu jest właściwie komunikowana.

Dlatego wynik 100/100 z pojedynczego narzędzia automatycznego nie jest certyfikatem dostępności.

Czy widżet dostępności wystarczy do zgodności z WCAG?

Nie powinno się traktować nakładki lub widżetu dostępności jako zamiennika prawidłowego wdrożenia.

Panel pozwalający zwiększyć tekst, przełączyć kontrast albo zatrzymać animacje może być dodatkową funkcją dla użytkownika. Nie naprawi jednak błędnej semantyki HTML, niedostępnego formularza, problemów z klawiaturą, źle zbudowanego modala, braku komunikatów statusu czy niedostępnego checkoutu.

O zgodności decyduje działanie właściwego interfejsu i treści, a nie obecność ikony „dostępność” w rogu strony.

Jeżeli problem istnieje w kodzie komponentu, powinien zostać poprawiony w tym komponencie.

Ile kosztuje dostosowanie sklepu do WCAG?

Nie istnieje jedna cena, ponieważ pojęcie „wdrożenie WCAG” może oznaczać sam audyt niewielkiego sklepu albo przebudowę kilkunastu niestandardowych komponentów rozbudowanej platformy.

Na polskim rynku w 2026 roku audyty stron i sklepów są oferowane od około 2 000 zł netto, a bardziej rozbudowane audyty manualne kosztują kilka tysięcy złotych i więcej. Koszt samego wdrożenia zależy przede wszystkim od liczby i rodzaju znalezionych problemów.

Do planowania budżetu można przyjąć orientacyjnie:

Widełki są orientacyjne i służą do planowania budżetu. Nie stanowią cennika Travi. Cena konkretnego projektu zależy od technologii, stanu kodu, liczby unikalnych widoków i funkcji oraz zakresu testów.

W praktyce najtańsze projekty to sklepy o poprawnej semantyce, spójnym design systemie i niewielkiej liczbie niestandardowych komponentów. Najdroższe są sytuacje, w których błędy dostępności wynikają z fundamentów frontendu i trzeba przebudować menu, filtry, modal, checkout lub konfigurator produktu.

Od czego zależy koszt wdrożenia WCAG?

Największy wpływ na budżet mają:

• platforma i sposób wykonania motywu,
• liczba unikalnych komponentów,
• złożoność checkoutu,
• filtry i wyszukiwarka,
• niestandardowe konfiguratory produktów,
• liczba formularzy i modalów,
• integracje zewnętrzne,
• stan semantyki HTML,
• stopień wykorzystania JavaScriptu i AJAX,
• liczba błędów wspólnych dla całego design systemu,
• konieczność zmian w projekcie UI,
• zakres treści, dokumentów i multimediów,
• potrzeba testów na wielu urządzeniach i technologiach asystujących.

Dlatego wycena tylko na podstawie liczby produktów jest mało użyteczna. Tysiące produktów korzystające z jednego dobrze zbudowanego szablonu mogą być prostsze do poprawy niż sklep z 50 produktami i pięcioma dedykowanymi konfiguratorami.

Nowy sklep czy poprawianie istniejącego – kiedy WCAG kosztuje mniej?

Najbardziej ekonomiczne jest uwzględnienie dostępności jeszcze na etapie projektowania nowego sklepu.

Jeżeli design system od początku ma prawidłowe kontrasty, stany fokusa i odpowiednie rozmiary elementów, a programiści budują komponenty semantycznie i testują je z klawiaturą, wiele problemów po prostu nie powstaje.

Przy gotowym sklepie koszt zależy od długu technicznego. Czasem wystarczy seria punktowych poprawek. W innych projektach trzeba przebudować podstawowe komponenty, co jest de facto częściowym redesignem i refaktoryzacją frontendu.

Dlatego przy nowym e-commerce warto połączyć dostępność z projektowaniem sklepu internetowego już od początku, zamiast traktować WCAG jako kontrolę wykonywaną dzień przed uruchomieniem.

WCAG a UX – czy dostępny sklep jest też łatwiejszy w obsłudze?

WCAG i UX nie są tym samym, ale mają wiele wspólnych obszarów.

Widoczny fokus pomaga osobie korzystającej z klawiatury, ale również użytkownikowi, który chwilowo nie korzysta z myszy. Czytelne etykiety formularzy wspierają technologie asystujące, a jednocześnie zmniejszają niepewność podczas checkoutu. Jasne komunikaty błędów pomagają osobom z niepełnosprawnościami poznawczymi, ale są korzystne dla praktycznie każdego klienta.

Z drugiej strony strona może spełniać kryteria WCAG i nadal mieć słabą architekturę informacji albo nieintuicyjną ścieżkę zakupową. Dlatego przy większej przebudowie warto spojrzeć jednocześnie na dostępność i użyteczność.

W Travi możemy połączyć audyt dostępności z audytem UX, gdy problem dotyczy zarówno barier WCAG, jak i skuteczności procesu zakupowego.

WooCommerce, PrestaShop, Shopify i Shoper – czy wdrożenie wygląda tak samo?

Cel jest podobny, ale sposób wdrażania zmian zależy od technologii.

Przy systemach SaaS i aplikacjach zewnętrznych szczególnie ważne jest ustalenie, które bariery można poprawić we własnym kodzie, a które wymagają działania dostawcy. Nie powinno się obiecywać naprawy elementu, nad którym zespół wdrożeniowy nie ma technicznej kontroli.

Ile trwa dostosowanie sklepu do WCAG?

Dla standardowego sklepu cały proces od audytu do re-audytu zwykle zajmuje od kilku tygodni do kilku miesięcy. Czas zależy od liczby błędów, dostępności zespołu, technologii i tego, czy poprawki wymagają przebudowy kluczowych funkcji.

Przykładowy harmonogram może wyglądać tak:

W dużym sklepie lepiej realizować zmiany etapami niż próbować jednocześnie przebudować wszystkie komponenty. Krytyczne bariery w checkoutcie powinny mieć wyższy priorytet niż drobne problemy na rzadko odwiedzanej stronie informacyjnej.

Co po wdrożeniu? Dostępność trzeba utrzymywać

Sklep zgodny w dniu re-audytu może po kilku miesiącach ponownie mieć problemy. Wystarczy nowa wtyczka, przebudowany formularz, baner marketingowy z nieczytelnym tekstem albo aktualizacja komponentu.

Dlatego dostępność powinna wejść do normalnego procesu rozwoju:

• nowe komponenty powinny być sprawdzane przed publikacją,
• zmiany design systemu powinny uwzględniać kontrasty i stany interakcji,
• redaktorzy powinni wiedzieć, jak pisać alternatywy tekstowe i budować strukturę treści,
• większe aktualizacje checkoutu powinny kończyć się testem klawiaturą i czytnikiem ekranu,
• okresowo warto wykonać re-audyt najważniejszych ścieżek.

To jeden z powodów, dla których wdrożenie dostępności dobrze łączy się ze stałą obsługą sklepu internetowego. Zespół znający kod może pilnować, aby kolejne funkcje nie przywracały wcześniej usuniętych barier.

Jak wybrać firmę do audytu i wdrożenia WCAG?

W przypadku sklepu ważna jest nie tylko znajomość listy kryteriów, ale również umiejętność wdrożenia zmian bez uszkodzenia procesu sprzedażowego.

Przed wyborem wykonawcy warto sprawdzić:

• czy audyt obejmuje testy manualne,
• czy testowana jest cała ścieżka zakupowa,
• czy raport zawiera konkretne rekomendacje dla programistów,
• czy wykonawca potrafi również wdrożyć poprawki,
• czy testuje klawiaturę i technologie asystujące,
• czy rozróżnia WCAG od wymagań prawnych PAD,
• czy po wdrożeniu wykonuje re-audyt,
• czy rozumie UX i specyfikę e-commerce,
• czy potrafi pracować z używaną przez sklep platformą i integracjami.

Sygnałem ostrzegawczym jest oferta sprowadzająca cały proces do instalacji jednego pluginu, automatycznego skanu albo dodania panelu dostępności.

Dostosowanie sklepu do WCAG w Travi

W Travi łączymy audyt z developmentem. Dzięki temu możemy nie tylko wskazać bariery, ale również poprawić kod, komponenty interfejsu i proces zakupowy, a następnie ponownie zweryfikować wdrożenie.

Pracujemy ze stronami i sklepami już działającymi, a przy nowych projektach możemy uwzględnić WCAG na etapie UX/UI i developmentu. Zobacz usługę audytu i wdrożenia WCAG.

Źródła i dalsza lektura

• Gov.pl – Polski Akt o Dostępności i usługi handlu elektronicznego
• Gov.pl – obowiązki informacyjne w Polskim Akcie o Dostępności
• Gov.pl – normy i specyfikacje dla dostępności usług handlu elektronicznego
• W3C – Web Content Accessibility Guidelines (WCAG) 2.2
• W3C WAI – ocena dostępności stron internetowych
• Dziennik Ustaw – ustawa z 26 kwietnia 2024 r. o zapewnianiu spełniania wymagań dostępności niektórych produktów i usług przez podmioty gospodarcze

FAQ: dostosowanie sklepu internetowego do WCAG