Dostępność strony internetowej według WCAG 2.1 — przewodnik dla firm

Czym jest dostępność cyfrowa i dlaczego warto ją wdrożyć

Dostępność cyfrowa (ang. web accessibility, w skrócie a11y) to projektowanie stron internetowych w taki sposób, aby mogły z nich korzystać wszystkie osoby — niezależnie od ewentualnych niepełnosprawności, używanych urządzeń czy warunków, w jakich przeglądają internet.

WCAG (Web Content Accessibility Guidelines) to międzynarodowy standard opracowany przez organizację W3C, który definiuje zasady i kryteria dostępności. Aktualna wersja to WCAG 2.1 — obowiązująca jako punkt odniesienia dla wdrożeń w całej Europie.

Ważne: Wdrożenie WCAG nie jest obowiązkowe dla większości firm prywatnych. Przepisy prawne (m.in. Ustawa o dostępności cyfrowej) dotyczą przede wszystkim podmiotów publicznych. Jednak dostępność to nie kwestia prawna — to kwestia jakości produktu, doświadczenia użytkownika i skuteczności biznesowej.

Dostępność = więcej klientów, lepsza konwersja

Pomyśl o typowych sytuacjach, z jakimi mierzą się Twoi użytkownicy. Osoba starsza, która powiększa czcionkę w przeglądarce. Ktoś przeglądający stronę na telefonie podczas jazdy tramwajem — jedną ręką, jasne słońce za oknem. Użytkownik z czasowym urazem nadgarstka, który nie może użyć myszy. Każda z tych osób to potencjalny klient.

Przykład z życia: Użytkownik otwiera Twoją stronę na telefonie, stojąc na zewnątrz w słoneczny dzień. Ekran odbija światło. Jeśli tekst na stronie ma zbyt niski kontrast — np. jasnoszary na białym tle — użytkownik po prostu nie przeczyta oferty i zamknie kartę. Ten jeden błąd (kryterium WCAG 1.4.3 — Kontrast) może kosztować Cię dziesiątki klientów miesięcznie.

Badania pokazują, że dostępne strony mają:

• o 20–30% niższy wskaźnik odrzucenia (bounce rate),
• wyższą konwersję na urządzeniach mobilnych,
• lepsze oceny w Google PageSpeed i Core Web Vitals,
• większy zasięg — osoby z niepełnosprawnościami to ok. 15% populacji, plus ich rodziny i opiekunowie.

WCAG a SEO — Google również korzysta z dostępności

Robot Google nie widzi obrazków — czyta tekst alternatywny. Nie rozumie niejasnych linków — analizuje ich opisy. Nie interpretuje struktury wizualnej — czyta hierarchię nagłówków. Innymi słowy: wszystko, co sprawia, że strona jest dostępna dla człowieka z niepełnosprawnością wzroku, pomaga również robotowi Google zrozumieć i zaindeksować Twoje treści.

Przykład z życia: Strona bez hierarchii nagłówków (wszystkie treści oznaczone jako <p> lub <div>) wygląda tak samo wizualnie, ale dla robota Google to bezkształtna masa tekstu. Strona z prawidłową hierarchią H1 > H2 > H3 jest jak dobrze zatytułowana książka z rozdziałami — Google rozumie, co jest ważne, co jest podtematem i jak te treści powiązać z zapytaniami użytkowników. Wynik: lepsze pozycje w wyszukiwarce.

Cztery zasady POUR — fundament WCAG 2.1

Wszystkie kryteria WCAG 2.1 organizują się wokół czterech zasad, tworzących akronim POUR. To nie są techniczne wymagania — to filozofia projektowania. Jeśli Twoja strona spełnia te zasady, jest dostępna.

1. Postrzegalność (Perceivable)

Wszystkie informacje i elementy interfejsu muszą być prezentowane w taki sposób, aby użytkownik mógł je postrzec — co najmniej jednym ze swoich zmysłów.

Oznacza to w praktyce:

• każdy obraz ma tekst alternatywny (alt), który opisuje jego treść,
• filmy wideo mają napisy dla głuchych,
• treści nie są przekazywane wyłącznie przez kolor (np. „kliknij czerwony przycisk”),
• tekst ma odpowiedni kontrast względem tła.

