Częste błędy dostępności, których należy unikać

Dlaczego wciąż pojawiają się te same problemy z dostępnością

Większość barier nie jest egzotyczna. Rok po roku audyty automatyczne i ręczne ujawniają tę samą krótką listę błędów: brakujący tekst alternatywny, niski kontrast, nieopisane pola formularzy, pułapki klawiaturowe oraz uszkodzoną strukturę. Powracają, ponieważ są wprowadzane niezauważalnie — programista wdraża nowy komponent, marketingowiec przesyła obraz, projektant wybiera kolor marki — a nic w normalnym przepływie pracy nie sygnalizuje problemu. Efekt wizualny wygląda dobrze dla kogoś, kto używa myszy i ma sokoli wzrok, więc bariera trafia na produkcję.

Ten katalog omawia najczęstsze naruszenia WCAG 2.2, które widujemy w rzeczywistych audytach. Dla każdego z nich znajdziesz, dlaczego ma znaczenie, kogo dotyczy, odpowiednie kryterium sukcesu oraz konkretną poprawkę przed i po. Razem te problemy odpowiadają za zdecydowaną większość barier blokujących osoby z niepełnosprawnościami — oraz za zdecydowaną większość skarg prawnych składanych na podstawie European Accessibility Act, ADA i Section 508.

Jedna rzecz do wyjaśnienia przed listą: narzędzia automatyczne nie potrafią znaleźć wszystkich tych problemów. Niezależne badania konsekwentnie pokazują, że nawet najlepsze skanery niezawodnie wykrywają tylko 30–40% problemów WCAG. Świetnie radzą sobie z wychwytywaniem brakujących atrybutów alt, programowo wykrywalnych błędów kontrastu i brakujących etykiet formularzy, ale nie potrafią ocenić, czy tekst alternatywny jest trafny, czy kolejność fokusu jest logiczna ani czy niestandardowy widżet faktycznie działa z czytnikiem ekranu. Dlatego każdy wiarygodny program łączy skanowanie z przeglądem ręcznym. Nasze oprogramowanie do skanowania dostępności obsługuje warstwę możliwą do zautomatyzowania; audyty ręczne oraz audyty przeprowadzane przez osoby z niepełnosprawnościami pokrywają resztę.

Szybki sposób, by znaleźć własny punkt wyjścia przed dalszą lekturą: wyświetl stronę z wyłączonymi obrazami, przeczytaj każde słowo jako jeden nieustrukturyzowany akapit i spróbuj wykonać każde zadanie wyłącznie za pomocą klawiatury. Wszędzie tam, gdzie doświadczenie się załamuje, znalazłeś barierę.

Postrzegalność: treści, których ludzie nie widzą ani nie czytają

Brakujący lub niedokładny tekst alternatywny obrazów

Kogo dotyczy: osoby niewidome lub słabowidzące korzystające z czytników ekranu; każdego na wolnym łączu, gdzie obrazy się nie ładują.

Kryterium WCAG: 1.1.1 Treść nietekstowa (Poziom A).

Obrazy bez atrybutu alt są niewidoczne dla technologii wspomagających — użytkownik może nawet nie wiedzieć, że obraz istnieje. Gorszy od brakującego atrybutu jest niedokładny: nazwy plików takie jak IMG_4821.jpg, ogólne słowa jak „obraz” czy ciągi naszpikowane słowami kluczowymi aktywnie wprowadzają słuchacza w błąd.

Reguła jest prosta, ale zależna od sytuacji. Obrazy informacyjne potrzebują zwięzłego opisu ich znaczenia, a nie wyglądu. Obrazy dekoracyjne, które nic nie wnoszą, powinny mieć puste alt="", aby czytniki ekranu je pomijały. Obrazy funkcjonalne — ikona pełniąca rolę przycisku — muszą opisywać czynność, a nie obrazek. Złożone elementy wizualne, takie jak wykresy, potrzebują krótkiego alt plus dłuższego odpowiednika tekstowego w pobliżu.

<!-- Before: useless, misleading -->
<img src="chart-final-v2.png">

<!-- After: meaningful for an informative image -->
<img src="chart-final-v2.png"
     alt="Revenue grew 24% between Q1 and Q4 2025">

<!-- After: decorative image, correctly hidden -->
<img src="divider-flourish.svg" alt="">

