28 czerwca 2025 r. wchodzi w życie Ustawa z 26 kwietnia 2024 r. o zapewnianiu spełniania wymagań dostępności niektórych produktów i usług (tzw. polski Akt o Dostępności, implementacja European Accessibility Act, EAA). Nowe prawo sprawia, że cyfrowa dostępność stron internetowych przestaje być opcjonalna, a staje się obowiązującym standardem. Celem regulacji jest zapewnienie, by osoby z niepełnosprawnościami (np. narządu wzroku, słuchu, ograniczeniami ruchowymi czy poznawczymi) mogły swobodnie korzystać z produktów i usług cyfrowych, w tym ze stron WWW.

Uwaga: Ustawa przewiduje pewne wyjątki. Najważniejszy – mikroprzedsiębiorcy (firmy zatrudniające mniej niż 10 osób i o obrocie mniejszym niż 2 mln € rocznie) są wyłączeni z obowiązku stosowania nowych wymagań. Mimo braku formalnego obowiązku dla mikro firm, warto w mojej ocenie rozważyć wdrożenie dostępności – zwiększy to grono potencjalnych klientów, SEO i pozytywnie wpłynie na wizerunek firmy 

Ten poradnik krok po kroku wyjaśnia jak twórcy stron internetowych mogą przygotować się na nadchodzące zmiany. Skupiamy się na obowiązkach wynikających z ustawy dla twórców stron WWW, łącząc wymogi prawne z praktycznymi aspektami technicznymi. Wszystkie zalecenia bazują na uznanych standardach WCAG 2.1/2.2 oraz oficjalnych źródłach rządowych i W3C.

Będzie długo – ale będzie warto 😉

Krok 1: Sprawdź, czy nowe przepisy dotyczą Twojej strony

Na początek ustal, czy Twoja strona internetowa podlega nowym wymaganiom. Ustawa obejmuje szeroko pojęte podmioty gospodarcze (producentów, importerów, dystrybutorów, usługodawców) oferujące produkty i usługi wymienione w ustawie . W praktyce dotyczy to większości firm wprowadzających na rynek określone produkty lub świadczących wskazane usługi. Ustawa wymienia kluczowe branże i usługi cyfrowe, które muszą spełniać wymogi dostępności, m.in.:

• Handel elektroniczny (e-commerce) – sklepy internetowe sprzedające towary lub usługi .
• Bankowość detaliczna i usługi płatnicze – np. serwisy bankowości internetowej, aplikacje bankowe, systemy płatności online .
• Telekomunikacja – strony operatorów telekomunikacyjnych oferujące usługi dla konsumentów.
• Usługi audiowizualne – serwisy VOD, platformy streamingowe, dostawcy mediów cyfrowych.
• Transport publiczny – np. systemy zakupu biletów online, rozkłady jazdy publikowane w internecie (z wyj. lokalnej komunikacji miejskiej) .
• Książki elektroniczne (e-booki) – sklepy i platformy dystrybuujące e-booki oraz czytniki e-booków .

Jeśli tworzysz lub utrzymujesz stronę WWW należącą do powyższych kategorii i nie jesteś mikroprzedsiębiorcą, masz prawny obowiązek zapewnić jej dostępność od 28 czerwca 2025. Warto zaznaczyć, że wymagania dotyczą zarówno nowych stron i aplikacji wdrażanych po tej dacie, jak i istotnych aktualizacji istniejących serwisów. Najbezpieczniej jednak potraktować je uniwersalnie – każda strona oferująca produkty/usługi publicznie powinna dążyć do zgodności, aby uniknąć ryzyka sankcji oraz zapewnić równe korzystanie wszystkim użytkownikom.

Krok 2: Zapoznaj się ze standardem WCAG

WCAG (Web Content Accessibility Guidelines) to międzynarodowy standard dostępności treści internetowych, przyjęty również w przepisach UE i Polski jako wzorzec spełniania wymagań dostępności. Ustawa nie narzuca wprost konkretnej metody technicznej, ale w praktyce przyjętym standardem jest właśnie WCAG (obecnie w wersji 2.1, a od 2025 – 2.2). Aby spełnić ustawowy obowiązek, należy więc dostosować strony zgodnie z wytycznymi WCAG na poziomie co najmniej AA.