Przykład z życia: Infografika przedstawiająca proces zamówienia nie ma tekstu alternatywnego. Osoba niewidoma używa czytnika ekranu (np. NVDA lub VoiceOver) — słyszy tylko „image.jpg”. Nie wie, co zawiera grafika, nie rozumie procesu, nie składa zamówienia. Rozwiązanie zajmuje 2 minuty: dodanie atrybutu alt z opisem infografiki.

2. Funkcjonalność (Operable)

Interfejs musi być możliwy do obsługi. Użytkownik musi móc nawigować i używać strony — także bez myszy, tylko za pomocą klawiatury lub innych urządzeń asystujących.

• cała nawigacja działa za pomocą klawiatury (Tab, Enter, strzałki),
• użytkownik ma wystarczająco dużo czasu na wypełnienie formularzy,
• strona nie zawiera elementów mogących wywołać atak epilepsji (migające treści >3 razy/s),
• każda podstrona ma unikalny, opisowy tytuł.

Przykład z życia: Rozwijane menu nawigacyjne działa tylko po najechaniu myszką (hover). Użytkownik poruszający się klawiaturą — np. osoba z drżeniem rąk, która nie może precyzyjnie kontrolować myszy — nie może w ogóle przejść do podstron. Utrata całej nawigacji to utrata całości serwisu. Rozwiązanie: obsługa menu również przez Tab i Enter.

3. Zrozumiałość (Understandable)

Treści i sposób działania interfejsu muszą być zrozumiałe. Język musi być jasny, zachowanie elementów przewidywalne, a błędy jasno komunikowane.

• język strony jest określony w kodzie HTML (atrybut lang),
• kliknięcie na element nie powoduje zaskakujących zmian kontekstu,
• formularze mają czytelne etykiety i komunikaty o błędach,
• błędy są opisywane słownie — nie tylko kolorem lub ikoną.

Przykład z życia: Formularz kontaktowy po błędnym wypełnieniu podświetla pola na czerwono — ale nie podaje żadnego komunikatu tekstowego. Użytkownik czytnika ekranu nie widzi koloru. Słyszy tylko: „Formularz nie został wysłany”. Nie wie, które pole jest błędne ani co poprawić. Opuszcza stronę. Rozwiązanie: komunikat tekstowy „Pole E-mail jest wymagane” przy każdym błędnym polu.

4. Solidność (Robust)

Treści muszą być na tyle solidnie zbudowane, aby można je było niezawodnie interpretować przez różne aplikacje użytkownika — w tym przez technologie asystujące.

• kod HTML jest poprawny i waliduje się,
• wszystkie elementy interfejsu mają prawidłowo ustawione role ARIA,
• status komponentów (zaznaczony, rozwinięty, wymagany) jest komunikowany programowo.

Przykład z życia: Slider produktów zbudowany w JavaScript nie ma żadnych atrybutów ARIA. Wizualnie wygląda świetnie. Ale czytnik ekranu „widzi” tylko kilka anonimowych divów. Użytkownik nie wie, że to jest carousel, ile ma slajdów ani jak je przewijać. Dodanie aria-label, aria-live i role="region" rozwiązuje problem bez zmiany wyglądu strony.

Kryteria sukcesu WCAG 2.1 — poziom A

Poziom A to absolutne minimum dostępności. Strona, która nie spełnia kryteriów poziomu A, jest niedostępna w fundamentalny sposób — część użytkowników nie będzie mogła z niej korzystać w ogóle. Poniżej omówione są wszystkie 30 kryteriów poziomu A.

1.1 Alternatywy tekstowe

1.1.1 Treść nietekstowa

Każdy element nietekstowy (obraz, ikona, przycisk graficzny, CAPTCHA, wykres) musi posiadać tekstową alternatywę, która przekazuje tę samą informację.

• Obrazy dekoracyjne: atrybut alt="" (pusty, nie brak atrybutu)
• Obrazy informacyjne: alt z opisem treści obrazu
• Przyciski z ikonami: aria-label z opisem akcji
• CAPTCHA: alternatywna forma weryfikacji (np. audio)

Dlaczego to ważne dla biznesu: Google Images indeksuje obrazy na podstawie atrybutu alt. Poprawne opisy obrazów to dodatkowy kanał pozyskania ruchu organicznego — szczególnie dla sklepów internetowych ze zdjęciami produktów.

1.2 Media oparte na czasie

1.2.1 Tylko audio i tylko wideo (nagrania)

