W poprzednim artykule na naszym blogu, WCAG 2025 a dostępność cyfrowa strony internetowej, przedstawiliśmy ogólny przegląd nowego standardu WCAG 2.2, który zacznie obowiązywać od czerwca 2025 roku. Omówiliśmy podstawowe aspekty, takie jak znaczenie dostępności cyfrowej, podstawowe zasady standardu WCAG oraz główne obszary, na które zwraca on uwagę.
W tym poradniku technicznym skoncentrujemy się na konkretnych aspektach technicznych, które należy wprowadzić lub poprawić na stronie internetowej, aby spełnić wymogi WCAG 2.2, a także omówimy przygotowywane już zmiany w przyszłej wersji standardu – WCAG 3.0. Ten materiał będzie szczególnie przydatny dla web developerów, administratorów stron internetowych oraz specjalistów SEO, którzy chcą nie tylko zapewnić zgodność z aktualnymi przepisami, ale także skorzystać na poprawie widoczności w wyszukiwarkach internetowych.
Zgodność z WCAG 2.2 jest kluczowa nie tylko ze względu na obowiązujące regulacje prawne w Unii Europejskiej oraz Europejskim Obszarze Gospodarczym, ale również dlatego, że standard ten gwarantuje dostępność treści cyfrowych dla możliwie najszerszego grona odbiorców. Przestrzeganie wytycznych WCAG 2.2 pozwala uniknąć dyskryminacji osób z niepełnosprawnościami oraz zapewnia optymalną użyteczność serwisów internetowych.
WCAG 3.0, obecnie w fazie przygotowań, wprowadzi istotne zmiany mające na celu jeszcze bardziej uprościć stosowanie standardów oraz uwzględnić rozwój technologii cyfrowych. Nowa wersja skupi się na większej elastyczności, bardziej zrozumiałym języku oraz praktycznym podejściu do oceny dostępności stron internetowych. Dlatego już teraz warto śledzić zmiany, aby w przyszłości móc szybko i efektywnie dostosować się do nowych wymogów.
Zgodność z WCAG jest oceniana na trzech poziomach: A, AA i AAA. Poziom AA stanowi minimalny standard wymagany przez Unię Europejską oraz Europejski Obszar Gospodarczy (EAA) zgodnie z Europejskim Aktem o Dostępności (European Accessibility Act), który zacznie obowiązywać od 28 czerwca 2025 roku. Standard WCAG 2.1 na poziomie AA jest obecnie podstawą prawną dla dostępności cyfrowej stron internetowych i aplikacji mobilnych.
Wymogi dostępności na poziomie AA obejmują zapewnienie między innymi:
Audyt dostępności przeprowadzany zgodnie z WCAG 2.2 zapewnia pełną zgodność z wymogami obowiązującymi w UE/EAA oraz pomaga uniknąć ryzyka prawnego i poprawić dostępność cyfrową produktów i usług osobom z niepełnosprawnościami.
Jednym z podstawowych wymogów dostępności cyfrowej według wytycznych WCAG 2.2 jest zapewnienie pełnej obsługi strony internetowej za pomocą samej klawiatury. Użytkownicy powinni mieć możliwość poruszania się po wszystkich interaktywnych elementach – takich jak linki, przyciski, formularze czy menu – bez konieczności użycia myszy. Strona internetowa powinna zapewniać logiczny i przewidywalny porządek nawigacji (np. za pomocą klawisza TAB), co jest kluczowe dla osób niewidomych, z ograniczeniami ruchowymi lub korzystających z technologii wspomagających.
Nowe kryterium 2.4.11 wprowadzone w WCAG 2.2 dotyczy widoczności wskaźników fokusu. Każdy interaktywny element strony internetowej – taki jak przycisk czy link – musi posiadać wyraźnie widoczny fokus, który informuje użytkownika, gdzie aktualnie znajduje się kursor klawiatury. To kluczowe dla osób nawigujących bez użycia myszy.
Przykłdowe stylowanie fokusu można osiągnąć za pomocą CSS, np.:
button:focus, a:focus {
outline: 3px solid #005fcc;
outline-offset: 2px;
}
Zaleca się unikać całkowitego usuwania stylów fokusu (np. outline: none) bez zapewnienia alternatywnej, dostępnej formy wizualnej. Zapewnienie kontrastu wskaźnika względem tła i zachowanie jego widoczności na wszystkich urządzeniach i przy wszystkich motywach graficznych ma kluczowe znaczenie dla dostępności cyfrowej stron internetowych i aplikacji.
Każdy obraz na stronie internetowej powinien posiadać odpowiedni atrybut alt, który opisuje jego zawartość lub funkcję. Zgodnie z wytycznymi WCAG 2.2 (wcześniej WCAG 2.1), dostępność cyfrowa wymaga, aby wszystkie treści nietekstowe były zrozumiałe również dla osób korzystających z czytników ekranu lub innych technologii asystujących.
Dobrze przygotowane opisy alternatywne:
Dla obrazów czysto dekoracyjnych należy zastosować pusty atrybut alt=””, aby były pomijane przez czytniki ekranu. Opisy alternatywne są również ważnym elementem SEO, wpływając na indeksację treści graficznych przez wyszukiwarki internetowe.
Dostępność cyfrowa wymaga, aby wszystkie treści na stronie internetowej były czytelne również dla osób z ograniczeniami wzroku, w tym daltonizmem czy niską ostrością widzenia. Kryteria 1.4.3 i 1.4.11 w ramach WCAG 2.2 określają minimalne kontrasty kolorystyczne, które należy stosować, by tekst oraz elementy nietekstowe (np. ikony, przyciski, obramowania) były dobrze widoczne.
Minimalny kontrast dla tekstu wynosi 4.5:1 (dla tekstu normalnej wielkości) i 3:1 dla dużego tekstu (powyżej 18px lub 14px pogrubionego). W przypadku elementów nietekstowych, kontrast względem tła musi wynosić co najmniej 3:1.
Zaleca się korzystanie z narzędzi do analizy kontrastu (np. WebAIM Contrast Checker) na etapie projektowania i testowania interfejsu. Wysoki kontrast kolorystyczny poprawia nie tylko zgodność z wytycznymi WCAG, ale również komfort korzystania z usług cyfrowych przez wszystkich użytkowników – szczególnie w trudnych warunkach oświetleniowych czy na urządzeniach mobilnych.
Formularze powinny być jednoznacznie opisane i intuicyjne. Każde pole musi posiadać widoczną etykietę (
Zamiast polegać wyłącznie na placeholderach, warto stosować tekstowe etykiety powiązane atrybutem for z odpowiednim polem. Instrukcje powinny być zrozumiałe i widoczne także po rozpoczęciu wypełniania formularza. Dobrze zaprojektowany formularz ułatwia obsługę osobom z niepełnosprawnościami i minimalizuje liczbę porzuconych zamówień.
Gdy użytkownik popełni błąd podczas wypełniania formularza, strona powinna go o tym poinformować w sposób czytelny i zrozumiały, jednocześnie podpowiadając, jak poprawnie uzupełnić dane. Może to być np. komunikat „Wprowadź poprawny adres e-mail” zamiast ogólnego „Błąd formularza”.
Sugestie powinny być dostępne zarówno wizualnie, jak i dla czytników ekranu. Dobrą praktyką jest również oznaczenie błędnych pól kolorem oraz dodanie etykiety z podpowiedzią, co wymaga poprawy. Takie podejście znacząco zwiększa dostępność stron internetowych i poprawia doświadczenie użytkownika.
Materiały wideo publikowane na stronie internetowej powinny zawierać napisy oraz – jeśli to możliwe – transkrypcje. Napisy umożliwiają odbiór treści osobom niesłyszącym lub słabosłyszącym, ale też są przydatne w sytuacjach, gdy nie można odtworzyć dźwięku (np. w miejscu publicznym).
Z kolei transkrypcja stanowi alternatywną formę dostępu do treści multimedialnych w postaci tekstu. Powinna zawierać nie tylko dialogi, ale także opis istotnych dźwięków i kontekstu. W kontekście wytycznych WCAG 2.2 są to obowiązkowe elementy dla nagrań uprzednio zarejestrowanych, zapewniające zgodność z zasadami dostępności cyfrowej stron internetowych i aplikacji mobilnych.
Automatyczne odtwarzanie dźwięku lub wideo po załadowaniu strony może być uciążliwe lub wręcz dezorientujące – zwłaszcza dla użytkowników korzystających z czytników ekranu albo przeglądających stronę w miejscu publicznym.
Zgodnie z WCAG 2.2 należy zapewnić użytkownikowi kontrolę nad odtwarzaniem mediów – np. przez domyślne wyciszenie oraz przycisk „Odtwórz” lub możliwość łatwego zatrzymania dźwięku. Jeśli dźwięk trwa dłużej niż 3 sekundy, użytkownik musi mieć opcję jego wyłączenia lub regulacji głośności.
Unikanie auto-play to nie tylko kwestia zgodności z wytycznymi dotyczącymi dostępności, ale również dobrego UX i komfortu korzystania z usług cyfrowych.
Zgodnie z kryterium 1.4.10 WCAG 2.2, zawartość strony internetowej powinna być czytelna i funkcjonalna na różnych rozdzielczościach, bez konieczności przewijania w poziomie. Dotyczy to szczególnie użytkowników korzystających z urządzeń mobilnych lub powiększających widok na ekranie.
Projektując responsywny design, należy zadbać o elastyczne układy siatki (np. CSS Grid, Flexbox), skalowalne elementy interfejsu i brak utraty funkcjonalności przy zawężeniu ekranu. Ułatwia to korzystanie z serwisu osobom starszym, niedowidzącym oraz wszystkim, którzy odwiedzają stronę na smartfonach czy tabletach.
Użytkownik powinien mieć możliwość powiększenia tekstu do 200% bez utraty zawartości lub funkcjonalności strony. Zbyt sztywno zakodowane style CSS, brak jednostek względnych (np. em, rem) lub sztywne kontenery mogą powodować, że powiększony tekst się nie mieści lub nachodzi na inne elementy.
Aby zapewnić zgodność z WCAG 2.2, należy stosować skalowalne jednostki i unikać układów, które „rozsypują się” przy zmianie rozmiaru czcionki. Taka elastyczność znacznie zwiększa komfort korzystania ze strony osobom z osłabionym wzrokiem oraz starszym użytkownikom.
Elementy wizualne migające więcej niż trzy razy na sekundę mogą wywoływać reakcje neurologiczne, w tym napady padaczkowe u wrażliwych użytkowników. Kryterium 2.3.1 WCAG 2.2 jasno określa, że należy unikać takich efektów lub ograniczyć ich częstotliwość poniżej progu trzech błysków.
W praktyce oznacza to, że animacje, bannery, efekty wizualne i wideo nie powinny zawierać gwałtownych, pulsujących błysków. Warto je całkowicie wyeliminować lub zastosować alternatywną, statyczną wersję treści. To prosta zasada, ale istotna dla zapewnienia bezpiecznej i inkluzywnej dostępności stron internetowych.
Interfejs użytkownika powinien być spójny i przewidywalny – zarówno pod względem nawigacji, jak i identyfikacji elementów na stronie. WCAG 2.2 kładzie nacisk na to, aby menu, stopki, nagłówki czy przyciski działały i wyglądały tak samo na wszystkich podstronach.
Zgodnie z kryteriami 3.2.3 i 3.2.4, użytkownik nie powinien być zaskakiwany zmianami układu czy funkcji bez wyraźnego powodu. Przykładowo: formularz zamówienia powinien mieć te same pola i układ niezależnie od wybranego produktu. Taka konsekwencja w projekcie ułatwia korzystanie ze strony wszystkim, zwłaszcza osobom z zaburzeniami poznawczymi.
Treść strony powinna być logicznie uporządkowana za pomocą nagłówków i odpowiednio opisanych etykiet. Każdy nagłówek powinien jasno wskazywać temat kolejnego fragmentu tekstu, a etykiety – funkcję danego elementu formularza lub przycisku.
Ułatwia to nawigację osobom korzystającym z czytników ekranu oraz poprawia ogólne zrozumienie treści. Zastosowanie struktury H1–H2–H3 zamiast przypadkowego formatowania pozwala zachować zgodność ze standardami dostępności i zwiększa użyteczność strony.
Linki na stronie powinny jasno informować, dokąd prowadzą lub co się stanie po ich kliknięciu. Teksty typu „kliknij tutaj” czy „więcej” bez kontekstu są nieczytelne dla osób korzystających z czytników ekranu.
Zgodnie z WCAG 2.2, linki powinny być osadzone w kontekście – najlepiej w zdaniu, które wyjaśnia ich cel. Dzięki temu użytkownik wie, czego się spodziewać, i może efektywnie korzystać z zasobów strony. Przykład poprawnego linku: „Zobacz harmonogram szkoleń WCAG 2.2”.
Formularze na stronie internetowej powinny jasno informować użytkownika, gdzie i jaki błąd został popełniony, zgodnie z wymaganiami dostępności cyfrowej i standardami WCAG. Komunikaty o błędach muszą być opisowe i zrozumiałe – nie mogą opierać się wyłącznie na kolorze lub ikonie.
Przykład: zamiast samego podświetlenia pola na czerwono, warto dodać komunikat „To pole jest wymagane” lub „Podaj poprawny numer telefonu”. Takie rozwiązania poprawiają dostępność dla osób korzystających z czytników ekranu i spełniają wymagania WCAG 2.1 AA. To również dobra praktyka w kontekście przepisów dotyczących dostępności treści i spełniania wymogów europejskiego aktu o dostępności.
W dynamicznych komponentach interfejsu – np. menu, modale, rozwijane listy – konieczne jest stosowanie znaczników ARIA, które zapewniają dostępność treści internetowych dla osób korzystających z technologii wspomagających. Zgodność z zasadami WAI-ARIA umożliwia prawidłowe rozpoznanie funkcji, roli i stanu elementów.
Przykład: przycisk rozwijający sekcję powinien posiadać aria-expanded oraz aria-controls, by użytkownicy czytników ekranu mogli zrozumieć aktualny kontekst. Należy pamiętać, że nadmiarowe lub błędne użycie znaczników ARIA może utrudniać odbiór treści – dlatego warto opierać się na semantycznym HTML i stosować ARIA jedynie tam, gdzie to konieczne, zgodnie z wytycznymi WCAG 2.2.
Budowanie stron internetowych zgodnych z WCAG opiera się na wykorzystaniu semantycznego HTML – np. < header >, < main >, < nav >, < section >, < article >. Takie podejście pozwala czytnikom ekranu oraz innym technologiom wspomagającym rozpoznać strukturę dokumentu i zachować logiczne relacje między elementami.
Przestrzeganie tych zasad poprawia nie tylko zgodność z wytycznymi WCAG 2.1 na poziomie AA i WCAG 2.2, ale również wpływa pozytywnie na SEO oraz jakość kodu. Jest to niezbędny element zapewnienia dostępności cyfrowej dla osób z niepełnosprawnościami i spełniania wymagań dotyczących dostępności usług cyfrowych w ramach Europejskiego Aktu o Dostępności.
<main>
<article>
<header>
<h1>Formularz kontaktowy</h1>
</header>
<section>
<form action="/wyslij" method="post">
<div>
<label for="name">Imię i nazwisko</label>
<input type="text" id="name" name="name" required>
</div>
<div>
<label for="email">Adres e-mail</label>
<input type="email" id="email" name="email" required>
</div>
<div>
<label for="message">Wiadomość</label>
<textarea id="message" name="message" rows="5"></textarea>
</div>
<button type="submit">Wyślij</button>
</form>
</section>
</article>
</main>Kolejność treści na stronie powinna być logiczna i zgodna z jej strukturą wizualną – również wtedy, gdy jest odczytywana przez czytniki ekranu. Technologia wspomagająca powinna przedstawiać elementy w taki sposób, w jaki są one zamierzone przez projektanta.
Przykładowo: jeśli wizualnie najpierw pojawia się nagłówek, a potem tekst, kod HTML również powinien zawierać je w tej kolejności. Unikanie układów tworzonych wyłącznie za pomocą CSS, które mieszają kolejność DOM, pozwala utrzymać spójność i zapewnić pełną dostępność cyfrową.
Warto testować kolejność odczytu za pomocą narzędzi typu NVDA, JAWS lub VoiceOver, aby mieć pewność, że użytkownicy niewidomi otrzymują treść w poprawnym, logicznym ciągu.
Zasada „POUR” stanowi fundament wytycznych WCAG 2.x i jednocześnie kierunek rozwoju WCAG 3.0. Skrót ten odnosi się do czterech kluczowych filarów dostępności:
Projektowanie zgodnie z zasadą POUR zapewnia uniwersalność interfejsu oraz przyszłościową zgodność z europejskimi i międzynarodowymi standardami w zakresie dostępności stron internetowych i aplikacji mobilnych.
WCAG a SEO
Dostosowanie strony do wytycznych WCAG przekłada się nie tylko na większą dostępność cyfrową, ale również na poprawę widoczności w wyszukiwarkach. Standardy WCAG 2.1 oraz nowe standardy dostępności WCAG 2.2 wspierają pozycjonowanie, wpływając pozytywnie na jakość kodu, struktury treści i szybkość działania strony internetowej. W kontekście obowiązujących od 28 czerwca 2025 r. przepisów dotyczących dostępności cyfrowej, spełnienie wymagań dostępności treści internetowych przynosi również wymierne korzyści marketingowe i prawne.
Semantyczny HTML, teksty alternatywne i logiczna struktura nagłówków
Stosowanie semantycznego HTML, przemyślane nagłówki (H1, H2, H3 itp.) oraz atrybuty alt dla grafik to nie tylko elementy zapewnienia dostępności cyfrowej dla osób z niepełnosprawnościami, ale także czynniki wpływające na skuteczną indeksację strony przez wyszukiwarki. Strony zgodne z wytycznymi WCAG są lepiej rozumiane przez roboty Google i częściej pojawiają się w wynikach wyszukiwania.
Dla sklepów internetowych czy stron usługowych to także sposób na zwiększenie dostępności usług, zgodność z wymogami europejskiego aktu o dostępności oraz spełnianie wymagań dotyczących dostępności treści cyfrowych.
Szybsze ładowanie strony i lepsza indeksacja przez wyszukiwarki
Unikanie zbędnych skryptów, czysty i zrozumiały kod HTML, brak zbędnych animacji oraz zoptymalizowana struktura treści wspierają zarówno SEO, jak i dostępność cyfrową. Dobrze zaprojektowana strona internetowa ładuje się szybciej, co zmniejsza współczynnik odrzuceń i zwiększa satysfakcję użytkowników.
Z perspektywy przepisów wprowadzanych przez polski akt o dostępności oraz przepisy dotyczące dostępności cyfrowej, takie działania są elementem zapewniania dostępności treści i spełniania wymogów dostępności niektórych produktów i usług. Regularne audyty dostępności, narzędzia do testowania dostępności i optymalizacja pod kątem standardów WCAG 2.2 pomagają osiągnąć zgodność z WCAG 2025 i przygotować stronę na życie 28 czerwca 2025 r.
WCAG 2.2 to kolejny etap rozwoju standardów WCAG i fundament nowych przepisów dotyczących dostępności cyfrowej. Stanowi rozwinięcie wytycznych WCAG 2.1 AA i skupia się na jeszcze lepszym zapewnianiu dostępności cyfrowej dla osób z różnymi ograniczeniami. Wprowadza on nowe kryteria sukcesu, które uwzględniają m.in. potrzeby użytkowników urządzeń mobilnych oraz osób z niepełnosprawnościami poznawczymi.
Najważniejsze zmiany względem standardów WCAG 2.1 na poziomie AA to:
Zgodność z WCAG 2.2 na poziomie AA będzie wymagana od 28 czerwca 2025 r. na mocy przepisów Europejskiego Aktu o Dostępności, który w Polsce wdrażany jest jako polski akt o dostępności. Oznacza to konieczność spełniania wymagań dostępności niektórych produktów i usług – w tym sklepów internetowych, aplikacji mobilnych oraz publicznych stron internetowych.
Przeprowadzenie audytu dostępności, wdrożenie narzędzi do testowania dostępności i dostosowanie strony do standardów WCAG to kluczowe kroki w kierunku spełnienia wymagań dostępności cyfrowej. Zapewnienie dostępności cyfrowej przyniesie korzyści nie tylko pod kątem zgodności z wymogami WCAG, ale również wizerunkowo, marketingowo i SEO. W czerwcu 2025 roku dostępność cyfrowa stanie się obowiązkiem prawnym – to najlepszy czas na dostosowanie strony zgodnie z wytycznymi WCAG 2.2.