Każda z tych zasad jest rozwinięta w szczegółowe wytyczne i kryteria sukcesu WCAG na trzech poziomach zgodności: A (podstawowy), AA (poziom średni, wymagany prawnie) i AAA (zaawansowany). Dla spełnienia wymogów ustawowych konieczna jest realizacja wszystkich kryteriów na poziomie AA. W praktyce oznacza to zgodność z WCAG 2.2 AA do czerwca 2025.

Co nowego w WCAG 2.2? Wersja 2.2 rozszerza WCAG 2.1 o kilka dodatkowych wymagań (poziom AA) istotnych m.in. dla użytkowników mobilnych i osób z niepełnosprawnościami poznawczymi . Do nowych kryteriów sukcesu należą: widoczny fokus elementów interfejsu (2.4.11 Focus Appearance), alternatywa dla czynności ,,przeciągnij i upuść” (2.5.7 Dragging), stała dostępność pomocy na stronie (3.2.6 Consistent Help), unikanie powtarzania informacji w formularzach (3.3.7 Redundant Entry) oraz ułatwienia przy uwierzytelnianiu (3.3.8 Accessible Authentication).

Polecam przejrzeć oficjalne źródła: skrót WCAG 2.1 na gov.pl, wszystkie linki podaję na końcu artykułu (jasno objaśnia zasady i wymagania w języku polskim) oraz pełne Wytyczne WCAG 2.1/2.2 na stronie W3C (dostępne także po polsku) Zrozumienie filozofii WCAG i kryteriów sukcesu to podstawa do kolejnych technicznych kroków.

Krok 3: Przeprowadź audyt dostępności swojej strony

W następnym kroku dokonaj szczegółowej oceny obecnej strony WWW pod kątem dostępności. Celem audytu jest zidentyfikowanie wszystkich barier utrudniających korzystanie osobom z różnymi niepełnosprawnościami. Audyt najlepiej przeprowadzić łącząc automatyczne narzędzia (np. wtyczki do przeglądarek, walidatory) z manualnymi testami i inspekcją kodu.

Obszary, na które należy zwrócić uwagę podczas audytu (zgodne z zasadami WCAG):

Po wykonaniu audytu będziesz mieć listę konkretnych braków do poprawy. Priorytetyzuj problemy według ich wpływu na użytkowników (krytyczne bariery usunąć w pierwszej kolejności). Pamiętaj, że pełna dostępność to spełnienie wszystkich kryteriów poziomu AA – nawet pozornie drobne kwestie (jak kolejność nagłówków czy opis przycisku) mają znaczenie dla niektórych grup użytkowników.

Krok 4: Wprowadź niezbędne zmiany – praktyczne wskazówki dla twórców

Gdy wiesz już, co wymaga poprawy, przejdź do wdrożenia zmian w kodzie i treści strony. Poniżej przedstawiamy zestawienie kluczowych wymagań WCAG 2.1/2.2 (poziom AA) w formie praktycznej checklisty dla webdevelopera. Wytyczne i przepisy pokazują nam konkretne kroki, ale podzieliłam je według czterech zasad WCAG, aby upewnić się, że żadna kategoria nie zostanie pominięta:

A. Postrzegalność – zapewnij alternatywne formy przekazu

• Teksty alternatywne dla obrazów: Dodaj atrybuty alt do wszystkich obrazków i elementów nietekstowych z treścią. Opis powinien przekazywać tę samą informację, jaką niesie obraz (np. <img src=”oferta.jpg” alt=”Nasza ekipa podczas realizacji projektu u klienta”>). Dekoracyjne grafiki można oznaczyć pustym alt (alt=””) lub za pomocą CSS, by je pominąć .

• Transkrypcje i napisy: Dołącz napisy do filmów (przynajmniej dla dialogów i ważnych dźwięków) oraz transkrypcje tekstowe audio (podcastów, nagrań) . Jeśli film demonstruje coś wizualnie istotnego bez opisu słownego, rozważ audiodeskrypcję lub dodaj opis tej akcji w tekście obok.