Nagrania audio (np. podcast) muszą mieć transkrypcję tekstową. Nagrania wideo bez dźwięku (np. animacje instruktażowe) muszą mieć alternatywę tekstową lub ścieżkę audio.

1.2.2 Napisy rozszerzone (nagrania)

Wszystkie nagrania wideo z dźwiękiem muszą zawierać napisy rozszerzone — synchroniczne z obrazem, obejmujące nie tylko dialogi, ale także ważne dźwięki (np. „[dzwonek telefonu]”).

Przykład z życia: Film instruktażowy na stronie produktu bez napisów — użytkownik w otwartym biurze nie może go oglądać z głośnikami. Nie włącza słuchawek. Zamyka film. Napisy rozwiązują problem i zwiększają czas spędzony na stronie.

1.2.3 Audiodeskrypcja lub alternatywa medialna (nagrania)

Nagrania wideo muszą zawierać audiodeskrypcję (opis na głos tego, co widać na ekranie) LUB pełną alternatywę tekstową prezentującą tę samą informację.

1.3 Możliwość adaptacji

1.3.1 Informacje i relacje

Informacje przekazywane za pomocą formatowania wizualnego (np. nagłówki, listy, tabele) muszą być również zakodowane w HTML tak, aby technologie asystujące mogły je odczytać.

• Nagłówki: znaczniki H1–H6, nie „pogrubiony, większy tekst”
• Listy: znaczniki <ul>/<ol>/<li>, nie myślniki wstawiane ręcznie
• Tabele danych: znaczniki <table> z <th> dla nagłówków
• Formularze: <label> powiązane z <input>

Dlaczego to ważne dla SEO: Hierarchia nagłówków H1 > H2 > H3 jest jednym z sygnałów rankingowych Google. Strona z prawidłową strukturą nagłówków jest lepiej zrozumiana przez robota indeksującego, co przekłada się na trafniejsze dopasowanie do zapytań i wyższe pozycje.

1.3.2 Znacząca kolejność

Jeśli kolejność treści ma znaczenie dla jej zrozumienia, ta kolejność musi być zachowana również w kodzie HTML — niezależnie od układów CSS czy kolumn wizualnych.

1.3.3 Właściwości zmysłowe

Instrukcje nie mogą opierać się wyłącznie na cechach zmysłowych jak kształt, kolor, rozmiar czy położenie. Nie „kliknij zielony przycisk” — ale „kliknij przycisk Wyślij zamówienie„.

1.4 Rozróżnianie

1.4.1 Użycie koloru

Kolor nie może być jedynym sposobem przekazywania informacji. Jeśli komunikujesz błąd czerwonym polem — dodaj również tekst lub ikonę.

1.4.2 Kontrola dźwięku

Jeśli na stronie automatycznie odtwarza się dźwięk dłuższy niż 3 sekundy, użytkownik musi móc go wyciszyć lub zatrzymać.

2.1 Dostępność z klawiatury

2.1.1 Klawiatura

Cała funkcjonalność strony musi być dostępna z poziomu klawiatury. Bez wyjątków — chyba że dana funkcja wymaga fizycznie ruchów gestami (np. rysowanie).

Przykład z życia: Serwis z rezerwacjami hotelowymi używający kalendarza wyboru daty, który działa tylko myszką. Użytkownik bez myszy (np. korzystający z urządzenia z ekranem dotykowym lub czytnika ekranu) nie może wybrać daty i nie może dokonać rezerwacji. Rozwiązanie: obsługa klawiatury w komponencie kalendarza.

2.1.2 Brak pułapki klawiatury

Jeśli fokus klawiatury wchodzi do komponentu (np. modal, widget), musi też umieć z niego wyjść za pomocą klawiatury — bez konieczności użycia myszy.

2.2 Wystarczający czas

2.2.1 Możliwość regulacji czasu

Jeśli strona zawiera limity czasowe (np. sesja koszyka zakupowego, formularz z odliczaniem), użytkownik musi móc wyłączyć ten limit, dostosować go lub przynajmniej trzykrotnie przedłużyć.

2.2.2 Pauza, zatrzymanie, ukrycie

Treści, które się poruszają, migają lub automatycznie się aktualizują i trwają dłużej niż 5 sekund, muszą zawierać mechanizm pauzy lub zatrzymania.

2.3 Napady padaczkowe

2.3.1 Trzy błyski lub poniżej progu

