Dostępność strony internetowej — praktyczna checklista WCAG 2.2 dla małej firmy

Dostępna strona nie jest wersją „dla osób niewidomych” dołączoną po projekcie. To witryna, której treść i funkcje można postrzegać, obsługiwać i rozumieć na różne sposoby: klawiaturą, czytnikiem ekranu, przy powiększeniu, bez dźwięku albo przy ograniczonej sprawności ruchowej. WCAG porządkuje te potrzeby w testowalne kryteria.

Krótka odpowiedź: sprawdź najważniejsze procesy według czterech zasad WCAG: postrzegalność, funkcjonalność, zrozumiałość i solidność techniczna. Zweryfikuj strukturę nagłówków, alternatywy obrazów, kontrast, powiększenie i reflow, napisy, klawiaturę, widoczny focus, formularze, komunikaty błędów, język dokumentu oraz nazwy kontrolek. Automatyczny skaner wykryje tylko część barier, więc potrzebne są testy ręczne z prawdziwymi zadaniami użytkownika.

Czym jest WCAG 2.2?

Web Content Accessibility Guidelines 2.2 to rekomendacja W3C opisująca sposób zwiększania dostępności treści internetowych. Kryteria są pogrupowane według czterech zasad, często zapamiętywanych jako POUR:

Perceivable — postrzegalne: informacja nie zależy wyłącznie od jednego zmysłu;
Operable — funkcjonalne: interfejs można obsłużyć różnymi metodami;
Understandable — zrozumiałe: treść i zachowanie są przewidywalne;
Robust — solidne: kod przekazuje nazwę, rolę i stan technologiom wspomagającym.

WCAG ma poziomy A, AA i AAA. Zgodność jest formalnym pojęciem dotyczącym pełnych stron i kompletnych procesów, nie procentem z wtyczki. Ten poradnik pomaga rozpocząć audyt, ale sam nie stanowi certyfikacji ani opinii prawnej.

Zacznij od procesów, nie przypadkowych podstron

Spisz zadania kluczowe dla firmy:

poznanie oferty;
znalezienie ceny lub warunków;
przejście przez menu;
wysłanie formularza;
umówienie wizyty albo zakup;
pobranie dokumentu;
znalezienie danych kontaktowych.

Audytuj każdy proces od wejścia do potwierdzenia. Dostępna strona główna nie pomaga, jeśli przycisk wysłania formularza nie działa z klawiatury.

Struktura dokumentu

Sprawdź, czy:

dokument ma trafny tytuł;
język strony jest określony w HTML;
nagłówki opisują sekcje i tworzą logiczny konspekt;
listy są listami, a nie akapitami z ręcznym znakiem;
tabela danych ma właściwe nagłówki;
regiony strony używają semantycznych elementów;
link „przejdź do treści” pozwala ominąć powtarzalną nawigację.

Nie wybieraj H2 tylko dlatego, że ma pożądany rozmiar. Wygląd ustala CSS, a poziom nagłówka strukturę informacji.

Obrazy, dźwięk i wideo

Obraz informacyjny potrzebuje alternatywy przekazującej jego funkcję w danym kontekście. Dekoracja powinna być ignorowana przez technologie wspomagające. Wykres może wymagać krótkiego alt i pełnego opisu danych obok.

Materiały z nagranym dźwiękiem wymagają odpowiednich alternatyw, m.in. napisów dla treści mówionej i istotnych dźwięków. Automatycznie wygenerowane napisy trzeba sprawdzić — nazwiska, liczby i specjalistyczne słowa często są rozpoznawane błędnie.

Kolor i kontrast

Tekst na tle powinien spełniać wymagany kontrast, a elementy interfejsu być rozpoznawalne. Informacja nie może zależeć tylko od koloru: czerwone pole bez komunikatu tekstowego jest niewystarczające.

Testuj stany normalny, hover, focus, błąd, disabled i odwiedzony link. Gradient, zdjęcie w tle i półprzezroczystość mogą sprawić, że kontrast zmienia się w różnych miejscach tego samego napisu.

Powiększenie, reflow i tekst

Przy dużym powiększeniu użytkownik nie powinien przewijać jednocześnie w dwóch kierunkach dla zwykłej treści ani tracić funkcji. Sprawdź:

powiększenie tekstu;
wąski viewport odpowiadający powiększeniu;
zwiększony odstęp między liniami, literami i akapitami;
długie słowa i adresy;
komunikaty oraz menu mobilne;
treść przy orientacji pionowej i poziomej.

Nie blokuj skalowania w meta viewport. Responsywność jest ważną częścią dostępności, ale sama nie zapewnia reflow wszystkich komponentów.

Klawiatura i focus

Odłącz mysz i wykonaj cały proces za pomocą Tab, Shift+Tab, Enter, Spacji, strzałek i Escape zgodnie z typem kontrolki. Focus powinien być zawsze widoczny, mieć logiczną kolejność i nie znikać pod przyklejonym nagłówkiem lub banerem.

Nie dodawaj dodatnich wartości tabindex, by ręcznie „naprawić” kolejność. Zwykle lepiej poprawić kolejność DOM. Modal musi zarządzać focusem i pozwalać bezpiecznie wrócić do elementu, który go otworzył.

Formularze i błędy

Każde pole potrzebuje programowo powiązanej etykiety. Placeholder nie zastępuje etykiety, bo znika po wpisaniu i często ma słaby kontrast. Instrukcje wymagane do poprawnego wpisania danych powinny być dostępne przed wysłaniem.

Po błędzie:

wskaż pole tekstem, nie samą czerwienią;
opisz, co należy poprawić;
powiąż komunikat z polem;
zachowaj poprawnie wpisane wartości;
przenieś uwagę do podsumowania lub pierwszego błędu w przewidywalny sposób;
ogłoś status czytnikowi ekranu, gdy treść zmienia się dynamicznie.

Nazwa, rola, stan

Natywny <button> przekazuje przeglądarce więcej niż klikalny <div>. Używaj HTML zgodnie z przeznaczeniem. Własne komponenty muszą udostępniać nazwę, rolę, stan i obsługę klawiatury.

ARIA może uzupełnić semantykę, ale nie naprawia automatycznie zachowania. role="button" nie dodaje aktywacji klawiaturą ani focusu. Preferuj natywny element.

Co wykryje automat?

Skaner może znaleźć część brakujących nazw, błędów struktury i kontrastu. Nie oceni wiarygodnie:

czy alt ma sens w kontekście;
czy kolejność czytania jest logiczna;
czy instrukcja jest zrozumiała;
czy focus trafia we właściwe miejsce;
czy cały proces można ukończyć;
czy napisy poprawnie oddają nagranie;
czy komunikat błędu rzeczywiście pomaga.

Traktuj automat jako szybki filtr regresji, a nie dowód pełnej zgodności.

Minimalny plan testów

Uruchom walidację i skaner dostępności.
Przejdź proces tylko klawiaturą.
Sprawdź widoczność i kolejność focusu.
Powiększ treść i zmniejsz viewport.
Sprawdź kontrast wszystkich stanów.
Przejrzyj konspekt nagłówków i landmarki.
Odczytaj kluczową stronę czytnikiem ekranu.
Wyłącz obrazy i oceń alternatywy.
Wywołaj błędy formularza.
Przetestuj na realnym telefonie.

Najwięcej dają testy z osobami korzystającymi z technologii wspomagających. Ekspert i automat nie odtworzą w pełni ich doświadczeń.

Jak utrzymać dostępność?

Dodaj kryteria do projektu, biblioteki komponentów, odbioru treści i testów regresji. Redaktorzy potrzebują zasad nagłówków, linków, opisów obrazów oraz napisów. Po aktualizacji motywu, formularza i systemu zgód powtarzaj kluczowe scenariusze.

Naprawiaj komponent, nie każdą instancję osobno. Poprawienie wspólnego przycisku, pola albo karty usuwa barierę w wielu miejscach i ogranicza jej powrót.

Podsumowanie

Dostępność jest właściwością kompletnego procesu, a nie wynikiem jednego skanera. WCAG 2.2 daje wspólny język, lecz rzetelny audyt łączy narzędzia automatyczne, klawiaturę, powiększenie, czytnik ekranu i testy użytkowników. Najlepszy moment na dostępność to projekt komponentu; drugi najlepszy to uporządkowany audyt obecnej strony.