• Dostępność informacji wizualnych: Upewnij się, że informacje przekazywane kolorem są dostępne również inaczej. Np. jeśli pola formularza z błędem są oznaczane tylko czerwoną obwódką, dodaj także tekstowy komunikat o błędzie. Nie polegaj wyłącznie na kolorach czy kształtach, by przekazać istotną informację.

• Kontrast kolorów: Sprawdź kontrast tekstu do tła – powinien wynosić co najmniej 4.5:1 dla zwykłego tekstu (i 3:1 dla dużego tekstu). Użyj narzędzi do analizy kontrastu i dostosuj paletę barw, aby tekst był czytelny dla osób słabowidzących.

• Skalowalność tekstu: Upewnij się, że powiększenie tekstu do 200% nie rozbija layoutu ani nie ucina treści. Strona powinna być responsywna i skalować się na różne rozdzielczości, tak by użytkownicy z wadami wzroku mogli powiększać zawartość.

• Struktura nagłówków i list: Organizuj treść za pomocą odpowiednich nagłówków HTML (<h1> – <h6>) oraz list (<ul>, <ol>). Zachowuj hierarchię – pojedynczy <h1> na stronę, potem <h2> dla sekcji itd. To nie tylko kwestia struktury, ale i dostępności – ułatwia nawigację np. osobom niewidomym przeglądającym stronę po nagłówkach.

• Etykiety pól form: Każde pole formularza (<input>, <textarea>, <select>) musi mieć powiązaną etykietę tekstową (<label for=”id_pola”>Opis</label>). Jeśli etykieta jest wizualnie ukryta, zapewnij ją przynajmniej dla czytników (np. klasa .sr-only). Bez poprawnych etykiet użytkownicy czytników nie wiedzą, czego dane pole dotyczy.

B. Funkcjonalność – umożliwiaj nawigację i obsługę dla każdego

• Pełna obsługa klawiaturą: Zapewnij, że wszystkie funkcje strony są dostępne z klawiatury. Standardowo elementy interaktywne (linki, przyciski, kontrolki formularzy) są fokusable, ale własne komponenty (np. niestandardowe menu rozwijane) muszą otrzymać obsługę zdarzeń klawiaturowych (onkeydown itp.). Przetestuj nawigację klawiszem Tab – fokus powinien przechodzić w logicznej kolejności przez kolejne elementy.

• Widoczny fokus: Zaimplementuj widoczny styl fokusu (obramowanie lub podświetlenie) dla elementów aktywnych. Domyślny styl przeglądarki bywa słabo widoczny, dlatego lepiej nadać np. wyraźny obrys o grubości 2px i kontrastującym kolorze dla elementu :focus. Nowe wymogi WCAG 2.2 szczególnie to podkreślają, wymagając większej widoczności fokusa

• Omijanie powtarzalnych bloków: Dodaj na początku strony link “Przejdź do treści” (tzw. skip link), który pozwoli szybkie przeskoczenie do głównej zawartości, omijając menu i nagłówek. Ułatwia to życie osobom korzystającym z klawiatury lub technologii asystujących, umożliwiając pominięcie powtarzalnych fragmentów strony.

• Unikanie pułapek klawiatury: Upewnij się, że żaden element (np. wyskakujące okno) nie zatrzymuje fokusu i nie uniemożliwia opuszczenia go klawiaturą. Jeśli otwierasz modal, fokus powinien automatycznie przejść do okna modalnego, a po zamknięciu – wrócić w miejsce, z którego wyszło.

• Obsługa gestów i drag-drop: Jeśli interfejs korzysta z gestów dotykowych (przeciąganie, uszczypnięcie itp.), zapewnij dla nich alternatywę. Np. funkcję przeciągania elementów zrealizuj też w formie przycisków „przenieś w górę/dół” lub innym mechanizmem aktywowanym kliknięciem. Osoby o ograniczonej sprawności manualnej lub korzystające z samych klawiszy będą wtedy mogły z tego skorzystać.

• Czas na reakcję: Jeśli jakieś akcje na stronie są ograniczone czasowo (np. limit sesji, odliczanie), umożliw wydłużenie czasu lub wyłączenie limitu dla potrzebujących. Nie każ użytkownikowi zdążyć kliknąć w 5 sekund, bo nie każdy może reagować tak szybko.

