Dostępność stron oznacza, że mogą z nich korzystać także osoby z niepełnosprawnościami wzroku, słuchu, ruchu i funkcji poznawczych. W 2026 roku to wymóg prawny, sygnał rankingowy i element dobrego rzemiosła. Niedostępne witryny wykluczają szacunkowo 1,3 miliarda ludzi na świecie i coraz częściej narażają firmy na konsekwencje regulacyjne.
Czym jest web accessibility?
Web accessibility (skrót a11y — „a” + 11 liter + „y”) to praktyka projektowania i tworzenia stron w taki sposób, aby osoby z niepełnosprawnościami mogły postrzegać, rozumieć, nawigować i korzystać z nich skutecznie.
Niepełnosprawności istotne z punktu widzenia korzystania z internetu obejmują:
- Wzrokowe – ślepota, słabowzroczność, daltonizm
- Słuchowe – głuchota, niedosłuch
- Ruchowe – ograniczona precyzja ruchów, brak możliwości korzystania z myszy
- Poznawcze – dysleksja, ADHD, zaburzenia pamięci, spektrum autyzmu
- Sytuacyjne – złamana ręka, ostre światło słoneczne na ekranie, wolne połączenie internetowe
Dostępny projekt może ułatwić korzystanie ze strony także osobom bez trwałej niepełnosprawności. Napisy pomagają w hałaśliwym otoczeniu, dobry kontrast w ostrym słońcu, a obsługa klawiaturą — osobom, które wolą taki sposób nawigacji.
Dlaczego dostępność ma tak duże znaczenie w 2026 roku?
Wymogi prawne
Przepisy dotyczące dostępności zmieniały się w ostatnich latach w wielu krajach:
| Region | Przepisy | Wymagany standard |
|---|---|---|
| Unia Europejska | European Accessibility Act (EAA) — obowiązuje od czerwca 2025 | WCAG 2.1 AA |
| Stany Zjednoczone | ADA Title III, Section 508 | WCAG 2.1 AA |
| Wielka Brytania | Equality Act 2010, Public Sector Bodies Accessibility Regulations | WCAG 2.1 AA |
| Kanada | AODA, ACA | WCAG 2.0 AA |
Europejski European Accessibility Act obowiązuje od czerwca 2025 roku i obejmuje prywatne firmy oferujące produkty oraz usługi cyfrowe, nie tylko administrację publiczną. Brak zgodności może oznaczać kary finansowe i spory prawne.
Dostępność a SEO
Dostępność i SEO często opierają się na tych samych praktykach, takich jak semantyczna struktura, opisy linków i poprawnie oznaczone obrazy:
- Alt text przy obrazach pomaga zarówno czytnikom ekranu, jak i Google Image Search
- Semantyczny HTML (poprawna struktura nagłówków, landmarki) pomaga technologiom asystującym i robotom zrozumieć strukturę strony
- Opisowe anchor texty poprawiają użyteczność i sygnały linkowania wewnętrznego
- Szybkie ładowanie strony pomaga użytkownikom z trudnościami poznawczymi i poprawia Core Web Vitals
- Czytelna, jasna treść wspiera zarówno wytyczne WCAG, jak i Helpful Content System Google
Argument biznesowy
Dostępne strony regularnie osiągają lepsze wyniki niż niedostępne. Dotyczy to między innymi:
- większa grupa odbiorców — 15–20% populacji świata ma jakąś formę niepełnosprawności
- mniejsze ryzyko pozwów związanych z dostępnością
- lepszy wizerunek marki i większa lojalność klientów
- lepsze doświadczenie mobilne — poprawki dostępności szczególnie pomagają użytkownikom mobile
WCAG 2.2 – obowiązujący standard
Web Content Accessibility Guidelines (WCAG), opracowane przez W3C Web Accessibility Initiative (WAI), to międzynarodowy standard techniczny dostępności stron. Aktualną stabilną wersją jest WCAG 2.2, opublikowane w październiku 2023 roku.
Poziomy zgodności
WCAG określa trzy poziomy zgodności:
| Poziom | Opis | Wymagany przez |
|---|---|---|
| A | Minimalna dostępność — usuwa najpoważniejsze bariery | wszystkie regulacje |
| AA | Standardowy poziom dostępności — cel prawny w większości jurysdykcji | EAA, ADA, Section 508 |
| AAA | Maksymalna dostępność — niewymagana prawnie, aspiracyjna | tylko best practice |
Wiele organizacji przyjmuje WCAG 2.2 na poziomie AA jako cel prac nad dostępnością.
Cztery zasady POUR
Kryteria WCAG opierają się na czterech zasadach:
- Perceivable (Postrzegalne) – informacje muszą być prezentowane w sposób możliwy do odebrania przez użytkownika
- Operable (Funkcjonalne) – elementy interfejsu muszą być obsługiwalne dla wszystkich użytkowników
- Understandable (Zrozumiałe) – treść i działanie interfejsu muszą być zrozumiałe
- Robust (Solidne / odporne) – treść musi być wystarczająco poprawna technicznie, by mogły ją interpretować technologie asystujące
Semantyczny HTML – fundament dostępności
Jednym z najważniejszych kroków jest używanie semantycznego HTML-a. Elementy takie jak <main> czy <nav> przekazują strukturę przeglądarce i technologiom asystującym.
Używaj właściwego elementu do właściwego celu
<!-- Źle — div soup bez znaczenia semantycznego -->
<div class="button" onclick="submit()">Wyślij</div>
<div class="header">Tytuł strony</div>
<div class="nav">Menu</div>
<!-- Dobrze — semantyczny HTML działający od razu -->
<button type="submit">Wyślij</button>
<h1>Tytuł strony</h1>
<nav>Menu</nav>
Natywny <button> można od razu obsługiwać klawiaturą i poprawnie rozpoznają go czytniki ekranu. <div> z onclick nie zapewnia tych zachowań bez dodatkowego kodu.
Elementy landmark w HTML
Landmarki oznaczają główne obszary strony, dzięki czemu użytkownicy czytników ekranu mogą szybciej przejść do potrzebnej sekcji:
| Element | Rola | Zastosowanie |
|---|---|---|
<header> | banner | nagłówek strony, logo, główna nawigacja |
<nav> | navigation | menu nawigacyjne |
<main> | main | główna treść strony (jedna na stronę) |
<aside> | complementary | sidebar, powiązane treści |
<footer> | contentinfo | stopka strony |
<section> | region | wydzielone sekcje treści (powinny mieć accessible name) |
Hierarchia nagłówków
Logiczna kolejność nagłówków (H1 → H2 → H3) ułatwia orientację w treści. Wielu użytkowników czytników ekranu porusza się po stronie, przeglądając nagłówki.
Nigdy:
- nie pomijaj poziomów nagłówków
- nie używaj nagłówków wyłącznie do stylowania wizualnego
Nawigacja klawiaturą
Każdy element interaktywny powinien dać się obsłużyć samą klawiaturą.
To szczególnie ważne dla osób korzystających z:
- użytkowników z niepełnosprawnościami ruchowymi
- power userów
- osób korzystających z urządzeń alternatywnych
Focus management
- wszystkie linki, przyciski, pola formularzy i modale muszą otrzymywać focus
- focus musi być widoczny
- kolejność focusa musi być logiczna i zgodna z układem wizualnym
/* Nigdy tak nie rób bez zamiennika */
*:focus { outline: none; }
/* Zamiast tego */
*:focus-visible {
outline: 3px solid #005FCC;
outline-offset: 2px;
}
Keyboard traps
W modalu i własnym dropdownie zadbaj o:
- „zamykać” focus wewnątrz siebie podczas otwarcia
- po zamknięciu oddawać focus do elementu, który je otworzył
Skip links
Link „Przejdź do treści głównej” na początku strony pozwala pominąć powtarzającą się nawigację i od razu przejść do głównej treści.
<a href="#main-content" class="skip-link">Przejdź do treści głównej</a>
ARIA – Accessible Rich Internet Applications
ARIA dodaje atrybuty, które uzupełniają semantykę HTML, gdy natywny element jej nie zapewnia — na przykład w niestandardowych:
- zakładki
- akordeony
- slidery
- date pickery
Pierwsza zasada ARIA
Sięgaj po ARIA dopiero wtedy, gdy natywny HTML nie rozwiązuje problemu.
ARIA uzupełnia HTML, ale go nie zastępuje. Jeśli możesz użyć <button>, wybierz go zamiast <div role="button">.
Najważniejsze atrybuty ARIA
role– określa, czym jest elementaria-label– nadaje nazwę elementowi bez widocznego tekstuaria-labelledby– odwołuje się do tekstu innego elementu jako nazwyaria-describedby– odwołuje się do dodatkowego opisuaria-expanded– informuje, czy element zwijany jest rozwiniętyaria-hidden="true"– ukrywa element przed technologiami asystującymiaria-live– ogłasza dynamiczne zmiany treści
<!-- Custom modal z poprawnym ARIA -->
<div role="dialog" aria-modal="true" aria-labelledby="modal-title">
<h2 id="modal-title">Potwierdź działanie</h2>
<p>Czy na pewno chcesz usunąć ten element?</p>
<button>Potwierdź</button>
<button aria-label="Zamknij okno dialogowe">×</button>
</div>
Kolor i dostępność wizualna
Kontrast kolorów
WCAG 2.2 AA określa minimalne współczynniki kontrastu tekstu względem tła:
- 4.5:1 dla zwykłego tekstu
- 3:1 dla dużego tekstu
- 3:1 dla komponentów UI i elementów graficznych
Kontrast można sprawdzić między innymi w:
- WebAIM Contrast Checker
- Colour Contrast Analyser
Słaby kontrast należy do częstych błędów dostępności, a jego poprawa zwykle nie wymaga przebudowy strony.
Kolor nie może być jedynym nośnikiem informacji
Nie przekazuj informacji wyłącznie kolorem. Formularz, w którym błąd oznacza tylko czerwony kolor, może być nieczytelny dla osób z zaburzeniami rozpoznawania barw.
<!-- Źle — tylko kolor -->
<span style="color: red;">Błąd</span>
<!-- Dobrze — kolor + ikona + tekst -->
<span style="color: #D32F2F;">
<svg aria-hidden="true"><!-- ikona błędu --></svg>
Błąd: To pole jest wymagane
</span>
Ruch i animacje
Nadmierny ruch może powodować nudności lub dyskomfort u osób z zaburzeniami przedsionkowymi. Uwzględnij systemowe ustawienie prefers-reduced-motion:
@media (prefers-reduced-motion: reduce) {
*, *::before, *::after {
animation-duration: 0.01ms !important;
transition-duration: 0.01ms !important;
}
}
Formularze i dostępne inputy
Formularze są kluczową częścią wielu zadań, a przy tym często zawierają błędy dostępności.
Label
Z każdym polem formularza powiąż etykietę <label>, którą technologie asystujące mogą odczytać.
<!-- Źle — brak powiązanego labela -->
<input type="email" placeholder="Adres e-mail">
<!-- Dobrze — poprawne powiązanie -->
<label for="email">Adres e-mail</label>
<input type="email" id="email" name="email">
Placeholder nie zastępuje etykiety: znika po rozpoczęciu wpisywania i często ma zbyt niski kontrast.
Komunikaty o błędach
- muszą być opisane tekstowo
- muszą być powiązane z polem przez
aria-describedby - powinny być konkretne
Zamiast:
- „Nieprawidłowe dane”
Lepiej:
- „Adres e-mail musi zawierać znak @”
Autocomplete
Używaj atrybutu autocomplete, aby ułatwić wypełnianie formularzy:
<input type="text" autocomplete="given-name">
<input type="email" autocomplete="email">
<input type="tel" autocomplete="tel">
Obrazy i multimedia
Dobre praktyki alt textu
- Obrazy informacyjne – opisuj treść i funkcję
- Obrazy dekoracyjne – używaj pustego
alt="" - Obrazy funkcyjne – opisuj działanie, np. „Szukaj”, „Zamknij menu”
- Obrazy złożone – dodaj dłuższy opis przez
aria-describedbylub widoczny podpis
Wideo i audio
- każde wideo powinno mieć napisy
- treści audio powinny mieć transkrypcję
- wideo z ważnymi informacjami wizualnymi powinno mieć audiodeskrypcję
- nie używaj autoplay z dźwiękiem
Narzędzia do testowania dostępności
Testy automatyczne (wychwytują ok. 30–40% problemów)
- axe DevTools – standard branżowy
- Lighthouse – zakładka accessibility
- WAVE – wizualna analiza błędów
- Deque axe-core – integracja z CI/CD
Testy manualne (konieczne)
- nawigacja wyłącznie klawiaturą
- testy screen readerem
- testy zoomu 200% i 400%
- analiza kontrastu kolorów
Testy z prawdziwymi użytkownikami
Automaty nie wychwycą wszystkich barier. Testy z osobami z niepełnosprawnościami często ujawniają problemy, których nie zauważą skanery ani sami deweloperzy.
Nowe kryteria WCAG 2.2
WCAG 2.2 dodało kryteria szczególnie przydatne przy ocenie nowoczesnych aplikacji webowych:
| Kryterium | Poziom | Wymaganie |
|---|---|---|
| 2.4.11 Focus Appearance | AA | wskaźnik focusa musi mieć odpowiedni rozmiar i kontrast |
| 2.4.12 Focus Appearance (Enhanced) | AAA | ostrzejsze wymagania dla focusa |
| 2.4.13 Focus Appearance | AA | obszar focusa musi być wystarczający |
| 2.5.7 Dragging Movements | AA | funkcje drag & drop muszą mieć alternatywę |
| 2.5.8 Target Size (Minimum) | AA | cele interaktywne min. 24×24 px CSS |
| 3.2.6 Consistent Help | A | elementy pomocy muszą być w spójnym miejscu |
| 3.3.7 Redundant Entry | A | użytkownik nie powinien wpisywać tych samych danych ponownie |
| 3.3.8 Accessible Authentication | AA | logowanie nie może wymagać testów poznawczych |
Checklist audytu dostępności
Perceivable
- wszystkie obrazy mają odpowiedni alt text
- wideo ma poprawne napisy
- audio ma transkrypcję
- kontrast spełnia wymagania
- informacja nie jest przekazywana wyłącznie kolorem
prefers-reduced-motionjest respektowane
Operable
- cała funkcjonalność działa z klawiatury
- focus jest widoczny
- brak keyboard trapów
- skip link istnieje
- elementy interaktywne mają min. 24×24 px
- nic nie miga częściej niż 3 razy na sekundę
Understandable
- język strony zadeklarowany (
<html lang="pl">) - formularze mają widoczne i powiązane labele
- komunikaty o błędach są konkretne
- nawigacja jest spójna
- brak nieoczekiwanych zmian kontekstu
Robust
- HTML jest poprawny i uporządkowany
- jedna sekcja
<main>i logiczna struktura nagłówków - ARIA użyte poprawnie
- strona przetestowana co najmniej jednym screen readerem
- automatyczny skan axe nie wykazuje krytycznych błędów
Dodaj axe-core do pipeline’u CI/CD, aby wykrywać regresje dostępności przed wdrożeniem. Naprawa na tym etapie kosztuje ułamek pracy potrzebnej po publikacji i pomaga nadążyć za coraz bardziej restrykcyjnymi regulacjami.