Zgłoszenie zwykle wygląda tak samo. Ktoś z zewnątrz pisze, że nie da się wypełnić formularza kontaktowego z klawiatury, albo dział prawny przysyła maila o obowiązku zapewnienia dostępności. Pierwszy odruch firmy? Znaleźć wtyczkę, która załatwi sprawę w weekend. A WCAG dla firm to sprawa inżynierska, nie prawnicza – kryteria opisują konkretne zachowania interfejsu, które albo są w kodzie, albo ich nie ma.
W audytach stron firmowych robionych bez myślenia o dostępności widzę w kółko ten sam obraz: ładny layout, wizualnie bez zarzutu, a pod spodem divy udające przyciski, formularz bez etykiet i modal, z którego czytnik ekranu nie potrafi wyjść. Naprawa nie polega na dostawieniu osobnej “wersji dla niepełnosprawnych”. Dotyka szablonów, komponentów współdzielonych i tego, jak redakcja publikuje treści.
Spis treści
Od czego zacząć: audyt, który mówi, co naprawić
Sensowny audyt rozdziela dwie warstwy. Testy automatyczne wyłapują część problemów technicznych: brakujące atrybuty, zbyt niski kontrast, pola bez powiązanej etykiety, błędy w strukturze dokumentu. Tania i szybka warstwa, którą uruchamiam jako pierwszą. Ale zamyka tylko fragment listy.
Reszta wymaga oceny człowieka. Żaden skaner nie powie, czy tekst alternatywny faktycznie opisuje wykres. Ani czy kolejność fokusu odpowiada logice wizualnej strony. Ani czy etykieta “Wybierz” znaczy cokolwiek dla kogoś, kto nie widzi układu obok. A kryteria dotyczące zrozumiałości i unikania powtórnego wpisywania danych nie mają reguł automatycznych w ogóle.
Typowy błąd to potraktowanie raportu z narzędzia jako listy zadań posortowanej po liczbie wystąpień. Lepiej zrobić inaczej: audyt serwisu WWW ograniczony do kluczowych szablonów – strony głównej, listingu, karty usługi i formularza kontaktowego – czyli ścieżek, którymi realnie chodzi użytkownik. Zamiast przemiału wszystkich podstron.
Nakładki i widżety dostępności: dlaczego to nie działa
Nakładka to skrypt, który po załadowaniu strony podmienia jej wygląd w przeglądarce: powiększa czcionkę, odwraca kolory, dokłada panel z suwakami. Źródłowy HTML zostaje nietknięty. Czyli wszystko, co wynika ze złej struktury dokumentu, dalej jest zepsute – błędna semantyka, brak etykiet w formularzach, pułapki fokusu, modale, których nie da się zamknąć klawiszem Escape.
Do tego dochodzi ryzyko utrzymaniowe, o którym przy zakupie nikt nie mówi. Skrypt nadpisuje style i przechwytuje zdarzenia, więc kolejne wdrożenia frontendu zaczynają zachowywać się nieprzewidywalnie, a diagnozowanie takiego konfliktu bywa droższe niż sama poprawka. Porównaj to z alternatywą: te same pieniądze wydane na komponenty zostają w projekcie na stałe i pracują przy każdej następnej podstronie. Podobnie podchodzę do modernizacji starszych aplikacji webowych, gdzie łatanie objawów zwykle wraca po kilku miesiącach.
Warstwa techniczna: co konkretnie zmieniamy w kodzie
Fundamentem jest semantyka HTML. Nagłówki układają się w hierarchię opisującą dokument, listy są listami, przycisk jest elementem button, a odnośnik znacznikiem a z sensownym adresem. Nudne? Może. Ale ta jedna decyzja usuwa więcej barier niż dowolna liczba atrybutów ARIA doklejonych później.
Drugi obszar to formularze, czyli miejsce, w którym firma traci kontakty. Etykieta musi być powiązana z polem programowo, komunikat błędu ma pojawiać się przy polu i być ogłaszany przez czytnik ekranu, a status pola nie może zależeć wyłącznie od koloru ramki. Trzeci obszar to klawiatura: widoczny fokus, przewidywalna kolejność tabulacji, skip link, poprawne otwieranie i zamykanie modali oraz menu.
Zestaw poprawek, od których zaczynam w typowym projekcie WordPress albo w aplikacji frontendowej:
- uporządkowanie hierarchii nagłówków w szablonach motywu i w blokach edytora,
- zamiana klikalnych divów i spanów na natywne przyciski oraz linki,
- etykiety, opisy i komunikaty błędów w każdym formularzu, łącznie z newsletterem i wyszukiwarką,
- przywrócenie widocznego stylu fokusu usuniętego przez reset CSS,
- obsługa klawiatury w menu, karuzelach, zakładkach i modalach,
- kontrast tekstu oraz elementów interfejsu, w tym stanów hover i disabled,
- sprawdzenie układu przy powiększeniu do 200 procent i przy zawijaniu treści na wąskim ekranie.
Treść i redakcja: tu dostępność psuje się po wdrożeniu
Wykonawca oddaje czysty szablon, a po pół roku strona znowu ma setki błędów. Powód jest prozaiczny: teksty alternatywne pisze redakcja, nie programista. Zdjęcie dekoracyjne powinno mieć pusty atrybut alt, żeby czytnik je pominął. Infografika z danymi wymaga opisu przekazującego tę samą informację co grafika. Dwie różne sytuacje, dwie różne decyzje.
Druga typowa regresja to nagłówki używane jako narzędzie formatowania. Redaktor wybiera H3, bo ma odpowiedni rozmiar, i struktura dokumentu przestaje cokolwiek znaczyć dla nawigacji po nagłówkach. Trwałym długiem bywają też materiały wideo bez napisów, skanowane PDF-y i grafiki z osadzonym tekstem, publikowane latami.
Rozwiązanie jest procesowe, nie techniczne. Walidacja w CMS blokująca publikację obrazu bez decyzji o opisie, krótka checklista przy publikowaniu, szkolenie zespołu redakcyjnego. To daje trwalszy efekt niż jednorazowy audyt zamknięty raportem PDF.
Utrzymanie: dostępność jako element procesu
Regresja jest normą, nie wypadkiem. Każdy nowy landing pod kampanię, każda wtyczka i każda integracja potrafi cofnąć wcześniejsze poprawki – zwykle po cichu. Dlatego testy automatyczne dostępności wpięte w CI opłacają się nawet przy skromnym zakresie. Łapią najczęstsze błędy, zanim trafią na produkcję, a kosztują ułamek ręcznego przeglądu.
Druga rzecz to definicja ukończenia zadania rozszerzona o obsługę klawiatury i semantykę, sprawdzana przy odbiorze, a nie przy następnym audycie. No i osobna kategoria: elementy, których wykonawca strony nie kontroluje w pełni. Widżety czatu, mapy, systemy rezerwacji, bramki płatnicze. Zwykle najsłabsze ogniwo całej ścieżki konwersji, dlatego przy integracjach API i usług zewnętrznych sprawdzam dostępność dostawcy przed wyborem, a nie po wdrożeniu.
Koszty i kolejność prac: co napędza budżet
Koszt rozkłada się na cztery części: audyt, poprawki w komponentach współdzielonych, poprawki w treści oraz testy wraz z kontrolą regresji. Proporcje między nimi zależą głównie od tego, jak zbudowany jest frontend. Liczba podstron ma tu mniejsze znaczenie, niż wszyscy zakładają.
Budżet podbija brak systemu komponentów, w którym ten sam przycisk istnieje w kilku wariantach. Dalej: wiele odmian szablonów robionych ad hoc pod kampanie, stary motyw z warstwami nadpisanych stylów, nietypowe elementy interaktywne pisane od zera. Obniża go sytuacja odwrotna – jedna naprawa w komponencie propaguje się na wszystkie widoki, a decyzje architektoniczne podjęte na etapie projektu kosztują wielokrotnie mniej niż korekta po wdrożeniu. Z tego samego powodu tworzenie stron internetowych z dostępnością w wymaganiach wychodzi taniej niż dokładanie jej później.
Bywa też, że poprawki przestają się opłacać. Jeśli motyw jest niewspierany, a każda zmiana wywraca układ w innym miejscu, rozsądniej zaplanować przebudowę frontendu i przy okazji zamknąć temat wydajności oraz bezpieczeństwa.
Podsumowanie: co zrobić w pierwszej kolejności
Praktyczny skrót wygląda tak: audyt kluczowych szablonów zamiast całego serwisu, poprawki w komponentach zamiast na pojedynczych podstronach, uporządkowany proces publikacji treści i kontrola regresji wpięta w codzienną pracę zespołu.
Miej przy tym realistyczne oczekiwania. Dostępność zmniejsza liczbę barier i ryzyko prawne, ale nie jest certyfikatem wydanym raz na zawsze – to stan, który utrzymuje się razem z serwisem. Jeśli planujesz audyt, poprawki frontendu, integracje albo modernizację istniejącego systemu, napisz do nas i przejdźmy przez zakres na konkretach. Jeśli zależy Ci na tym, żeby efektem były strony zgodne z WCAG, a nie sam raport, zacznijmy od przeglądu kluczowych szablonów.
