Jak naprawić 6 najczęstszych naruszeń WCAG na dowolnej stronie internetowej

Otwórz teraz dowolną z miliona najpopularniejszych stron internetowych, a istnieje 96‑na‑100 szans, że znajdziesz naruszenie WCAG, które automatyczny skaner wychwyci w kilka sekund. Na milionie stron głównych wykryto 56 114 377 odrębnych błędów dostępności — średnio 56,1 błędu na stronę. Szczególnie uderzające jest to, że 96% wszystkich wykrytych błędów mieści się zaledwie w sześciu kategoriach, a te sześć najczęstszych typów błędów pozostaje niezmiennych od siedmiu lat. Oznacza to, że naprawienie garstki dobrze zrozumianych problemów dramatycznie poprawiłoby dostępność w całej sieci — i zaczyna się to od Twojej strony.

Dlaczego wciąż pojawia się tych samych sześć błędów

Możesz się zastanawiać, jak to możliwe, że w erze zaawansowanych narzędzi deweloperskich i rosnącej kontroli prawnej te same błędy utrzymują się na taką skalę rok po roku. Odpowiedź jest systemowa. To zagęszczenie błędów odzwierciedla, jak głęboko niedostępność została wbudowana w praktyki tworzenia stron. Problemy w szablonach mnożą się na każdej stronie. Błędy w komponentach powtarzają się w całych serwisach. Bez celowego zwracania uwagi na dostępność standardowe procesy deweloperskie systematycznie produkują niedostępne rezultaty.

Istnieje też fałszywe poczucie postępu napędzane automatyzacją. Testy automatyczne wychwytują jedynie 30–40% potencjalnych naruszeń WCAG. Strony przechodzące testy automatyczne mogą nadal mieć istotne problemy z nawigacją klawiaturą, obsługą czytników ekranu czy dostępnością poznawczą. Oznacza to, że nawet ten niewielki odsetek stron, które na papierze wydają się zgodne, prawdopodobnie zawodzi w praktyce.

Stawka prawna jest realna i rośnie. Według Seyfarth Shaw w 2024 roku wniesiono 8 800 federalnych pozwów na podstawie Tytułu III ADA, z czego około 2 452 dotyczyło konkretnie dostępności stron internetowych. Serwisy e‑commerce są narażone w nieproporcjonalnym stopniu — 77% pozwów dotyczących dostępności stron dotyczy handlu online. Zgodność nie jest już miłym dodatkiem. To kwestia ciągłości działania biznesu.

Budująca strona medalu? To skupienie ma praktyczne konsekwencje. Organizacje mogą rozwiązać większość problemów z dostępnością, koncentrując się na garstce typów błędów. Pełna zgodność z WCAG wymaga uwzględnienia wszystkich 78 kryteriów, ale najbardziej wpływowe usprawnienia wynikają z naprawienia tych najczęstszych błędów. Przejdźmy więc przez każdy z nich, z praktycznymi poprawkami, które możesz wdrożyć już dziś.

Błąd nr 1 — tekst o niskim kontraście (WCAG 1.4.3)

Tekst o niskim kontraście — tekst, który nie ma wystarczającego zróżnicowania kolorystycznego względem tła — pojawia się na 83,6% przeanalizowanych stron głównych. To najczęstsze naruszenie WCAG, dotykające ponad czterech na pięć serwisów. WCAG 1.4.3 (Minimalny kontrast) jest bezlitośnie prosty: zwykły tekst musi osiągać współczynnik kontrastu co najmniej 4,5:1 względem tła, a duży tekst (18 pt lub 14 pt pogrubiony) musi osiągać co najmniej 3:1.

Błędy kontrastu często wynikają z decyzji projektowych, które przedkładają estetykę nad czytelność. Jasnoszary tekst na białym tle wygląda wyrafinowanie dla projektantów z idealnym wzrokiem. Dla użytkowników słabowidzących, starszych lub kogokolwiek czytającego na ekranie z odblaskami jest nieczytelny. Typowymi winowajcami są etykiety drugorzędne, tekst zastępczy w polach formularzy, tekst w stopce oraz stany wyłączonych przycisków — są stylizowane tak, by wyglądały subtelnie, a kończą jako niewidoczne dla istotnej części Twojej publiczności.

