Dostosowanie strony do WCAG 2.2 w serwisie ogłoszeniowym, który codziennie przyrasta o nowe treści, to nie jednorazowa poprawka kolorów. W tym projekcie przeszliśmy pełny cykl: badanie stanu wyjściowego, trzy rundy poprawek i trzy retesty obejmujące za każdym razem wszystkie 55 kryteriów poziomu AA. Wynik końcowy: zero niespełnionych kryteriów i pusty wykaz treści niedostępnych.
Kluczowe informacje o projekcie
- Klient: serwis motoryzacyjny z katalogiem ogłoszeń, około 2,5 tysiąca adresów
- Problem: 9 z 55 kryteriów WCAG 2.2 AA niespełnionych, 617 elementów o zbyt niskim kontraście, wskaźnik fokusu wyłączony w części elementów sterujących
- Rozwiązanie: audyt metodyką WCAG-EM, poprawki w szablonach i wtyczce serwisu, trzy retesty na tej samej próbce
- Efekt: 43 z 43 stosowalnych kryteriów spełnionych, Lighthouse 95,7 → 100, serwis może deklarować zgodność
- Czas: 13 dni, od 13 do 26 sierpnia 2026
| 9 → 0 | 617 → 0 | 95,7 → 100 | 4 |
|---|---|---|---|
| niespełnionych kryteriów | elementów o złym kontraście | ocena dostępności Lighthouse | rundy pełnego badania |
Wyzwanie: serwis, który zmienia się codziennie
Katalog ogłoszeń, strony marek i modeli, słownik techniczny, formularz logowania klienta — każdy z tych typów stron ma własny szablon i własne bariery. Do tego treść rośnie z dnia na dzień, więc barierę może wywołać nie zmiana kodu, lecz sam przyrost danych. Tak było w tym projekcie: w trakcie cyklu ujawniło się przewijanie poziome na liście marek przy szerokości 320 pikseli — bariera starsza niż poprawki, wywołana samym przyrostem danych w katalogu.
Badanie stanu wyjściowego z 13 sierpnia wykazało dziewięć niespełnionych kryteriów. Najpoważniejsze dotyczyły samej oferty:
- kontrast — 617 elementów poniżej progu, w tym opisy parametrów aut: przebieg, rocznik, pojemność. Najgorszy przypadek, biały tekst na żółtym tle, miał kontrast 2,03:1 przy wymaganych 4,5:1,
- widoczny fokus — przy przechodzeniu klawiszem Tab po liście samochodów 9 kolejnych elementów nie miało żadnego wskaźnika,
- baner zgód zasłaniał elementy z fokusem przy pierwszej wizycie, czyli u każdego nowego użytkownika,
- cele dotykowe poniżej 24 × 24 piksele przy karcie ogłoszenia — 25 elementów.
Jak prowadziliśmy badanie
Pracujemy według WCAG-EM, metodyki oceny zgodności rekomendowanej przez W3C. Próbkę — 17 adresów reprezentujących typy stron — zamknęliśmy przed badaniem i nie zmienialiśmy jej do końca, żeby każdy retest był porównywalny z poprzednim.
| Data | Krok | Niespełnione kryteria |
|---|---|---|
| 13.08 | badanie stanu wyjściowego | 9 |
| 21.08 | pierwszy retest po poprawkach | 5 |
| 25.08 | drugi retest | 2 |
| 26.08 | badanie końcowe | 0 |
Każdy retest obejmował wszystkie 55 kryteriów, nie tylko naprawiane — poprawka dostępności potrafi zepsuć inne kryterium. Żaden retest nie wykazał regresji.
Poprawki wdrażała osobna sesja wykonawcza, a audytor mierzył je od nowa własnym narzędziem, nie przyjmując liczb wykonawcy. Ten rozdział ról zadziałał w obie strony: wykonawca trzy razy skutecznie zakwestionował ustalenia audytora — jedna pozycja została wycofana jako błąd audytora, a jedna rekomendacja naprawcza okazała się błędna i została sprostowana. Audytor z kolei odrzucił cztery zgłoszenia narzędzi automatycznych jako fałszywe alarmy.
W ostatniej rundzie rozszerzyliśmy metodę: komplet reguł sprawdzamy przy dwóch szerokościach ekranu, 1366 i 320 pikseli, bo część naruszeń ujawnia się wyłącznie na wąskim ekranie. Ta zmiana została w procedurze na stałe.
Co zostało naprawione
- Kontrast: pogłębiony odcień koloru marki w arkuszach motywu, wtyczki i wartościach generowanych w PHP — 0 elementów poniżej progu przy obu szerokościach ekranu,
- Fokus: dwubarwny wskaźnik (biała obwódka i ciemna poświata), widoczny na każdym tle z co najmniej trzykrotnym zapasem ponad próg — sprawdzony na 150 przystankach klawiatury,
- Baner zgód: okno dialogowe z pętlą fokusu i czterema wyjściami klawiaturą,
- Struktura: nagłówki bez przeskoków poziomów, etykiety pól filtrów katalogu, obszary przewijane w poziomie dostępne z klawiatury,
- Lista marek przy 320 px: naprawa strukturalna, która nie wróci przy kolejnej marce o długiej nazwie.
Wynik
| Miara | Przed — 13.08 | Po — 26.08 |
|---|---|---|
| Kryteria spełnione | 31 z 55 | 43 z 55 |
| Kryteria niespełnione | 9 | 0 |
| Elementy o niewystarczającym kontraście | 617 | 0 |
| Cele dotykowe poniżej progu | 25 | 0 |
| Elementy bez widocznego fokusu | 17 | 0 |
| Lighthouse — ocena dostępności | 95,7 | 100 |
Pozostałe 12 kryteriów nie dotyczy tego serwisu — na przykład w serwisie nie ma nagrań wideo ani transmisji. Serwis może opublikować deklarację dostępności o pełnej zgodności, z pustym wykazem treści niedostępnych.
Czego ten wynik nie oznacza. Orzeczenie dotyczy 17 adresów reprezentujących typy stron, a nie każdego z 2,5 tysiąca adresów, i stanu na dzień badania. Audyt i poprawki prowadziliśmy w ramach opieki nad serwisem, więc nie jest to badanie niezależne organizacyjnie — tam, gdzie wymagana jest niezależność, potrzebny jest audytor zewnętrzny. Piszemy o tym wprost, bo raport, który ukrywa swoje ograniczenia, nie obroni się przy kontroli.
Dla kogo jest takie podejście
- serwisy i sklepy sprzedające konsumentom, objęte Europejskim aktem o dostępności od 28 czerwca 2025,
- serwisy z dużą liczbą adresów generowanych z szablonów — poprawka w szablonie naprawia tysiące stron naraz,
- firmy, które potrzebują nie listy błędów ze skanera, lecz dokumentu z metodą, próbką i datą, do okazania klientowi korporacyjnemu albo organowi.
Najczęstsze pytania (FAQ)
Ile trwa dostosowanie strony do WCAG 2.2?
W tym projekcie 13 dni od badania stanu wyjściowego do badania końcowego, w czterech rundach. Czas zależy od liczby szablonów i od tego, jak szybko zespół utrzymujący serwis wdraża poprawki — samo badanie pełne trwa od 10 do 15 dni roboczych.
Czy wystarczy poprawić błędy wskazane przez skaner?
Nie. Narzędzia automatyczne wykrywają około 30% problemów, a część ich zgłoszeń to fałszywe alarmy — w tym projekcie odrzuciliśmy cztery. Kryteria takie jak kolejność fokusu, zasłanianie elementów czy etykiety pól wymagają badania w przeglądarce i klawiaturą.
Dlaczego retest obejmuje wszystkie kryteria, a nie tylko naprawione?
Bo poprawka dostępności potrafi zepsuć inne kryterium — na przykład przewijany kontener naprawia dopasowanie do ekranu, ale tworzy obowiązek dostępności z klawiatury. Pełny retest wyłapuje takie zależności.
Co dostaje firma po zakończeniu?
Raport końcowy z orzeczeniem dla każdego z 55 kryteriów, opis każdej niezgodności i sposobu naprawy, archiwum dowodowe oraz podstawę do deklaracji dostępności. Zakres i ceny pakietów: audyt WCAG 2.2.
Następny krok
Chcesz wiedzieć, ile barier ma Twój serwis i ile pracy dzieli go od zgodności? Zacznij od audytu WCAG 2.2 — przegląd wstępny pokazuje skalę problemu, zanim zdecydujesz o pełnym badaniu. Napisz: office@auranet.com.pl.
