Dostępność WCAG 2.2 w praktyce: strona dla każdego użytkownika

Większość problemów z dostępnością znika, gdy używasz właściwych elementów HTML zamiast div-ów z JavaScriptem.

• jeden <h1> na stronę i logiczna hierarchia h2–h3 bez przeskakiwania poziomów,
• obszary strony: <header>, <nav>, <main>, <footer>,
• przyciski to <button>, linki to <a href> — nie odwrotnie,
• atrybut lang w znaczniku <html>,
• ARIA tylko tam, gdzie HTML nie wystarcza — „żadna ARIA jest lepsza niż zła ARIA”.

• kontrast tekstu do tła co najmniej 4,5:1 (duży tekst od 24 px lub 18,66 px pogrubiony — 3:1),
• elementy interfejsu i ikony informacyjne — minimum 3:1,
• nie przekazuj informacji wyłącznie kolorem (np. błąd w formularzu = czerwona ramka + komunikat tekstowy),
• tekst musi dać się powiększyć do 200% bez utraty treści, a układ działać przy szerokości 320 px,
• szanuj ustawienie prefers-reduced-motion — wyłącz duże animacje i paralaksę.

Odłóż mysz i przejdź stronę klawiszem Tab. Wszystko, co klikalne, musi być osiągalne i obsługiwalne z klawiatury.

• logiczna kolejność fokusu, zgodna z kolejnością wizualną,
• widoczny wskaźnik fokusu — nigdy outline: none bez zamiennika (użyj :focus-visible),
• WCAG 2.2: element z fokusem nie może być zasłonięty przez przyklejony nagłówek czy baner cookies (2.4.11),
• link „Przejdź do treści” na początku strony,
• okna modalne zatrzymują fokus w środku, zamykają się klawiszem Esc i oddają fokus do przycisku, który je otworzył.

• każdy obraz informacyjny ma opisowy alt — opisz funkcję lub treść, a nie „zdjęcie123”,
• obrazy dekoracyjne mają pusty alt="",
• wykresy i infografiki mają opis lub tabelę z danymi w treści,
• wideo ma napisy, a nagrania audio — transkrypcję,
• nic nie odtwarza się automatycznie z dźwiękiem; ruchome treści dłuższe niż 5 sekund można zatrzymać.

Formularz to miejsce, gdzie dostępność przekłada się bezpośrednio na zapytania i sprzedaż.

• każde pole ma widoczną etykietę <label> (placeholder to nie etykieta),
• komunikaty błędów są tekstowe, konkretne i powiązane z polem (aria-describedby),
• używaj autocomplete (np. email, name, tel),
• rozmiar celu dotykowego co najmniej 24×24 px (2.5.8), a w praktyce na mobile — 44×44 px,
• nie każ wpisywać dwa razy tych samych danych w jednym procesie (3.3.7),
• logowanie bez testów pamięciowych — pozwól wklejać hasła i korzystać z menedżerów haseł (3.3.8),
• operacje przeciągania mają alternatywę kliknięciem (2.5.7).

Narzędzia automatyczne wykrywają tylko część problemów (szacunkowo 30–40%). Łącz oba podejścia:

1. automatycznie: axe DevTools, WAVE, Lighthouse — przy każdym wdrożeniu,
2. klawiatura: pełne przejście kluczowych ścieżek (menu, formularz, koszyk),
3. czytnik ekranu: NVDA (Windows), VoiceOver (macOS / iOS), TalkBack (Android),
4. powiększenie do 200% i 400% oraz tryb wysokiego kontrastu.

Wyniki opisz w deklaracji / informacji o dostępności wraz z kontaktem do zgłaszania problemów. To wymóg dla usług objętych EAA i dobra praktyka dla wszystkich.