Strona nie może zawierać elementów migających więcej niż 3 razy na sekundę. To kryterium dotyczy głównie wideo, animacji i reklam.

2.4 Nawigacja

2.4.1 Pomijanie bloków

Musi istnieć mechanizm pozwalający pominąć powtarzające się bloki treści (np. nagłówek, menu). Najczęściej realizowany jako niewidoczny link „Przejdź do treści” na początku strony.

2.4.2 Tytuły stron

Każda podstrona musi mieć unikalny, opisowy tytuł w tagu <title>. Nie „Strona główna” na każdej podstronie — ale „Kontakt — Nazwa firmy”, „Oferta SEO — Nazwa firmy” itd.

Dlaczego to ważne dla SEO: Tag <title> jest jednym z najważniejszych czynników rankingowych. Unikalny, opisowy tytuł na każdej podstronie zwiększa szanse na właściwe zaindeksowanie i dopasowanie do konkretnych fraz kluczowych.

2.4.3 Kolejność fokusa

Kolejność, w jakiej elementy strony otrzymują fokus klawiatury (Tab), musi być logiczna i zgodna z wizualną kolejnością treści.

2.4.4 Cel linku (w kontekście)

Każdy link musi być zrozumiały z jego treści lub z otaczającego kontekstu. „Kliknij tutaj” i „Więcej” to złe praktyki — bo co znaczą poza kontekstem? Lepiej: „Przeczytaj pełny artykuł o pozycjonowaniu lokalnym”.

Przykład z życia: Strona z listą produktów zawiera dwadzieścia linków z tekstem „Sprawdź ofertę”. Użytkownik czytnika ekranu może przeglądać listę linków na stronie — i słyszy dwadzieścia identycznych „Sprawdź ofertę”. Nie wie, do którego produktu każdy link prowadzi. Rozwiązanie: „Sprawdź ofertę — Laptop Dell XPS 15”.

2.5 Metody wejścia (nowe w WCAG 2.1)

2.5.1 Gesty wskaźnikowe

Funkcje, które wymagają gestów wielopunktowych (np. pinch-to-zoom, przeciąganie) lub gestów po ścieżce (np. swipe), muszą mieć alternatywne sterowanie jednopunktowe.

2.5.2 Anulowanie wskaźnika

Akcje wywoływane kliknięciem nie powinny być uruchamiane przy naciśnięciu przycisku (mousedown/touchstart), lecz dopiero przy jego zwolnieniu (mouseup/touchend). Dzięki temu użytkownik może zrezygnować z akcji przesuwając palec lub kursor poza element.

2.5.3 Etykieta w nazwie

Jeżeli element interfejsu ma widoczną etykietę tekstową (np. przycisk z napisem „Wyślij”), to ta sama etykieta musi być również w dostępnej nazwie elementu (np. w atrybucie aria-label lub aria-labelledby).

2.5.4 Aktywowanie ruchem

Funkcje uruchamiane ruchem urządzenia (np. potrząśnięcie telefonem) muszą mieć również alternatywę interfejsową. Użytkownik musi też móc wyłączyć reakcję na ruch.

3.1 Czytelność

3.1.1 Język strony

Język główny strony musi być określony w atrybucie lang znacznika <html>. Na przykład: <html lang="pl"> dla strony polskiej. To pozwala czytnikowi ekranu używać właściwej syntezy mowy.

3.2 Przewidywalność

3.2.1 Po fokusie

Samo przeniesienie fokusa na element nie powinno wywoływać żadnych znaczących zmian kontekstu (np. nie może automatycznie otworzyć okna dialogowego).

3.2.2 Po wprowadzeniu danych

Zmiana ustawień komponentu (np. wybór opcji z listy rozwijanej) nie powinna automatycznie wywoływać akcji bez wiedzy użytkownika — chyba że został o tym poinformowany.

3.3 Pomoc przy wprowadzaniu danych

3.3.1 Identyfikacja błędu

Jeśli błąd zostanie automatycznie wykryty, element, w którym wystąpił, musi być zidentyfikowany, a opis błędu dostarczony użytkownikowi w formie tekstowej.

3.3.2 Etykiety lub instrukcje

Jeśli treści wymagają wprowadzenia danych przez użytkownika (formularze), muszą być dostarczone etykiety lub instrukcje.

4.1 Kompatybilność

4.1.1 Parsowanie