Naprawa to prawie zawsze korekta CSS. Przepuść pary kolorów przez narzędzie do sprawdzania kontrastu, takie jak WebAIM Contrast Checker lub panel dostępności w DevTools przeglądarki, a następnie skoryguj kolor pierwszego planu lub tła, aż test przejdzie. Oto typowy wzorzec, który nie spełnia wymogów, i sposób jego poprawy:

/* Błąd — współczynnik około 2,3:1 */
.secondary-label {
  color: #aaaaaa;
  background-color: #ffffff;
}

/* Poprawne — współczynnik około 7:1 */
.secondary-label {
  color: #595959;
  background-color: #ffffff;
}

W przypadku tekstu zastępczego pamiętaj, że WCAG traktuje go jak prawdziwy tekst — nie dekoracyjną podpowiedź — więc on również musi spełniać próg 4,5:1. Unikaj polegania wyłącznie na placeholderach do przekazywania instrukcji; zawsze łącz je z widocznym elementem <label>. Jeśli używasz obrazów zawierających tekst, nie naprawisz kontrastu za pomocą CSS — musisz wygenerować te obrazy na nowo, co jest kolejnym powodem, by preferować żywy tekst HTML zamiast tekstu wtopionego w grafikę.

Błąd nr 2 — brak alternatywnego tekstu obrazów (WCAG 1.1.1)

Obrazy bez alternatywnego tekstu pojawiają się na 58,2% stron głównych. Gdy obrazom brakuje tekstu alternatywnego, użytkownicy czytników ekranu napotykają ciszę lub bezsensowne nazwy plików tam, gdzie powinny znajdować się treści. To nie jest nowy problem. Tekst alternatywny jest podstawowym wymogiem dostępności od czasu WCAG 1.0 z 1999 roku. Dwadzieścia pięć lat później większość stron wciąż nie wdraża go konsekwentnie.

Utrzymuje się on z powodu luki w procesie, a nie braku wiedzy. Ten odsetek błędów wskazuje na systemowe luki w przepływach pracy z treścią. Autorzy i redaktorzy często nie wiedzą, że tekst alternatywny jest potrzebny. Systemy zarządzania treścią nie zawsze o niego proszą. Kontrola jakości nie wychwytuje jego braku. Naprawa ma więc dwie warstwy: techniczną i procesową.

Po stronie technicznej każdy znaczący obraz potrzebuje atrybutu alt, który przekazuje tę samą informację, co obraz. Obrazy dekoracyjne — czysto wizualne ozdobniki, które nie dodają informacji — powinny otrzymać pusty alt="", aby czytniki ekranu całkowicie je pomijały. Poprawne rozróżnienie jest równie ważne jak samo dodanie atrybutu. Duży odsetek obrazów ma brakujący lub nieprawidłowy tekst alternatywny. Niektóre znaczące obrazy nie mają żadnych opisów, podczas gdy obrazy dekoracyjne są często traktowane jak treści znaczące. Oba problemy łamią zgodność z WCAG w zakresie treści postrzegalnych.

<!-- Znaczący obraz: opisz, co przekazuje -->
<img src='team-photo.jpg' alt='The Accsible engineering team at their 2024 offsite in Lisbon' />

<!-- Obraz dekoracyjny: pusty alt, rola niepotrzebna -->
<img src='wave-divider.svg' alt='' />

<!-- Obraz jako link: opisz cel, nie sam obraz -->
<a href='/pricing'>
  <img src='pricing-icon.svg' alt='View pricing plans' />
</a>

Po stronie procesowej zaktualizuj szablony CMS tak, by pole alt było wymagane dla obrazów treściowych, i przeszkol wszystkich, którzy wgrywają zasoby. Automatyczne narzędzia, takie jak Accsible, mogą wykrywać obrazy z brakującym lub pustym tekstem alternatywnym w całym serwisie, dostarczając zespołowi listę do systematycznego przepracowania.

