Czy sklep internetowy musi spełniać WCAG w 2026 roku?

Czy sklep internetowy musi spełniać WCAG? W 2026 roku sklep działający w Polsce może podlegać wymaganiom dostępności, ale nie każda firmowa strona automatycznie musi spełniać ten sam zakres. Znaczenie ma rodzaj świadczonej usługi, możliwość zawarcia umowy z konsumentem przez internet oraz status przedsiębiorcy. Sam napis „zgodne z WCAG” nie rozstrzyga też zgodności z prawem.

Jeżeli planujesz nowy sklep albo przebudowę obecnego, dostępność warto ustalić przed projektem makiet i wyboru komponentów. Poprawianie gotowego checkoutu, menu oraz integracji płatniczych po publikacji jest zwykle trudniejsze niż uwzględnienie wymagań w projekcie.

Krótka odpowiedź: nie każda strona, ale e-commerce często tak

Od 28 czerwca 2025 roku obowiązuje ustawa nazywana Polskim Aktem o Dostępności, która wdraża Europejski Akt o Dostępności. Oficjalne wyjaśnienie Ministerstwa Cyfryzacji wskazuje, że obejmuje ona między innymi usługi handlu elektronicznego. Chodzi o usługi oferowane na odległość przez stronę lub urządzenie mobilne, drogą elektroniczną i na indywidualne żądanie konsumenta w celu zawarcia umowy.

W praktyce sklep B2C z koszykiem i płatnością online znajduje się znacznie bliżej tego zakresu niż prosta strona informacyjna, na której można jedynie przeczytać ofertę i zadzwonić. Ocenia się jednak rzeczywistą funkcję serwisu, a nie nazwę używaną w menu.

Ustawa przewiduje wyłączenie dla usług oferowanych lub świadczonych przez mikroprzedsiębiorcę. Nie należy jednak utożsamiać tego automatycznie z jednoosobową działalnością. Status wynika z ustawowych kryteriów i sytuacji konkretnej firmy. Jeśli nie masz pewności, potwierdź zakres obowiązków z prawnikiem lub doradcą, zanim wpiszesz wymóg do umowy z wykonawcą.

WCAG, EN 301 549 i ustawa to trzy różne rzeczy

Te pojęcia często są wrzucane do jednego worka:

• Polski Akt o Dostępności określa obowiązki podmiotów gospodarczych i nadzór nad ich wykonaniem,
• EN 301 549 opisuje wymagania dostępności dla produktów i usług ICT,
• WCAG zawiera testowalne kryteria dostępności treści internetowych.

Ministerstwo Cyfryzacji w wykazie norm dla usług e-handlu wskazuje EN 301 549 V3.2.1 z 2021 roku. Norma odwołuje się do kryteriów WCAG 2.1. Z kolei W3C zaleca stosowanie aktualnej wersji WCAG 2.2 i wyjaśnia, że rozwija ona WCAG 2.1.

Dla nowego sklepu rozsądnym celem projektowym jest WCAG 2.2 na poziomie AA, ale zapis w umowie nie powinien kończyć się na tym jednym zdaniu. Trzeba wskazać także badane widoki, pełne procesy, metodę odbioru i sposób raportowania błędów. Ocena obowiązku prawnego powinna odnosić się do ustawy oraz właściwej normy, a nie tylko do checklisty WCAG.

Dostępny musi być cały proces zakupu

Nie wystarczy poprawić stronę główną i kartę produktu. Klient powinien móc samodzielnie przejść cały proces, także bez myszy i przy użyciu technologii asystujących. Zakres testów powinien objąć co najmniej:

• wyszukiwarkę, menu, filtry i sortowanie,
• listę produktów i kartę produktu,
• wybór wariantu, ilości oraz dodanie do koszyka,
• koszyk, kod rabatowy i wybór dostawy,
• formularz danych, zgody i komunikaty o błędach,
• płatność, uwierzytelnienie oraz powrót do sklepu,
• potwierdzenie zamówienia i wiadomości transakcyjne,
• konto klienta, logowanie i odzyskiwanie dostępu,
• regulamin, informacje o zwrotach i dokumenty do pobrania.

Element zewnętrzny, taki jak bramka płatnicza, czat, system opinii lub mapa punktów odbioru, nie znika z doświadczenia klienta tylko dlatego, że dostarcza go inna firma. Już przy wyborze integracji trzeba sprawdzić jej obsługę klawiaturą, czytnikiem ekranu i powiększeniem oraz ustalić, kto odpowiada za zgłoszenia i poprawki.

Najczęstsze bariery w sklepie internetowym

Problemy rzadko ograniczają się do braku tekstu alternatywnego przy zdjęciu. W ścieżce zakupowej szczególnie ważne są:

• widoczny fokus i logiczna kolejność poruszania się klawiszem Tab,
• możliwość otwarcia menu, filtrów, modali i wyboru wariantu bez myszy,
• etykiety pól powiązane z formularzem oraz błędy opisane tekstem,
• informacja o dodaniu produktu do koszyka przekazywana także czytnikowi ekranu,
• kontrast tekstu i elementów interfejsu,
• czytelny układ po powiększeniu i na wąskim ekranie,
• znaczenie nieprzekazywane wyłącznie kolorem, ikoną lub położeniem,
• możliwość zatrzymania ruchu i animacji, które przeszkadzają w obsłudze,
• dostępne logowanie bez testu zależnego wyłącznie od pamięci lub rozpoznawania obrazu.

Te same poprawki często pomagają osobom korzystającym z telefonu w słońcu, z wolnego połączenia, z uszkodzonym ekranem albo chwilowo tylko jedną ręką. Dostępność nie zastępuje optymalizacji konwersji, ale usuwa bariery, które mogą zatrzymać gotowego kupującego. Diagnostykę innych problemów sprzedażowych opisuje poradnik dlaczego sklep internetowy nie sprzedaje.

Wtyczka dostępności nie załatwia zgodności

Panel do zmiany kontrastu lub wielkości tekstu może być dodatkiem, ale nie naprawi niepoprawnej struktury HTML, pułapki klawiaturowej, źle nazwanych przycisków ani błędów w płatności. Nie sprawi też, że nieczytelny regulamin PDF stanie się dostępny.

Wymagania trzeba realizować w projekcie, kodzie, treści i procesie utrzymania. Nakładka uruchamiana nad gotową stroną nie zastępuje semantycznych komponentów, testów ani poprawek u źródła.

Jak sprawdzić dostępność sklepu

Automatyczny skaner jest dobrym początkiem, ale nie może być jedynym dowodem odbioru. W3C w przewodniku o ocenie dostępności stron wyraźnie wskazuje, że samo narzędzie nie potrafi ustalić zgodności i potrzebna jest ocena człowieka.

Praktyczny odbiór powinien łączyć:

1. automatyczne testy reprezentatywnych widoków,
2. ręczne przejście sklepu wyłącznie klawiaturą,
3. sprawdzenie kluczowych procesów z czytnikiem ekranu,
4. test powiększenia, reflow i różnych rozmiarów ekranu,
5. kontrolę etykiet, błędów, statusów i komunikatów dynamicznych,
6. raport z lokalizacją błędu, kryterium, wagą i sposobem odtworzenia,
7. ponowny test po wdrożeniu poprawek.

Nie testuj wyłącznie idealnego zamówienia. Sprawdź brak wymaganej zgody, błędny kod pocztowy, niedostępny wariant, odrzuconą płatność, pusty wynik wyszukiwania i ponowienie transakcji. Zasady projektowania formularzy rozwija artykuł o formularzu kontaktowym i lepszych zapytaniach.

Co wpisać do wyceny nowego sklepu

Przed porównaniem ofert poproś o jednoznaczną odpowiedź na poniższe pytania:

1. Jaki standard, wersja i poziom zgodności są celem?
2. Które szablony oraz procesy zostaną zbadane?
3. Czy testy obejmują klawiaturę i czytnik ekranu?
4. Kto sprawdza płatności, dostawę i pozostałe integracje?
5. Czy otrzymasz raport przed odbiorem oraz retest po poprawkach?
6. Kto odpowiada za dostępność treści dodawanych później w CMS?
7. Jak będą obsługiwane nowe błędy po aktualizacji sklepu?
8. Czy zakres obejmuje informację o dostępności wymaganą dla usługi?

Gov.pl opisuje również obowiązki informacyjne w PAD. Usługodawca objęty ustawą powinien podać konsumentom informacje o usłudze, korzystaniu z niej i sposobie spełniania wymagań dostępności, w regulaminie lub równoważnym dokumencie. To osobne zadanie, którego nie należy zostawiać na ostatni dzień przed publikacją.

Dostępność nie kończy się w dniu uruchomienia

Nowa promocja, aplikacja do opinii, zmieniony checkout albo nieopisane zdjęcie produktu mogą ponownie stworzyć barierę. Dlatego sklep potrzebuje prostych zasad redakcyjnych, kontroli nowych integracji i okresowych testów głównych procesów.

Jeżeli platforma pozwala naprawić komponenty i proces zakupu, wystarczy audyt oraz celowane poprawki. Gdy motyw, checkout lub integracje blokują dostępne rozwiązania, lepsza może być przebudowa. Pomagają to rozdzielić poradniki o SEO technicznym nowej strony i decyzji między poprawą a redesignem.

AMCompany projektuje i rozwija sklepy internetowe z uwzględnieniem dostępności, ścieżki zakupu, wydajności i SEO technicznego. Zobacz usługi oraz portfolio. Jeśli chcesz ustalić zakres nowego wdrożenia lub audytu, opisz sklep i kluczowe integracje.