WCAG 2.1 i dostępność strony w 2026 — obowiązki prawne i wdrożenie w praktyce

WCAG 2.1 to międzynarodowy standard dostępności serwisów internetowych, a od czerwca 2025 roku wymagania dostępności obejmują w Unii Europejskiej nie tylko podmioty publiczne, ale też szeroką grupę firm prywatnych świadczących usługi konsumenckie. Dla większości przedsiębiorstw oznacza to, że dostępność przestała być kwestią dobrej praktyki, a stała się obowiązkiem wynikającym z przepisów.

Kogo dotyczy obowiązek dostępności

• Podmioty publiczne — urzędy, szkoły, uczelnie, szpitale, instytucje kultury. Obowiązek od 2019 roku wraz z wymogiem publikacji deklaracji dostępności.
• Firmy objęte European Accessibility Act — sklepy internetowe, banki, operatorzy telekomunikacyjni, przewoźnicy, dostawcy e-booków i usług audiowizualnych.
• Projekty z dofinansowaniem publicznym — dostępność bywa warunkiem rozliczenia dotacji niezależnie od branży.
• Dostawcy podmiotów publicznych — wymóg przenosi się kontraktowo na wykonawców w postępowaniach przetargowych.

Cztery zasady WCAG — co oznaczają w praktyce

1. Postrzegalność

Treść musi być dostępna dla zmysłów użytkownika, także gdy jeden z kanałów jest niedostępny.

• Każdy obraz niosący informację ma tekst alternatywny; obrazy czysto dekoracyjne mają atrybut pusty.
• Materiały wideo mają napisy, a nagrania dźwiękowe transkrypcję.
• Kontrast tekstu wobec tła wynosi co najmniej 4,5:1 dla tekstu zwykłego i 3:1 dla dużego.
• Informacja nie jest przekazywana wyłącznie kolorem — błąd formularza opisany jest też słowem.
• Treść pozostaje czytelna przy powiększeniu do 200% bez utraty funkcjonalności.

2. Funkcjonalność

Wszystko musi dać się obsłużyć bez myszy i bez presji czasu.

• Pełna obsługa klawiaturą, w logicznej kolejności, bez pułapek uniemożliwiających opuszczenie elementu.
• Widoczny wskaźnik fokusu — usuwanie go ze względów estetycznych jest jednym z najczęstszych błędów.
• Odnośnik pozwalający pominąć nawigację i przejść wprost do treści.
• Brak treści migającej częściej niż trzy razy na sekundę.
• Możliwość zatrzymania animacji i automatycznie przewijanych karuzel.

3. Zrozumiałość

• Zadeklarowany język dokumentu, aby czytniki ekranu użyły właściwej syntezy mowy.
• Spójna nawigacja i przewidywalne zachowanie elementów w obrębie serwisu.
• Etykiety pól formularza powiązane programowo z polami, a nie jedynie umieszczone obok.
• Komunikaty o błędach wskazujące konkretne pole i sposób naprawy.
• Brak zmian kontekstu wywołanych samym ustawieniem fokusu na elemencie.

4. Solidność

• Poprawny, semantyczny kod HTML — nagłówki jako nagłówki, przyciski jako przyciski.
• Atrybuty ARIA stosowane wyłącznie tam, gdzie semantyka HTML nie wystarcza.
• Komunikaty dynamiczne ogłaszane czytnikom ekranu przez odpowiednie regiony aktywne.

Poziomy zgodności

Siedem błędów spotykanych najczęściej

• Usunięty wskaźnik fokusu. Deklaracja outline: none bez zastąpienia własnym stylem czyni serwis nieobsługiwalnym z klawiatury.
• Puste lub bezużyteczne teksty alternatywne. Opis w rodzaju „obrazek1” nie niesie żadnej informacji.
• Nagłówki użyte dla efektu wizualnego. Dobieranie poziomu nagłówka według wielkości czcionki niszczy strukturę dokumentu.
• Formularze bez powiązanych etykiet. Sam tekst zastępczy w polu znika po rozpoczęciu pisania i nie jest odczytywany jako etykieta.
• Za niski kontrast. Jasnoszary tekst na białym tle jest modny i niemożliwy do odczytania przy słabszym wzroku lub w silnym świetle.
• Odnośniki bez kontekstu. Lista odnośników „czytaj więcej” odczytana poza kontekstem nie mówi nic o celu.
• Nakładki reklamujące się jako rozwiązanie zgodności. Skrypty obiecujące automatyczną zgodność nie naprawiają błędów w kodzie źródłowym i bywają przedmiotem sporów prawnych.

