Sklep może wyglądać świetnie, mieć porządne zdjęcia i przyciski aż proszące się o kliknięcie, a mimo to skutecznie zablokować zakupy części osób. Wystarczy menu, którego nie da się obsłużyć klawiaturą, niewidoczny fokus albo formularz, który przy błędzie pokazuje tylko czerwone obramowanie. Dla właściciela wszystko działa. Dla klienta? Ściana.
Polski Akt o Dostępności obowiązuje od 28 czerwca 2025 r. W tym tekście bez prawniczego dymu przejdziemy przez dostępność sklepu internetowego: od menu i wyszukiwarki, przez kartę produktu, aż po koszyk, płatność i potwierdzenie zamówienia. To praktyczna checklista, nie indywidualna porada prawna ani pełny audyt kodu.
PAD i EAA bez prawniczego bełkotu — o co w ogóle chodzi?
Polski Akt o Dostępności, w skrócie PAD, to ustawa z 26 kwietnia 2024 r. Wdraża do polskiego prawa Europejski Akt o Dostępności, czyli dyrektywę 2019/882. Przepisy weszły w życie 28 czerwca 2025 r. I tak, to już nie jest temat „kiedyś tam poprawimy”.
W przypadku sklepu internetowego ważne jest nie tylko to, czy strona jest czytelna. Liczy się możliwość skorzystania z całej usługi handlu elektronicznego. Czy konsument może znaleźć produkt, wybrać wariant, wpisać dane, wybrać dostawę i płatność, sprawdzić zamówienie oraz zawrzeć umowę na odległość? Właśnie tę drogę trzeba brać pod lupę.
Dostępność to nie tylko wygląd
Dostępność nie kończy się na kontraście, wielkości tekstu czy ładnym układzie. Można mieć estetyczny sklep, który przy pierwszym formularzu rozkłada ręce. Dlatego test zaczynamy w menu i wyszukiwarce, a kończymy dopiero na podsumowaniu zamówienia. Po drodze sprawdzamy kartę produktu, koszyk, formularze, dostawę, płatność i komunikaty.
Czy Twój sklep podpada pod przepisy?
Co do zasady PAD obejmuje usługi handlu elektronicznego świadczone konsumentom na odległość, przez strony internetowe i urządzenia mobilne, drogą elektroniczną i na indywidualne żądanie, w celu zawarcia umowy. Brzmi formalnie, ale praktyczny sens jest prosty: chodzi o sprzedaż internetową produktów i usług, a nie wyłącznie o stronę z adresem firmy i godzinami otwarcia.
Oficjalne materiały wskazują szeroki zakres e-handlu. Mowa między innymi o sprzedaży odzieży, kosmetyków, leków, ubezpieczeń i usług opieki zdrowotnej. Nie chodzi więc tylko o wielkie platformy i sklepy z tysiącami produktów. Jeśli przez stronę lub urządzenie mobilne konsument przechodzi do zawarcia umowy, warto sprawdzić, jak wygląda dostępność tej usługi.
Jest ważny wyjątek: PAD nie stosuje się do usług oferowanych lub świadczonych przez mikroprzedsiębiorcę. Nie warto jednak wyciągać z tego automatycznego wniosku, że każdy mały sklep ma temat z głowy. Zakres obowiązków zależy od konkretnego modelu działalności. Sam fakt, że firma jest mała, nie zastępuje indywidualnej oceny sytuacji.
Szybkie pytania przed testem
- Czy sklep służy konsumentom do zawarcia umowy na odległość?
- Czy sprzedaż odbywa się przez stronę internetową albo urządzenie mobilne?
- Czy działalność może korzystać z wyjątku dla mikroprzedsiębiorcy?
- Czy model organizacyjny firmy nie powoduje dodatkowych wątpliwości?
Jeśli odpowiedź na któreś pytanie nie jest jasna, potraktuj to jako temat do indywidualnej konsultacji. Ten artykuł porządkuje temat, ale nie kwalifikuje prawnie konkretnej firmy.
Checklista: menu i nawigacja
Najprostszy test nie wymaga czarów ani specjalnego laboratorium. Odłóż mysz i spróbuj przejść sklep samą klawiaturą. Używaj Tab, Entera i klawiszy sterujących. WCAG 2.2 wskazuje, że funkcje treści powinny być dostępne z użyciem klawiatury, a użytkownik nie powinien zostać uwięziony w komponencie bez możliwości wyjścia.
Przejdź od strony głównej do menu, wyszukiwarki, karty produktu i koszyka. Obserwuj, gdzie jesteś. Jeśli nie widać fokusu, poruszasz się trochę jak po ciemnym magazynie. Niby coś klikasz, ale nie wiadomo co.
Test bez myszy, bez czarów
- Otwórz menu i przejdź przez jego elementy klawiszem Tab.
- Sprawdź, czy fokus jest widoczny na każdym aktywnym elemencie.
- Uruchom wyszukiwarkę i zobacz, czy możesz wpisać frazę oraz przejść do wyniku.
- Otwórz ewentualne okno modalne i sprawdź, czy da się z niego wyjść klawiaturą.
- Zapisz miejsce, w którym ścieżka się urywa albo fokus znika.
To praktyczna checklista, nie dowód pełnej zgodności. Kilka udanych przejść nie oznacza jeszcze, że cały sklep jest dostępny.
Checklista: karta produktu, koszyk i checkout
Gdy nawigacja działa, przejdź całą ścieżkę zakupową. Nie testuj podstron w oderwaniu od siebie. Klient nie kupuje przecież samej karty produktu. Kupuje dopiero wtedy, gdy przejdzie przez kolejne kroki i może bez przeszkód zakończyć proces.
Na karcie produktu sprawdź nazwy przycisków, wariantów i pól wyboru. Potem dodaj produkt do koszyka. Przejdź dalej, wybierz dostawę oraz płatność i otwórz podsumowanie. Wszystko spróbuj obsłużyć klawiaturą. Dane testowe powinny być bezpieczne — nie używaj prawdziwych danych osobowych ani danych kart płatniczych.
Ścieżka zakupowa od A do Z
- Menu i wyszukiwarka: znajdź konkretny produkt.
- Karta produktu: wybierz wariant i dodaj produkt do koszyka.
- Koszyk: sprawdź zawartość i przejdź do checkoutu.
- Formularz: uzupełnij pola oraz przejdź do kolejnego kroku.
- Dostawa i płatność: sprawdź, czy elementy da się wybrać bez myszy.
- Podsumowanie: zweryfikuj dane przed ostatecznym wysłaniem zamówienia.
Jeśli któryś etap wymaga myszy, nie pokazuje aktualnego fokusu albo gubi użytkownika, zapisz to jako osobny problem. Poprawienie jednego przycisku nie naprawi całego checkoutu.
Formularz zakupowy dostępny, czyli jak nie zgubić klienta przy ostatniej prostej
Formularz zakupowy to miejsce, w którym wiele ścieżek kończy się przed metą. Pole może wyglądać oczywiście dla osoby, która je projektowała, ale użytkownik powinien dostać jasną etykietę i instrukcję. Sam tekst pomocniczy znikający po rozpoczęciu pisania to za mało jako jedyny drogowskaz.
W praktyce sprawdź każde pole: imię, adres, dane kontaktowe i inne informacje wymagane przez proces. Zobacz, czy można do niego trafić klawiaturą, czy wiadomo, czego dotyczy, oraz czy po pominięciu pola komunikat wskazuje konkretny problem.
Błąd ma mówić, co poszło nie tak
WCAG 2.2 wskazuje, że automatycznie wykryty błąd formularza powinien zostać zidentyfikowany i opisany użytkownikowi w formie tekstowej. Czerwony kolor albo sama ikonka nie wystarczą. Komunikat powinien mówić, które pole wymaga poprawy i co trzeba zrobić.
- Sprawdź, czy każde pole ma zrozumiałą etykietę.
- Wywołaj błąd na danych testowych i przeczytaj komunikat.
- Upewnij się, że błąd jest opisany tekstem, a nie wyłącznie kolorem.
- Sprawdź, czy komunikat wskazuje konkretne pole.
- Zweryfikuj, czy da się poprawić dane i wrócić do procesu.
- Przed finalizacją sprawdź, czy użytkownik może spokojnie przejrzeć informacje i skorygować pomyłkę.
Ta lista wynika z praktycznego przełożenia kryteriów WCAG 2.2. Nie jest statystycznym rankingiem najczęstszych błędów. Konkretne bariery w konkretnym sklepie trzeba potwierdzić testem.
Informacja o dostępności — czego nie schować pod dywan
Usługodawca e-commerce powinien przekazać konsumentowi informacje o oferowanej i świadczonej usłudze, informacje niezbędne do korzystania z niej oraz informację o tym, w jaki sposób usługa spełnia wymagania dostępności. Oficjalne materiały wskazują, że takie informacje można umieścić w regulaminie lub równoważnym dokumencie.
Warto więc sprawdzić nie tylko sam checkout, ale też to, czy konsument może znaleźć opis usługi i sposób korzystania z niej. Taki dokument nie zastąpi jednak poprawienia niedostępnego menu, formularza czy płatności. Kartka z napisem „u nas jest dostępnie” nie naprawi przycisku, którego nie da się znaleźć klawiaturą.
Nie formułuj zapewnienia o zgodności, jeśli nie wykonano odpowiedniej weryfikacji. Lepiej opisać faktycznie sprawdzone elementy i jasno wskazać, co jeszcze wymaga oceny.
Co możesz sprawdzić sam, a kiedy lepiej zawołać Szwagra?
Na start możesz samodzielnie przejść sklep bez myszy i spisać miejsca, w których pojawiają się bariery. To dobry pierwszy krok, bo szybko pokazuje problemy z menu, fokusem, formularzami i checkoutem. Zapisuj adres lub nazwę miejsca, opis problemu oraz jego wpływ na przejście zakupów.
Automatyczny skaner może pomóc znaleźć część problemów, ale nie jest dowodem pełnej dostępności. Wynik narzędzia warto uzupełnić ręcznym przejściem ścieżki zakupowej. Research nie obejmuje konkretnego kodu sklepu, motywu, wtyczek, bramki płatniczej ani wersji WooCommerce, więc bez takiej analizy nie da się uczciwie obiecać pełnej zgodności prawnej.
Mini-plan działania na start
- Przejdź sklep od menu do potwierdzenia zamówienia, używając klawiatury.
- Spisz bariery w menu, karcie produktu, koszyku, formularzach i płatności.
- Sprawdź, czy błędy są opisane tekstem i przypisane do właściwych pól.
- Zweryfikuj możliwość poprawienia danych przed finalizacją transakcji.
- Ustal priorytety poprawek, zaczynając od miejsc blokujących dalszy zakup.
- Jeśli temat jest technicznie albo prawnie niejasny, zaplanuj dokładniejszy audyt lub konsultację specjalistyczną.
Dokumentuj wykonane testy, wykryte problemy i wprowadzone poprawki. To porządkuje pracę, ale samo w sobie nie jest gwarancją zgodności. Jeśli chcesz uporządkować problem ze sklepem, formularzem albo ścieżką zakupową, Napisz do Szwagra i opowiedz, czego potrzebujesz — strony, grafiki, filmu albo tekstów.
Dostępność sklepu internetowego ocenia się przez całą drogę do zawarcia umowy: od nawigacji, przez wybór produktu i formularz, aż po poprawienie danych oraz finalizację transakcji. PAD obejmuje co do zasady usługi handlu elektronicznego, ale przewiduje wyjątek dla usług oferowanych lub świadczonych przez mikroprzedsiębiorcę. Dlatego sytuację firmy trzeba ocenić indywidualnie. WCAG 2.2 jest praktycznym punktem odniesienia do testów, nie automatycznym rozstrzygnięciem każdej sytuacji prawnej. Zacznij od klawiatury, spisz bariery i nie udawaj, że jeden skaner załatwia temat.
