Najczęstsze błędy dostępności na stronach internetowych – przewodnik ekspercki cz. 1

Dostępność cyfrowa to dziś nie tylko dobry zwyczaj, ale przede wszystkim wymóg prawny (ustawa o dostępności cyfrowej, rozporządzenie WCAG 2.1) oraz standard pozytywnego wizerunku marki. Niestety w praktyce większość serwisów boryka się z poważnymi niedociągnięciami, które uniemożliwiają lub utrudniają korzystanie ze strony osobom z różnymi niepełnosprawnościami – lecz także zwykłym użytkownikom. Poniżej omawiamy najczęściej spotykane błędy, ilustrujemy je przykładami i podpowiadamy dobre praktyki naprawcze.

Brak deklaracji dostępności

Opis błędu

Wymóg publikowania deklaracji dostępności dotyczy wszystkich instytucji publicznych i organizacji użyteczności publicznej. To dokument, w którym administrator strony opisuje stan zgodności z przepisami i procedurę zgłaszania uwag. Często deklaracja:

• w ogóle nie jest publikowana,
• ukryta jest w trudno dostępnym miejscu (np. w regulaminach, załącznikach PDF),
• nie była aktualizowana od roku lub dłużej.

Skutki

Brak jasnej deklaracji pozbawia użytkowników (zwłaszcza z niepełnosprawnościami) informacji, jak zgłaszać problemy, ocenę aktualnego stanu i harmonogram poprawy dostępności. W konsekwencji rośnie ryzyko złamania prawa i utraty zaufania.

Dobre praktyki

• Wyeksponuj deklarację w stopce każdej podstrony.
• Zadbaj o czytelny, prosty język i wyjaśnienie, na jakim poziomie WCAG 2.1 (A/AA) strona spełnia wymagania.
• Aktualizuj dokument co roku (lub przy większych zmianach serwisu).

Niepoprawne zachowanie przy powiększeniu (200%)

Opis błędu

Wytyczne WCAG 2.1 (kryterium 1.4.4 Resize text) nakazują, by użytkownik mógł powiększyć tekst do 200% bez utraty czytelności lub funkcjonalności strony. Powszechnie zdarza się, że:

• układ „rozsypuje się” – elementy nachodzą na siebie, przesuwają w nieprzewidziane miejsca,
• tekst wypada poza kontenery lub jest obcinany,
• zmienione proporcje uniemożliwiają odczytanie fragmentów treści.

Skutki

Osoby słabowidzące lub po prostu korzystające z niewielkich ekranów (np. smartfony) nie są w stanie przeczytać tekstu ani skorzystać z linków/przycisków.

Dobre praktyki

• Stosuj elastyczne jednostki (em, rem) zamiast pikseli.
• Unikaj absolutnego pozycjonowania i nakładania elementów.
• Testuj responsywność przy różnych poziomach powiększenia na desktopie i urządzeniach przenośnych.

Zaburzona kolejność tabulacji i pułapki klawiaturowe

Opis błędu

Nawigacja klawiaturowa (Tab + Shift + Tab) to podstawowe narzędzie dla osób niewidomych i mających problemy motoryczne. Najczęstsze przewinienia:

• niewłaściwy porządek tabindex – elementy nie występują w logicznej kolejności wizualnej,
• brak możliwości „wyjścia” z modalnych warstw (overlay, dialog), czyli tzw. pułapka klawiaturowa,
• menu i formularze, które nie otwierają się po najechaniu lub aktywacji klawiszem.

Skutki

Użytkownicy klawiatury nie mogą dotrzeć do wszystkich elementów strony lub utknąć w obszarze, z którego nie ma „wyjścia”.

Dobre praktyki

• Nie ustawiaj dodatnich wartości tabindex — pozwól przeglądarce samodzielnie wyznaczyć porządek.
• Upewnij się, że po zamknięciu modalnego dialogu fokus wraca do elementu, który go wcześniej otworzył.
• Testuj stronę wyłącznie klawiaturą – każdy interaktywny element musi być dostępny.

Niewystarczająca nawigacja i nieczytelne menu

Opis błędu

Struktura menu powinna być prosta i konsekwentna. Błędy, które widzimy najczęściej:

• podmenu otwiera się tylko na hover, ale nie na focus,
• kontrast tekstu/menu z tłem jest niewystarczający (< 4,5:1 dla tekstu standardowego),
• brak opisów ARIA dla elementów rozwijanych (aria-expanded, aria-controls),
• zbyt głębokie drzewo nawigacji, bez jasnej informacji o poziomie zagłębienia.

