Jak czytać WCAG 2.2 dla własnej strony, poprawki obejmujące większość realnych błędów, 30-minutowy test ręczny, który wykona każdy, oraz jak nakładają się dostępność i użyteczność.
Najczęściej zadawane pytania
Co znaczy, że strona jest zgodna z WCAG?
Oznacza to, że strona spełnia kryteria sukcesu Web Content Accessibility Guidelines na wybranym poziomie, zwykle WCAG 2.1 lub 2.2 poziom AA. Poziom AA obejmuje każde kryterium poziomu A i AA. Większość przepisów i polityk zamówień odwołujących się do WCAG wymaga poziomu AA.
Jak interpretować wytyczne WCAG dla mojej strony?
Zacznij od skróconego przewodnika W3C „How to Meet WCAG”, przefiltruj go do poziomów A i AA, a dla każdego kryterium przeczytaj stronę „Understanding”, która wyjaśnia intencję prostym językiem. Potem przetestuj kluczowe szablony (strona główna, strona treści, formularz, kasa), zamiast każdej strony osobno.
Czy nakładka lub wtyczka dostępności może sprawić, że moja strona będzie zgodna?
Żadne narzędzie nie sprawi samo, że strona będzie zgodna. Nakładki dodające pasek narzędzi nie naprawiają kodu pod spodem, a wielu użytkowników z niepełnosprawnościami i specjalistów od dostępności zgłasza, że przeszkadzają. Napraw bezpośrednio HTML, kontrast, etykiety i obsługę klawiatury.
Czym różni się użyteczność od dostępności?
Dostępność oznacza, że osoby z niepełnosprawnościami mogą postrzegać stronę, rozumieć ją, poruszać się po niej i korzystać z niej. Użyteczność oznacza, że strona jest łatwa i wydajna dla wszystkich. Bardzo się nakładają: czytelne etykiety, dobry kontrast i przewidywalna nawigacja pomagają wszystkim odwiedzającym, nie tylko osobom z niepełnosprawnościami.
Czy automatyczne narzędzia znajdują wszystkie problemy z dostępnością?
Nie. Narzędzia takie jak WAVE, axe i Lighthouse wyłapują problemy typu brak tekstu alternatywnego, niski kontrast i brakujące etykiety, ale wiele kryteriów, jak to, czy tekst alternatywny ma sens lub czy kolejność fokusu jest sensowna, wymaga sprawdzenia przez człowieka.
Strona zgodna z WCAG spełnia Web Content Accessibility Guidelines na wybranym poziomie, a dla prawie każdej firmy oznacza to WCAG 2.2 poziom AA. W praktyce większość stron zawodzi w tej samej garści spraw: niski kontrast kolorów, brak tekstu alternatywnego obrazów, nieopisane pola formularzy, puste linki i przyciski oraz elementy, do których nie da się dotrzeć klawiaturą. Napraw je i przetestuj klawiaturą oraz czytnikiem ekranu, a pokryjesz dużą część tego, na co trafiają prawdziwi użytkownicy.
Ten poradnik wyjaśnia, jak czytać WCAG, nie gubiąc się, poprawki, które mają największe znaczenie, i 30-minutowy test, który możesz wykonać sam.
Jak zbudowane jest WCAG
WCAG publikuje W3C. Jest uporządkowane w warstwy:
Cztery zasady, znane jako POUR: treść musi być Perceivable (postrzegalna), Operable (obsługiwalna), Understandable (zrozumiała) i Robust (solidna).
Wytyczne pod każdą zasadą (na przykład „Alternatywy tekstowe” lub „Dostępność z klawiatury”).
Kryteria sukcesu pod każdą wytyczną. To testowalne reguły, każda ponumerowana (jak 1.4.3 Kontrast) i mająca poziom: A, AA lub AAA.
Poziom A to minimum. Poziom AA to częsty cel dla wymogów prawnych i zamówień. Poziom AAA jest surowszy i zwykle nie jest wymagany dla całych stron.
WCAG 2.2 stało się zaleceniem W3C w październiku 2023. Dodało kryteria takie jak minimalny rozmiar celu, nieprzesłonięty fokus i dostępne uwierzytelnianie, a usunęło 4.1.1 Parsing jako przestarzałe.
Jak interpretować WCAG dla własnej strony
Specyfikacja czyta się jak standard, bo nim jest. Praktyczna droga przez nią:
Otwórz „How to Meet WCAG (Quick Reference)” W3C.
Przefiltruj ją tylko do poziomów A i AA.
Dla każdego kryterium przeczytaj podlinkowaną stronę „Understanding”. Wyjaśnia intencję prostym językiem, z przykładami spełnienia i niespełnienia.
Zamiast testować każdą stronę, testuj swoje szablony: stronę główną, standardową stronę treści, wpis na blogu, formularz, stronę produktu lub kasy. Naprawa szablonu naprawia każdą stronę zbudowaną na nim.
Zapisuj każdy problem z numerem kryterium, stroną i tym, jak wygląda poprawka.
Poprawki, które pokrywają większość realnych błędów
1. Kontrast kolorów (1.4.3 i 1.4.11)
Zwykły tekst: co najmniej 4.5:1 względem tła.
Duży tekst (około 24px zwykły lub 18.66px pogrubiony i większy): co najmniej 3:1.
Elementy interfejsu i znaczące grafiki (obramowania przycisków, kontury pól, ikony niosące informację): co najmniej 3:1.
Jasnoszary tekst zastępczy i biały tekst na bladych kolorach marki to typowi winowajcy. Sprawdzaj kontrolerem kontrastu WebAIM lub narzędziami deweloperskimi przeglądarki.
2. Alternatywy tekstowe dla obrazów (1.1.1)
Obrazy informacyjne dostają tekst alternatywny opisujący to, co ważne: alt="Technik wymieniający filtr pieca".
Obrazy ozdobne dostają pusty alt: alt="", aby czytniki ekranu je pomijały.
Obrazy z tekstem (zrzut ulotki, menu jako JPG) wymagają tego samego tekstu dostępnego jako prawdziwy tekst.
Obrazy będące linkami, jak logo prowadzące na stronę główną, opisują cel: alt="Strona główna Acme Plumbing".
3. Etykiety formularzy i błędy (1.3.1, 3.3.1, 3.3.2)
Każde pole potrzebuje widocznej <label> z nim powiązanej. Tekst zastępczy nie jest etykietą: znika, gdy piszesz.
Komunikaty o błędach mówią, co poszło nie tak i jak to naprawić („Wpisz numer telefonu z numerem kierunkowym”), tekstem, a nie tylko czerwoną ramką.
Pola wymagane są oznaczone tekstem lub dostępnym wskaźnikiem, a nie samym kolorem.
4. Dostęp z klawiatury (2.1.1, 2.4.3, 2.4.7)
Każdy link, przycisk, menu i kontrolka formularza musi działać z Tab, Shift+Tab, Enter i Spacją.
Kolejność fokusu podąża za kolejnością wizualną.
Widoczny wskaźnik fokusu pokazuje, gdzie jesteś. Usunięcie obramowania przeglądarki przez outline: none bez zamiennika to częsty błąd.
Menu rozwijane i okna modalne muszą otwierać się, działać i zamykać z klawiatury, a okna modalne powinny trzymać fokus w środku do zamknięcia.
5. Linki i przyciski z nazwami (2.4.4, 4.1.2)
Przyciski tylko z ikoną (menu hamburger, lupa wyszukiwania, ikony społecznościowe) potrzebują dostępnej nazwy, przez widoczny tekst, aria-label lub ukryty tekst.
Unikaj strony pełnej linków „Kliknij tutaj” i „Czytaj więcej”. Niech tekst linku opisuje cel albo nadaj każdemu odrębną dostępną nazwę.
6. Struktura i nagłówki (1.3.1, 2.4.6)
Jeden <h1> na stronę opisujący stronę.
Nagłówki w logicznej kolejności (h2 dla sekcji, h3 wewnątrz nich), a nie dobierane pod rozmiar czcionki.
Używaj prawdziwych list, tabel z komórkami nagłówkowymi i punktów orientacyjnych (<header>, <nav>, <main>, <footer>).
Ustaw język strony: <html lang="pl">.
7. Nowości w WCAG 2.2, warte znajomości
2.5.8 Target Size (Minimum), AA: klikalne cele o wymiarach co najmniej 24 na 24 piksele CSS lub wystarczające odstępy wokół mniejszych.
2.4.11 Focus Not Obscured (Minimum), AA: przyklejone nagłówki, banery cookies i widżety czatu nie mogą całkowicie zasłaniać elementu z fokusem.
3.3.8 Accessible Authentication (Minimum), AA: nie wymagaj rozwiązywania łamigłówek ani pamiętania informacji przy logowaniu bez alternatywy; zezwalaj na menedżery haseł i wklejanie.
3.3.7 Redundant Entry, A: nie każ ludziom ponownie wpisywać informacji, które już podali w tym samym procesie.
8. Media i ruch
Filmy potrzebują napisów (1.2.2); nagrane wideo potrzebuje audiodeskrypcji lub alternatywy tekstowej dla ważnej treści wizualnej.
Wszystko, co porusza się automatycznie dłużej niż pięć sekund, potrzebuje sposobu na wstrzymanie (2.2.2).
Szanuj ustawienie prefers-reduced-motion dla dużych animacji.
30-minutowy test ręczny
Narzędzia automatyczne wychwytują tylko część obrazu. Dodaj tę rutynę dla każdego kluczowego szablonu.
Minuty od 0 do 5: skan automatyczny. Uruchom WAVE (rozszerzenie przeglądarki) lub axe DevTools albo sekcję dostępności w Lighthouse. Napraw wyraźne błędy, jak brak alt, brak etykiet i niespełniony kontrast.
Minuty od 5 do 15: tylko klawiatura. Odłóż mysz. Przechodź po stronie klawiszem Tab od góry.
Czy przez cały czas widzisz, gdzie jest fokus?
Czy możesz otworzyć i zamknąć menu, użyć każdego pola formularza i wysłać?
Czy jest link „Przejdź do treści” i czy działa?
Czy fokus kiedykolwiek znika za przyklejonym nagłówkiem lub banerem?
Minuty od 15 do 25: czytnik ekranu. Użyj VoiceOver (wbudowany w macOS i iOS) lub NVDA (darmowy w Windows).
Posłuchaj listy nagłówków. Czy opisuje stronę?
Przejdź Tabem do obrazów i przycisków. Czy mają sens bez kontekstu?
Wypełnij formularz. Czy każde pole jest zapowiadane z etykietą? Czy błędy są zapowiadane?
Minuty od 25 do 30: powiększenie i zawijanie. Powiększ przeglądarkę do 200%, a potem 400%. Przy 400% treść powinna zawinąć się do jednej kolumny bez przewijania poziomego (1.4.10 Reflow), a nic nie powinno być ucięte.
Nakładanie się użyteczności i dostępności
Osoby szukające „użyteczność i dostępność stron” słusznie je grupują. Prawie każda poprawka dostępności jest poprawką użyteczności:
Poprawka dostępności
Komu jeszcze pomaga
Mocny kontrast
Każdemu na telefonie w słońcu
Widoczne etykiety
Każdemu wypełniającemu formularz w pośpiechu
Napisy
Osobom oglądającym bez dźwięku
Obsługa klawiatury
Zaawansowanym użytkownikom, osobom z zepsutym gładzikiem
Większe cele stuknięć
Wszystkim na urządzeniach mobilnych
Jasne komunikaty o błędach
Każdemu, kto się pomyli w pisowni
Nakładki, oświadczenia i prawo
Nakładki: widżety obiecujące zgodność jedną linią nie zmieniają kodu pod spodem. Napraw samą stronę.
Oświadczenie o dostępności: opublikuj krótką stronę mówiącą, jaki standard obierasz za cel, znane problemy i jak się z Tobą skontaktować po pomoc lub alternatywne formaty.
Kontekst prawny: wymagania różnią się w zależności od kraju. Europejski akt o dostępności obowiązuje dla wielu produktów i usług w UE od czerwca 2025; w USA ADA jest często stosowane do stron internetowych; instytucje sektora publicznego mają często specyficzne przepisy. Uzyskaj poradę prawną dla swojej sytuacji.
Lista kontrolna
[ ] Kontrast: 4.5:1 tekst, 3:1 duży tekst i elementy interfejsu
[ ] Tekst alternatywny na obrazach informacyjnych, pusty alt na ozdobnych
[ ] Każde pole ma widoczną, powiązaną etykietę
[ ] Cała strona działa z klawiatury z widocznym fokusem
[ ] Przyciski z ikoną mają dostępne nazwy
[ ] Logiczne nagłówki i punkty orientacyjne, ustawiony język strony
[ ] Cele stuknięć co najmniej 24 na 24 piksele CSS
[ ] Napisy w filmach, kontrola wstrzymania ruchu
[ ] Zawijanie przy powiększeniu 400%
[ ] Opublikowane oświadczenie o dostępności
Dostępność wspiera też wyszukiwanie: nagłówki, tekst alternatywny i opisowe linki to także podstawy SEO na stronie, omówione w naszej liście kontrolnej SEO na stronie.
We.Inc generuje strony jako standardowy kod HTML, CSS i React, który możesz edytować bezpośrednio, więc możesz sam poprawić etykiety, tekst alternatywny i kontrast albo poprosić o zmiany w czacie. Zawsze wykonuj powyższe kontrole ręczne na tym, co publikujesz.