Błąd nr 3 — brak etykiet pól formularzy (WCAG 1.3.1, 3.3.2)

48,6% stron ma brakujące etykiety pól formularzy. Ten błąd jest szczególnie dotkliwy, ponieważ formularze to miejsce, w którym użytkownicy faktycznie coś robią — zapisują się, finalizują zakup, kontaktują się, zgłaszają prośby o wsparcie. Wiele formularzy nie ma dostępnych etykiet, polega wyłącznie na placeholderach, nie udostępnia instrukcji i komunikatów o błędach lub nie wspiera obsługi wyłącznie klawiaturą. Ponieważ formularze są kluczowe dla większości doświadczeń cyfrowych, te błędy tworzą poważne bariery użyteczności.

Najczęstszym błędem jest używanie tekstu zastępczego jako zamiennika elementu <label>. Placeholder znika, gdy użytkownik zaczyna pisać, pozostawiając osoby z zaburzeniami pamięci krótkotrwałej — lub po prostu kogoś, kto został rozproszony w trakcie wypełniania — bez informacji, do czego służy pole. Czytniki ekranu różnie traktują placeholdery, a żadne z tych podejść nie jest tak niezawodne jak poprawne powiązanie etykiety.

Poprawny wzorzec to użycie elementu <label> powiązanego z polem poprzez pasujące atrybuty for i id. Jeśli widoczna etykieta nie jest możliwa z powodów projektowych, użyj aria-label lub aria-labelledby — ale nie sięgaj po ARIA, gdy możesz po prostu użyć <label>.

<!-- Poprawne: jawne powiązanie etykiety -->
<label for='email'>Email address</label>
<input type='email' id='email' name='email' autocomplete='email' />

<!-- Błędne: tylko placeholder -->
<input type='email' placeholder='Email address' />

<!-- Akceptowalne, gdy etykieta musi być wizualnie ukryta -->
<label for='search' class='visually-hidden'>Search the site</label>
<input type='search' id='search' name='q' />

Komunikaty o błędach również muszą być powiązane programowo. Gdy formularz wykryje błąd, komunikat powinien być powiązany z polem za pomocą aria-describedby, a idealnie fokus powinien zostać przeniesiony do pierwszego nieprawidłowego pola. Błędy walidacji formularzy powinny być efektywne, intuicyjne i dostępne — błąd musi być wyraźnie zidentyfikowany, szybki dostęp do problematycznego elementu zapewniony, a użytkownik musi móc łatwo poprawić błąd i ponownie wysłać formularz.

Błąd nr 4 — puste linki i przyciski (WCAG 2.4.4, 4.1.2)

44,6% stron ma puste hiperłącza. Puste przyciski znaleziono na prawie 30% stron, a liczba ta wzrosła w porównaniu z poprzednim rokiem. Oznacza to, że użytkownicy niewidomi lub słabowidzący nie zrozumieją celu przycisków takich jak wyślij, resetuj, filtruj czy szukaj. Razem puste linki i przyciski stanowią jedno z najbardziej frustrujących doświadczeń dla użytkowników czytników ekranu — napotkanie elementów interaktywnych bez nazwy jest jak naciskanie klamki bez etykiety i bez pojęcia, dokąd prowadzi.

Puste linki najczęściej pojawiają się, gdy ikonka lub obraz jest jedynym dzieckiem znacznika <a>, a nie zapewniono tekstu alternatywnego. Puste przyciski powstają, gdy przyciski oparte wyłącznie na ikonach — menu hamburger, ikony zamknięcia, przyciski udostępniania — nie mają żadnej dostępnej nazwy. Oba problemy są proste do naprawienia.

<!-- Pusty link — błąd -->
<a href='/dashboard'><svg>...</svg></a>

<!-- Naprawione za pomocą aria-label -->
<a href='/dashboard' aria-label='Go to dashboard'><svg aria-hidden='true'>...</svg></a>

