Twoja strona główna przeszła audyt dostępności. O twoim serwisie to nie mówi prawie nic.

Część 1 była inżynierią: jak warstwa discovery znajduje strony, których audyt strony głównej nie tyka, i jak deduper zamienia 5 808 wystąpień jednego buga w jedno znalezisko. Ta część to pytanie, które faktycznie zadaje CTO. Ile to jest warte i ile kosztuje tego nie mieć?

Bez kodu. Tylko ta część, która pokazuje się w budżecie.

Single-page-green to fałszywy odbiór

Celujesz audytem w stronę główną. Świeci się na zielono. Podpisujesz odbiór.

A koszyka nikt nie audytował. Konta użytkownika nie. Wyników wyszukiwania nie. Szablonów artykułów nie. Ścieżki rezerwacji nie. Strony, na których faktycznie żyją konwersja i zgodność, to dokładnie te, których audyt jednego URL-a nie widzi.

Single-page-green nie znaczy, że serwis jest dostępny. Znaczy, że ta jedna strona jest. Nauczyłem się tego na własnym portfolio: strona główna była czysta przez trzy rundy audytu, a w momencie, w którym skierowałem discovery na router, znalazłem dziewięć znalezisk SERIOUS na trzech stronach, których ręcznie nigdy bym nie zaudytował.

Ta przepaść - między “ta strona przechodzi” a “ten serwis jest zgodny” - była kiedyś kwestią jakości. Teraz jest kwestią prawną.

Od czerwca 2025 to przestało być opcją

European Accessibility Act (dyrektywa 2019/882) obowiązuje od 28 czerwca 2025. Obejmuje e-commerce, bankowość konsumencką, bilety i transport, e-booki i więcej. Baseline techniczny to zgodność na poziomie WCAG. Egzekwowanie i kary ustala każde państwo członkowskie osobno.

Przeczytaj zakres uważnie: obowiązek dotyczy usługi. Całego produktu. Nie strony lądowania.

Masz więc prawo wycelowane w całą ścieżkę użytkownika i audyt wycelowany w jeden URL. Odległość między tymi dwoma zakresami to twoje ryzyko. Skarga nie przychodzi o stronę, którą zaudytowałeś. Przychodzi o tę, której nie.

Koszt to nie “audytuj więcej stron”

I tu matematyka zwykle się sypie.

Ręczny audyt dostępności całego serwisu - dziesiątki do setek stron - to tygodnie pracy specjalisty. A na wyjściu płaska lista tysięcy znalezisk, której nikt nie ogarnie. Drogo zrobić, bezużytecznie wdrożyć.

Dźwignia to nie audytowanie większej liczby stron. To raportowanie po przyczynie zamiast po liczbie. 5 816 znalezisk na moim portfolio to były trzy bugi. Nie płacisz nikomu za przeklikanie 5 808 duplikatów - poprawiasz jedną zmienną CSS i 34 strony robią się zielone naraz. Ta deduplikacja jest oszczędnością. Po prostu wygląda jak techniczny szczegół.

Ta sama metoda, realne liczby z mojej roboty: pełny audyt performance zajął 7 godzin tym podejściem wobec 16 godzin billowalnych ręcznie, wobec tygodnia klasycznie. Portfolio przeszło z oceny niedostatecznej na A w ośmiu commitach, 75 minut pracy. Dostępność ma ten sam kształt. Pętla audyt-i-fix leci w godzinach, nie w wielotygodniowym zleceniu, bo narzędzie zwija objawy w przyczyny, zanim człowiek w ogóle przeczyta raport.

Co faktycznie kupujesz

Możliwość powiedzenia, że cały twój serwis jest zgodny. Każdy szablon, każda trasa za logowaniem, każda strona, na której zmieniają się pieniądze. Ze ścieżką naprawy, która brzmi “jedna zmiana, trzydzieści cztery strony na zielono” - i z tym zrobionym, zanim skarga z tytułu EAA znajdzie stronę, o której zapomniałeś, że istnieje.

Audyt jednej strony odpowiada na “czy ta strona jest dostępna”. Audyt multi-page odpowiada na “czy mój biznes jest zgodny”. Tylko jedno z tych pytań pojawia się w piśmie prawnym.

Gdzie jest granica

Publiczny toolkit robi rdzeń tego - discovery, cross-page dedup, ocenę A-F - open source na AGPL-3.0. Sklonuj, odpal, zobacz metodę.

Skala produkcyjna to inna robota: trasy za logowaniem, równoległe wykonanie po setkach stron, bramkowanie audytu w CI, żeby regresja nigdy nie wyszła, federacja tokenów w design systemie używanym przez dziesięć repo. To Pro tier i robota konsultingowa, i to tam “zgodna strona główna” zamienia się w “zgodną firmę”.

Jeśli twój odbiór dostępności obejmuje teraz jedną stronę, podpisujesz się pod zgadywanką. To jest ta część, którą warto poprawić najpierw.

To część 2 historii budowy multi-page WCAG. Część 1 omawia architekturę: warstwa discovery i deduper. Toolkit jest open source: sdet-wcag-toolkit, AGPL-3.0.