Jak sprawdzić dostępność własnego serwisu

• Test klawiaturą. Odłóż mysz i przejdź całą ścieżkę zakupową lub kontaktową samym tabulatorem. To najszybszy sposób wykrycia poważnych barier.
• Automatyczny audyt narzędziem takim jak Lighthouse, axe DevTools lub WAVE — wykrywa około jednej trzeciej problemów.
• Weryfikacja kontrastu wszystkich kombinacji kolorów używanych w serwisie.
• Test z czytnikiem ekranu — NVDA na Windows lub VoiceOver na macOS. Nawet pobieżny odsłuch strony głównej bywa odkrywczy.
• Powiększenie do 200% i sprawdzenie, czy układ nie rozsypuje się i nie wymusza przewijania poziomego.
• Audyt ekspercki przy obowiązku ustawowym — narzędzia automatyczne nie wystarczą do potwierdzenia zgodności.

Deklaracja dostępności i obowiązki formalne

Zgodność techniczna to jedna część obowiązku. Druga to udokumentowanie jej w sposób przewidziany przepisami.

Co zawiera deklaracja dostępności

• Status zgodności serwisu ze standardem — pełna, częściowa albo jej brak, wraz z uzasadnieniem.
• Wykaz elementów niedostępnych z podaniem przyczyny i planowanego terminu naprawy.
• Data sporządzenia deklaracji i data ostatniego przeglądu.
• Metoda oceny — audyt zewnętrzny, samoocena albo połączenie obu.
• Dane kontaktowe osoby odpowiedzialnej za dostępność wraz z trybem zgłaszania problemów.
• Informacja o procedurze odwoławczej i o możliwości złożenia skargi.
• Opis dostępności architektonicznej siedziby, jeśli podmiot obsługuje interesantów.

Kiedy aktualizować

Deklaracja wymaga przeglądu co najmniej raz w roku, a także po każdej istotnej zmianie w serwisie — przebudowie, dodaniu nowego modułu czy zmianie systemu zarządzania treścią. Deklaracja sprzed kilku lat, opisująca nieistniejącą już wersję serwisu, jest w praktyce brakiem deklaracji.

Konsekwencje zaniedbania

W sektorze publicznym brak zgodności może skutkować postępowaniem i karą finansową, a każdy użytkownik ma prawo zgłosić żądanie zapewnienia dostępności konkretnego elementu — podmiot ma określony czas na reakcję. W przypadku firm objętych European Accessibility Act nadzór sprawują organy krajowe, a naruszenia mogą prowadzić do sankcji oraz nakazu usunięcia nieprawidłowości. Niezależnie od trybu, koszt pilnej naprawy pod presją terminu jest zwykle wielokrotnie wyższy niż zaplanowane wdrożenie.

Dostępność a SEO — wspólny mianownik

Znaczna część wymagań WCAG pokrywa się z dobrymi praktykami optymalizacji dla wyszukiwarek. Poprawna hierarchia nagłówków, opisowe teksty odnośników, teksty alternatywne obrazów, semantyczny kod i logiczna struktura dokumentu służą jednocześnie czytnikom ekranu i robotom indeksującym.

Stabilny układ bez przeskoków treści poprawia zarówno komfort osób korzystających z powiększenia, jak i metrykę CLS w Core Web Vitals. W praktyce oznacza to, że wdrożenie dostępności podnosi też widoczność serwisu — te dwa obszary rzadko bywają konkurencyjne.

Podsumowanie

Dostępność najtaniej wdraża się na etapie projektowania. Dobranie kontrastów, zaplanowanie obsługi klawiaturą i semantycznej struktury nie podnosi kosztu projektu w istotny sposób. Poprawianie gotowego serwisu bywa natomiast pracochłonne, bo wymaga ingerencji w warstwę wizualną i w kod jednocześnie.

Jeśli Twoja firma podlega European Accessibility Act albo realizuje projekt z dofinansowaniem, potraktuj zgodność z WCAG 2.1 AA jako wymóg wpisany do umowy z wykonawcą, wraz z obowiązkiem przedstawienia raportu z audytu po wdrożeniu. To jedyny sposób, żeby zgodność była faktem, a nie deklaracją.