Jak zrobić dostępną stronę internetową zgodną z WCAG w 2026?

Jak zrobić dostępną stronę internetową zgodną z WCAG w 2026?

Rok 2026 to nie science-fiction – to rzeczywistość, w której dostępność cyfrowa przestała być opcją. Od czerwca 2025 roku wszystkie strony podmiotów publicznych w UE muszą spełniać standard WCAG 2.2 na poziomie AA. Ale uwaga: to samo dotyczy firm, które chcą uniknąć pozwów i utraty klientów. W Polsce coraz więcej organizacji prywatnych dobrowolnie wdraża dostępność, bo po prostu opłaca się to biznesowo.

W tym poradniku pokażę Ci krok po kroku, jak zrobić stronę internetową zgodną z WCAG 2.2. Nie będę owijał w bawełnę – to wymaga pracy. Ale efekt? Strona, która działa dla każdego: osób niewidomych, niedowidzących, z niepełnosprawnością ruchową czy poznawczą. I co ważne – lepiej pozycjonuje się w Google.

Zaczynamy.

Krok 1: Przeprowadź audyt dostępności istniejącej strony

Zanim cokolwiek zmienisz, musisz wiedzieć, co jest zepsute. Audyt dostępności to fundament. Bez niego będziesz działał po omacku. A w 2026 roku nikt nie ma na to czasu.

Narzędzia do automatycznego audytu

Automatyczne skanery to Twój pierwszy krok. Są szybkie i tanie (często darmowe). Użyj WAVE (rozszerzenie do Chrome), axe DevTools wbudowanego w przeglądarkę albo Lighthouse w Chrome DevTools. Każde z tych narzędzi w kilka sekund wypluje listę błędów: brakujące atrybuty alt, zbyt niski kontrast, problemy z nawigacją klawiaturą.

Ale uwaga – automatyka nie wystarczy. Wykrywa może 30-40% problemów. Resztę musisz sprawdzić ręcznie.

Ręczna weryfikacja krytycznych elementów

Tu zaczyna się prawdziwa robota. Weź do ręki Colour Contrast Analyser (darmowe narzędzie od TPGi) i sprawdź kontrasty. Dla tekstu podstawowego wymagane jest minimum 4.5:1, dla dużego tekstu (powyżej 18px lub 14px bold) – 3:1. Zaskoczenie? Większość firmowych stron ma kontrast na poziomie 3:1 dla zwykłego tekstu. To dyskwalifikuje.

Następnie wyłącz myszkę. Tak, po prostu odłóż ją na bok. Każdy interaktywny element – linki, przyciski, pola formularzy – musi być osiągalny i obsługiwany za pomocą samej klawiatury. Tab, Shift+Tab, Enter, Strzałki. Jeśli gdzieś utkniesz, masz błąd krytyczny.

Z doświadczenia: najczęściej zawodzą menu rozwijane, karuzele i niestandardowe checkboxy. Sprawdź je szczególnie dokładnie.

Krok 2: Zaprojektuj czytelną i przewidywalną strukturę

Dostępność zaczyna się na etapie projektu, nie wdrożenia. Jeśli układ strony jest chaotyczny, żaden kod tego nie naprawi. Projektuj z myślą o tym, że użytkownik może nie widzieć ekranu albo widzieć go fragmentarycznie.

Nagłówki i hierarchia treści

To banalne, ale łamane nagminnie. Logiczna hierarchia nagłówków (H1 → H2 → H3... H6) to podstawa. Nigdy nie przeskakuj poziomów – nie wrzucaj H3 zaraz po H1. Czytniki ekranu traktują nagłówki jak spis treści. Jeśli jest poprzestawiany, użytkownik się gubi.

Każda strona powinna mieć dokładnie jeden H1. To tytuł strony. H2 to główne sekcje. H3 to podsekcje. Proste? A jednak w audytach regularnie widzę strony z pięcioma H1 na jednej podstronie.

Układ responsywny i skalowanie

Twoja strona musi działać przy powiększeniu do 400% bez utraty treści i funkcjonalności. To nie jest opcjonalne – to wymóg WCAG 2.2. Przetestuj to w przeglądarce: Ctrl+ plusik, aż do 400%. Jeśli tekst wychodzi poza ekran, przyciski znikają, a menu się rozjeżdża – masz problem.

Odstępy między akapitami i elementami też mają znaczenie. Dla linków i przycisków minimalna wielkość klikalnego obszaru to 24x24px (zgodnie z WCAG 2.2). To nowość w porównaniu do starszych standardów. W praktyce oznacza to, że małe linki w stopce czy ciasne przyciski są niedozwolone.

Krok 3: Wdróż semantyczny HTML i role ARIA

To sedno technicznej dostępności. Dobry HTML to połowa sukcesu. Zły HTML? Nawet najlepszy design nie pomoże.

Znaczniki HTML5 dla lepszej dostępności

