Jak zrobić dostępną stronę internetową: przewodnik startowy po WCAG 2.2

Aby zrobić dostępną stronę internetową, zbuduj ją tak, by można było z niej korzystać klawiaturą, czytnikiem ekranu, powiększeniem lub urządzeniem przełączającym, a nie tylko myszą: używaj prawdziwych elementów HTML dla przycisków, linków, nagłówków i etykiet formularzy, nadawaj obrazom sensowny tekst alternatywny, utrzymuj wysoki kontrast tekstu i dbaj o widoczny fokus. Standardem, do którego warto dążyć, jest WCAG 2.2 na poziomie AA. Automatyczne narzędzia wychwytują część problemów; dziesięciominutowy test klawiaturą i czytnikiem ekranu wychwytuje sporo reszty.

Co „dostępne” oznacza w praktyce

Dostępność dotyczy ludzi: osoby niewidomej, która korzysta z czytnika ekranu, osoby z drżeniem rąk, która porusza się klawiaturą, osoby słabowidzącej, która powiększa stronę do 200%, osoby czytającej w jasnym słońcu, osoby z czasowo złamanym nadgarstkiem. Dobra dostępność zwykle poprawia stronę dla wszystkich — czytelniejszą strukturę, tekst, który łatwo czytać, formularze wyjaśniające swoje błędy.

Standardem odniesienia są Wytyczne Dostępności Treści Internetowych (WCAG) W3C. Od września 2026 roku aktualną wersją jest WCAG 2.2 (opublikowana w październiku 2023, zaktualizowana w grudniu 2024); WCAG 3 jest wczesnym projektem. WCAG opiera się na czterech zasadach — treść musi być postrzegalna, funkcjonalna, zrozumiała i solidna — i ma trzy poziomy zgodności:

Przepisy w kilku miejscach odwołują się do WCAG — na przykład Europejski akt o dostępności, który od czerwca 2025 roku obowiązuje wiele cyfrowych usług konsumenckich w UE. To, które zasady dotyczą ciebie, zależy od tego, gdzie działasz i co sprzedajesz; w razie wątpliwości skonsultuj się z doradcą. Ten przewodnik omawia praktyczną pracę.

Opcje: jak tam dotrzeć

Dla większości małych stron wystarczą dwie pierwsze: poproś AI, by budowało dostępnie od początku, a przed startem przeprowadź audyt.

Poprawki, które mają największe znaczenie

Używaj właściwych elementów HTML

Wiele dostępności przychodzi za darmo wraz z poprawnym HTML. <button> jest fokusowalny, działa z Enter i Spacją i jest ogłaszany jako przycisk. <div> z obsługą kliknięcia nie ma żadnej z tych cech. Kod generowany przez AI czasem używa stylizowanych div do wszystkiego; poproś o elementy semantyczne:

• <button> dla akcji, <a href> dla nawigacji
• Jeden <h1> na stronę, potem <h2>, <h3> w kolejności — użytkownicy czytników ekranu przeskakują między nagłówkami
• Punkty orientacyjne: <header>, <nav>, <main>, <footer>
• <label> powiązany z każdym polem formularza
• Język strony w <html lang="pl">

Atrybutów ARIA używaj tylko wtedy, gdy żaden natywny element nie pasuje — na przykład przy niestandardowym zestawie kart lub comboboksie. Błędne ARIA jest gorsze niż jego brak.

Obsługa klawiaturą i widoczny fokus

Wszystko, co możesz zrobić myszą, musi działać samą klawiaturą (WCAG 2.1.1). Przejdź klawiszem Tab przez stronę: każdy link, przycisk i pole powinien być osiągalny w logicznej kolejności, a zawsze powinno być widać, gdzie jest fokus (2.4.7 Widoczny fokus). WCAG 2.2 dodał, że element z fokusem nie może być całkowicie ukryty za przyklejonymi nagłówkami ani banerami cookies (2.4.11, poziom AA).

Typowe błędy: menu otwierane tylko po najechaniu kursorem, okna modalne, które nie przechwytują fokusu lub nie dają się zamknąć klawiszem Escape, oraz outline: none w CSS bez żadnej zastępczej wersji.

Alternatywy tekstowe

Każdy istotny obraz potrzebuje tekstu alternatywnego, który w kontekście mówi, co pokazuje („Szef kuchni układa menu degustacyjne”, a nie „image1.jpg”). Obrazy dekoracyjne dostają puste alt="", by czytniki ekranu je pomijały. Przyciski zawierające tylko ikonę potrzebują dostępnej nazwy („Zamknij”, „Szukaj”). Filmy potrzebują napisów; nagrania audio — transkrypcji.

Kolor i kontrast

WCAG 2.2 AA wymaga współczynnika kontrastu co najmniej 4,5:1 dla zwykłego tekstu i 3:1 dla dużego tekstu (1.4.3) oraz 3:1 dla elementów interfejsu, takich jak obramowania pól i istotne ikony (1.4.11). Typowe błędy to jasnoszary tekst zastępczy w polach i blade przyciski. Nigdy też nie przekazuj znaczenia samym kolorem — czerwone obramowanie niepoprawnego pola wymaga również komunikatu o błędzie.

Zmiana rozmiaru i reflow

Tekst musi pozostać użyteczny przy powiększeniu do 200% (1.4.4), a treść musi działać przy szerokości 320 pikseli CSS bez przewijania w bok (1.4.10). Dobrze responsywny układ załatwia większość tego.

Cele, formularze i błędy