<!-- Pusty przycisk — błąd -->
<button><svg>...</svg></button>

<!-- Naprawione za pomocą wizualnie ukrytego tekstu -->
<button>
  <svg aria-hidden='true'>...</svg>
  <span class='visually-hidden'>Close menu</span>
</button>

Zwróć uwagę na aria-hidden='true' na SVG w każdym poprawionym przykładzie. Gdy zapewniasz tekst alternatywny za pomocą aria-label lub wizualnie ukrytego tekstu, chcesz wykluczyć SVG z drzewa dostępności — w przeciwnym razie czytniki ekranu mogą ogłaszać zarówno etykietę, jak i własny tytuł lub opis SVG, tworząc mylące podwójne ogłoszenie. Niejasny tekst linków — frazy takie jak „kliknij tutaj”, „czytaj więcej” czy „dowiedz się więcej” — to pokrewny błąd. Inne problemy z hiperłączami, takie jak niejednoznaczny tekst linków, znaleziono na prawie 14% stron głównych, co stanowi wzrost w porównaniu z poprzednim rokiem. Hiperłącza z właściwym tekstem są ważne, aby użytkownicy wiedzieli, dokąd prowadzi link. Dostępna nazwa każdego linku powinna mieć sens poza kontekstem, ponieważ użytkownicy czytników ekranu często nawigują, wyświetlając listę wszystkich linków na stronie.

Błąd nr 5 — brak języka dokumentu (WCAG 3.1.1)

Ten błąd może wydawać się drobny w porównaniu z kontrastem czy tekstem alternatywnym, ale około 16% stron nie ma ustawionego języka dokumentu — a wpływ na użytkowników czytników ekranu jest natychmiastowy i szokujący. Jeśli użytkownik czytnika ekranu ma zainstalowany odpowiedni pakiet językowy, treść zostanie odczytana poprawnie. W przeciwnym razie będzie brzmiała jak z silnym akcentem i może być niezrozumiała.

Naprawa to pojedynczy atrybut HTML — dosłownie jedna linijka kodu — i nie ma usprawiedliwienia dla jej braku. Dodaj atrybut lang do elementu <html> z odpowiednim tagiem językowym BCP 47. Jeśli sekcje strony są w innym języku niż reszta, dodaj atrybut lang również do tych konkretnych elementów.

<!-- Brak: brak atrybutu lang -->
<html>

<!-- Poprawne: strona po angielsku -->
<html lang='en'>

<!-- Poprawne: strona po francusku -->
<html lang='fr'>

<!-- Zmiana języka w obrębie strony -->
<p>The French phrase <span lang='fr'>joie de vivre</span> means a cheerful enjoyment of life.</p>

Jeśli używasz CMS lub generatora statycznych stron, atrybut lang powinien być ustawiony w szablonie bazowym. Sprawdź szablon raz, popraw go raz, a każda strona w serwisie zostanie natychmiast naprawiona. To prawdopodobnie poprawka o najwyższym zwrocie z wysiłku na całej tej liście — pojedyncza zmiana w szablonie eliminuje problem w całej domenie.

Błąd nr 6 — niedostępna nawigacja klawiaturą i zarządzanie fokusem (WCAG 2.1.1, 2.4.7)

Dostępność klawiatury to obszar, w którym luka między testami automatycznymi a rzeczywistą użytecznością jest największa. Narzędzia automatyczne mogą wykryć niektóre błędy klawiaturowe — jak elementy interaktywne zbudowane z niesemantycznych tagów — ale nie są w stanie zasymulować kolejności tabulacji, pułapek fokusu czy doświadczenia nawigowania po menu rozwijanym wyłącznie za pomocą klawiszy strzałek. Strony często usuwają domyślne wskaźniki fokusu bez zapewnienia alternatyw, co czyni nawigację klawiaturą niemal niemożliwą. Dotyczy to nie tylko użytkowników z niepełnosprawnościami ruchowymi, ale także wszystkich, którzy preferują nawigację klawiaturą, użytkowników zaawansowanych oraz osoby korzystające z urządzeń przełącznikowych.

