- Strategia oparta o dane i cele biznesowe.
- Rekomendacje UX, integracji i automatyzacji.
- Plan wdrożeń i wsparcie zespołu.
Poprzedni artykuł wyjaśniał, czego wymaga Polski Akt o Dostępności od sklepów internetowych i jaki jest zakres obowiązku. Tutaj przechodzimy do konkretnego planu wdrożenia: co zrobić w pierwszych 30 dniach, co w ciągu 30–60 dni i co do końca okresu wdrożenia. To jest checklist, z którego możesz korzystać operacyjnie — bez czytania kilkudziesięciu stron dokumentacji. Pełny kontekst wymagań PAD znajdziesz w artykule o PAD dla e-commerce.
Dni 1–30: audyt, diagnoza i szybkie naprawy
Tydzień 1 — audyt i lista błędów. Uruchom automatyczne narzędzia: Axe DevTools (rozszerzenie Chrome) lub WAVE na kluczowych stronach sklepu: strona główna, strona kategorii, strona produktu, koszyk (/cart), checkout (/checkout), formularz kontaktowy, strona logowania. Zapisz wyniki — liczba błędów i ich kategorie (kontrast, brakujący alt, etykiety formularzy). Przetestuj ręcznie nawigację klawiaturą na checkoucie: czy możesz przejść przez cały proces zakupu wyłącznie Tab/Enter/Spacja, bez myszy? Jeśli nie — to P1 do naprawy przed terminem PAD.
Przeprowadzimy audyt, naprawimy krytyczne błędy i przygotujemy deklarację dostępności — w realnym harmonogramie i budżecie.
Tydzień 2–3 — naprawy krytyczne. Na podstawie audytu napraw błędy poziomu A i AA na krytycznych ścieżkach: checkout, formularze kontaktowe, konto klienta. Konkretne zadania: dodaj/uzupełnij tekst alt na wszystkich zdjęciach produktowych (priorytet: zdjęcia na stronach produktów i kategorii), dodaj/napraw etykiety label powiązane z polami formularzy, napraw zarządzanie focusem w modalnych oknach i popupach (login, newsletter, quick view), sprawdź i napraw kontrast tekstu na przyciskach CTA (minimum 4,5:1). Każde z tych zadań to praca deweloperska 1–4 godziny — szacunkowy czas napraw: 3–5 dni roboczych dla typowego sklepu WooCommerce.
Tydzień 4 — deklaracja dostępności i kanał zgłoszeń. Przygotuj i opublikuj deklarację dostępności: wypisz, które wymagania WCAG 2.1 AA spełniasz, które częściowo (z wykazem niezgodnych elementów) i które są wykluczone (z uzasadnieniem). Dodaj adres email lub formularz do zgłaszania problemów z dostępnością — i upewnij się, że ktoś to skrzynkę monitoruje i odpowiada w ciągu 30 dni. Umieść link do deklaracji w stopce strony.
Dni 30–60: kolejna warstwa napraw i testowanie z użytkownikami
W drugim etapie adresuj błędy drugiej kolejności: strukturę nagłówków (hierarchia H1–H6 bez pomijania poziomów), dostępność treści multimedialnych (wideo z napisami lub transkrypcją, obrazy złożone z opisem tekstowym), dostępność dokumentów PDF (polityka prywatności, regulamin — muszą być dostępne lub dostępna musi być wersja HTML), kontrast kolorów w treściach edytorskich (artykuły blogowe, opisy produktów stworzonych przez redaktorów). Ten etap wymaga zazwyczaj przeglądu CMS i szablonów — żeby „fabrycznie” generowana treść spełniała wymagania, a redaktorzy wiedzieli, jak tworzyć dostępne treści.
W tym etapie warto przeprowadzić test z rzeczywistymi użytkownikami — nawet jedną sesją z osobą słabowidzącą lub korzystającą z czytnika ekranu. Narzędzia automatyczne i testy ręczne w przeglądarce mają ograniczenia: nie zawsze odwzorowują realne doświadczenie użytkownika z niepełnosprawnością. Organizacje takie jak Fundacja Widzialni w Polsce świadczą usługi audytu z udziałem użytkowników z niepełnosprawnościami — warto skorzystać, szczególnie jeśli sklep ma duży ruch.
Dni 60–90: wbudowanie dostępności w procesy
Naprawa błędów to za mało — dostępność musi być wbudowana w proces tworzenia i aktualizacji serwisu. Konkretne działania: szkolenie deweloperów z podstaw WCAG (2–4 godziny, można online — WebAIM oferuje bezpłatne materiały), dodanie automatycznych testów dostępności do CI/CD (axe-core w testach end-to-end, Playwright lub Cypress z integracją axe), szkolenie redaktorów z tworzenia dostępnych treści (alt texty, czytelna struktura, linkowanie opisowe), przegląd procesów wdrożeń nowych komponentów — czy każdy nowy element UI przechodzi test dostępności przed go-live.
Dostępność wbudowana w procesy jest najtańszym sposobem jej utrzymania. Koszt naprawy błędu dostępności wykrytego w fazie projektowania to x. Koszt naprawy po wdrożeniu to 10x. Koszt naprawy po zgłoszeniu przez użytkownika lub regulatora to 100x. To nie jest metafora — to realna różnica kosztów, którą potwierdzają analizy Accessibility Management Platform i KPMG w raporcie „The Business Case for Accessibility 2023”.
Szybki checklist do kontroli
Do szybkiej weryfikacji stanu wdrożenia PAD użyj tej listy: [ ] Audyt automatyczny przeprowadzony na kluczowych stronach sklepu. [ ] Nawigacja klawiaturą przez checkout działa bez myszy. [ ] Tekst alt uzupełniony na zdjęciach produktów. [ ] Etykiety formularzy poprawnie powiązane z polami. [ ] Kontrast kolorów na głównych CTA i treściach spełnia 4,5:1. [ ] Deklaracja dostępności opublikowana w stopce. [ ] Kanał zgłoszeń problemów dostępności aktywny i monitorowany. [ ] Przynajmniej jedna osoba w firmie odpowiedzialna za dostępność. [ ] Szczegółowe omówienie priorytetów naprawczych znajdziesz w artykule o priorytetach WCAG 2.2.