Narzędzia automatyczne natychmiast wychwytują brak tekstu alternatywnego. Nie powiedzą ci, czy tekst jest poprawny — to wymaga, by człowiek przeczytał stronę w kontekście.

Niewystarczający kontrast kolorów

Kogo dotyczy: osoby słabowidzące, z daltonizmem lub związaną z wiekiem utratą wzroku; każdego, kto korzysta z ekranu w jasnym świetle słonecznym.

Kryterium WCAG: 1.4.3 Kontrast (minimalny), Poziom AA; oraz 1.4.11 Kontrast elementów nietekstowych dla komponentów interfejsu.

WCAG 2.2 wymaga współczynnika kontrastu wynoszącego co najmniej 4,5:1 dla zwykłego tekstu i 3:1 dla dużego tekstu (mniej więcej 18 pt lub 14 pt pogrubiony). Komponenty interfejsu i istotna grafika — obramowania pól wejściowych, wskaźniki fokusu, ikony przekazujące stan — muszą osiągać 3:1 względem otoczenia. Błędy kontrastu należą do najczęstszych problemów wykrywanych w każdym audycie na dużą skalę i niemal zawsze są wprowadzane na etapie projektowania.

/* Before: light gray on white = 2.8:1, fails AA */
.helper-text { color: #9a9a9a; background: #ffffff; }

/* After: 4.6:1, passes AA */
.helper-text { color: #717171; background: #ffffff; }

Testuj całą paletę, nie tylko tekst główny: tekst zastępczy (placeholder), wyłączone stany, które wciąż muszą być czytelne, komunikaty o błędach oraz tekst nałożony na zdjęcia to częsti winowajcy. Nigdy nie polegaj wyłącznie na kolorze, by przekazać znaczenie (1.4.1) — czerwone obramowanie nieprawidłowego pola musi być uzupełnione tekstem lub ikoną.

Automatycznie odtwarzane media i ruch

Kogo dotyczy: osoby z zaburzeniami przedsionkowymi, niepełnosprawnościami uwagi lub poznawczymi, użytkowników czytników ekranu, których wyjście dźwiękowe zostaje zagłuszone, oraz każdego w cichej, wspólnej przestrzeni.

Kryteria WCAG: 1.4.2 Kontrola dźwięku (Poziom A), 2.2.2 Pauza, zatrzymanie, ukrycie (Poziom A), 2.3.1 Trzy błyski (Poziom A) oraz 2.3.3 Animacja wywoływana interakcją (Poziom AAA).

Dźwięk lub wideo odtwarzane automatycznie dłużej niż trzy sekundy muszą oferować oczywisty sposób na wstrzymanie lub wyciszenie. Poruszające się, migające lub automatycznie aktualizujące się treści trwające dłużej niż pięć sekund — karuzele, animowane banery, paski przewijane — potrzebują dostępnego elementu sterującego pauzą. Treści migające częściej niż trzy razy na sekundę mogą wywołać napady padaczkowe i należy ich całkowicie unikać. Uszanuj ustawienie prefers-reduced-motion użytkownika, aby złagodzić nieistotną animację.

/* After: honour the user's OS-level motion preference */
@media (prefers-reduced-motion: reduce) {
  *, *::before, *::after {
    animation-duration: 0.01ms !important;
    transition-duration: 0.01ms !important;
  }
}

Funkcjonalność: rzeczy, z których ludzie nie mogą korzystać

Niedostępność klawiaturowa i pułapki klawiaturowe

Kogo dotyczy: osoby z niepełnosprawnościami ruchowymi, które nie mogą używać myszy, użytkowników czytników ekranu (poruszających się za pomocą klawiatury) oraz osoby korzystające z urządzeń przełączających lub sterowania głosem.

Kryteria WCAG: 2.1.1 Klawiatura (Poziom A) i 2.1.2 Brak pułapki na klawiaturę (Poziom A).

Każda interakcja — linki, przyciski, pola formularzy, menu, okna modalne, selektory dat, przeciąganie i upuszczanie — musi być w pełni obsługiwalna samą klawiaturą. Najbardziej szkodliwym wariantem jest pułapka klawiaturowa: fokus wchodzi do komponentu (często okna modalnego lub osadzonego widżetu) i nie może się z niego wydostać, pozostawiając użytkownika uwięzionego na stronie. Niestandardowe widżety są zwykle winowajcami, ponieważ natywne elementy takie jak <button> i <a> są domyślnie obsługiwane klawiaturą, podczas gdy imitacje oparte na <div> już nie.

<!-- Before: not focusable, not operable by keyboard -->
<div class="btn" onclick="submit()">Submit</div>

<!-- After: native element, free keyboard support -->
<button type="submit">Submit</button>

Przejdź swoje kluczowe ścieżki, używając wyłącznie Tab, Shift+Tab, klawiszy strzałek, Enter, Spacji i Escape. Upewnij się, że fokus zawsze może poruszać się do przodu oraz wyjść z każdego komponentu, że Escape zamyka nakładki i że nic nie wymaga wskaźnika. Nasza usługa oceny z czytnikiem ekranu testuje dokładnie te przepływy w taki sposób, w jaki doświadczają ich rzeczywiści użytkownicy technologii wspomagających.

Brakujące lub niewidoczne wskaźniki fokusu i nielogiczna kolejność fokusu

Kogo dotyczy: widzących użytkowników klawiatury, użytkowników słabowidzących oraz każdego, kto stracił orientację, gdzie znajduje się na stronie.

Kryteria WCAG: 2.4.7 Widoczny fokus (Poziom A) i 2.4.3 Kolejność fokusu (Poziom A); 2.4.11 Fokus niezasłonięty (Poziom AA) w WCAG 2.2.

Częstym błędem „porządkowym” jest usunięcie domyślnego pierścienia fokusu przeglądarki za pomocą outline: none i nigdy go nie zastąpienie. Użytkownicy klawiatury nie mają pojęcia, który element jest aktywny. Równie szkodliwa jest kolejność fokusu, która nie odpowiada wizualnej i logicznej kolejności czytania — zwykle spowodowana dodatnimi wartościami tabindex lub kolejnością DOM rozbieżną z renderowanym układem.

/* Before: focus ring deleted, keyboard users lost */
:focus { outline: none; }

/* After: a clear, high-contrast indicator */
:focus-visible {
  outline: 3px solid #0b5cff;
  outline-offset: 2px;
}

WCAG 2.2 dodaje 2.4.11: gdy element otrzymuje fokus, nie może być całkowicie ukryty za przyklejonymi nagłówkami, banerami cookie lub widżetami czatu. Otwórz okno modalne, przejdź przez nie tabulatorem i potwierdź, że element z fokusem nigdy nie jest przesłonięty.

Nieopisowe linki i przyciski

Kogo dotyczy: użytkowników czytników ekranu, którzy przywołują listę wszystkich linków, by przejrzeć stronę, oraz osoby z niepełnosprawnościami poznawczymi.

Kryteria WCAG: 2.4.4 Cel linku (w kontekście), Poziom A; 2.5.3 Etykieta w nazwie, Poziom A.

Użytkownicy czytników ekranu często nawigują, przeskakując między linkami poza kontekstem. Strona pełna linków „kliknij tutaj”, „czytaj więcej” i „dowiedz się więcej” staje się bez znaczenia, gdy jest odczytywana jako lista. Tekst linku powinien sam opisywać swój cel. To samo dotyczy przycisków z samą ikoną, które potrzebują dostępnej nazwy.

<!-- Before: ambiguous out of context -->
<a href="/resources/wcag">Read more</a>

<!-- After: self-describing -->
<a href="/resources/wcag">Read our WCAG 2.2 compliance guide</a>

<!-- Icon button with an accessible name -->
<button aria-label="Close dialog">
  <svg aria-hidden="true">…</svg>
</button>

Przeładowana nawigacja i brak możliwości jej pominięcia

Kogo dotyczy: użytkowników czytników ekranu, użytkowników klawiatury oraz osoby z niepełnosprawnościami poznawczymi.

Kryterium WCAG: 2.4.1 Możliwość pominięcia bloków (Poziom A).

Mega-menu z dziesiątkami linków zmusza użytkowników czytników ekranu i klawiatury do brnięcia przez całą listę na każdej stronie, zanim dotrą do treści. Link „Przejdź do treści głównej” jako pierwszy element możliwy do sfokusowania pozwala im przeskoczyć od razu poza powtarzające się bloki. Grupuj powiązane pozycje, utrzymuj menu zwięzłe i zadbaj, by link pomijający stawał się widoczny po otrzymaniu fokusu.

<!-- After: first focusable element on the page -->
<a class="skip-link" href="#main">Skip to main content</a>
…
<main id="main">…</main>

Zrozumiałość: treści, które wprowadzają w błąd

Nieopisane lub nieprawidłowo powiązane pola formularzy

Kogo dotyczy: użytkowników czytników ekranu, osób z niepełnosprawnościami poznawczymi oraz użytkowników sterowania głosem, którzy odnoszą się do pól po nazwie.

Kryteria WCAG: 1.3.1 Informacje i relacje, 3.3.2 Etykiety lub instrukcje oraz 4.1.2 Nazwa, rola, wartość (wszystkie Poziom A).

Pola wejściowe bez programowo powiązanej etykiety <label> są odczytywane jako „edycja tekstu, puste” — użytkownik nie ma pojęcia, co wpisać. Tekst zastępczy (placeholder) nie jest zamiennikiem: znika po wprowadzeniu danych i zwykle nie spełnia wymogu kontrastu. Pola wymagane, reguły formatowania i błędy walidacji również muszą być przekazywane tekstem, a nie wyłącznie kolorem czy położeniem.

<!-- Before: placeholder masquerading as a label -->
<input type="email" placeholder="Email">

<!-- After: explicit, associated label + described error -->
<label for="email">Email address</label>
<input type="email" id="email"
       aria-describedby="email-err" aria-invalid="true">
<p id="email-err">Enter a valid email, e.g. name@example.com</p>

Powiąż komunikaty o błędach z ich polem za pomocą aria-describedby, oznacz nieprawidłowe pola atrybutem aria-invalid i zadbaj, by wysłanie niekompletnego formularza przenosiło fokus do pierwszego błędu.

Brakujący język strony

Kogo dotyczy: użytkowników czytników ekranu — niewłaściwy język powoduje, że syntezator wymawia wszystko błędnie.

Kryteria WCAG: 3.1.1 Język strony (Poziom A) i 3.1.2 Język części (Poziom AA).

Jeden brakujący atrybut psuje wymowę całej strony. Zadeklaruj język główny na elemencie głównym i oznacz fragmenty w innym języku ich własnym atrybutem lang.

<!-- Before -->
<html>

<!-- After -->
<html lang="en">
  …
  <blockquote lang="fr">Le client a raison.</blockquote>

Nieprawidłowa hierarchia nagłówków i brakujące punkty orientacyjne

Kogo dotyczy: użytkowników czytników ekranu, którzy nawigują po nagłówkach i regionach, oraz każdego, kto polega na strukturze dokumentu.

Kryterium WCAG: 1.3.1 Informacje i relacje (Poziom A).

Nagłówki są konspektem strony. Użytkownicy czytników ekranu przeskakują od nagłówka do nagłówka, by szybko znaleźć treść; gdy poziomy są pomijane, używane wyłącznie dla rozmiaru czcionki lub nieobecne, ta nawigacja się załamuje. Każda strona powinna mieć jeden <h1> oraz logiczną, nieprzerwaną sekwencję <h2>, <h3> i tak dalej. Równie ważne są regiony orientacyjne — <header>, <nav>, <main>, <footer> — które pozwalają użytkownikom przeskakiwać między głównymi obszarami. Strona zbudowana w całości z elementów <div> nie oferuje takiej mapy.

<!-- After: semantic landmarks + ordered headings -->
<header>…</header>
<nav aria-label="Primary">…</nav>
<main>
  <h1>Common accessibility issues</h1>
  <h2>Perceivable</h2>
    <h3>Missing alt text</h3>
</main>
<footer>…</footer>

Solidność: kod, którego technologie wspomagające nie potrafią zinterpretować

Niedostępne niestandardowe widżety i błędnie używane ARIA

Kogo dotyczy: przede wszystkim użytkowników czytników ekranu oraz każdej technologii wspomagającej, która polega na poprawnym drzewie dostępności.

Kryterium WCAG: 4.1.2 Nazwa, rola, wartość (Poziom A).

Niestandardowe listy rozwijane, karty, akordeony, pola kombi, okna modalne i podpowiedzi zbudowane z <div> i <span> nie mają wbudowanej roli, stanu ani zachowania klawiaturowego. Programiści sięgają po ARIA, by to załatać, ale ARIA jedynie opisuje — nie dodaje żadnego zachowania, a błędne ARIA jest gorsze niż jego brak. Pierwsza zasada ARIA mówi, by preferować natywny element HTML zawsze, gdy taki istnieje. Gdy musisz zbudować niestandardowy widżet, zaimplementuj pełną interakcję klawiaturową określoną przez wzorce projektowe ARIA i utrzymuj aria-expanded, aria-selected oraz podobne stany w zgodzie z rzeczywistością.

<!-- Before: a div pretending to be a control, no role or state -->
<div class="dropdown" onclick="toggle()">Choose plan ▾</div>

<!-- After: correct role, name, and state -->
<button aria-expanded="false" aria-controls="plan-list">
  Choose plan
</button>
<ul id="plan-list" role="listbox" hidden>…</ul>

To właśnie te problemy automatyczne skanery pomijają najczęściej. Skaner widzi atrybut aria-expanded i go przepuszcza; tylko człowiek (lub tester korzystający z czytnika ekranu) może potwierdzić, że wartość faktycznie się przełącza, gdy menu się otwiera. Zobacz nasz przewodnik po testowaniu z czytnikiem ekranu, aby dowiedzieć się, jak zweryfikować zachowanie widżetu od początku do końca.

Uwaga o widżetach nakładkowych

Kuszące jest zainstalowanie jednoliniowego „widżetu dostępności” lub nakładki, która obiecuje natychmiastową zgodność. Te narzędzia nie naprawiają powyższych problemów — tekst alternatywny wciąż brakuje w źródle, kontrast wciąż jest niewystarczający, niestandardowy widżet wciąż nie działa. Nakładki nie potrafią naprawić kodu wywołującego bariery, często zakłócają działanie własnych technologii wspomagających użytkowników i pojawiają się w rosnącej liczbie pozwów dotyczących dostępności. Prawdziwa dostępność cyfrowa bierze się z naprawiania bazowego HTML, CSS i zachowania, a nie z ich maskowania.

Powstrzymaj powracanie tych problemów

Jednorazowe naprawienie listy błędów jest konieczne, ale niewystarczające; te same problemy pojawią się ponownie przy następnym wydaniu, o ile nie zmienisz sposobu wdrażania. Trwałym rozwiązaniem jest wbudowanie dostępności w przepływ pracy:

Wychwytuj wcześnie możliwe do zautomatyzowania 30–40%, podłączając skany do swojego potoku. Integracja dostępności z CI/CD sprawia, że kompilacja kończy się niepowodzeniem, gdy zostanie wprowadzona regresja, zanim trafi ona na produkcję.
Resztę pokryj ludźmi. Zaplanuj ręczne audyty dostępności oraz audyty przeprowadzane przez osoby z niepełnosprawnościami, które ujawniają bariery, jakich żadne narzędzie nie wykryje.
Daj zespołom właściwe narzędzia. Zestaw narzędzi dostępności QualiBooth oraz Agora pomagają projektantom i programistom testować w trakcie pracy.
Uczyń z tego proces, a nie projekt. Bieżące doradztwo w zakresie dostępności oraz usprawnianie procesu dostępności zakorzeniają nawyki, dzięki czemu jakość utrzymuje się w czasie.

Po szczegółową mapę drogową naprawiania krok po kroku zacznij od naszego przewodnika o tym, jak sprawić, by Twoja strona była zgodna z WCAG.

Od czego zacząć dzisiaj

Ponad 1,3 miliarda ludzi na świecie żyje z jakąś formą niepełnosprawności, więc biznesowe uzasadnienie dla dostępności jest jasne — a od czerwca 2025 r. jasne jest również uzasadnienie prawne na mocy European Accessibility Act. Problemy z tego katalogu to te, które są badane w pierwszej kolejności w każdej skardze lub audycie.

Najszybszym sposobem, by sprawdzić, na czym stoisz, jest uruchomienie bezpłatnego skanowania adresu URL — bez konfiguracji, bez zobowiązań. Gdy będziesz gotów wyjść poza to, co potrafi osiągnąć automatyzacja, poproś o demo, a pokażemy Ci, jak połączony program automatyczny i ręczny domyka pozostałą lukę.