Dostępność strony WCAG 2.2: zero błędów w teście, a bariery zostały

Dla administratorów: pełny przebieg z dokładnymi liczbami, poleceniami i konfiguracją. Wersje: stan na listopad 2026.

W skrócie

Kontekst

Trzy wersje tej samej treści w laboratorium: stara (motyw z generatora), po redesignie mobile-first (osobne case study) i po poprawkach dostępności. Redesign przeszedł już bramkę jakości, która dała część wymagań WCAG (kontrast tekstu i kontrolek, :focus-visible, prefers-reduced-motion, cele dotyku ≥ 48 px), więc audyt „przed” na wersji po redesignie zaczynał od czystego wyniku narzędzi.

Diagnoza

1. axe-core na 9 stronach × 390 i 1280 px; osobno stany interaktywne: formularz po nieudanym wysłaniu, otwarte menu na telefonie, otwarty lightbox. Zapisane także wyniki incomplete (do ręcznej oceny).

2. Lighthouse 12.8.2, profil mobilny, 5 stron × 2 przebiegi.

3. Przejście klawiaturą (desktop 1280 px i telefon 390 px z klawiaturą): Tab od początku do końca strony; przy każdym zatrzymaniu: czy fokus jest widoczny, czy element jest w oknie i niczym niezasłonięty, czy fokus nie krąży w kółko. Scenariusze: skip link (czy widoczny po fokusie, dokąd prowadzi), menu (Enter, następny Tab, wyjście fokusu z panelu, Esc, powrót fokusu), lightbox (Enter, fokus w oknie, strzałki, Tab w oknie, Esc, powrót fokusu).

4. Dodatki: Shift+Tab od końca strony (2.4.11 pod przyklejonym nagłówkiem), podmenu desktopu z fokusem + Esc (1.4.13), style odstępów tekstu z kryterium 1.4.12 (line-height: 1.5, letter-spacing: 0.12em, word-spacing: 0.16em, akapity 2em) i wykrywanie uciętego tekstu w kontenerach overflow: hidden, formularz: pusty, z błędnym e-mailem i poprawny (aria-invalid, opis z aria-describedby, validationMessage, fokus, regiony role="status"/alert), drzewo dostępności formularza i strony z otwartym menu, podgląd w trybie wymuszonych kolorów.

Wyniki „przed”

Stara wersja:

Po redesignie (przed poprawkami dostępności):

Problemy i poprawki (z kryteriami WCAG 2.2)

Kryteria sprawdzone i spełnione już po redesignie: 1.4.10 (reflow: 0 px przewijania w poziomie od 320 do 1920 px), 1.4.11 (obramowanie pól 4,6:1, pierścień fokusu 12,6:1), 2.5.8 (wszystkie cele ≥ 44 px), 1.3.5 (autocomplete="name", email, tel), 3.1.1 (lang="pl-PL"), 3.2.6 (kontakt w stopce każdej strony), 2.5.7 (przewijanie zdjęć gestem ma przyciski), ruch: prefers-reduced-motion: reduce wyłącza animacje i płynne przewijanie.

Przyczyna

Narzędzia automatyczne sprawdzają stan dokumentu w chwili uruchomienia: atrybuty, nazwy, kontrast policzalny z CSS. Bariery po redesignie dotyczyły zachowania: kolejności fokusu po interakcji, tego, co dzieje się po naciśnięciu Esc, co trafia do drzewa dostępności po wysłaniu formularza. axe uruchomiony w stanie „menu otwarte” widzi poprawne aria-expanded i poprawne linki, ale nie naciska Tab. Stara wersja miała problemy innego rodzaju: generator motywu nie dawał nazw elementom, a treść wpisywana w edytorze klasycznym nie miała tekstów alternatywnych.

Co nie było oczywiste