Najczęstsze błędy klawiaturowe to: niestandardowe komponenty interaktywne zbudowane z tagów <div> lub <span>, które nigdy nie otrzymują fokusu; reguły CSS usuwające domyślny pierścień fokusu za pomocą outline: none lub outline: 0 bez zastąpienia go czymś równie widocznym; okna modalne, które nie przechwytują fokusu (więc użytkownicy klawiatury mogą tabulować „za” nakładkę); oraz karuzele czy akordeony, których nie da się obsłużyć bez myszy.

<!-- Niestandardowy przycisk niedostępny z klawiatury — błąd -->
<div class='btn' onclick='doSomething()'>Submit</div>

<!-- Poprawne: użyj prawdziwego przycisku -->
<button type='button' onclick='doSomething()'>Submit</button>

<!-- Usuwanie stylów fokusu — narusza WCAG 2.4.7 -->
* {
  outline: none; /* nigdy nie rób tego globalnie */
}

<!-- Lepsze: widoczny fokus przy zachowaniu estetyki -->
:focus-visible {
  outline: 3px solid #005fcc;
  outline-offset: 2px;
}

Pseudoklasa :focus-visible jest tu Twoim najlepszym sprzymierzeńcem. Pokazuje style fokusu, gdy użytkownik nawiguje klawiaturą, ale ukrywa je przy kliknięciach myszą — zapewniając czystą estetykę bez poświęcania dostępności. W przypadku modali i wysuwanych paneli użyj narzędzia przechwytującego fokus, które ogranicza nawigację tabulatorem do wnętrza dialogu, gdy jest otwarty, i przywraca fokus do elementu wywołującego po jego zamknięciu. Wyskakujące okna często pojawiają się bez odpowiedniego zarządzania fokusem, bez etykiet lub bez wsparcia dla nawigacji klawiaturą. Powoduje to poważne zakłócenia, zwłaszcza w krytycznych ścieżkach użytkownika, takich jak rejestracja, logowanie i proces zakupowy.

Poza pojedynczymi komponentami rozważ dodanie linku do pominięcia nawigacji — wizualnie ukrytego linku, który staje się widoczny po uzyskaniu fokusu i pozwala użytkownikom klawiatury przeskoczyć powtarzalną nawigację do głównej treści. Linki umożliwiające pominięcie powtarzalnej nawigacji są nieobecne w większości serwisów. To trzy linijki HTML i mały fragment CSS, a robi ogromną różnicę dla każdego, kto nawiguję po bogatej w treść stronie za pomocą klawiatury.

<!-- Umieść to jako pierwszy element wewnątrz <body> -->
<a href='#main-content' class='skip-link'>Skip to main content</a>

<!-- Następnie w CSS -->
.skip-link {
  position: absolute;
  left: -9999px;
}
.skip-link:focus {
  left: 0;
  top: 0;
  z-index: 9999;
}

Uwaga o ARIA: używaj ostrożnie

Wiele zespołów sięga po atrybuty ARIA (Accessible Rich Internet Applications) jako szybkie rozwiązanie luk w dostępności. Dane sugerują, że częściej przynosi to szkody niż korzyści. Około 79% ocenianych stron głównych używało ARIA, co stanowi wzrost w porównaniu z poprzednim rokiem. Strony główne z ARIA miały ponad dwukrotnie więcej błędów niż strony bez ARIA. Problemem nie jest samo ARIA — zwykle jest nim niewłaściwe lub błędne użycie ARIA. Wielu dobrze nastawionych deweloperów sądzi, że czyni treści bardziej dostępnymi, dodając ARIA, podczas gdy w rzeczywistości często czynią je mniej dostępnymi.

Przewodnia zasada jest prosta: najpierw używaj semantycznego HTML. <button> jest lepszy niż <div role='button'>. <nav> jest lepszy niż <div role='navigation'>. Natywne elementy HTML mają wbudowane zachowanie klawiatury, zarządzanie fokusem i domyślne role ARIA, które w przypadku niestandardowego kodu musisz odtwarzać ręcznie — a właśnie w tym ręcznym odtwarzaniu pojawiają się błędy. Zostaw ARIA na sytuacje, w których HTML naprawdę nie potrafi wyrazić potrzebnej semantyki, takie jak regiony dynamiczne, złożone widżety złożone czy dynamiczne zmiany stanu.