• Rozmiar celu: WCAG 2.2 AA wymaga, by cele wskaźnika miały co najmniej 24 na 24 piksele CSS lub wystarczający odstęp wokół mniejszych (2.5.8). Większe jest przyjaźniejsze na telefonach.
• Formularze: widoczne etykiety (nie tylko tekst zastępczy w polu), jasne instrukcje i komunikaty o błędach, które mówią, co jest nie tak i jak to naprawić, obok pola.
• Logowanie: nie każ ludziom rozwiązywać łamigłówki ani przepisywać kodu bez alternatywy; pozwól na menedżery haseł i wklejanie (3.3.8 Dostępne uwierzytelnianie).

Prompty, które działają

Zbuduj tę stronę zgodnie z WCAG 2.2 na poziomie AA: semantyczne punkty orientacyjne HTML, jeden h1 na stronę z nagłówkami w kolejności, prawdziwe elementy button i link, etykiety przy każdym polu formularza, widoczne style fokusu, kontrast tekstu co najmniej 4,5:1, tekst alternatywny przy istotnych obrazach i alt="" przy dekoracyjnych, oraz ustawiony atrybut html lang.

Przeprowadź audyt dostępności stron /signup i /checkout. Sprawdź obsługę samą klawiaturą, kolejność fokusu, widoczność fokusu, etykiety, komunikaty o błędach, kontrast i nazwy dla czytników ekranu przy przyciskach z ikonami. Wypisz każdy problem z kryterium WCAG, a potem napraw je, zmieniając projekt wizualny tylko w niezbędnym zakresie.

Menu mobilne nie da się obsłużyć klawiaturą. Zrób z niego przycisk z aria-expanded, przenieś fokus do menu po otwarciu, zamykaj je klawiszem Escape i zwracaj fokus na przycisk.

Krok po kroku

1. Uruchom automatyczne sprawdzenie. Sekcja Dostępności w Lighthouse w narzędziach dla deweloperów Chrome albo rozszerzenie przeglądarki axe, na każdej głównej stronie. Napraw wszystko, co zgłasza.
2. Odłącz mysz. Przechodź klawiszem Tab przez każdą stronę i wykonaj każde kluczowe zadanie — rejestrację, wyszukiwanie, płatność. Zanotuj wszystko, do czego nie możesz dotrzeć, nie widzisz fokusu lub z czego nie możesz wyjść.
3. Powiększ do 200% i zwęź okno do szerokości telefonu. Nic nie powinno być ucięte ani wymagać przewijania w bok.
4. Wypróbuj czytnik ekranu przez dziesięć minut: VoiceOver na Macu i iPhonie, TalkBack na Androidzie lub NVDA na Windows (darmowy). Posłuchaj nagłówków, linków i pól formularza. „Przycisk” bez nazwy albo „link, kliknij tutaj” to praca do zrobienia.
5. Sprawdź kontrast tekstu, przycisków i pól narzędziem do sprawdzania kontrastu.
6. Napraw, a potem przetestuj ponownie te same zadania.
7. Opublikuj deklarację dostępności z informacją, do jakiego standardu dążysz i jak zgłaszać problemy — i odpowiadaj na te zgłoszenia.

Częste błędy

• Poleganie na widżecie-nakładce zamiast naprawy kodu.
• Usuwanie obrysów fokusu, bo wyglądają nieporządnie, bez żadnego zamiennika.
• Tekst zastępczy w polu jako jedyna etykieta. Znika, gdy ktoś zaczyna pisać, i często ma niski kontrast.
• Linki „Kliknij tutaj” i „Czytaj więcej”. Poza kontekstem użytkownicy czytników słyszą listę identycznych linków.
• Tekst alternatywny nafaszerowany słowami kluczowymi. Tekst alternatywny jest dla ludzi; opisz obraz.
• Testowanie tylko raz. Każda nowa funkcja może zepsuć obsługę klawiaturą. Dodaj przejście klawiaturą do swojego testowania przed startem.

Lista kontrolna dostępności

• Automatyczne sprawdzenie (Lighthouse lub axe) bez błędów na głównych stronach
• Każde zadanie można wykonać samą klawiaturą
• Fokus zawsze widoczny i nigdy nie ukryty za przyklejonymi elementami
• Semantyczne nagłówki, punkty orientacyjne, przyciski i linki; ustawiony lang
• Sensowny tekst alternatywny; obrazy dekoracyjne z alt=""; napisy do filmów
• Kontrast tekstu ≥ 4,5:1 (duży tekst ≥ 3:1); elementy interfejsu ≥ 3:1
• Działa przy powiększeniu 200% i szerokości 320 px
• Każde pole formularza ma widoczną etykietę i jasne komunikaty o błędach
• Deklaracja dostępności z możliwością zgłaszania problemów

Aby poznać koncepcje stojące za tym, przeczytaj czym jest dostępność stron internetowych. Dostępny projekt i dobry projekt bardzo się pokrywają; jak zaprojektować dobrze wyglądającą aplikację z AI omawia stronę wizualną.

Dostępność w Mythex

Mythex buduje zgodnie ze standardem, o który poprosisz, więc wpisz „WCAG 2.2 AA” w pierwszym prompcie i w kolejnych. Możesz użyć ramki w rozmiarze telefonu w Podglądzie, by sprawdzić małe ekrany (Podgląd i kod), ale testy klawiaturą, powiększeniem i czytnikiem ekranu najlepiej działają na opublikowanym adresie URL lub podglądzie otwartym we własnej karcie. Poproś agenta o audyt strony, naprawę tego, co znajdzie, a potem sam przetestuj poprawki — automatyczne sprawdzenie to początek, a nie zatwierdzenie.

Pytania