Kod HTML musi być poprawnie zbudowany: elementy mają poprawnie zagnieżdżone znaczniki i nie ma zduplikowanych atrybutów id. Dostępny walidator: validator.w3.org.

4.1.2 Nazwa, rola, wartość

Wszystkie komponenty interfejsu (formularze, linki, przyciski, widgety) muszą mieć programowo określoną nazwę (co to jest), rolę (jakim jest elementem) i wartość (jaki jest jej stan). Realizowane przez semantyczny HTML lub atrybuty ARIA.

Kryteria sukcesu WCAG 2.1 — poziom AA

Poziom AA to zalecany minimalny standard dla stron komercyjnych. Strony spełniające AA są dostępne dla zdecydowanej większości użytkowników z niepełnosprawnościami. Przepisy dla podmiotów publicznych również wymagają osiągnięcia poziomu AA.

1.2 Media oparte na czasie — AA

1.2.4 Napisy rozszerzone (na żywo)

Transmisje na żywo z dźwiękiem muszą mieć napisy w czasie rzeczywistym. Dotyczy webinarów i transmisji live na stronie firmowej.

1.2.5 Audiodeskrypcja (nagrania)

Nagrania wideo muszą zawierać audiodeskrypcję wszystkich ważnych informacji wizualnych, które nie są opisane w samej ścieżce dźwiękowej.

1.3 Możliwość adaptacji — AA

1.3.4 Orientacja (nowe w WCAG 2.1)

Treść nie może być ograniczona do jednej orientacji ekranu (pionowej lub poziomej), chyba że konkretna orientacja jest niezbędna (np. aplikacja do gry na fortepianie).

Przykład z życia: Formularz kontaktowy na stronie mobilnej zablokowany w orientacji pionowej. Użytkownik obraca telefon poziomo — formularz pozostaje pionowy i część jest połowicznie niewidoczna. Rozwiązanie: usunięcie blokady orientacji w CSS/JavaScript.

1.3.5 Określenie oczekiwanej wartości (nowe w WCAG 2.1)

Pola formularzy zbierające dane osobowe muszą mieć atrybut autocomplete z prawidłową wartością (np. autocomplete="email", autocomplete="given-name"). Pozwala to przeglądarkom i narzędziom asystującym na autouzupełnianie danych.

1.4 Rozróżnianie — AA

1.4.3 Kontrast (minimalny)

Współczynnik kontrastu pomiędzy tekstem a tłem musi wynosić co najmniej 4,5:1 dla normalnego tekstu i 3:1 dla dużego tekstu (18pt lub 14pt pogrubiony). To jedno z najczęściej naruszanych kryteriów.

Przykład z życia — telefon w słońcu: Użytkownik stoi na przystanku, kieszeń od słońca. Jego telefon ma ekran ze współczynnikiem kontrastu ok. 300:1 w ciemności — ale słońce znacząco obniża postrzegany kontrast. Jasnoniebieskie litery na białym tle (kontrast 2,5:1 w warunkach laboratoryjnych) stają się zupełnie nieczytelne. Zmiana na ciemnoniebieskie litery na białym tle (kontrast 8:1) rozwiązuje problem w każdych warunkach oświetlenia. Bezpośredni wpływ na wskaźnik odczytu oferty i konwersję mobilną.

1.4.4 Zmiana rozmiaru tekstu

Tekst musi dać się powiększyć do 200% bez utraty treści lub funkcjonalności — i bez konieczności przewijania w poziomie.

1.4.5 Tekst w postaci obrazu

Do przekazywania informacji należy używać prawdziwego tekstu, a nie tekstu umieszczonego w obrazach — z wyjątkiem logo i elementów, w których konkretna prezentacja graficzna jest niezbędna.

1.4.10 Dopasowanie do okna — Reflow (nowe w WCAG 2.1)

Treści muszą być dostępne przy szerokości ekranu 320px CSS (odpowiednik telefonu 400px przy zoomie 400%) bez konieczności przewijania w dwóch wymiarach jednocześnie. Czyli: strona musi być w pełni responsywna.

Dlaczego to ważne: Google od 2021 roku stosuje Mobile-First Indexing. Strona niespełniająca kryterium Reflow praktycznie nie istnieje dla użytkowników mobilnych — a to ponad połowa ruchu w internecie. Kryterium dostępności = kryterium SEO = kryterium biznesowe.

1.4.11 Kontrast elementów nietekstowych (nowe w WCAG 2.1)