Skutki

Trudności w orientacji – użytkownik nie wie, w którym miejscu struktury jest, nie może sprawnie przejść do interesującej sekcji.

Dobre praktyki

• Zapewnij, by podmenu otwierało się również po naciśnięciu klawisza Enter lub Space.
• Użyj opisowych atrybutów ARIA i roli navigation.
• Ogranicz poziomy zagłębienia do 2–3 warstw i daj użytkownikowi informację, ile poziomów jeszcze musi pokonać.

Błędne kontrasty kolorystyczne

Opis błędu

Kontrast to jeden z najprostszych do wykrycia i naprawienia problemów, a jednak…

• tekst na tle obrazka bez półprzezroczystego overlaya,
• linki i przyciski o jasnych barwach zbliżonych do tła (np. żółty na białym),
• elementy wykorzystywane przy wysokim kontraście (systemowy tryb inwersji kolorów) zupełnie nieczytelne.

Skutki

Osoby ze słabym wzrokiem albo daltonizmem nie widzą treści, gubią się w interfejsie, nie rozpoznają przycisków i łączy.

Dobre praktyki

• Sprawdzaj kontrast z narzędziami: ARC Toolkit, Lighthouse, Colour Contrast Analyzer.
• Stosuj minimalne wartości WCAG: 4,5:1 (tekst normalny), 3:1 (duży tekst ≥18 pt lub 14 pt pogrubiony).
• Planuj design tak, by sam wygląd przycisków (kształt, obrys) wprowadzał rozróżnienie oprócz koloru.

Automatycznie przewijające się slajdy (karuzele)

Opis błędu

Slider na stronie głównej to powszechny element marketingowy, ale bardzo problematyczny, gdy:

• zmiana slajdów następuje automatycznie, bez pauzy i możliwości ręcznej kontroli,
• tempo przewijania jest zbyt szybkie (< 5 s),
• brak przycisków „pauza/play” lub widocznej nawigacji pomiędzy slajdami,
• brak wsparcia klawiatury oraz czytników ekranowych (ARIA live regions).

Skutki

Użytkownicy mający problemy z koncentracją lub wrażliwi na ruch nie nadążają za treścią, tracą orientację. Slider może „zabijać” użyteczność danego bloku, bo użytkownik nawet na niego nie wejdzie.

Dobre praktyki

• Dodaj zawsze kontrolki: play/pause, poprzedni/następny slajd.
• Ustaw domyślnie pauzę i pozostaw użytkownikowi decyzję o automatycznym odtwarzaniu.
• Dla czytników ekranowych zadbaj o aria-live="polite" i odpowiednie role.
• Testuj dostępność sliderów na urządzeniach mobilnych i bez użycia myszy.

Podsumowanie i podejście do raportu

1. Priorytetyzacja problemów:

   • Zacznij raport od najbardziej rażących barier (np. zasłaniający cały ekran overlay, brak deklaracji dostępności).
   • Następnie przejdź do błędów na poziomie WCAG A (np. tabulacja, powiększenie 200%).
   • Na końcu omów kwestie poziomu AA (kontrast, struktura ARIA, automatyzacja sliderów).

2. Dokumentuj dowodami

   • Zamieszczaj screenshoty (szczególnie z mobilnej wersji).
   • Podawaj odniesienia do konkretnych kryteriów WCAG (np. 1.4.4, 2.1.1, 2.2.2).
   • Opisuj, kto i w jaki sposób odczuwa dany problem (osoba niewidoma, słabowidząca, motorika).

3. Język i edukacja

   • Zakładaj, że czytelnik raportu nie zna szczegółów dostępności – tłumacz pojęcia prosto i obrazowo.
   • Dodaj przykłady, case study, efekty „przed i po” wdrożeniu poprawek.

4. Rekomendacje

   • Każdy opisywany błąd zakończ prostą, techniczną radą: fragment kodu ARIA, przykład CSS, wskazówka do narzędzia auditowego.
   • Ustal harmonogram poprawek (np. najpilniejsze do miesiąca, reszta w ciągu kwartału).

Dbanie o dostępność to proces ciągły – naprawienie pojedynczych błędów to tylko początek. Kluczem jest wdrożenie w organizacji kultury „dostępności od serca”, regularne audyty i wczesna weryfikacja nowych funkcji. Dzięki temu strona stanie się bardziej przyjazna dla wszystkich użytkowników – a równocześnie zgodna z prawem i najlepszymi praktykami UX.