Dostępny sklep internetowy to nie tylko czytelna kolorystyka i odpowiednio zaprojektowane przyciski. Dostępność cyfrowa e-commerce obejmuje całą usługę: architekturę informacji, wyszukiwanie produktów, nawigację, treści, formularze, koszyk, wybór dostawy, płatność oraz informacje przekazywane konsumentowi. Każdy z tych elementów może ułatwiać zawarcie umowy albo tworzyć barierę uniemożliwiającą wykonanie kolejnego kroku.
Od 28 czerwca 2025 r. obowiązuje w Polsce Polski Akt o Dostępności, obejmujący między innymi usługi handlu elektronicznego. Zakres obowiązków zależy jednak od statusu podmiotu, rodzaju usługi, sposobu jej świadczenia i ustawowych wyłączeń. WCAG 2.2 dostarcza natomiast technicznych, testowalnych kryteriów pomocnych w projektowaniu oraz ocenie interfejsu. W artykule omawiamy zakres regulacji, kluczowe decyzje projektowe i sposób włączenia dostępności do procesu, a nie do listy poprawek wykonywanych po wdrożeniu.
Dostępny sklep internetowy: zakres problemu i znaczenie biznesowe
Dostępność jako cecha całej ścieżki zakupowej
Dostępność należy traktować jako cechę całej ścieżki zakupowej, a nie jako dodatkową warstwę wizualną. Użytkownik może napotkać barierę już podczas odczytywania menu, wyszukiwania produktu lub korzystania z filtrów. Kolejne problemy mogą pojawić się na karcie produktu, przy wyborze wariantu, w koszyku albo podczas podawania danych dostawy i płatności. Z perspektywy organizacji oznacza to potrzebę objęcia projektem nie tylko ekranów, lecz także treści, komunikatów, stanów komponentów i zachowania systemu.
Takie podejście uwzględnia osoby z niepełnosprawnościami, seniorów oraz osoby doświadczające czasowych lub sytuacyjnych ograniczeń. Wspiera również spójność i skalowalność interfejsu, ponieważ powtarzalne elementy są projektowane według jasno określonych zasad. Nie oznacza to jednak automatycznej gwarancji wzrostu sprzedaży, konwersji ani ograniczenia liczby skarg. Dostępność jest kryterium jakości usługi i elementem zarządzania ryzykiem, nie obietnicą konkretnego wyniku biznesowego.
Kogo obejmuje Polski Akt o Dostępności
Zakres usługi e-commerce i obowiązki informacyjne
Polski Akt o Dostępności, czyli ustawa z 26 kwietnia 2024 r. o zapewnianiu spełniania wymagań dostępności niektórych produktów i usług przez podmioty gospodarcze, obowiązuje w Polsce od 28 czerwca 2025 r. Obejmuje między innymi usługi handlu elektronicznego oferowane lub świadczone na odległość za pośrednictwem stron internetowych i urządzeń mobilnych, drogą elektroniczną, na indywidualne żądanie konsumenta i w celu zawarcia umowy.
Regulacja dotyczy między innymi usługodawców oferujących usługi wskazane w ustawie, ale nie każdy sklep należy automatycznie kwalifikować do identycznego zakresu obowiązków. Znaczenie mają status podmiotu, model usługi oraz ustawowe wyłączenia. Ustawa przewiduje między innymi wyjątek dotyczący usług oferowanych lub świadczonych przez mikroprzedsiębiorcę. Nie należy jednak przedstawiać tego wyjątku jako uniwersalnego zwolnienia z projektowania użytecznych i dostępnych interfejsów.
Usługodawca e-commerce powinien przekazywać konsumentom informacje o oferowanej i świadczonej usłudze, informacje niezbędne do korzystania z niej oraz informacje o sposobie spełniania wymagań dostępności. Dostępność dotyczy więc zarówno działania interfejsu, jak i komunikacji z użytkownikiem. Przed rozpoczęciem projektu warto ustalić, czy konkretny podmiot i jego sposób sprzedaży mieszczą się w zakresie PAD. W razie wątpliwości potrzebna jest indywidualna analiza prawna; sam fakt sprzedaży internetowej nie przesądza o identycznych obowiązkach każdej firmy.
WCAG 2.2 jako standard projektowania interfejsu
Kontrast, fokus i klawiatura
WCAG 2.2 jest technicznym standardem zawierającym testowalne kryteria projektowania i oceny dostępności treści internetowych. Nie jest jednak pojęciem całkowicie tożsamym z Polskim Aktem o Dostępności. Zastosowanie określonych kryteriów WCAG, nawet na poziomie AA, nie przesądza samo w sobie o pełnej zgodności prawnej konkretnej usługi z PAD. Ocena prawna wymaga analizy konkretnego przedsiębiorstwa, usługi i przepisów.
W praktyce projektowej istotne znaczenie ma kontrast. WCAG 2.2 na poziomie AA określa dla zwykłego tekstu minimalny kontrast 4,5:1, a dla dużego tekstu 3:1, z określonymi wyjątkami. Weryfikacja powinna obejmować nie tylko podstawowy tekst, lecz także elementy interfejsu używane w procesie zakupowym. Kolor nie powinien być jedynym sposobem przekazania informacji o stanie, wyborze lub problemie.
WCAG 2.2 wymaga także dostępności całej funkcjonalności z poziomu interfejsu klawiatury, z wyjątkami wynikającymi ze specyfiki funkcji. Dotyczy to między innymi menu, wyszukiwarki, filtrów, wyboru wariantów, koszyka i formularzy. Użytkownik powinien móc przejść przez interakcje w logicznej kolejności, a fokus klawiatury musi być widoczny. Projektowanie stanów focus, hover, active, error i disabled należy rozpocząć już na poziomie komponentów, a nie dopiero podczas implementacji.
Formularze i komunikaty błędów
Formularze są jednym z najważniejszych punktów ścieżki zakupowej. Logowanie, dane dostawy, dane do faktury, kod rabatowy oraz płatność powinny mieć jednoznaczne etykiety, zrozumiałą kolejność pól i przewidywalne zachowanie. Jeżeli system automatycznie wykryje błąd danych wejściowych, WCAG 2.2 wymaga wskazania tego błędu oraz przekazania użytkownikowi jego opisu w formie tekstowej.
Komunikat nie powinien ograniczać się do zmiany koloru obramowania pola. Użytkownik musi otrzymać informację, które dane wymagają korekty i co należy poprawić. Zasady te trzeba uwzględnić w makietach oraz w specyfikacji komponentów, aby zespół projektowy, programistyczny i redakcyjny realizował ten sam model obsługi błędów.
Elementy sklepu, które wymagają decyzji projektowych
Od architektury informacji do karty produktu
Punktem wyjścia jest architektura informacji. Kategorie, menu, wyszukiwarka, listy produktów, filtry i sortowanie powinny tworzyć zrozumiałą ścieżkę orientacji. Użytkownik musi wiedzieć, gdzie się znajduje, jakie opcje wybrał i jaki rezultat przyniosło zastosowanie filtra. Logiczna struktura informacji ogranicza ryzyko, że poprawnie zaprojektowany pojedynczy komponent zostanie użyty w chaotycznym procesie.
Karta produktu powinna obejmować czytelne treści, obrazy, warianty i informacje potrzebne do podjęcia decyzji zakupowej. W projekcie należy uwzględnić sposób prezentowania nazw, opisów, statusów oraz dostępnych opcji. Obrazy i treści nie mogą być traktowane jako elementy oderwane od całej usługi. Ich forma powinna wspierać zrozumienie informacji, a nie zastępować ją niejasnym komunikatem wizualnym.
Koszyk, checkout i płatność
Koszyk i checkout wymagają przeanalizowania wszystkich punktów decyzyjnych. Zakres powinien obejmować logowanie lub zakup bez rejestracji, edycję koszyka, dane dostawy i faktury, wybór dostawy, wybór płatności oraz potwierdzenie kolejnych etapów. Każdy stan, w tym brak danych, zmiana ilości, błąd lub poprawne wykonanie czynności, powinien być komunikowany w sposób zrozumiały.
Projektowanie dostępnego interfejsu obejmuje także responsywny układ i interakcje obsługiwane z klawiatury. Dotyczy to zarówno własnych komponentów, jak i systemów płatności, wtyczek oraz innych rozwiązań firm trzecich. Ich dostępność wymaga osobnej weryfikacji. Powyższa lista jest praktyczną syntezą wymagań dotyczących usługi i kryteriów WCAG, a nie zamkniętym katalogiem ustawowych obowiązków.
Dostępność w procesie: od briefu do wdrożenia
Kryteria akceptacji i system komponentów
Dostępność należy określić już w briefie. Dokument powinien wskazywać zakres usługi, kluczowe ścieżki zakupowe oraz kryteria akceptacji związane z dostępnością. Dzięki temu wymagania nie pozostają ogólną deklaracją, lecz stają się częścią decyzji projektowych i odbioru kolejnych etapów.
W makietach i prototypach trzeba uwzględnić architekturę informacji, kolejność interakcji, kontrast oraz stany focus, error i disabled. Komponenty warto projektować jako powtarzalne elementy systemu. Takie podejście ułatwia utrzymanie spójności i skalowanie zmian w całym sklepie. Obejmuje również odpowiedzialność za treści, grafiki i prawa do materiałów, a także za elementy dostarczane przez zewnętrznych dostawców.
Testy przed i po publikacji
Przed publikacją należy zaplanować testy techniczne i manualne na pełnych, rzeczywistych ścieżkach zakupowych. Weryfikacja powinna obejmować obsługę klawiaturą, widoczność fokusu, formularze, stany błędów, responsywność oraz technologie asystujące. Automatyczny skaner może wspierać kontrolę, lecz nie zastępuje testów manualnych ani oceny zachowania całej usługi.
Po wdrożeniu dostępność wymaga dalszego zarządzania. Organizacja powinna mieć procedury zgłaszania barier, kontroli treści, utrzymania komponentów i ponownej weryfikacji zmian. Każda modyfikacja checkoutu, integracji, treści lub systemu komponentów może wpływać na wcześniej sprawdzone ścieżki. Dostępność nie jest więc jednorazowym etapem, lecz stałym kryterium jakości rozwijanego sklepu.
Weryfikacja, dokumentacja i ograniczenia odpowiedzialności
Jak rzetelnie opisywać zakres zgodności
Komunikowanie dostępności powinno być precyzyjne. Wyniki weryfikacji należy odnosić do określonego zakresu widoków, komponentów i ścieżek, zamiast używać nieprecyzyjnej deklaracji pełnej dostępności. Dokumentacja powinna rozdzielać trzy obszary: wymagania prawne wynikające z PAD, zastosowane kryteria WCAG 2.2 oraz ograniczenia rozwiązania.
Warto wskazać, które elementy zostały sprawdzone, jakie testy przeprowadzono i jakie komponenty lub integracje pozostają zależne od zewnętrznych dostawców. Sam automatyczny skan nie jest pełnym audytem dostępności. Nie potwierdza również samodzielnie zgodności prawnej z PAD. Rzetelny opis powinien unikać ogólnych deklaracji marketingowych i przedstawiać dostępność w odniesieniu do konkretnego zakresu prac oraz wersji zastosowanego standardu.
Dostępny sklep internetowy wymaga połączenia analizy zakresu Polskiego Aktu o Dostępności, wykorzystania WCAG 2.2 jako technicznego punktu odniesienia oraz zaprojektowania całej ścieżki zakupowej. Kontrast, fokus, klawiatura, formularze, komunikaty i treści powinny zostać uwzględnione przed wdrożeniem, a następnie ponownie zweryfikowane po zmianach. WCAG nie zastępuje indywidualnej oceny prawnej, a automatyczny skan nie jest pełnym audytem dostępności. Ten artykuł nie zastępuje analizy prawnej konkretnego przedsiębiorstwa ani audytu konkretnego sklepu. Umów konsultację z BrandingHouse, aby stworzyć spójny wizerunek marki i materiały dopasowane do celów Twojej firmy.