Elementy interfejsu (przyciski, pola formularza, ikony) oraz elementy graficzne (wykresy, schematy) muszą mieć kontrast co najmniej 3:1 względem otaczających kolorów.

1.4.12 Odstępy w tekście (nowe w WCAG 2.1)

Strona musi działać poprawnie, gdy użytkownik ustawia własne odstępy: wysokość linii 1,5× wielkość czcionki, odstęp po akapitach 2×, odstęp między literami 0,12×, odstęp między słowami 0,16×. Treści nie mogą się na siebie nakładać ani być odcięte.

1.4.13 Treści przy najechaniu lub fokusie (nowe w WCAG 2.1)

Treści pojawiające się po najechaniu myszką lub przeniesieniu fokusa (np. tooltipy, rozwijane menu) muszą być: odwracalne (można je zamknąć bez przesuwania fokusa), trwałe (nie znikają natychmiast gdy kursor opuści element wywołujący) i widoczne (nie są zasłaniane przez inne elementy).

2.4 Nawigacja — AA

2.4.5 Wiele sposobów

Musi istnieć więcej niż jeden sposób dotarcia do każdej podstrony — np. menu nawigacyjne + mapa strony, lub menu + wyszukiwarka.

2.4.6 Nagłówki i etykiety

Nagłówki i etykiety formularzy muszą opisywać temat lub cel. Nagłówek „Rozdział 3” jest niezgodny. Nagłówek „Kryteria sukcesu poziomu AA” jest zgodny.

Przykład z życia — hierarchia nagłówków: Blog firmowy z artykułami, gdzie każdy artykuł ma H1 jako tytuł, ale środkowe nagłówki są oznaczone przez CSS jako większy pogrubiony tekst bez znaczników H2/H3. Robot Google skanuje stronę i nie rozumie struktury — traktuje cały artykuł jako jednorodną masę tekstu. Poprawne tagowanie nagłówków przekłada treści na konkretne frazy kluczowe, co poprawia widoczność w wyszukiwarce.

2.4.7 Widoczność fokusa

Każdy element, który może otrzymać fokus klawiatury, musi mieć widoczny wskaźnik fokusa — np. obramowanie, podświetlenie. Nie można usuwać outline bez zapewnienia alternatywy.

3.1 Czytelność — AA

3.1.2 Język części

Fragmenty strony w innym języku muszą być oznaczone atrybutem lang na danym elemencie HTML (np. <span lang="en">Web accessibility</span>). Pozwala to czytnikowi ekranu prawidłowo wymawiać słowa w obcym języku.

3.2 Przewidywalność — AA

3.2.3 Spójność nawigacji

Elementy nawigacji powtarzające się na wielu stronach muszą mieć tę samą kolejność na każdej stronie.

3.2.4 Spójność identyfikacji

Komponenty o tej samej funkcjonalności muszą być identyfikowane konsekwentnie — ta sama ikona, ta sama etykieta.

3.3 Pomoc przy wprowadzaniu danych — AA

3.3.3 Sugestia korekty błędu

Jeśli błąd zostanie wykryty i znane są sugestie poprawek, muszą być dostarczone użytkownikowi — chyba że zagrozi to bezpieczeństwu lub celowi formularza.

3.3.4 Zapobieganie błędom

W formularzach z ważnym skutkiem prawnym lub finansowym (zakup, umowa) użytkownik musi móc: sprawdzić dane przed wysyłką, poprawić je lub anulować.

4.1 Kompatybilność — AA

4.1.3 Komunikaty o stanie (nowe w WCAG 2.1)

Komunikaty o stanie (np. „Produkt dodany do koszyka”, „Formularz wysłany”, „Trwa ładowanie”) muszą być programowo możliwe do określenia bez przenoszenia fokusa — za pomocą atrybutów role="status", role="alert" lub aria-live.

Tabela zbiorcza kryteriów WCAG 2.1 — poziomy A i AA

Poniżej zestawiono wszystkie kryteria w jednej tabeli — jako szybki punkt odniesienia podczas audytu lub wdrożenia.

Narzędzia do testowania dostępności

Testowanie dostępności składa się z dwóch części: automatycznej (narzędzia wykrywają ok. 30–40% problemów) i manualnej (reszta wymaga oceny człowieka lub użytkownika technologii asystujących).

Narzędzia automatyczne

axe DevTools