Wbudowywanie dostępności w proces pracy

Naprawianie istniejących naruszeń jest konieczne, ale zapobieganie pojawianiu się nowych odróżnia dojrzałe programy dostępności od jednorazowych sprintów zgodności. Dostępność nie jest jednorazową poprawką. Każda aktualizacja treści, zmiana projektu czy wdrożenie kodu może wprowadzić nowe problemy. Sześć kategorii błędów omówionych w tym przewodniku to zwykle problemy na poziomie szablonów — napraw nagłówek, stopkę i współdzielone komponenty, a wyeliminujesz problem na setkach stron jednocześnie.

Zintegruj automatyczne skanowanie z pipeline’em CI/CD, aby naruszenia były wychwytywane, zanim trafią na produkcję. Narzędzia takie jak axe-core można wbudować w testy jednostkowe i end‑to‑end. Połącz to z okresowymi ręcznymi przejściami klawiaturą i testami z czytnikami ekranu — VoiceOver na macOS i iOS, NVDA na Windows — ponieważ testy automatyczne mogą wykryć typowe błędy dostępności, ale testy manualne pomagają wypełnić luki. Dla zespołów potrzebujących szybszego startu widżet nakładki dostępności, taki jak Accsible, może ujawnić i zredukować znaczną klasę problemów na warstwie renderowania, podczas gdy długoterminowe poprawki w kodzie są planowane i wdrażane.

Na koniec zajmij się punktem o największej dźwigni w Twojej bazie kodu: szablonami. Większość stron korzysta z szablonów — nagłówka, stopki, nawigacji i układu strony, które powtarzają się na każdej podstronie. Problemy w tych szablonach mnożą się w całym serwisie. Napraw je najpierw, aby uzyskać maksymalny efekt. Pojedynczy poprawiony szablon bazowy może zamienić 10 000 naruszeń WCAG w zero jednym wdrożeniem.

Najważniejsze wnioski

• Sześć typów problemów dominuje w krajobrazie. Tekst o niskim kontraście, brak tekstu alternatywnego, nieopisane pola formularzy, puste linki i przyciski, brak języka dokumentu oraz uszkodzona nawigacja klawiaturą odpowiadają za przytłaczającą większość naruszeń WCAG. Naprawienie tych sześciu kategorii daje nieproporcjonalnie duże efekty względem włożonego wysiłku.
• Większość poprawek to zmiany w CSS lub jednolinijkowe zmiany w HTML. Dodanie lang='en' do znacznika <html>, zastąpienie outline: none stylami :focus-visible oraz powiązanie etykiet z polami to godziny pracy, nie miesiące — a eliminują błędy, które dotykają każdego użytkownika z niepełnosprawnością odwiedzającego Twoją stronę.
• Szablony to miejsce o największej dźwigni. Błędy dostępności we współdzielonych komponentach i szablonach stron replikują się w całym serwisie. Najpierw przeanalizuj nagłówek, stopkę, nawigację i formularze — naprawienie ich tam naprawia je wszędzie.
• ARIA to narzędzie ostatniej szansy, nie pierwszej reakcji. Strony, które mocno polegają na ARIA bez solidnych podstaw w semantycznym HTML, mają zwykle znacznie więcej błędów dostępności, a nie mniej. Preferuj natywne elementy HTML wszędzie tam, gdzie to możliwe.
• Automatyczne skanowanie wychwytuje mniej niż połowę rzeczywistych problemów. Uzupełnij narzędzia testami manualnymi z użyciem klawiatury i czytników ekranu, aby znaleźć błędy, których żaden skaner nie pokaże, w tym pułapki fokusu, problemy z logiczną kolejnością tabulacji oraz dynamiczne treści, które nie ogłaszają zmian.