1. axe 0 i Lighthouse 100 przy pięciu barierach. Po redesignie axe nie zgłosił nic na 9 stronach w dwóch szerokościach, także w stanach: formularz z błędami, otwarte menu, otwarty lightbox. Wszystkie bariery (fokus pod panelem, Esc w podmenu, błędy formularza, brak ogłoszenia statusu, gwiazdka w nazwach) wyszły w przejściu klawiaturą i w drzewie dostępności.
2. Kontrast na tle z obrazkiem trafia do „incomplete”, nie do błędów. Stara strona ma tło z teksturą (page.png), więc axe oznaczył 152–195 węzłów jako „Element's background color could not be determined due to a background image” i Lighthouse dał 89–90 bez kary za kontrast; policzony ręcznie kontrast linków to 2,11:1.
3. Kolejność DOM po otwarciu panelu. <nav id="menu"> stoi w kodzie przed <button aria-controls="menu">, więc po otwarciu kolejny Tab idzie w przód, do main zasłoniętego panelem (position: fixed; inset: 60px 0 0). Samo aria-expanded tego nie naprawia; potrzebne było przeniesienie fokusu i inert na tle. Po poprawce strona za panelem znika też z drzewa dostępności, a fokus po ostatnim elemencie paska przechodzi do interfejsu przeglądarki.
4. Fokus na komunikacie po przeładowaniu znika przez kotwicę. Skrypt z defer ustawiał fokus na role="status" od razu, ale przewinięcie do #formularz po załadowaniu kasowało go (document.activeElement = body). Fokus ustawiony w load + requestAnimationFrame zostaje: activeElement = div.form-status. Komunikat obecny w HTML od początku nie jest ogłaszany przez region role="status" (ogłaszane są zmiany), dlatego fokus jest konieczny.
5. Dymki walidacji przeglądarki mówią językiem przeglądarki, nie strony. W testowej przeglądarce ustawionej na angielski formularz polskiej strony mówił „Please fill out this field.” i „Please include an '@' in the email address.”, po jednym błędzie naraz, bez śladu w DOM. Własne komunikaty (novalidate + te same teksty w PHP i JS) są po polsku i zostają przy polach.
6. CSS Elementora wyłącza podkreślenia i wygrywa z motywem. Elementor ma .elementor a{box-shadow:none;text-decoration:none} bez warstw kaskady, a style motywu Tailwind są w @layer components. Reguła spoza warstwy wygrywa z każdą regułą w warstwie, niezależnie od specyficzności, więc text-decoration: underline motywu nie działał (getComputedStyle → none). Poprawka: reguła poza @layer z selektorem .elementor .text-link (wyższa specyficzność niż .elementor a).
7. Wbudowany <dialog> z showModal() przechodzi bez poprawek. Fokus w oknie, Tab zostaje w środku, Esc zamyka, fokus wraca do miniatury (opener.focus() w zdarzeniu close). Stary lightbox z wtyczki galerii (simplelightbox) zostawiał fokus na stronie pod spodem.

Rozwiązanie

Menu na telefonie (assets/js/app.js):

const tlo = () => [...doc.querySelectorAll('main, .footer, .skip-link, .to-top')];
const setOpen = (open, oddajFokus) => {
  toggle.setAttribute('aria-expanded', String(open));
  nav.classList.toggle('is-open', open);
  tlo().forEach((el) => { el.inert = open; });
  if (open) nav.querySelector('a')?.focus();
  else if (oddajFokus) toggle.focus();
};
doc.addEventListener('keydown', (e) => { if (e.key === 'Escape' && toggle.getAttribute('aria-expanded') === 'true') setOpen(false, true); });

Podmenu, Esc (1.4.13): li.classList.add('is-dismissed') po Esc, usunięcie przy focusout poza pozycję albo mouseleave; CSS: .nav__menu li.is-dismissed > .sub-menu { visibility: hidden; }.

Formularz (inc/form.php, ten sam tekst błędu w PHP i JS):

<p class="form-hint">Pola oznaczone gwiazdką (*) są wymagane.</p>
<div class="form-status" role="status" tabindex="-1">…</div>
<div class="error-summary" tabindex="-1" hidden>…lista linków do pól…</div>
<form novalidate …>
  <label for="f-email">E-mail <span aria-hidden="true">*</span></label>
  <input type="email" id="f-email" name="email" required autocomplete="email"
         aria-describedby="f-email-blad" aria-invalid="true">
  <p class="field__error" id="f-email-blad">Wpisz adres e-mail w formacie nazwa@domena.pl.</p>

Przy wysyłce z błędami: komunikat przy każdym polu, podsumowanie „Formularz zawiera błędy (3)” z linkami do pól, fokus na podsumowaniu; komunikat znika, gdy pole jest poprawne (zdarzenie input, bez komunikatu przy każdym znaku). Bez JS: te same komunikaty z serwera (transient 10 min), wartości wracają do pól.

Podkreślenie linków poza warstwą (src/app.css, na końcu, poza @layer):

.elementor .text-link,
.elementor .error-summary a,
.elementor .elementor-widget-text-editor p a:not(.contact-link) { text-decoration: underline; text-underline-offset: 3px; }

Wyniki „po”

Rezultaty

Wnioski

• Raport z narzędzia to punkt wyjścia. W tym projekcie wszystkie bariery w nowej wersji przeszły przez axe i Lighthouse.
• Najtańsza kontrola z największym zwrotem: jedno przejście każdej strony samą klawiaturą i sprawdzenie formularza z błędami.
• Kreatory stron i ich CSS potrafią po cichu cofnąć poprawki; trzeba sprawdzać wynik w przeglądarce, nie w kodzie motywu.
• Przed deklaracją zgodności warto dodać odsłuch z NVDA lub VoiceOver i test z użytkownikiem czytnika; tu tego nie robiliśmy.