Rozszerzenie do przeglądarki (Chrome/Firefox) od Deque Systems. Skanuje aktualną stronę i raportuje naruszenia WCAG z opisem, porażonym elementem i sugestią naprawy. Bezpłatna wersja obejmuje ok. 50 testów.

Google Lighthouse

Wbudowany w Chrome DevTools. Sekcja Accessibility pokazuje wynik od 0 do 100 i listę konkretnych problemów. Przydatne jako szybki przegląd przed audytem.

WAVE (WebAIM)

wave.webaim.org — nakładka wizualna na stronę, pokazująca błędy i ostrzeżenia bezpośrednio na podglądzie strony. Intuicyjny dla osób bez wiedzy technicznej.

Sprawdzarka kontrastu

contrastchecker.com lub WebAIM Contrast Checker — narzędzia do weryfikacji współczynnika kontrastu między dwoma kolorami. Przydatne podczas projektowania.

Testowanie manualne

Nawigacja klawiaturą

Odłóż mysz i spróbuj przejść przez całą stronę tylko klawiszami Tab, Shift+Tab, Enter, Space i strzałkami. Sprawdź: czy widzisz gdzie jest fokus, czy możesz dostać się do wszystkich elementów, czy nie ugrzęzłeś w żadnym miejscu.

Czytnik ekranu

NVDA (Windows, bezpłatny), VoiceOver (macOS/iOS, wbudowany), TalkBack (Android, wbudowany). Uruchom i spróbuj nawigować przez stronę tylko słuchając — bez patrzenia na ekran. To najbardziej miarodajny test dostępności.

Powiększenie do 200%

Ustaw zoom przeglądarki na 200% i sprawdź, czy strona nie traci treści, czy tekst nie jest obcięty i czy nie pojawia się poziomy pasek przewijania.

FAQ — najczęściej zadawane pytania o WCAG 2.1

Czy WCAG 2.1 obowiązuje firmy prywatne w Polsce?

Przepisy prawne (Ustawa o dostępności cyfrowej z 2019 roku) nakładają obowiązkową dostępność przede wszystkim na podmioty publiczne: urzędy, szkoły, szpitale. Firmy prywatne nie mają obowiązku prawnego. Jednak wdrożenie WCAG przynosi wymierne korzyści biznesowe: szersza grupa odbiorców, lepsze SEO, wyższa konwersja na mobile — dlatego jest warte wdrożenia również bez przymusu prawnego.

Jaka jest różnica między WCAG 2.1 a WCAG 2.2?

WCAG 2.2 (opublikowane w październiku 2023) dodaje 9 nowych kryteriów, skupionych głównie na użytkownikach z trudnościami poznawczymi i motorycznymi. Wszystkie kryteria z 2.1 pozostają w mocy. Dla większości firm wdrożenie 2.1 AA jest aktualnym, wystarczającym standardem.

Ile kosztuje wdrożenie dostępności WCAG?

To zależy od stanu wyjściowego strony. Nowa strona projektowana z myślą o dostępności od początku — niemal bez kosztów dodatkowych. Istniejąca strona z wieloma problemami — od kilku do kilkudziesięciu godzin pracy dewelopera. Najtańszy moment na wdrożenie dostępności to etap projektowania, nie po wdrożeniu.

Czy WordPress/WooCommerce wspiera WCAG?

WordPress jako CMS dostarcza narzędzia do budowania dostępnych stron, ale sam rdzeń nie gwarantuje zgodności z WCAG. Wiele popularnych motywów i wtyczek ma poważne problemy dostępności. Zgodność zależy od wyboru motywu, wtyczek i od sposobu redagowania treści. Zalecane: wybór motywów z certyfikatem dostępności i regularne testy narzędziem axe.

Jak sprawdzić, czy moja strona jest dostępna?

Zacznij od automatycznego testu: zainstaluj rozszerzenie axe DevTools lub użyj WAVE (wave.webaim.org). Dostaniesz listę konkretnych problemów z opisem. Następnie przeprowadź test manualny: przejdź przez stronę wyłącznie klawiaturą. Na koniec — jeśli to możliwe — przeprowadź testy z prawdziwymi użytkownikami korzystającymi z technologii asystujących.

Dokument przygotowany na podstawie: Web Content Accessibility Guidelines (WCAG) 2.1, W3C Recommendation 05 June 2018. https://www.w3.org/TR/WCAG21/