Gdy strona ma być wygodna dla wszystkich użytkowników, samo atrakcyjne UI nie wystarcza. Pytanie, Jak przygotować stronę zgodną z WCAG krok po kroku?, pojawia się dziś zarówno przy budowie nowego serwisu, jak i przy modernizacji starszej witryny, sklepu internetowego czy aplikacji. Ten materiał porządkuje najważniejsze decyzje: od wymagań, przez projekt i kod, po testy, dokumenty i utrzymanie dostępności w praktyce.
Od czego zacząć, zanim pojawi się pierwszy ekran projektu
Punktem wyjścia nie powinno być poprawianie pojedynczych błędów znalezionych przez wtyczkę, ale zrozumienie, czym naprawdę jest dostępność cyfrowa. Chodzi o takie zaprojektowanie i wdrożenie serwisu, aby mogły z niego korzystać osoby niewidome, słabowidzące, głuche, z ograniczeniami ruchowymi, poznawczymi, neurologicznymi, a także użytkownicy czasowo wykluczeni, na przykład korzystający wyłącznie z klawiatury, telefonu w słońcu albo wolnego łącza. W praktyce oznacza to pracę z wymaganiami opisanymi przez WCAG, czyli Web Content Accessibility Guidelines. Dla większości organizacji celem jest dziś zgodność z WCAG na poziomie poziom AA, zwykle w odniesieniu do WCAG 2.1 lub coraz częściej WCAG 2.2.
Jeśli ktoś pyta, jak przygotować stronę zgodną z WCAG krok po kroku, odpowiedź zaczyna się od ustalenia zakresu. Inaczej planuje się dostępność dla prostego serwisu informacyjnego, inaczej dla e-commerce, panelu klienta, aplikacji mobilnej czy platformy z filmami i dokumentami PDF. Należy zidentyfikować kluczowe procesy użytkownika: znalezienie informacji, wyszukanie produktu, dodanie do koszyka, wypełnienie formularza, pobranie dokumentu, kontakt, logowanie, płatność. To właśnie te ścieżki powinny być traktowane priorytetowo podczas projektowania, developmentu i testów.
Ważne jest też rozróżnienie między deklaracją a rzeczywistym doświadczeniem użytkownika. Sama deklaracja dostępności, instalacja nakładki, uruchomienie automatycznego skanera albo poprawienie kilku kontrastów nie oznacza jeszcze, że serwis jest realnie dostępny. Narzędzia automatyczne pomagają wykryć część problemów, ale nie sprawdzą sensowności opisów, kolejności odczytu, jakości formularzy, zrozumiałości treści ani tego, czy proces zakupu działa poprawnie z użyciem klawiatury i czytnika ekranu.
WCAG 2.1 czy WCAG 2.2 i co oznaczają poziomy A, AA oraz AAA
Standard WCAG opisuje kryteria sukcesu pogrupowane wokół czterech zasad: postrzegalności, funkcjonalności, zrozumiałości i kompatybilności. Poziom A obejmuje podstawowe wymagania, bez których część użytkowników w ogóle nie skorzysta z treści lub funkcji. Poziom AA jest najczęściej przyjmowanym celem wdrożeniowym i prawnym, bo łączy realną użyteczność z wykonalnością biznesową. Poziom AAA zawiera kryteria najbardziej rygorystyczne, wartościowe w wybranych kontekstach, ale nie zawsze możliwe do spełnienia dla całego serwisu.
W aktualnym kontekście warto uwzględniać WCAG 2.2, ponieważ rozszerza ono wymagania dotyczące między innymi widoczności fokusu, rozmiaru celu dotykowego czy pewnych aspektów uwierzytelniania. Dla właściciela strony oznacza to, że nawet jeśli serwis był oceniany według WCAG 2.1, przy przebudowie lub nowym wdrożeniu rozsądnie jest od razu projektować pod nowszy zestaw kryteriów. To szczególnie istotne dla sklepów internetowych, bankowości, usług samoobsługowych i aplikacji, gdzie wiele interakcji odbywa się na urządzeniach mobilnych.
Kogo dotyczą wymagania dostępności i dlaczego to nie jest tylko kwestia urzędów
Przez lata wiele osób kojarzyło dostępność głównie z sektorem publicznym i z obowiązkami wynikającymi z przepisów krajowych. Rzeczywiście, ustawa o dostępności cyfrowej ma szczególne znaczenie dla podmiotów publicznych, ale praktyka rynkowa i regulacyjna mocno się rozszerzyła. Coraz większą rolę odgrywa Europejski Akt o Dostępności, czyli EAA, który wpływa na wybrane produkty i usługi oferowane także przez sektor prywatny, w tym część obszaru e-commerce i usług cyfrowych.
Z perspektywy biznesowej dostępność strony internetowej nie jest wyłącznie obowiązkiem formalnym. To także mniejsze ryzyko wykluczenia klientów, lepsza jakość UX, większa czytelność treści, niższa liczba błędów w procesach oraz wyższa odporność serwisu na zmiany technologiczne. Dobrze zaprojektowana dostępna strona internetowa zwykle poprawia również SEO techniczne, wydajność i spójność komponentów. Trzeba jednak mówić o tym ostrożnie: dostępność nie zastępuje pozycjonowania ani strategii marketingowej, ale bardzo często wzmacnia podstawy jakości serwisu.
Jak zaplanować odpowiedzialność za dostępność w organizacji
Najczęstszy błąd organizacyjny polega na tym, że wdrożenie WCAG trafia wyłącznie do programisty albo wyłącznie do osoby od treści. Tymczasem dostępność serwisu powstaje na wielu etapach. Właściciel produktu określa priorytety i budżet, UX projektuje przepływy i logikę, UI odpowiada za czytelność interfejsu i kontrast kolorów, developerzy wdrażają semantykę i zachowania komponentów, redaktorzy przygotowują zrozumiałe treści, a testerzy weryfikują działanie z użyciem różnych metod i narzędzi.
Jeżeli organizacja pracuje na design systemie albo gotowych komponentach, warto już na początku ustalić, które elementy są zweryfikowane pod kątem dostępności, a które wymagają przebudowy. Dotyczy to szczególnie menu, modali, akordeonów, zakładek, sliderów, formularzy wieloetapowych i niestandardowych kontrolek. Bez przypisania odpowiedzialności dostępność serwisu szybko zamienia się w zbiór przypadkowych poprawek, które znikają przy kolejnej aktualizacji.
Projektowanie i tworzenie strony: treść, interfejs i kod, które naprawdę działają
Na etapie projektu wiele problemów można wyeliminować znacznie taniej niż po wdrożeniu. Projektowanie dostępne nie polega na dokładaniu dostępności na końcu, ale na budowaniu rozwiązań, które od początku uwzględniają różne sposoby korzystania z serwisu. Właśnie tutaj spotykają się UX i dostępność oraz UI i dostępność. Jeżeli makieta przewiduje nieczytelne komunikaty, niski kontrast, ukryte etykiety, nieprzewidywalną nawigację albo interakcje zależne wyłącznie od myszy, programista nie naprawi tego samym kodem.
Dla wielu zespołów praktyczna odpowiedź na pytanie, jak przygotować stronę zgodną z WCAG krok po kroku, brzmi: zacznij od komponentów i scenariuszy użytkownika, nie od przypadkowych ekranów. Sprawdź, czy użytkownik może odczytać treść, poruszać się po stronie, zrozumieć strukturę, wypełnić formularz, skorygować błąd i zakończyć zadanie bez barier. To ważniejsze niż deklaratywne hasła o accessible design.
Semantyczny HTML, struktura nagłówków i logiczna nawigacja
Jednym z fundamentów dostępnej strony internetowej jest semantyczny HTML. Oznacza to używanie elementów zgodnie z ich znaczeniem: nagłówków dla tytułów sekcji, przycisków do akcji, linków do przejść, list dla zbiorów elementów, tabel dla danych tabelarycznych, pól formularza do wprowadzania danych. Taka semantyka pomaga przeglądarkom, wyszukiwarkom i przede wszystkim użytkownikom korzystającym z technologie asystujące, w tym z programów takich jak czytnik ekranu.
Szczególnie ważna jest struktura nagłówków. Na stronie powinien istnieć logiczny porządek treści, bez przeskakiwania poziomów tylko dlatego, że wizualnie coś lepiej wygląda. Nagłówek nie jest ozdobą, ale znacznikiem informującym o organizacji treści. Osoba korzystająca z czytnika ekranu często przeskakuje po nagłówkach, aby zrozumieć układ strony i szybko dotrzeć do potrzebnej sekcji. Jeśli nagłówki są pozorne, puste albo stosowane wyłącznie do stylizacji, użytkownik traci orientację.
Tak samo istotna jest nawigacja. Menu powinno być przewidywalne, spójne i możliwe do obsłużenia bez myszy. Linki muszą mieć zrozumiałe nazwy, a nie powtarzające się „czytaj więcej” bez kontekstu. Dobrą praktyką jest również link umożliwiający przejście bezpośrednio do głównej treści, co skraca drogę osobom poruszającym się po stronie klawiaturą.
Kontrast kolorów, czytelność i widoczny fokus
Problemy z kontrast tekstu i rozróżnianiem elementów interfejsu należą do najczęstszych błędów w audytach. Osoba słabowidząca, starsza albo korzystająca z telefonu w trudnych warunkach oświetleniowych musi móc odczytać tekst oraz rozpoznać, które elementy są aktywne, wyłączone, zaznaczone lub wymagają uwagi. Dlatego kontrast kolorów nie jest sprawą estetycznych preferencji, lecz podstawą czytelności.
W praktyce należy ocenić nie tylko tekst na tle, ale też kontrast ikon, obramowań pól, stanów hover, aktywnego elementu, błędu formularza i komunikatów statusu. Często problemem nie jest sam główny kolor marki, lecz jego stosowanie na zbyt jasnym tle albo w zbyt małym kroju pisma. Dostępny interfejs nie oznacza rezygnacji z identyfikacji wizualnej, ale zwykle wymaga bardziej świadomego systemu kolorów.
Równie ważny jest fokus klawiatury, czyli wizualna informacja o tym, który element jest aktualnie aktywny podczas poruszania się klawiszem Tab. Fokus musi być dobrze widoczny, spójny i nie może znikać tylko dlatego, że projekt uznał go za nieestetyczny. W wymaganiach WCAG 2.2 temat widoczności fokusu został jeszcze mocniej podkreślony, co ma bezpośrednie znaczenie dla projektantów i frontend developerów.
Obrazy, ikony i alternatywa tekstowa bez zbędnych opisów
Każda grafika nie wymaga długiego opisu, ale każda powinna być świadomie oceniona. Jeśli obraz przekazuje istotną informację, potrzebna jest właściwa alternatywa tekstowa. Jeśli jest dekoracyjny, powinien zostać pominięty przez technologie asystujące. W praktyce oznacza to odpowiednie użycie tekst alternatywny i atrybutów takich jak atrybut alt. Dobry opis nie tłumaczy wszystkiego dosłownie, lecz przekazuje sens obrazu w kontekście treści i zadania użytkownika.
Typowy błąd polega na wpisywaniu do altu słów „zdjęcie”, „grafika”, nazwy pliku albo fraz marketingowych. Drugim błędem jest brak opisu tam, gdzie obraz zawiera kluczową treść, na przykład schemat procesu, infografikę, wykres albo baner z ważnym komunikatem. W takich przypadkach sam alt bywa niewystarczający i potrzebne jest tekstowe rozwinięcie w treści strony. Dotyczy to także ikon funkcyjnych, które powinny mieć dostępną nazwę, gdy sam symbol nie wystarcza.
Formularze, błędy i procesy, które nie frustrują użytkownika
Dostępne formularze należą do najbardziej biznesowo istotnych obszarów, bo bezpośrednio wpływają na kontakt, sprzedaż, rejestrację i obsługę klienta. Każde pole powinno mieć prawdziwą etykietę, a nie jedynie placeholder. Etykiety formularzy muszą być czytelne, powiązane programistycznie z polami i zrozumiałe bez zgadywania. Jeżeli pole jest obowiązkowe, należy to jasno oznaczyć. Jeżeli wymagany jest określony format danych, użytkownik powinien dostać instrukcję przed popełnieniem błędu, a nie dopiero po wysłaniu formularza.
Niezwykle ważne są także komunikaty błędów. Powinny wskazywać, co dokładnie jest nie tak, w którym polu i jak to poprawić. Czerwone obramowanie bez tekstowego wyjaśnienia nie wystarcza, podobnie jak komunikat „wystąpił błąd”. Formularz musi dać się obsłużyć myszą, klawiaturą i na ekranie dotykowym. Kolejność przechodzenia między polami ma być logiczna, a po wystąpieniu błędu fokus powinien pomagać użytkownikowi wrócić do problematycznego miejsca. To obszar, w którym dobrze widać, że dostępność strony internetowej i dobra użyteczność to często ten sam cel osiągany innymi słowami.
Jak sprawdzić stronę pod kątem WCAG i poprawiać błędy w odpowiedniej kolejności
Bez weryfikacji nawet najlepiej zaplanowany projekt może zawierać istotne bariery. Dlatego kluczowym etapem jest audyt dostępności albo przynajmniej uporządkowany test najważniejszych procesów. Wiele osób oczekuje prostego wyniku procentowego, ale realna ocena dostępności nie działa jak pojedynczy wskaźnik jakości. Strona może przejść automatyczny skan i jednocześnie być bardzo trudna dla użytkownika niewidomego lub osoby korzystającej wyłącznie z klawiatury.
Dobry audyt WCAG rozdziela problemy krytyczne od kosmetycznych, odnosi je do konkretnych kryteriów sukcesu, wskazuje ryzyko dla użytkownika oraz proponuje sposób naprawy. To ważne, bo organizacja zwykle nie poprawia wszystkiego jednego dnia. Potrzebna jest kolejność działań: najpierw ścieżki krytyczne, potem komponenty powtarzalne, następnie treści i elementy mniej istotne biznesowo.
Automatyczny skan to za mało: co naprawdę obejmuje test dostępności strony
Test dostępności strony powinien łączyć kilka metod. Narzędzia automatyczne wykrywają część oczywistych problemów, takich jak brakujące alty, niektóre błędy semantyki, zbyt niski kontrast czy brak etykiet. To przydatny pierwszy filtr, zwłaszcza przy dużych serwisach. Nie wolno jednak traktować raportu z wtyczki jako dowodu pełnej zgodności.
Potrzebna jest analiza ekspercka, która ocenia sens rozwiązań, jakość treści, logikę interakcji i zgodność procesów z wymaganiami użytkowników. Konieczne są też testy manualne: przejście całej strony klawiaturą, sprawdzenie działania fokusu, weryfikacja formularzy, modali, rozwijanych list, karuzel i elementów dynamicznych. Dodatkowo należy sprawdzić działanie z użyciem czytnika ekranu, bo dopiero wtedy widać, czy nazwy przycisków, kolejność odczytu, komunikaty statusu i struktura treści mają sens.
W zależności od typu usługi warto uwzględnić także testy mobilne, powiększenie tekstu, orientację pionową i poziomą, reakcję interfejsu na zmianę rozmiaru ekranu oraz zachowanie przy włączonych ustawieniach systemowych wspierających użytkownika. W serwisach z dokumentami i multimediami zakres testów powinien obejmować również pliki oraz odtwarzacze.
Najczęstsze błędy wykrywane w audytach dostępności
W praktyce powtarzają się podobne problemy niezależnie od branży. Należą do nich brak semantyki przy niestandardowych komponentach, nieprawidłowo użyta ARIA, klikane elementy zbudowane z divów zamiast przycisków, błędna kolejność fokusu, formularze bez etykiet, brak informacji o błędach, niewidoczny fokus, nieczytelny kontrast, puste linki, nieopisane przyciski ikonowe, modal zamykający się w nieprzewidywalny sposób i treści, których nie da się zrozumieć bez kontekstu wizualnego.
Warto podkreślić rolę ARIA. To ważny zestaw atrybutów wspierających dostępność, ale nie służy do naprawiania źle zaprojektowanego interfejsu na skróty. Zasada praktyczna brzmi: najpierw poprawny HTML, potem ewentualnie rozsądne użycie ARIA tam, gdzie potrzebne są dodatkowe informacje dla technologii asystujących. Nadużywana ARIA potrafi pogorszyć doświadczenie użytkownika zamiast je poprawić.
Jak ustalać priorytety poprawek i współpracować z zespołem
Skuteczna poprawa dostępności strony wymaga nadania priorytetów nie według liczby błędów, ale według wpływu na użytkownika i biznes. Jeżeli użytkownik nie może przejść do koszyka, zalogować się, wysłać formularza albo przeczytać kluczowego komunikatu, to są to błędy krytyczne. Następnie warto zająć się komponentami globalnymi, powtarzającymi się na wielu podstronach, bo jedna poprawka może przynieść efekt w całym serwisie.
Dobra praktyka to przygotowanie backlogu z opisem problemu, odniesieniem do kryterium WCAG, przykładem miejsca występowania, zalecaną zmianą i sposobem testu po wdrożeniu. Dzięki temu projektant, programista, redaktor i tester rozumieją, co dokładnie trzeba zrobić. W przypadku większych organizacji opłaca się też zdefiniować wzorce komponentów dostępnych oraz zasady publikacji treści, żeby nie wracać do tych samych błędów przy każdej aktualizacji.
Multimedia, dokumenty, prawo i utrzymanie dostępności po wdrożeniu
Wiele serwisów nie kończy się na tekstach i formularzach. Pojawiają się filmy, webinary, podcasty, instrukcje PDF, katalogi, regulaminy, raporty, dokumenty dla klientów oraz treści generowane przez różne działy firmy. To właśnie tutaj organizacje często tracą spójność. Strona główna bywa poprawiona, ale użytkownik odpada na etapie filmu bez napisów albo skanu PDF, którego czytnik ekranu nie potrafi odczytać. Dlatego dostępność serwisu należy rozumieć szerzej niż sam kod witryny.
W praktyce odpowiedź na pytanie, jak przygotować stronę zgodną z WCAG krok po kroku, musi obejmować także proces utrzymania. Jednorazowa poprawa nie wystarczy, jeśli po miesiącu redaktor doda obraz bez opisu, marketing opublikuje film bez napisów, a deweloper wdroży nowy komponent bez testów klawiatury. Dostępność WCAG to stały element jakości produktu cyfrowego.
Napisy, transkrypcje, audiodeskrypcja i sterowanie odtwarzaczem
Materiały wideo i audio powinny być dostępne dla osób o różnych potrzebach. W przypadku filmów kluczowe są napisy do filmów, które pomagają osobom głuchym i słabosłyszącym, ale też wielu innym użytkownikom oglądającym materiał bez dźwięku. Dla treści audio przydatna jest transkrypcja tekstowa. Gdy obraz wnosi istotne informacje niewypowiedziane w ścieżce dźwiękowej, potrzebna może być audiodeskrypcja.
Nie można zapominać o samym odtwarzaczu. Musi być możliwa obsługa klawiaturą, odczyt nazw przycisków przez czytnik ekranu oraz kontrola odtwarzania bez niespodzianek. Automatyczne uruchamianie dźwięku bez zgody użytkownika jest złą praktyką zarówno z perspektywy dostępności, jak i ogólnego UX. Ważna jest też możliwość zatrzymania ruchu, pauzy oraz przewidywalne sterowanie multimediami osadzonymi z zewnętrznych platform.
PDF i inne dokumenty: kiedy plik jest naprawdę dostępny
Dostępność dokumentów PDF to obszar często pomijany, mimo że dla wielu instytucji i firm dokument jest kluczową częścią usługi. Dostępny PDF nie jest zwykłym obrazem zapisanym w pliku. Musi posiadać warstwę tekstową, logiczną strukturę nagłówków, tagi, poprawną kolejność odczytu, opisy elementów znaczących i sensowny tytuł dokumentu. Tabele powinny być zakodowane jako tabele, a nie narysowane graficznie. Formularze w PDF również wymagają etykiet i poprawnej kolejności pól.
Jeżeli dokument ma znaczenie operacyjne lub prawne, warto rozważyć, czy w ogóle musi być publikowany wyłącznie jako PDF. Często lepszym rozwiązaniem jest równoległa wersja HTML, łatwiejsza do odczytu na różnych urządzeniach i wygodniejsza dla technologii asystujących. Dotyczy to szczególnie instrukcji, regulaminów, cenników, informacji o usługach i treści, które użytkownik powinien szybko przeszukać lub przeczytać na telefonie.
Wymogi prawne, deklaracja dostępności i odpowiedzialność organizacji
Przepisy warto traktować jako ramę, ale nie jako jedyny cel. W praktyce obowiązki zależą od rodzaju podmiotu, oferowanych usług i kontekstu regulacyjnego. Ustawa o dostępności cyfrowej ma szczególne znaczenie dla podmiotów publicznych, natomiast Europejski Akt o Dostępności wpływa na wybrane usługi i rozwiązania oferowane na rynku unijnym. W obszarze e-commerce, samoobsługi klienta i usług cyfrowych znaczenie zgodności rośnie także po stronie podmiotów komercyjnych.
Deklaracja dostępności ma sens tylko wtedy, gdy odzwierciedla rzeczywisty stan serwisu, wskazuje ograniczenia, opisuje alternatywne sposoby kontaktu i jest aktualizowana. Nie powinna być traktowana jako dokument osłonowy przygotowany raz i zapomniany. Równie ważne są procedury wewnętrzne: kto odpowiada za poprawki, kto przegląda nowe treści, jak reaguje się na zgłoszenia użytkowników i jak często wykonywany jest ponowny audyt dostępności. To nie jest indywidualna porada prawna, ale praktyczna zasada zarządzania ryzykiem i jakością.
Jak utrzymać dostępność strony po publikacji i rozwoju serwisu
Najbardziej dojrzałe podejście zakłada, że poprawa dostępności strony trwa przez cały cykl życia produktu. Po wdrożeniu warto wprowadzić checklisty redakcyjne, kryteria akceptacji dla nowych funkcji, przeglądy komponentów, testy regresji dostępności oraz okresowe kontrole najważniejszych ścieżek użytkownika. Przy większych zmianach serwisu, migracji CMS, przebudowie sklepu czy wdrożeniu nowego panelu klienta audyt powinien wrócić jako element obowiązkowy, a nie opcjonalny.
Coraz częściej pojawiają się też narzędzia oparte na AI i rozbudowane automatyczne testy jakości. Mogą przyspieszyć wykrywanie części problemów, ale nie zastąpią eksperta ani użytkownika. Algorytm może zasugerować brakujący opis obrazu, ale nie oceni, czy opis jest trafny. Może wykryć element bez etykiety, ale nie rozstrzygnie, czy cały proces jest zrozumiały. Dlatego sensowne utrzymanie dostępności aplikacji i strony internetowej opiera się na połączeniu automatyzacji, wiedzy zespołu i regularnej weryfikacji manualnej.
Arkadiusz Urbaś
Arkadiusz Urbaś od ponad 14 lat zajmuje się tworzeniem nowoczesnych stron internetowych, które łączą estetyczny design, intuicyjną nawigację, funkcjonalność oraz optymalizację pod wyszukiwarkę Google. Jako specjalista WordPress i współwłaściciel firmy działającej w obszarze marketingu internetowego pomaga przedsiębiorcom budować silną obecność online oraz rozwijać strony, które…