• Unikaj elementów rozpraszających: Zadbaj o możliwość wstrzymania animacji, autoodtwarzania audio/wideo itp. Użytkownik powinien mieć kontrolę nad tym, co się dzieje na stronie – automatyczne treści (muzyka, rotatory) powinny dać się zatrzymać. Ponadto eliminuj migające lub błyskające treści (powyżej 3x/sek.), by nie narażać nikogo na ataki epilepsji czy dyskomfort.

C. Zrozumiałość – twórz czytelne treści i przewidywalne interakcje

->Pisz jasno i zrozumiale. Unikaj zdań wielokrotnie złożonych, żargonu i specjalistycznych terminów bez wyjaśnienia . Jeśli Twoja strona jest kierowana do szerokiej publiczności, dostosuj język do poziomu zrozumiałego dla przeciętnego użytkownika. Gdzie to możliwe, stosuj krótkie akapity, wypunktowania i nagłówki ułatwiające odbiór.

-> Zapewnij, że instrukcje obsługi są klarowne, a interfejs dostarcza użytkownikowi informacji o tym, co się dzieje. Np. przyciski akcji powinny mieć jednoznaczne etykiety (“Zarejestruj się”, nie “Wyślij”). Po wysłaniu formularza wyświetl komunikat potwierdzający lub informujący o błędach – i opisz, jak je poprawić .

-> Gdy coś pójdzie nie tak (np. walidacja formularza), pokaż czytelny komunikat błędu blisko danego pola, w zrozumiałej formie. Unikaj tylko koloru czerwonego czy ikony – napisz tekstem co jest nie tak (“Hasło musi mieć min. 8 znaków”). Dodatkowo, jeżeli to możliwe, podpowiedz rozwiązanie (np. “Wpisz co najmniej 8 znaków, w tym jedną cyfrę”).

-> Układ menu i nawigacji powinien być spójny na całej stronie. Użytkownik nie powinien zgadywać, czy na innej podstronie menu nagle wygląda inaczej lub elementy zamieniły miejscami – trzymaj się jednego szablonu. Również terminologia powinna być jednolita (np. jeśli używasz słowa “Koszyk” w e-sklepie, nie zamieniaj go na “Wózek” na innej stronie).

-> Unikaj nagłych, niespodziewanych zmian na stronie. Przykładowo: link lub przycisk nie powinien automatycznie otwierać nowego okna bez uprzedzenia; focus po wykonaniu akcji powinien logicznie przechodzić na kolejny element. Dąż do tego, by interakcje były intuicyjne – użytkownik po kliknięciu powinien dostać oczekiwany efekt, bez zaskoczeń.

-> Określ poprawnie język domyślny strony w kodzie (lang). Jeśli część treści jest w innym języku, otaguj ją (np. <span lang=”en”>Hello</span>). Dzięki temu czytniki przełączą język syntezy mowy i poprawnie przeczytają tekst w obcym języku . Błędnie ustawiony język lub jego brak może powodować niezrozumiałe odczytywanie treści przez syntezator mowy.

D. Solidność (Kompatybilność) – dbaj o techniczną poprawność i przyszłość

• Poprawny kod HTML/CSS: Waliduj kod strony za pomocą narzędzi (np. W3C Validator). Usuń błędy składniowe, zduplikowane ID, niezamknięte znaczniki itp. Poprawny kod to podstawa, by różne przeglądarki i technologie asystujące interpretowały stronę właściwie. Zwróć uwagę, czy elementy mają poprawną strukturę (np. listy z <li> w <ul>, tabelki z <th> dla nagłówków kolumn).

• Semantyczne elementy: Wykorzystuj semantyczne znaczniki HTML5 gdzie to możliwe (<header>, <nav>, <main>, <footer>, <article>, <aside> itd.). Nadają one znaczenie strukturom strony, co ułatwia nawigację użytkownikom czytników oraz integrację z narzędziami typu czytnik ekranu. Unikaj nadużywania kontenerów <div> tam, gdzie istnieje semantyczny odpowiednik.