Używaj natywnych znaczników HTML5: <nav> dla nawigacji, <main> dla głównej treści, <article> dla samodzielnych bloków treści, <aside> dla treści pobocznych. Czytniki ekranu rozpoznają te znaczniki i pozwalają użytkownikom szybko przeskakiwać między sekcjami.

Dodaj atrybut lang w znaczniku <html>. Dla polskiej strony to lang="pl". Bez tego czytnik ekranu może odczytać polski tekst z angielskim akcentem – brzmi to koszmarnie i dezorientuje użytkownika.

Uzupełnienie o role ARIA tam, gdzie HTML nie wystarcza

ARIA (Accessible Rich Internet Applications) to zestaw atrybutów, które uzupełniają semantykę HTML. Ale uwaga: pierwsza zasada ARIA to nie używać ARIA, jeśli można użyć natywnego HTML. Role ARIA są jak przyprawy – odrobina poprawia smak, przesada psuje danie.

Stosuj role tam, gdzie brakuje natywnej semantyki: dla dynamicznych paneli (role="tabpanel"), dla okien modalnych (role="dialog"), dla pól z autouzupełnianiem (role="combobox"). Unikaj nadmiarowości – nie dodawaj role="navigation" do <nav>, bo to już jest domyślnie nawigacją.

Krok 4: Optymalizuj multimedia i formularze

Obrazy, filmy i formularze to najczęstsze źródła błędów dostępności. I jednocześnie najłatwiejsze do naprawienia. Wystarczy odrobina wiedzy i konsekwencji.

Alternatywy tekstowe dla obrazów i wideo

Każdy obraz musi mieć atrybut alt. To nie podlega dyskusji. Jeśli obraz jest dekoracyjny (tło, ozdobnik, ikona bez znaczenia informacyjnego), użyj alt="" (pusty alt). Czytnik ekranu wtedy go pominie. Jeśli obraz niesie treść (zdjęcie produktu, wykres, infografika), alt musi opisywać tę treść krótko i konkretnie.

Dla filmów sprawa jest bardziej złożona. Potrzebujesz transkrypcji tekstowej (pełny zapis słów i dźwięków) oraz napisów w formacie VTT. Napisy są obowiązkowe dla osób niesłyszących, transkrypcja dla osób, które nie mogą odtworzyć dźwięku. W 2026 roku brak napisów to praktycznie gwarantowany pozew.

Dostępne formularze i komunikaty błędów

Formularze to często najważniejsza część strony – zamówienia, rejestracje, kontakt. Jeśli są niedostępne, tracisz klientów. Każde pole formularza musi mieć etykietę (label) połączoną z polem za pomocą atrybutu for. Nie używaj placeholderów jako etykiet – znikają po wpisaniu tekstu, a użytkownik czytnika ekranu nie wie, co wpisał.

Komunikaty błędów muszą być czytelne dla czytników ekranu. Nie wystarczy czerwona ramka wokół pola. Dodaj tekst błędu w aria-describedby lub aria-errormessage. I nie kasuj błędów po sekundzie – daj użytkownikowi czas na przeczytanie.

Krok 5: Przetestuj z użytkownikami i narzędziami asystującymi

To krok, który większość firm pomija. I to błąd. Automatyczne testy nie zastąpią prawdziwych użytkowników. Tylko oni powiedzą Ci, czy Twoja strona faktycznie działa, czy tylko teoretycznie spełnia standardy.

Testy z osobami z niepełnosprawnościami

Zaproś 3-5 użytkowników korzystających z czytników ekranu (NVDA na Windows, VoiceOver na Mac, TalkBack na Androidzie). Daj im konkretne zadania: znajdź produkt, wypełnij formularz, przejdź do koszyka. Obserwuj, gdzie utkną, co ich frustruje, ile czasu zajmuje wykonanie zadania.

Nie oszukuj się – jeśli nie testujesz z prawdziwymi użytkownikami, nie wiesz, czy Twoja strona jest dostępna. Automatyka nie wyłapie problemów z logiką nawigacji czy nieintuicyjnymi etykietami.

Automatyczne walidatory i symulatory

Użyj symulatora daltonizmu (np. Colorblindly dla Chrome), żeby zobaczyć, jak Twoja strona wygląda dla osób z różnymi typami ślepoty barw. Sprawdź nawigację klawiaturą jeszcze raz – tym razem z włączonym czytnikiem ekranu. To symuluje doświadczenie użytkownika niewidomego.

Na koniec przeprowadź walidację końcową zgodnie z kryteriami sukcesu WCAG 2.2 na poziomie AA. To 50 kryteriów – od kontrastu przez nawigację po multimedia. Brzmi dużo? W praktyce większość z nich spełnisz, stosując się do kroków powyżej. Jeśli potrzebujesz wsparcia, agencja taka jak netzure.pl może przeprowadzić pełny audyt i wdrożenie – to oszczędza czas i nerwy.