Dostępność strony internetowej oznacza, że treść i funkcje można postrzegać, rozumieć oraz obsługiwać na różne sposoby: klawiaturą, czytnikiem ekranu, przy powiększeniu, na małym ekranie i bez polegania wyłącznie na kolorze, dźwięku lub precyzyjnym ruchu. WCAG 2.2 daje kryteria testowe, ale zgodność wymaga procesu, nie pojedynczej wtyczki.
Zacznij od zadań użytkownika, popraw semantykę, klawiaturę, fokus, kontrast, formularze, alternatywy dla mediów i zachowanie przy powiększeniu. Automatyczny skaner wykryje część błędów, lecz potrzebne są testy ręczne i redakcyjne. Ten poradnik opisuje praktykę techniczną, a nie rozstrzyga obowiązków prawnych konkretnej organizacji.
Ustal, które zadania i treści mają najwyższe ryzyko
Nie zaczynaj od listy przypadkowych kolorów. Spisz kluczowe ścieżki: znalezienie informacji, wybór produktu, wysłanie formularza, rezerwacja, płatność, pobranie dokumentu, zmiana ustawień i kontakt. Dostępność całego procesu jest ważniejsza niż idealny wynik pojedynczej strony, która nie prowadzi do wykonania zadania.
WCAG porządkuje wymagania według czterech zasad: treść ma być postrzegalna, funkcjonalna, zrozumiała i solidna technicznie. Poziomy zgodności nie są oceną estetyczną. Spełnienie kryterium oznacza konkretny stan komponentu lub treści, ale nie gwarantuje, że cała usługa jest wygodna dla każdej osoby.
| Obszar | Ryzyko | Pierwszy test |
|---|---|---|
| Nawigacja | Brak dostępu do działów bez myszy | Przejdź całość Tabem i Escape |
| Formularz | Brak etykiet lub niezrozumiały błąd | Wyślij pusty i błędnie wypełniony formularz |
| Zakup/rezerwacja | Przerwanie procesu na jednym kroku | Wykonaj pełne zadanie klawiaturą |
| Dokumenty | Skan bez tekstu i struktury | Wyszukaj tekst i sprawdź kolejność odczytu |
| Treść | Brak hierarchii i niejasne linki | Przejdź po nagłówkach i linkach |
| Mobile | Ucięcie treści po powiększeniu | 400% zoom lub szerokość 320 CSS px |
Wysoki priorytet mają strony dotyczące zdrowia, bezpieczeństwa, finansów, spraw publicznych i terminowych procedur, ponieważ błąd może uniemożliwić wykonanie ważnej czynności. Serwis opisujący dofinansowanie ZUS na poprawę warunków BHP jest przykładem miejsca, w którym czytelne terminy, etapy i wymagane dokumenty mają znaczenie dla przedsiębiorcy. Link ilustruje kontekst informacji proceduralnej, nie ocenę zgodności strony.
Obowiązki prawne zależą od rodzaju podmiotu, usługi i aktualnych przepisów. Audyt techniczny nie zastępuje analizy prawnej. W projekcie zapisz osobno: docelowy standard, zakres badanych stron, kryteria, metody testu i dowody. Nie deklaruj zgodności całego serwisu na podstawie strony głównej.
Dostępność warto włączyć już do briefu, makiet i kryteriów odbioru. Naprawa gotowego komponentu może wymagać zmiany biblioteki, HTML i zachowania, nie tylko CSS. Proces planowania zakresu opisuje poradnik o briefie na stronę internetową.
Semantyczna treść daje strukturę, której nie zastąpi wygląd
Każda strona potrzebuje opisowego tytułu dokumentu, jednego głównego H1 i logicznych nagłówków kolejnych sekcji. Nie wybieraj poziomu nagłówka według rozmiaru czcionki. H3 powinien należeć do wcześniejszego H2. Osoba korzystająca z czytnika może nawigować po nagłówkach, więc muszą streszczać temat sekcji.
Akapit powinien zawierać jedną myśl, a ważna informacja pojawiać się wcześnie. Instrukcje zapisuj krokami, gdy kolejność ma znaczenie. Listy twórz jako listy, a tabele tylko dla danych mających relacje wierszy i kolumn. Układu wizualnego nie buduj tabelą.
Tekst linku powinien wyjaśniać cel w swoim kontekście. Seria „więcej”, „zobacz” i „kliknij tutaj” utrudnia przegląd listy linków. Nazwij dokument, usługę lub dział. Jeśli link prowadzi do pliku, podaj format i rozmiar. Jeżeli otwiera nową kartę, nie zaskakuj użytkownika.
- Język dokumentu i fragmentów obcojęzycznych jest oznaczony.
- H1 i kolejne nagłówki tworzą logiczny konspekt.
- Listy i tabele mają semantyczną strukturę.
- Linki są zrozumiałe z otaczającym kontekstem.
- Informacja nie zależy wyłącznie od koloru, położenia lub kształtu.
- Skróty, terminy i instrukcje są wyjaśnione na poziomie odbiorcy.
Prosty język nie oznacza usuwania terminów fachowych. Wyjaśnij pojęcie przy pierwszym użyciu, dodaj przykład i zachowaj spójne nazewnictwo. W komunikacie proceduralnym podaj najpierw czynność, termin i osobę, której dotyczy informacja. Ogólne wprowadzenie może pojawić się dalej.
Dynamicznie wstawiana treść również musi mieć strukturę. Akordeon potrzebuje nagłówka i przycisku, modal — nazwy oraz sposobu zamknięcia, a komunikat statusu — właściwego mechanizmu ogłaszania. Nie naprawiaj braku semantyki wieloma atrybutami ARIA, jeśli można użyć natywnego elementu HTML.
Dobre pisanie dla czytelnika i dostępność wzajemnie się wspierają. Zasady naturalnej, konkretnej treści rozwija poradnik o pisaniu uporządkowanego artykułu, choć oznaczenie współpracy i cel tekstu wymagają osobnej decyzji.
Każdą funkcję obsłuż klawiaturą i pokaż widoczny fokus
Przejdź stronę klawiszem Tab od początku do końca. Kolejność fokusu powinna odpowiadać kolejności czytania i działania. Każdy aktywny element musi mieć widoczny stan. Fokus nie może znikać pod stałym nagłówkiem, banerem cookies ani dolnym paskiem. Po zamknięciu okna powinien wrócić do elementu, który je otworzył.
Link służy do przejścia pod adres, a przycisk do wykonania działania. Klikalny div bez roli, nazwy i obsługi klawiatury jest trudny do użycia. Natywne elementy zapewniają podstawowe zachowanie i są bardziej odporne na różne technologie wspomagające.
Menu rozwijane, zakładki, akordeony, dialogi i karuzele mają różne wzorce sterowania. Nie dodawaj strzałek i klawiszy losowo. Wybierz rozpoznawalny model, opisz stany i przetestuj go. Karuzela automatyczna potrzebuje możliwości zatrzymania, a jej kontrolki nie mogą znikać przed użytkownikiem klawiatury.
Gest przeciągania powinien mieć prostą alternatywę, na przykład przyciski. Małe cele dotykowe utrudniają obsługę osobom z ograniczoną precyzją i każdemu w ruchu. Zapewnij właściwy rozmiar oraz odstęp. Nie umieszczaj dwóch przeciwstawnych działań obok siebie bez wyraźnego rozróżnienia.
Usuwanie obrysu bez równoważnego, czytelnego stylu pozbawia użytkownika informacji o miejscu. Stan powinien być widoczny na każdym tle, także w ciemnej stopce, menu i modalach.
Kompleksową nawigację warto sprawdzić zgodnie z poradnikiem o menu na stronie internetowej. Dostępność nie jest dodatkiem do gotowego menu; wynika z jego HTML i logiki stanów.
Formularz ma prowadzić do poprawy błędu i potwierdzać wynik
Każde pole potrzebuje trwałej etykiety opisującej oczekiwaną wartość. Placeholder może pokazać przykład, ale nie zastępuje etykiety. Pola wymagane oznacz tekstem i odpowiednią semantyką. Instrukcja formatu powinna pojawić się przed wysłaniem, szczególnie dla daty, telefonu, hasła i załącznika.
Po błędzie pokaż podsumowanie oraz komunikat przy konkretnym polu. Wyjaśnij, co jest niepoprawne i jak to naprawić. Sam czerwony obrys nie wystarczy. Fokus może przejść do podsumowania lub pierwszego błędu, ale zmiana musi być przewidywalna i dostępna dla czytnika ekranu.
Grupy opcji wymagają wspólnej legendy, a powiązane pola logicznej kolejności. Nie zmieniaj kontekstu natychmiast po wyborze wartości bez ostrzeżenia. Jeśli wybór otwiera kolejne pytania, ogłoś zmianę i zachowaj fokus. Formularz wieloetapowy powinien pokazywać postęp, możliwość powrotu i podsumowanie przed wysłaniem.
- Etykieta pozostaje widoczna po wpisaniu tekstu.
- Instrukcje i błędy są programowo powiązane z polem.
- Kolejność Tab odpowiada kolejności wizualnej.
- Limit czasu można przedłużyć albo jasno uzasadnić.
- CAPTCHA ma dostępną alternatywę i nie blokuje procesu.
- Potwierdzenie rozróżnia wysłanie, przyjęcie i wykonanie usługi.
Walidacja w przeglądarce pomaga, ale serwer nadal musi sprawdzać dane. Komunikat techniczny nie powinien ujawniać szczegółów systemu. Przy załączniku podaj formaty, limit rozmiaru i stan przesyłania. Błąd sieci nie może usuwać całej treści formularza, jeśli można ją zachować bezpiecznie.
Zgoda powinna opisywać konkretny cel i nie być domyślnie zaznaczona tam, gdzie wymagana jest aktywna decyzja. Nie łącz zgody niezbędnej do obsługi zapytania z marketingiem w jednym polu. Szczegóły przepływu kontaktu rozwija poradnik o formularzu kontaktowym w WordPressie.
Testuj formularz z błędami, pustymi polami, długimi danymi, znakami diakrytycznymi, powiększeniem i klawiaturą. Pomyślne wysłanie jest częścią testu dostępności, nie osobną kwestią techniczną.
Obrazy, multimedia i układ muszą zachować informację
Tekst alternatywny opisuje funkcję obrazu w konkretnym kontekście. Zdjęcie dekoracyjne może mieć pusty alt, a wykres potrzebuje krótkiej alternatywy i dostępu do danych lub szerszego opisu. Nie wpisuj „obrazek” ani nie kopiuj nazwy pliku. Jeśli grafika zawiera kluczowy tekst, najlepiej przenieść go do HTML.
Film z mową potrzebuje napisów, a istotna informacja wizualna może wymagać audiodeskrypcji lub odpowiednika tekstowego. Nagranie audio potrzebuje transkrypcji. Odtwarzacz musi działać klawiaturą, mieć widoczny fokus i czytelne etykiety. Nie uruchamiaj dźwięku automatycznie.
Przy powiększeniu tekstu do 200% treść i funkcje powinny pozostać dostępne. Reflow sprawdzaj przy wąskim widoku odpowiadającym 320 pikselom CSS. Wyjątki dotyczą elementów wymagających układu dwuwymiarowego, ale zwykły artykuł, formularz i karta produktu nie powinny wymuszać przewijania w dwóch kierunkach.
Kolor nie może być jedynym nośnikiem stanu. Błąd potrzebuje ikony lub tekstu, wybrana opcja znacznika, a wykres etykiety lub wzoru. Kontrast sprawdzaj dla tekstu, ikon i kontrolek w każdym stanie: spoczynku, hover, fokus, aktywny, błąd i disabled.
Animacje i przejścia powinny respektować preferencję ograniczenia ruchu. Nie używaj migania ani automatycznego przesuwania bez kontroli. Efekt 3D nie może być jedynym sposobem przekazania wartości lub wykonania czynności. Statyczna alternatywa często poprawia również wydajność.
Zdjęcia trzeba optymalizować bez usuwania potrzebnej jakości. Rozmiar pliku i dostępność to różne warstwy, które powinny działać razem. Proces formatów, wymiarów i LCP opisuje poradnik o optymalizacji zdjęć na stronie.
Połącz automat, test ręczny i odpowiedzialność redakcyjną
Skaner automatyczny wykryje część problemów: brakujące nazwy, niektóre kontrasty, błędy struktury i atrybutów. Nie oceni sensu tekstu alternatywnego, logicznej kolejności, zrozumiałości komunikatu ani pełnego zadania. Traktuj go jako alarm i regresję, nie certyfikat.
Ręczny audyt obejmuje klawiaturę, fokus, powiększenie, reflow, czytnik ekranu, formularze, multimedia i reprezentatywne szablony. W serwisie z CMS-em zbadaj stronę główną, kategorię, artykuł, produkt, wyszukiwarkę, formularz, dokument i błąd 404. Następnie sprawdź próbkę treści redakcyjnych.
Każdy błąd powinien mieć stronę, kryterium, opis reprodukcji, wpływ, dowód i rekomendowany sposób naprawy. Priorytet wynika z blokady zadania, liczby miejsc i znaczenia procesu. Kolor o minimalnie zbyt niskim kontraście oraz brak możliwości wysłania formularza nie mają tej samej pilności.
Redaktorzy potrzebują instrukcji dotyczącej nagłówków, linków, altów, tabel, dokumentów i multimediów. System może zapobiegać części błędów przez odpowiednie pola i komponenty. Nie przerzucaj całej odpowiedzialności na osobę publikującą, jeśli CMS zachęca do złych praktyk.
Po wdrożeniu trzeba obejrzeć rzeczywisty render na desktopie i mobile. Wynik techniczny oddziel od wizualnego. Poprawny kontrast liczbowy nie gwarantuje dobrej hierarchii, a brak overflow nie oznacza, że ekran jest czytelny. Status zgodności powinien opisywać zakres i datę badania.
Strona przechodzi odbiór dostępności, gdy kluczowe zadania można wykonać klawiaturą i przy powiększeniu, treść ma poprawną strukturę, formularze prowadzą przez błędy, media mają alternatywy, a dowody z testów automatycznych i ręcznych są zapisane dla reprezentatywnych szablonów.