• ARIA i komunikaty dynamiczne: Gdy standardowe HTML nie wystarcza (np. budujesz niestandardowy kontrolkę), stosuj ARIA (Accessible Rich Internet Applications) rozważnie, by przekazać rolę i stan elementów do czytników. Na przykład dodaj role=”dialog” dla modala, a atrybut aria-live=”polite” na element, w którym pojawiają się komunikaty systemowe, aby czytnik je ogłosił . Używaj ARIA zgodnie z dokumentacją – niewłaściwe zastosowanie może pogorszyć dostępność zamiast ją poprawić.

• Kompatybilność z czytnikami: Przetestuj stronę w popularnych technologiach asystujących: czytniku ekranu(np. NVDA/JAWS na Windows, VoiceOver na iOS/Mac) oraz powiększalniku ekranu. Sprawdź, czy ważne informacje są ogłaszane (np. czy po dodaniu produktu do koszyka pojawia się komunikat odczytywany przez NVDA). Zwróć uwagę na elementy dynamiczne – czy czytnik informuje o zmianach stanu (np. rozwinięcie menu, walidacja pola). Jeśli pewne treści są dostępne dopiero po najechaniu myszą, dodaj obsługę focusem klawiatury lub inną metodę dla użytkowników klawiatury.

• Testy wieloplatformowe: Upewnij się, że strona działa poprawnie w różnych przeglądarkach (Chrome, Firefox, Safari, Edge…) oraz na różnych urządzeniach (komputer, smartfon z czytnikiem ekranu, tablet). Różne kombinacje mogą inaczej obsługiwać elementy dostępności. Np. mobilne czytniki ekranu obsługują gesty – sprawdź, czy aplikacja webowa jest dla nich przyjazna.

• Przygotowanie na przyszłość: Śledź rozwój standardów – nadchodzi WCAG 3.0, który może zmienić podejście do dostępności w kolejnych latach . Budując już teraz z myślą o dostępności (zgodnie z WCAG 2.2), tworzysz solidną bazę pod przyszłe wymagania. Staraj się pisać kod czysty i modularny, co ułatwi ewentualne późniejsze dostosowania do nowych wytycznych.

Krok 5: Weryfikacja

Po wprowadzeniu poprawek koniecznie przetestuj ponownie stronę. Najlepiej zaangażuj w to użytkowników z niepełnosprawnościami (np. niewidomych testerów) – ich opinia jest bezcenna, bo mogą wychwycić problemy niewidoczne na pierwszy rzut oka. Wykorzystaj również automatyczne testery i raporty porównawcze z audytu, aby upewnić się, że wszystkie wcześniej zidentyfikowane bariery zostały usunięte.

Co ważne, dostępność to proces ciągły, nie jednorazowy projekt. Zaplanuj regularne przeglądy dostępności strony – np. coroczny audyt lub testy przy większych aktualizacjach. Ustal procedury, aby nowe treści również były dodawane w sposób dostępny (przeszkol redaktorów, dodaj checklisty dla programistów). Dzięki temu utrzymasz zgodność z wymogami na dłuższą metę i zminimalizujesz ryzyko błędów przy rozbudowie witryny.

Gdzie szukać szczegółowych wytycznych i aktualizować wiedzę? Sprawdzone źródła wrzucam poniżej:

1. WCAG 2.1 – oficjalne tłumaczenie na język polski (13.04.2021)
   • To autoryzowana wersja wytycznych WCAG 2.1, na której bazuje większość przykładów z zakresu: alt textów, kontrastu, semantycznych nagłówków, etykiet formularzy itp.
2. Understanding WCAG 2.1
   • Każde kryterium WCAG 2.1 ma dedykowane „omówienie”, w którym są opisane typowe błędy, przykłady dobrych praktyk, techniki HTML/ARIA/CSS.
3. Techniques for WCAG 2.1
   • Zawiera konkretne techniki, np. „G83: Providing text alternatives for non-text content”, „H42: Using h1-h6 to identify headings”, „ARIA15: Using aria-label”.
4. WCAG 2.1 w skrócie – gov.pl
   Bardzo przystępne podsumowanie zasad WCAG z przykładami – np. nawigacja klawiaturą, etykiety formularzy, kontrast kolorów.

Mam nadzieję, że udało Ci się dotrwać do końca – a jeśli tak, to daj mi znać, czy pomogłam 🙂

Do następnego!