Audyt deklaracja dostępności sklep internetowy – od czego zacząć?
W tym artykule pokażę Ci, jak przeprowadzić skuteczna deklaracja dostępności sklep internetowy – bez stresu, bez kosztownego sprzętu i bez studiowania kilkuset stron dokumentacji WCAG. Dowiesz się, które narzędzia są naprawdę przydatne, jak priorytetyzować znalezione problemy i jak przekształcić wyniki audytu w konkretny plan działania.
Czym jest audyt dostępności i dlaczego go potrzebujesz?
Audyt dostępności to systematyczne sprawdzenie, czy Twój sklep internetowy mogą obsługiwać WSZYSTKIE osoby – w tym te z niepełnosprawnościami wzrokowymi, słuchowymi, motorycznymi czy poznawczymi. To nie abstrakcyjna filozofia, ale konkretne testowanie według standardu WCAG 2.1 poziom AA.
Trzy powody, dla których audyt jest niezbędny w 2026
Powód 1: Podstawa prawnej deklaracji dostępności
Nie możesz napisać rzetelnej deklaracji dostępności sklep internetowy bez audytu. Jak masz opisać stan zgodności, skoro nie wiesz, co faktycznie działa, a co nie? Deklaracja oparta na zgadywaniu to prosta droga do kary od RPO.
Powód 2: Ochrona przed karami (do 50 000 zł)
Audyt ujawnia problemy ZANIM znajdzie je użytkownik, który może złożyć skargę do Rzecznika Praw Obywatelskich. Lepiej odkryć, że Twój formularz zamówienia jest niedostępny podczas własnego testu niż z pisma urzędowego.
Powód 3: Zysk biznesowy
Według badań WebAIM z 2025 roku:
- 71% użytkowników z niepełnosprawnościami opuszcza niedostępną stronę natychmiast
- Dostępne sklepy mają o 23% wyższą konwersję (dla wszystkich użytkowników!)
- Poprawione kontrasty i czytelność zwiększają sprzedaż o średnio 12%
Audyt to nie koszt – to inwestycja.
Kiedy przeprowadzić audyt?
ZAWSZE przed:
- Publikacją deklaracji dostępności (inaczej to fikcja)
- Dużym redesignem sklepu (sprawdź nowy projekt wcześniej)
- Dodaniem nowej funkcjonalności (płatności, czat, konfigurator)
REGULARNIE co:
- 6 miesięcy – szybki przegląd (narzędzia automatyczne)
- 12 miesięcy – pełny audyt (łącznie z testami manualnymi)
NATYCHMIAST gdy:
- Otrzymałeś skargę użytkownika na bariery
- Dodałeś dużo nowych produktów (sprawdź opisy, zdjęcia)
- Zmieniłeś platformę e-commerce
Przygotowanie do audytu – co musisz wiedzieć przed startem
Zanim uruchomisz jakiekolwiek narzędzie, potrzebujesz podstawowej wiedzy i przygotowania.
Zrozum podstawy WCAG 2.1
WCAG (Web Content Accessibility Guidelines) to międzynarodowy standard dostępności. Brzmi groźnie, ale wystarczy znać podstawy:
4 zasady POUR:
P – Perceivable (Postrzegalność)
Użytkownik musi móc ODEBRAĆ informacje (wzrokiem, słuchem, dotykiem)
- Przykład: Zdjęcia muszą mieć opisy tekstowe dla niewidomych
- Przykład: Filmy muszą mieć napisy dla niesłyszących
O – Operable (Funkcjonalność)
Użytkownik musi móc OBSŁUGIWAĆ interfejs (myszą, klawiaturą, głosem)
- Przykład: Wszystko musi działać bez myszy (tylko strzałki i Enter)
- Przykład: Użytkownik musi mieć wystarczająco dużo czasu na akcje
U – Understandable (Zrozumiałość)
Interfejs i treści muszą być JASNE i PRZEWIDYWALNE
- Przykład: Komunikaty błędów muszą wyjaśniać, co naprawić
- Przykład: Nawigacja działa konsekwentnie na każdej stronie
R – Robust (Solidność)
Strona działa z różnymi technologiami, także asystującymi
- Przykład: Kompatybilność z czytnikami ekranu (NVDA, JAWS)
- Przykład: Prawidłowy kod HTML
3 poziomy zgodności:
- Poziom A – minimum (bez tego strona jest praktycznie bezużyteczna)
- Poziom AA – standard wymagany prawnie w Polsce i UE
- Poziom AAA – ideał (nie jest wymagany, nice to have)
Wniosek dla e-commerce: Musisz spełnić poziom AA.
Przygotuj listę stron do audytu
Nie musisz testować każdej pojedynczej podstrony (jeśli masz 5000 produktów). Wystarczy reprezentatywna próbka:
Strony obowiązkowe do audytu:
- Strona główna
- Strona kategorii produktów (wybierz 2-3 różne kategorie)
- Karta produktu (wybierz 3-5 różnych produktów)
- Koszyk
- Proces zamówienia (wszystkie kroki)
- Rejestracja/logowanie
- Konto klienta
- Kontakt
- Regulamin i polityka prywatności
- Deklaracja dostępności (jeśli już masz)
Strony dodatkowe (jeśli masz):
- Blog/artykuły
- Konfigurator produktów
- Wyszukiwarka zaawansowana
- Porównywarka produktów
- Lista życzeń
Szacunkowy czas: Dla typowego sklepu audyt 10-15 stron zajmuje 6-12 godzin pracy.
Przygotuj środowisko testowe
Przeglądarka:
Chrome lub Firefox (najlepsze wsparcie dla narzędzi dostępności)
Rozszerzenia do zainstalowania (wszystkie DARMOWE):
- WAVE Evaluation Tool
- axe DevTools
- HeadingsMap (do sprawdzania struktury nagłówków)
- NoCoffee Vision Simulator (symuluje problemy wzrokowe)
Oprogramowanie:
- NVDA (czytnik ekranu, Windows, darmowy) LUB
- VoiceOver (wbudowany w macOS)
Narzędzia online:
- WebAIM Contrast Checker (kontrast.webaim.org)
- Google Lighthouse (wbudowany w Chrome)
Krok 1: Audyt automatyczny – szybki przegląd w 30 minut
Zacznij od narzędzi automatycznych. Wykryją 30-40% problemów, ale to najszybszy sposób na ogólny obraz sytuacji.
Narzędzie 1: WAVE (Web Accessibility Evaluation Tool)
Jak używać:
- Zainstaluj rozszerzenie WAVE w Chrome/Firefox
- Otwórz stronę do audytu (np. stronę główną)
- Kliknij ikonę WAVE w pasku przeglądarki
- Pojawi się panel z wynikami
Co pokazuje WAVE:
Errors (błędy) – CZERWONE – MUSZĄ być naprawione:
- Brak alt text na obrazach
- Puste linki lub przyciski
- Niski kontrast tekstu
- Brak etykiet w formularzach
- Zduplikowane ID elementów
Alerts (ostrzeżenia) – ŻÓŁTE – sprawdź manualnie:
- Podejrzane alt text (np. „image.jpg”)
- Redundantne linki obok siebie
- Możliwe problemy z nagłówkami
Features (cechy) – ZIELONE – dobre praktyki znalezione:
- Prawidłowe alt text
- Etykiety ARIA
- Poprawne nagłówki
Structural Elements (elementy strukturalne) – NIEBIESKIE – struktura strony:
- Nagłówki H1, H2, H3…
- Listy
- Linki
Przykład z praktyki:
Sklep z odzieżą – strona kategorii „Sukienki”:
- 18 błędów – 15 zdjęć produktów bez alt text, 3 przyciski bez dostępnej nazwy
- 6 ostrzeżeń – alt text typu „IMG_1234.jpg” (techniczny, nie opisowy)
- Akcja: Dodaj opisy alt text typu „Sukienka wieczorowa czarna, długa, widok z przodu”
Powtórz WAVE dla wszystkich stron z listy i zapisuj wyniki w tabeli:
| Strona | Errors | Alerts | Priorytet |
|---|---|---|---|
| Strona główna | 3 | 2 | Wysoki |
| Kategoria Sukienki | 18 | 6 | Krytyczny |
| Produkt XYZ | 2 | 1 | Średni |
| Koszyk | 0 | 0 | OK |
| Zamówienie krok 1 | 5 | 3 | Krytyczny |
Narzędzie 2: Google Lighthouse
Jak używać:
- Otwórz stronę w Chrome
- Naciśnij F12 (DevTools)
- Zakładka „Lighthouse”
- Zaznacz „Accessibility”
- Wybierz „Desktop” lub „Mobile”
- Kliknij „Generate report”
Co pokazuje Lighthouse:
Score (wynik) 0-100:
- 90-100 – dobry
- 50-89 – wymaga poprawy
- 0-49 – poważne problemy
Konkretne problemy:
- Kontrast kolorów
- Brakujące alt text
- Problemy z formularzami
- Brak prawidłowej struktury nagłówków
- Elementy interactive bez accessible name
Lighthouse vs WAVE:
- Lighthouse daje ogólny wynik (0-100) – łatwiejszy do komunikacji z szefem
- WAVE pokazuje dokładne lokalizacje błędów na stronie – łatwiejszy do naprawy
Używaj obu – uzupełniają się.
Narzędzie 3: axe DevTools
Jak używać:
- Zainstaluj rozszerzenie axe DevTools
- Otwórz DevTools (F12)
- Zakładka „axe DevTools”
- Kliknij „Scan ALL of my page”
Przewaga axe:
- Najbardziej szczegółowe wyjaśnienia (pokazuje KOD problemu)
- Sugestie naprawy krok po kroku
- Możliwość eksportu raportu do PDF/CSV
Przykład użycia:
Formularz kontaktowy – axe wykrył:
Issue: Form elements must have labels
Impact: Critical
Elements affected: 3
<input type="text" name="name" placeholder="Imię">
<input type="email" name="email" placeholder="E-mail">
<textarea name="message" placeholder="Wiadomość"></textarea>
How to fix:
Add <label> elements with for attribute matching input id
OR use aria-label attribute
To konkretna instrukcja naprawy!
Tworzenie pierwszego raportu
Po przejściu przez wszystkie strony automatycznymi narzędziami stwórz prostą tabelę:
Raport audytu automatycznego – [Nazwa sklepu] – [Data]
| Problem | Liczba wystąpień | Strony | Poziom WCAG | Priorytet |
|---|---|---|---|---|
| Brak alt text | 127 | Wszystkie produkty | 1.1.1 A | Krytyczny |
| Niski kontrast przycisku CTA | 1 | Wszystkie | 1.4.3 AA | Wysoki |
| Brak label w formularzach | 12 | Kontakt, Zamówienie | 3.3.2 A | Krytyczny |
| Nieprawidłowa struktura H | 8 | Strona główna, Blog | 1.3.1 A | Średni |
Czas: 30-60 minut dla całego sklepu.
Krok 2: Testy manualne – znajdź pozostałe 60% problemów
Narzędzia automatyczne to dopiero początek. Teraz musisz przetestować sklep „rękami” – sprawdzić, czy faktycznie DZIAŁA dla różnych użytkowników.
Test 1: Nawigacja tylko klawiaturą (bez myszy)
Cel: Sprawdzić, czy osoby z problemami motorycznymi (nie mogą używać myszy) są w stanie obsłużyć sklep.
Jak testować:
- Odłącz mysz lub po prostu jej nie dotykaj
- Nawiguj używając tylko:
- Tab – przejście do kolejnego elementu
- Shift+Tab – powrót do poprzedniego
- Enter – aktywacja linku/przycisku
- Spacja – zaznaczenie checkboxa, przewinięcie strony
- Strzałki – w menu rozwijanych, radio buttons
- Przejdź całą ścieżkę zakupową:
- Strona główna → Menu → Kategoria → Produkt → Dodaj do koszyka → Koszyk → Zamówienie → Potwierdzenie
Na co zwracać uwagę:
✓ DOBRZE:
- Widzisz wyraźnie, gdzie jesteś (focus indicator – ramka/podświetlenie wokół aktywnego elementu)
- Kolejność tabulacji jest logiczna (od góry do dołu, od lewej do prawej)
- Możesz dotrzeć do WSZYSTKICH interaktywnych elementów
- Menu rozwijane otwiera się po Enter (nie tylko po hover)
- Formularze dają się wypełnić
✗ ŹLE:
- Nie wiadomo, gdzie jest focus (niewidoczny lub brak)
- Musisz tabulować przez 50 elementów, żeby dostać się do treści głównej
- Niektóre przyciski są pominięte (nie można do nich dotrzeć)
- Menu działa tylko po najechaniu myszką
- Po naciśnięciu Enter na „Dodaj do koszyka” nic się nie dzieje
Przykładowe problemy z prawdziwych audytów:
Problem: Dropdown menu „Kategorie” nie otwiera się po naciśnięciu Enter, tylko po hover.
Wpływ: Użytkownik bez myszy nie może przeglądać kategorii produktów.
Priorytet: Krytyczny
Problem: Focus indicator (podświetlenie) niewidoczny – tło białe, ramka biała.
Wpływ: Użytkownik gubi się podczas nawigacji.
Priorytet: Wysoki
Czas tego testu: 30-60 minut (przejście całej ścieżki zakupowej)
Test 2: Kontrast kolorów
Cel: Sprawdzić, czy tekst jest czytelny dla osób słabowidzących, starszych, czy przeglądających w słoneczny dzień na telefonie.
Standard WCAG 2.1 AA:
- Normalny tekst (poniżej 18px): minimum 4.5:1
- Duży tekst (18px+ lub 14px+ bold): minimum 3:1
Jak testować:
- Użyj WebAIM Contrast Checker (webaim.org/resources/contrastchecker/)
- Sprawdź najważniejsze elementy:
- Ceny (zwykłe i promocyjne)
- Przyciski CTA („Dodaj do koszyka”, „Kup teraz”)
- Linki w tekście
- Komunikaty błędów (czerwony tekst na jakim tle?)
- Menu nawigacyjne
Jak sprawdzić kontrast:
Metoda 1: Ręczne pipetowanie
- Otwórz stronę i WebAIM Contrast Checker
- W DevTools (F12) użyj pipety, żeby pobrać kolor tekstu
- Pobierz kolor tła
- Wpisz do checkera (hex codes)
Metoda 2: Automatycznie w WAVE
- WAVE pokazuje elementy z niskim kontrastem (czerwone ikony)
- Kliknij, żeby zobaczyć szczegóły
Przykład:
Przycisk „Dodaj do koszyka”:
- Tło: #FF6B6B (jasny czerwony)
- Tekst: #FFFFFF (biały)
- Kontrast: 3.2:1 ❌ Za niski! (wymaga 4.5:1)
Naprawa:
- Zmień tło na ciemniejszy odcień: #D32F2F
- Nowy kontrast: 5.1:1 ✅ OK!
Częste problemy:
- Szary tekst na białym tle (modny design, zła dostępność)
- Żółty tekst na białym (prawie niewidoczny)
- Jasnoszare placeholdery w formularzach (nieczytalne)
Czas: 20-30 minut
Test 3: Powiększenie do 200%
Cel: Sprawdzić, czy osoby słabowidzące mogą powiększyć tekst bez utraty funkcjonalności.
Standard WCAG: Strona musi działać przy powiększeniu do 200% (bez przewijania poziomego).
Jak testować:
- Otwórz stronę w przeglądarce
- Naciśnij Ctrl/Cmd + kilka razy (lub Ctrl/Cmd + 0, potem +)
- Powiększ do 200% (sprawdź w ustawieniach przeglądarki)
Co sprawdzić:
- Tekst jest nadal czytelny (nie nachodzi na siebie)
- Nie trzeba przewijać strony w poziomie
- Menu nie rozjeżdża się
- Przyciski są nadal klikalne
- Formularze dają się wypełnić
Typowe problemy:
- Fixed width (stała szerokość) powoduje ucięcie tekstu
- Menu rozjeżdża się poza ekran
- Przyciski nakładają się na siebie
- Trzeba przewijać w prawo-lewo (bardzo męczące)
Czas: 15-20 minut
Test 4: Czytnik ekranu (podstawy)
Cel: Sprawdzić, czy osoby niewidome mogą użyć czytnika ekranu do robienia zakupów.
To brzmi strasznie technicznie, ale wystarczy podstawowy test.
Czytnik do użycia:
- Windows: NVDA (nvaccess.org – darmowy, prosty)
- Mac: VoiceOver (wbudowany, włącz: Cmd+F5)
Podstawowe polecenia NVDA:
- Ctrl – zatrzymanie/wznowienie czytania
- Strzałki w dół/górę – czytanie linia po linii
- H – przejście do następnego nagłówka
- K – przejście do następnego linku
- F – przejście do następnego pola formularza
- B – przejście do następnego przycisku
Co sprawdzić (uproszczona wersja):
- Obrazy produktów
- Włącz NVDA → przejdź do zdjęcia produktu
- Czy czytnik odczytuje sensowny opis (np. „Sukienka czarna długa”) czy tylko „image” lub nazwę pliku?
- Przyciski
- Przejdź do „Dodaj do koszyka”
- Czy czytnik mówi „Dodaj do koszyka, przycisk” czy tylko „przycisk”?
- Formularze
- Przejdź do pola „Imię” w formularzu
- Czy czytnik mówi „Imię, pole edycji” czy tylko „pole edycji”?
- Komunikaty
- Dodaj produkt do koszyka
- Czy czytnik odczytuje komunikat „Produkt dodany do koszyka”?
Nie musisz robić pełnego audytu czytnikiem (to wymaga wprawy). Wystarczy sprawdzić, czy:
- Zdjęcia mają opisy
- Przyciski mają nazwy
- Pola formularzy mają etykiety
- Ważne komunikaty są ogłaszane
Czas: 30-45 minut (jeśli pierwszy raz, może dłużej – NVDA wymaga przyzwyczajenia)
Jeśli czujesz, że to przekracza Twoje możliwości techniczne, pomiń ten test i zlecić go profesjonaliście. Testy automatyczne + nawigacja klawiaturą + kontrast to już 80% wartości audytu.
Test 5: Struktura nagłówków
Cel: Sprawdzić, czy strona ma logiczną strukturę dla użytkowników czytników ekranu.
Standard: Nagłówki H1-H6 powinny tworzyć hierarchię (jak spis treści).
Jak testować:
- Zainstaluj rozszerzenie HeadingsMap (Chrome/Firefox)
- Otwórz stronę
- Kliknij ikonę HeadingsMap
- Zobacz „drzewo” nagłówków
Prawidłowa struktura:
H1: Sklep Modowy Online (tylko JEDEN H1 na stronie!)
H2: Bestsellery
H2: Nowości
H3: Sukienki
H3: Spódnice
H2: Promocje
Zła struktura:
H1: Sklep Modowy Online
H1: Najnowsza kolekcja (drugi H1 – ŹLE!)
H4: Sukienki (pominięto H2 i H3 – ŹLE!)
H2: Kontakt
Zasady:
- Dokładnie jeden H1 na stronę (główny tytuł)
- Nie pomijaj poziomów (H1→H2→H3, nie H1→H4)
- Nagłówki powinny opisywać sekcję (nie „Kliknij tutaj”)
Czas: 10-15 minut
Krok 3: Priorytetyzacja problemów – co naprawić najpierw?
Masz listę 50, 100, może 200 problemów. Nie wszystkie są równie ważne. Musisz ustalić kolejność napraw.
Matryca priorytetów
Użyj dwóch kryteriów: Poziom WCAG i Wpływ na użytkownika.
Priorytet KRYTYCZNY (napraw W TYM TYGODNIU):
- Problemy poziomu A (podstawowa dostępność)
- Blokujące ścieżkę zakupową (nie można dodać do koszyka, nie można złożyć zamówienia)
- Dotyczące kluczowych funkcji (płatności, logowanie)
Przykłady:
- Brak alt text na WSZYSTKICH produktach
- Przycisk „Kup teraz” nie działa bez myszy
- Formularz zamówienia bez etykiet (czytnik ekranu nie wie, co wpisać gdzie)
Priorytet WYSOKI (napraw W TYM MIESIĄCU):
- Problemy poziomu AA (wymagane prawnie)
- Utrudniające, ale nie blokujące zakupy
- Powtarzające się na wielu stronach
Przykłady:
- Niski kontrast na przyciskach CTA
- Brak widocznego focus indicator
- Brak opisów w filmach produktowych (ale są opisy tekstowe jako alternatywa)
Priorytet ŚREDNI (napraw W CIĄGU 3 MIESIĘCY):
- Problemy mniejsze, ale warte poprawy
- Dotyczące drugorzędnych funkcji (blog, FAQ)
- Single cases (występują tylko raz)
Przykłady:
- Nieprawidłowa kolejność nagłówków na stronie „O nas”
- Alt text obecny, ale niezbyt opisowy („zdjęcie produktu” zamiast „czarna sukienka długa”)
Priorytet NISKI (nice to have):
- Problemy poziomu AAA (nie wymagane prawnie)
- Bardzo drobne kosmetyczne poprawki
- Zaawansowane funkcje dostępności
Przykłady:
- Brak transkrypcji tekstowej dla podcastów (jeśli masz)
- Możliwość zmiany skrótów klawiaturowych
Przykładowa priorytetyzacja (sklep odzieżowy)
| Nr | Problem | Wystąpień | Poziom | Wpływ | Priorytet | Deadline |
|---|---|---|---|---|---|---|
| 1 | Brak alt text na produktach | 127 | A | Krytyczny | KRYTYCZNY | 7 dni |
| 2 | Formularz bez labels | 12 | A | Krytyczny | KRYTYCZNY | 7 dni |
| 3 | Menu nie działa na klawiaturze | 1 | A | Krytyczny | KRYTYCZNY | 7 dni |
| 4 | Kontrast przycisku CTA | 1 | AA | Wysoki | WYSOKI | 30 dni |
| 5 | Brak focus indicator | Wszystkie | AA | Wysoki | WYSOKI | 30 dni |
| 6 | Filmy bez napisów | 3 | AA | Średni | ŚREDNI | 90 dni |
| 7 | Struktura H nieprawidłowa | 8 stron | A | Średni | ŚREDNI | 90 dni |
Szacowany czas napraw:
- Krytyczne (1-3): 2-3 dni pracy (lub 1 000-2 000 zł zlecenia)
- Wysokie (4-5): 1-2 dni pracy
- Średnie (6-7): 2-3 dni pracy
Łącznie: około 5-8 dni pracy lub 3 000-6 000 zł zlecenia zewnętrznego.
Krok 4: Dokumentacja wyników – stwórz użyteczny raport
Raport audytu to nie tylko lista błędów – to plan działania i podstawa deklaracji dostępności.
Struktura profesjonalnego raportu audytu
1. Strona tytułowa
RAPORT AUDYTU DOSTĘPNOŚCI
[Nazwa sklepu] – [URL]
Data audytu: [DD.MM.RRRR]
Audytor: [Imię Nazwisko / Firma]
Standard: WCAG 2.1 poziom AA
Narzędzia: WAVE, Lighthouse, axe DevTools, NVDA, testy manualne
2. Streszczenie wykonawcze (1 strona)
- Ogólny wynik (np. „Częściowa zgodność z WCAG 2.1 AA”)
- Liczba znalezionych problemów (krytycznych, wysokich, średnich)
- Główne obszary do poprawy
- Szacowany czas/koszt napraw
Przykład:
STRESZCZENIE
Sklep ModaStyle.pl jest CZĘŚCIOWO ZGODNY z WCAG 2.1 poziom AA.
Znaleziono:
- 3 problemy KRYTYCZNE (poziom A) – blokują zakupy dla osób niewidomych
- 5 problemów WYSOKICH (poziom AA) – utrudniają obsługę
- 12 problemów ŚREDNICH – do poprawy w dłuższym terminie
Główne problemy:
1. Brak opisów alternatywnych na 127 zdjęciach produktów
2. Formularze bez etykiet (12 pól)
3. Niski kontrast przycisków
Szacowany czas napraw: 5-8 dni pracy (lub 3 000-6 000 zł zlecenia).
Po naprawach sklep będzie w pełni zgodny z wymogami prawnymi.
3. Metodologia (1/2 strony)
- Jakie strony przetestowano
- Jakie narzędzia użyto
- Jacy użytkownicy zostali uwzględnieni (niewidomi, słabowidzący, z problemami motorycznymi)
4. Wyniki szczegółowe (tabela)
| ID | Problem | Strona | Kryterium WCAG | Poziom | Priorytet | Jak naprawić |
|---|---|---|---|---|---|---|
| 001 | Brak alt text | Wszystkie produkty | 1.1.1 | A | Krytyczny | Dodać opisy: „nazwa produktu – kolor – ujęcie” |
| 002 | Kontrast 3.2:1 | Przycisk CTA | 1.4.3 | AA | Wysoki | Zmienić #FF6B6B na #D32F2F |
5. Screenshoty/przykłady
- Pokaż konkretne błędy (zrzuty ekranu z WAVE)
- Przykłady „przed” i „po” (jeśli robiłeś już testy napraw)
6. Plan naprawczy (timeline)
TYDZIEŃ 1 (do DD.MM):
- Dodanie alt text do wszystkich produktów
- Naprawa formularzy (dodanie labels)
- Naprawa nawigacji klawiaturowej
MIESIĄC 1 (do DD.MM):
- Poprawa kontrastów
- Dodanie focus indicators
- Testy weryfikacyjne
MIESIĄC 2-3 (do DD.MM):
- Napisy do filmów lub alternatywne opisy tekstowe
- Poprawa struktury nagłówków
- Finalne testy i publikacja deklaracji
7. Zalecenia dodatkowe
- Szkolenie zespołu (jak dodawać dostępne treści w przyszłości)
- Regularne testy (co 6 miesięcy)
- Procedura obsługi zgłoszeń użytkowników
Gotowe szablony raportów
Nie musisz wymyślać koła od nowa. Użyj gotowych szablonów:
- axe DevTools – eksport raportu do PDF (automatyczny)
- Google Sheets – szablon do wypełnienia ręcznego
- Profesjonalne wzory – dostępne w ramach pakietów dokumentów prawnych dla e-commerce, np. na prokonsumencki.pl
Krok 5: Od raportu do działania – jak wdrożyć naprawy
Masz raport. Teraz czas na działanie.
Opcja 1: Naprawy własne (dla osób technicznych)
Jeśli masz dostęp do kodu i podstawową wiedzę o HTML/CSS:
Naprawa 1: Dodanie alt text
<!-- ŹLE -->
<img src="sukienka-czarna.jpg">
<!-- DOBRZE -->
<img src="sukienka-czarna.jpg" alt="Sukienka wieczorowa czarna, długa, widok z przodu">
W WordPress/WooCommerce:
- Produkty → kliknij produkt
- Sekcja „Obraz produktu”
- Kliknij zdjęcie → pole „Tekst alternatywny”
Naprawa 2: Dodanie labels do formularzy
<!-- ŹLE -->
<input type="text" placeholder="Imię">
<!-- DOBRZE -->
<label for="firstName">Imię:</label>
<input type="text" id="firstName" name="firstName" placeholder="Imię">
Naprawa 3: Poprawa kontrastu
/* ŹLE - kontrast 3.2:1 */
.cta-button {
background-color: #FF6B6B;
color: #FFFFFF;
}
/* DOBRZE - kontrast 5.1:1 */
.cta-button {
background-color: #D32F2F;
color: #FFFFFF;
}
Gdzie znaleźć pomoc:
- Dokumentacja WCAG (www.w3.org/WAI/WCAG21/quickref/)
- WebAIM articles (webaim.org/articles/)
- Fora: stackoverflow.com (tag: accessibility)
Opcja 2: Zlecenie programiście
Jeśli nie masz kompetencji technicznych:
Przygotuj brief dla programisty:
Temat: Naprawa dostępności sklepu zgodnie z audytem
Potrzebuję naprawienia problemów dostępności w sklepie [URL].
Załączam:
- Raport audytu (PDF)
- Lista priorytetów (najpilniejsze problemy wyróżnione)
Do zrobienia (PRIORYTET KRYTYCZNY - termin 7 dni):
1. Dodać alt text do 127 zdjęć produktów (wzór: "nazwa-kolor-ujęcie")
2. Dodać labels do 12 pól formularzy (kontakt, zamówienie)
3. Naprawić nawigację klawiaturową w menu głównym
Budżet: [kwota]
Wymagane: Testy po naprawach + krótki raport "co naprawiono"
Gdzie szukać programisty:
- Freelancer.com, Useme.com
- Grupy FB dla programistów/webmasterów
- Firma, która zrobiła Ci sklep (jeśli masz kontakt)
Szacunkowe koszty zlecenia:
- Naprawa problemów krytycznych (3 dni pracy): 1 500-3 000 zł
- Pełne wdrożenie dostępności (5-10 dni): 3 000-8 000 zł
- Duży sklep, zaawansowane naprawy (15+ dni): 10 000-25 000 zł
Opcja 3: Audyt + wdrożenie przez specjalistę
Jeśli chcesz pewność i spokój:
Firmy specjalizujące się w dostępności cyfrowej oferują:
- Pełny audyt WCAG 2.1 AA (5 000-10 000 zł)
- Wdrożenie napraw (10 000-30 000 zł)
- Certyfikat zgodności
- Roczne wsparcie i monitorowanie
Kiedy warto:
- Duży sklep (obrót >5 mln zł rocznie)
- Skomplikowana platforma (niestandardowe rozwiązania)
- Branża wymagająca (zdrowie, finanse, sektor publiczny)
- Potrzebujesz certyfikatu dla przetargów/partnerów B2B
Częste błędy podczas audytu – czego unikać
Błąd 1: Testowanie tylko na desktopie
ZAWSZE testuj też na mobile! 60% ruchu e-commerce to urządzenia mobilne. Problemy mogą być inne.
Błąd 2: Poleganie TYLKO na narzędziach automatycznych
Wykrywają max 40% problemów. Bez testów manualnych audyt jest niepełny.
Błąd 3: Audyt tylko strony głównej
Musisz przetestować CAŁĄ ścieżkę zakupową. Problemy często są w procesie zamówienia.
Błąd 4: Ignorowanie priorytetyzacji
Nie rzucaj się na wszystko naraz. Napraw krytyczne błędy najpierw, potem reszta.
Błąd 5: Brak dokumentacji
Zapisuj wszystko! Bez raportu nie napiszesz rzetelnej deklaracji dostępności.
Błąd 6: Audyt bez planu wdrożenia
Raport sam się nie zrealizuje. Ustal terminy, budżet, odpowiedzialności.
Błąd 7: Jednorazowy audyt i koniec
Dostępność to proces ciągły. Po każdej większej zmianie = nowy test.
Checklist: Czy audyt jest kompletny?
Przed uznaniem audytu za zakończony, sprawdź każdy punkt:
Przygotowanie
☐ Zrozumiałem podstawy WCAG 2.1 (4 zasady POUR, poziomy A/AA)
☐ Przygotowałem listę stron do audytu (min. 10 kluczowych)
☐ Zainstalowałem wszystkie potrzebne narzędzia
Audyt automatyczny
☐ Przeskanowałem wszystkie strony w WAVE
☐ Przeskanowałem wszystkie strony w Lighthouse
☐ Przeskanowałem w axe DevTools
☐ Zapisałem wyniki w tabeli
Testy manualne
☐ Przetestowałem nawigację klawiaturową (bez myszy, cała ścieżka zakupowa)
☐ Sprawdziłem kontrast kolorów (minimum: ceny, przyciski, linki)
☐ Przetestowałem powiększenie do 200%
☐ Sprawdziłem podstawy czytnika ekranu (alt text, labels) LUB zleciłem ekspertowi
☐ Sprawdziłem strukturę nagłówków (HeadingsMap)
Dokumentacja
☐ Stworzyłem raport ze streszczeniem
☐ Spisałem wszystkie problemy w tabeli
☐ Nadałem priorytety (krytyczny/wysoki/średni/niski)
☐ Oszacowałem czas/koszt napraw
☐ Stworzyłem timeline wdrożenia
Plan działania
☐ Wybrałem sposób napraw (własne/zlecenie/specjalista)
☐ Ustaliłem budżet
☐ Wyznaczyłem osobę odpowiedzialną
☐ Zaplanowałem datę rozpoczęcia napraw
☐ Zaplanowałem testy weryfikacyjne po naprawach
Im więcej checkboxów, tym bliżej do zgodności z prawem!
Podsumowanie: Audyt to nie straszak, tylko mapa do celu
Audyt dostępności e-sklepu brzmi strasznie, ale w praktyce to metodyczny, 6-12 godzinny proces, który każdy właściciel sklepu może przejść samodzielnie – przynajmniej w podstawowej wersji (narzędzia automatyczne + nawigacja klawiaturą + kontrast). To wystarczy, żeby:
- Napisać rzetelną deklarację dostępności (podstawa prawna)
- Uniknąć najwyższych kar od RPO (do 50 000 zł)
- Poprawić doświadczenie użytkowników (i konwersję o średnio 12%)
Kluczowe zasady udanego audytu:
✓ Zacznij od automatyki (WAVE, Lighthouse, axe) – 30-60 minut
✓ Przetestuj ręcznie (klawiatura, kontrast, powiększenie) – 2-4 godziny
✓ Priorytetyzuj bezlitośnie – napraw krytyczne błędy najpierw
✓ Dokumentuj wszystko – raport to podstawa deklaracji i planu napraw
✓ Działaj stopniowo – nie musisz naprawić wszystkiego w tydzień
Typowy timeline wdrożenia po audycie:
- Tydzień 1: Audyt (6-12h własnej pracy lub 2 000-5 000 zł zlecenie)
- Tydzień 2-3: Naprawy krytyczne (3-5 dni pracy lub 2 000-4 000 zł)
- Miesiąc 2: Naprawy wysokiego priorytetu + publikacja deklaracji
- Miesiąc 3-6: Naprawy średniego priorytetu + optymalizacja
Łączny koszt wdrożenia dostępności dla typowego sklepu: 3 000-8 000 zł (jednorazowo) + około 500-1 000 zł rocznie (monitoring i aktualizacje).
Czy to dużo? Porównaj z karą 15 000-50 000 zł za brak dostępności. Wybór jest prosty.
Potrzebujesz gotowych narzędzi prawnych? Sprawdź profesjonalną deklarację dostępności sklep internetowy oraz inne dokumenty niezbędne w e-commerce na prokonsumencki.pl – serwisie przygotowanym przez prawników specjalizujących się w branży online.
Nie odkładaj audytu na później. Im szybciej poznasz stan swojego sklepu, tym szybciej będziesz spać spokojnie, wiedząc, że działasz zgodnie z prawem i obsługujesz WSZYSTKICH klientów – bez wyjątków.
Następny krok: Po audycie przejdź do kompleksowego wdrożenia dostępności krok po kroku