Dostępność cyfrowa przestała być tematem tylko dla urzędów. Od 2025 r. coraz więcej firm prywatnych musi zadbać o to, żeby z ich strony mogły korzystać wszystkie osoby – a WCAG mówi, jak to zrobić. Ten przewodnik tłumaczy zasady, wymogi i koszty po ludzku.
Czym jest dostępność cyfrowa (i czym jest WCAG)
Dostępność cyfrowa oznacza, że z Twojej strony mogą korzystać także osoby z różnymi ograniczeniami: wzroku, słuchu, ruchu, koncentracji albo rozumienia treści. WCAG to zestaw zasad, które pomagają taką stronę zaprojektować, zbudować i sprawdzić.
W praktyce chodzi o proste sytuacje. Ktoś powiększa tekst, bo słabiej widzi. Ktoś porusza się po stronie samą klawiaturą, bo nie używa myszy. Ktoś korzysta z czytnika ekranowego, czyli programu, który odczytuje treść strony na głos. Ktoś ogląda film bez dźwięku i potrzebuje napisów.
Dostępność stron internetowych dotyczy treści, projektu, kodu i całej ścieżki użytkownika. Strona może wyglądać dobrze, a jednocześnie blokować część osób już na formularzu kontaktowym. Może mieć ładne kolory, ale zbyt niski kontrast. Może mieć rozbudowane menu, którego nie da się obsłużyć klawiaturą.
WCAG, czyli Web Content Accessibility Guidelines, porządkuje te wymagania. Najczęściej spotkasz się z poziomem AA, bo to rozsądny standard dla stron firmowych, sklepów i serwisów usługowych. W dokumentach prawnych i przetargowych zwykle pojawia się WCAG 2.1, choć istnieją też nowsze wersje wytycznych. Jeśli masz obowiązek zgodności, najpierw trzeba ustalić, jaka wersja i jaki poziom są wymagane w Twoim przypadku.
Dlaczego dostępność stron jest dziś obowiązkowa – stan prawny 2025
W 2025 r. dostępność cyfrowa stała się obowiązkiem nie tylko instytucji publicznych, ale też wielu firm prywatnych w UE. Dla podmiotów publicznych wymogi dostępności stron i aplikacji działają już od kilku lat, a od 28 czerwca 2025 r. dołączyła do nich część biznesu.
Dostępność przez długi czas była kojarzona głównie z urzędami, uczelniami i instytucjami publicznymi. To się zmienia. Przepisy unijne związane z dostępnością produktów i usług obejmują także część biznesu, zwłaszcza tam, gdzie klient kupuje, rezerwuje, płaci, loguje się albo korzysta z usługi przez internet.
Dla właściciela firmy oznacza to konkret: strona internetowa coraz częściej jest elementem zgodności z prawem. Jeśli prowadzisz sklep, platformę usługową, system rezerwacji, płatności online albo serwis z kontem klienta, dostępność stron internetowych powinna znaleźć się w planie prac tak samo jak RODO, regulamin, płatności i bezpieczeństwo.
Kogo to dotyczy
Podstawą jest Europejski Akt o Dostępności (dyrektywa UE 2019/882), w Polsce wdrożony ustawą z 26 kwietnia 2024 r. o zapewnianiu spełniania wymagań dostępności niektórych produktów i usług. Wymogi obejmują firmy oferujące określone produkty i usługi konsumentom – najczęściej mówi się o e-commerce, usługach finansowych, bankowości, transporcie, e-bookach, aplikacjach i serwisach z logowaniem. Aktualny zakres obowiązków dla przedsiębiorców opisuje serwis biznes.gov.pl.
Nie każda mała strona firmowa ma ten sam zakres obowiązków. Inaczej wygląda prosta strona psychologa z opisem usług i formularzem kontaktowym, inaczej sklep WooCommerce z płatnościami, koszykiem, kontem klienta i regulaminami. Mikrofirmy (zwykle poniżej 10 osób) świadczące usługi mogą korzystać z wyłączeń, ale to zależy od rodzaju działalności i przepisów krajowych.
Nawet gdy prawo nie wymaga od Ciebie pełnej zgodności, dostępność nadal wpływa na sprzedaż i obsługę. Jeśli klient nie może przeczytać oferty, przejść przez formularz albo dokończyć zakupu, firma traci kontakt z realną osobą.
Od kiedy obowiązuje i co grozi za brak zgodności
Obowiązki z Europejskiego Aktu o Dostępności ruszyły 28 czerwca 2025 r. Standardem technicznym dla stron jest zwykle WCAG 2.1 na poziomie AA, a dla szerszego zakresu produktów i usług – norma EN 301 549.
Konsekwencje mogą obejmować skargi użytkowników, kontrolę, wezwanie do usunięcia problemów, kary administracyjne albo ograniczenia w oferowaniu danej usługi. Dochodzi ryzyko biznesowe: porzucone koszyki, mniej zapytań, gorsza obsługa i wyższy koszt późniejszych poprawek. Dokładny zakres dla Twojej firmy najlepiej potwierdzić z prawnikiem, bo przepisy przewidują wyłączenia i okresy przejściowe.
Najrozsądniej potraktować WCAG jako standard pracy nad stroną. Najpierw sprawdzasz, gdzie jesteś. Potem poprawiasz bariery, które realnie blokują użytkowników. Na końcu pilnujesz, żeby nowe treści, formularze i funkcje nie psuły efektu.
Cztery zasady WCAG po ludzku (POUR)
WCAG opiera się na czterech zasadach: strona ma być postrzegalna, funkcjonalna, zrozumiała i solidna technicznie. Ten skrót zapisuje się jako POUR, od angielskich słów Perceivable, Operable, Understandable i Robust.
Postrzegalność oznacza, że użytkownik może odebrać treść strony. Tekst powinien mieć dobry kontrast. Obrazy, które niosą znaczenie, powinny mieć opis alternatywny, czyli krótki opis czytany przez czytnik ekranowy. Film powinien mieć napisy, jeśli zawiera wypowiedzi potrzebne do zrozumienia treści.
Funkcjonalność oznacza, że da się wykonać akcję. Użytkownik powinien móc przejść przez menu, formularz, koszyk i przyciski samą klawiaturą. Focus, czyli widoczne zaznaczenie aktualnego elementu, musi być dobrze widoczny. Jeśli ktoś wciska Tab, powinien wiedzieć, gdzie jest na stronie.
Zrozumiałość dotyczy języka, układu i komunikatów. Formularz powinien jasno mówić, czego oczekuje: imienia, adresu e-mail, numeru telefonu. Jeśli pojawia się błąd, komunikat powinien wyjaśniać problem po ludzku. Samo „Błąd walidacji” nic nie daje osobie, która chce wysłać zapytanie.
Solidność techniczna oznacza, że strona dobrze współpracuje z przeglądarkami, czytnikami ekranowymi i innymi narzędziami wspierającymi. Kod powinien używać właściwych elementów HTML. Przycisk powinien być przyciskiem, link powinien być linkiem, a pole formularza powinno mieć etykietę widoczną dla człowieka i zrozumiałą dla programu.
Najczęstsze bariery na stronach – i jak je rozpoznać
Najczęstsze bariery to zbyt niski kontrast, brak opisów obrazów, formularze bez etykiet, problemy z klawiaturą, nieczytelne komunikaty błędów i filmy bez napisów. Część z nich zobaczysz od razu, a część wychodzi dopiero w testach.
Kontrast to pierwszy sygnał. Jasnoszary tekst na białym tle może wyglądać delikatnie, ale dla wielu osób będzie trudny do przeczytania. W WCAG 2.1 na poziomie AA zwykły tekst powinien spełniać kontrast co najmniej 4,5:1. Duży tekst ma łagodniejsze wymagania, ale nadal musi być czytelny.
Brak opisów alternatywnych dotyczy zdjęć, ikon i grafik. Jeśli zdjęcie jest dekoracyjne, może zostać pominięte przez czytnik ekranowy. Jeśli pokazuje ważną informację, opis jest potrzebny. Przy zdjęciu produktu opis może brzmieć konkretnie: „Czarne skórzane botki na niskim obcasie”. Przy ikonie koszyka opis powinien mówić, co się stanie po kliknięciu.
Obsługa klawiaturą pokazuje, czy strona jest realnie używalna bez myszy. Otwórz stronę, odłóż mysz i użyj Tab, Shift+Tab, Enter, Spacji oraz Escape. Jeśli nie możesz wejść do menu, zamknąć okna, kliknąć przycisku albo przejść przez formularz, to jest bariera.
Formularze często zawodzą na etykietach. Placeholder, czyli tekst wpisany w puste pole, nie wystarcza jako etykieta. Po kliknięciu albo automatycznym uzupełnieniu może zniknąć. Osoba korzystająca z czytnika ekranowego powinna usłyszeć, jakie pole wypełnia i jaki błąd wystąpił.
Napisy do wideo są potrzebne osobom niesłyszącym i niedosłyszącym. Pomagają też wtedy, gdy ktoś ogląda film w biurze, pociągu albo bez słuchawek. Jeśli film zawiera instrukcję, opinię klienta albo ważny opis usługi, brak napisów ogranicza dostęp do treści.
Problemem są też linki typu „kliknij tutaj”. Gdy czytnik ekranowy odczytuje same linki na stronie, użytkownik słyszy kilka razy tę samą frazę i nie wie, dokąd prowadzi. Lepszy link mówi wprost: „Sprawdź cennik konsultacji” albo „Pobierz regulamin sklepu”.
Jak zrobić stronę dostępną – krok po kroku
Dostępną stronę najłatwiej zrobić wtedy, gdy WCAG jest obecne od początku projektu. Tak projektujemy i wdrażamy strony w Kiwwwi – od makiety w Figmie po kod. Przy istniejącej stronie zaczyna się od audytu, listy barier i poprawek ustawionych według wpływu na użytkownika.
Pierwszy krok to sprawdzenie zakresu. Inaczej pracuje się nad stroną wizytówką, inaczej nad sklepem, a jeszcze inaczej nad portalem z kontami użytkowników. Trzeba wypisać najważniejsze ścieżki: wejście na stronę, przeczytanie oferty, kontakt, zapis na wizytę, zakup, płatność, pobranie dokumentu, logowanie.
Drugi krok to projekt. Już w Figmie można sprawdzić kontrasty, wielkości tekstu, stany przycisków, komunikaty błędów i układ na telefonie. Dostępność zaczyna się przed kodowaniem, bo wiele problemów wynika z decyzji projektowych: zbyt małego fontu, słabego kontrastu, ukrytych etykiet albo niejasnych nazw przycisków.
Trzeci krok to treść. Nagłówki powinny mieć sensowną kolejność. Akapity powinny być krótkie. Linki powinny mówić, dokąd prowadzą. Komunikaty w formularzach powinny być konkretne. Jeśli używasz skrótów branżowych, wyjaśnij je przy pierwszym użyciu.
Czwarty krok to kod. Programista powinien używać semantycznego HTML, czyli takich elementów, które mają znaczenie dla przeglądarki i narzędzi wspierających. Nagłówek strony powinien być nagłówkiem, lista listą, przycisk przyciskiem. Przy bardziej złożonych elementach, takich jak zakładki, akordeony, modale albo menu, trzeba zadbać o właściwe role, nazwy i obsługę klawiaturą.
Piąty krok to testy. Automatyczne narzędzia pomagają, ale nie łapią wszystkiego. Mogą wskazać brak etykiety, słaby kontrast albo błąd w strukturze. Nie powiedzą jednak, czy tekst jest zrozumiały, czy kolejność przechodzenia klawiaturą ma sens, czy komunikat błędu naprawdę pomaga użytkownikowi.
Szósty krok to utrzymanie. Dostępność cyfrowa może się zepsuć po dodaniu nowej sekcji, formularza, baneru, wtyczki albo zmianie kolorów. Dlatego warto ustalić prostą zasadę: każda większa zmiana na stronie przechodzi szybki test kontrastu, klawiatury, formularzy i czytnika ekranowego.
Jak sprawdzić dostępność swojej strony
Dostępność swojej strony sprawdzisz przez połączenie automatycznych narzędzi, testu klawiaturą i testu z czytnikiem ekranowym. Sam wynik z jednego narzędzia nie wystarczy do oceny zgodności z WCAG.
Na start możesz użyć WAVE. To narzędzie pokazuje błędy, ostrzeżenia, strukturę nagłówków, opisy alternatywne i problemy z kontrastem. Dobrze sprawdza się przy szybkim przeglądzie pojedynczej podstrony, na przykład strony głównej, formularza kontaktowego albo strony produktu.
Lighthouse w przeglądarce Chrome daje raport dostępności. Pokazuje wybrane problemy techniczne, takie jak brak nazw przycisków, błędy kontrastu czy nieprawidłowe elementy formularzy. Wynik procentowy traktuj jako sygnał, a nie certyfikat. Strona może mieć wysoki wynik i nadal mieć poważny problem w koszyku albo formularzu.
Czytniki ekranowe pozwalają sprawdzić, jak strona działa dla osób niewidomych i słabowidzących. Na Windowsie często używa się NVDA. Na Macu i iPhonie dostępny jest VoiceOver. Test polega na przejściu przez stronę bez patrzenia wyłącznie na układ wizualny: odsłuchujesz nagłówki, linki, przyciski, formularze i komunikaty.
Test klawiaturą jest prosty i bardzo skuteczny. Przejdź przez całą ścieżkę użytkownika bez myszy. Sprawdź, czy widzisz zaznaczenie elementu, czy kolejność przechodzenia jest logiczna, czy możesz otworzyć i zamknąć menu, czy modal nie zatrzymuje Cię w miejscu, czy da się wysłać formularz.
Przy kolorach użyj narzędzi do kontrastu, na przykład wbudowanych funkcji przeglądarki albo dodatków projektowych. Sprawdź zwykły tekst, tekst na przyciskach, linki, komunikaty błędów i elementy na kolorowym tle. Samo „na oko” łatwo zawodzi, zwłaszcza przy odcieniach szarości, zieleni i jasnych pastelach.
Najlepszy obraz daje audyt łączony: automaty, ręczne testy, sprawdzenie kodu, przejście przez najważniejsze procesy i lista poprawek z priorytetami. Dzięki temu wiesz, które błędy są kosmetyczne, a które blokują kontakt, zakup albo dostęp do informacji.
Ile kosztuje dostosowanie strony do WCAG
Koszt dostosowania strony do WCAG zależy od wielkości serwisu, technologii, liczby formularzy, jakości kodu i zakresu wymaganej zgodności. Orientacyjne widełki są pomocne, ale bez audytu da się podać tylko rząd wielkości.
Mała strona wizytówka z kilkoma podstronami i prostym formularzem może wymagać poprawek liczonych od kilkuset do kilku tysięcy złotych, jeśli problemów jest niewiele. Dotyczy to sytuacji, w której trzeba poprawić kontrasty, opisy alternatywne, nagłówki, etykiety pól i kilka elementów interaktywnych.
Większa strona firmowa na WordPressie może kosztować od kilku do kilkunastu tysięcy złotych, jeśli dochodzą niestandardowe sekcje, wiele typów podstron, integracje, wyszukiwarka, formularze i dokumenty PDF. W takiej pracy więcej czasu zajmuje testowanie, poprawianie komponentów oraz sprawdzanie, czy zmiana w jednym miejscu nie psuje innego fragmentu strony.
Sklep internetowy zwykle jest bardziej wymagający. Trzeba sprawdzić listę produktów, filtry, kartę produktu, koszyk, konto klienta, płatność, komunikaty błędów, regulaminy i e-maile transakcyjne. Przy WooCommerce albo innym sklepie koszt może iść od kilku do kilkudziesięciu tysięcy złotych, zależnie od skali i jakości obecnego wdrożenia.
Osobno trzeba policzyć treści i dokumenty. Opisy alternatywne dla setek zdjęć, poprawa PDF-ów, napisy do wideo i uproszczenie trudnych komunikatów to praca redakcyjna, nie sama zmiana w kodzie. Przy dużej stronie właśnie treści potrafią zająć najwięcej czasu.
Najtaniej jest uwzględnić WCAG przy nowym projekcie. Wtedy projektant od razu dobiera kontrasty, stany elementów i układ formularzy, a programista buduje komponenty w dobrym standardzie. Naprawianie gotowej strony bywa droższe, bo wymaga cofania wcześniejszych decyzji.
Najczęstsze błędy i mity o dostępności
Najczęstszy błąd polega na traktowaniu dostępności jak jednorazowej checklisty do odhaczenia. WCAG pomaga sprawdzać jakość, ale dostępność cyfrowa wymaga też dobrego projektu, sensownej treści, porządnego kodu i regularnych testów.
Pierwszy mit mówi, że wystarczy wtyczka dostępności. Taka wtyczka może dodać zmianę kontrastu, powiększanie tekstu albo panel z ustawieniami, ale nie naprawi źle zbudowanego formularza, braku etykiet, złej kolejności nagłówków ani koszyka, którego nie da się obsłużyć klawiaturą.
Drugi mit mówi, że dostępność psuje wygląd strony. Dobrze zaprojektowana strona może być estetyczna, nowoczesna i zgodna z WCAG. Wymaga decyzji opartych na czytelności: odpowiedniego kontrastu, jasnych stanów przycisków, logicznego układu i przewidywalnych interakcji.
Trzeci mit mówi, że dostępność dotyczy wyłącznie osób niewidomych. To jedna z grup użytkowników, ale zakres jest szerszy. Dostępność pomaga osobom niedowidzącym, niesłyszącym, z ograniczoną sprawnością ruchową, z dysleksją, z trudnościami poznawczymi, po urazach i w czasowych ograniczeniach, na przykład po złamaniu ręki.
Czwarty mit mówi, że automatyczny raport wystarczy. Narzędzia takie jak WAVE i Lighthouse są potrzebne, ale wykrywają tylko część problemów. Nie ocenią w pełni sensu komunikatu, jakości opisu alternatywnego, wygody przejścia przez zakup ani tego, czy treść jest zrozumiała dla osoby spoza branży.
Piąty mit mówi, że WCAG dotyczy tylko dużych firm. Zakres obowiązków prawnych bywa różny, ale bariery na stronie dotykają klientów niezależnie od wielkości firmy. Mały gabinet, lokalna restauracja, fotograf ślubny albo sklep z niszowym produktem też mogą stracić zapytanie przez formularz, którego nie da się użyć.
Szósty mit mówi, że raz poprawiona strona zostaje dostępna na zawsze. Wystarczy nowy baner, wtyczka, sekcja promocyjna, popup albo zmiana kolorów, żeby pojawiły się nowe bariery. Dlatego dostępność stron internetowych powinna wejść do zwykłego procesu utrzymania strony.
FAQ
-
To zależy od rodzaju działalności, usług i przepisów, które Cię obejmują. Od 2025 r. wymogi dostępności dotyczą wielu usług i produktów na rynku UE, ale zakres dla konkretnej firmy trzeba sprawdzić osobno. Nawet bez obowiązku prawnego warto usunąć bariery, które blokują kontakt albo zakup.
-
Nie. Strona może być estetyczna, rozbudowana i dostępna. Trzeba pilnować kontrastu, czytelności, obsługi klawiaturą, jasnych formularzy, opisów obrazów i poprawnego kodu. Dobre projektowanie pomaga spełnić WCAG bez rezygnowania z charakteru marki.
-
Nie daje pełnej pewności. Lighthouse sprawdza część problemów technicznych, ale nie zastąpi ręcznego testu klawiaturą, czytnika ekranowego i oceny treści. Wysoki wynik jest dobrym sygnałem, ale nie jest pełnym audytem dostępności.
-
Jedno i drugie. Kod decyduje o tym, czy formularze, przyciski, menu i komunikaty są zrozumiałe dla technologii wspierających. Treść decyduje o tym, czy człowiek rozumie ofertę, błąd, instrukcję i następny krok. Przy WCAG 2.1 te obszary muszą działać razem.
-
Zacznij od najważniejszych ścieżek: strona główna, oferta, kontakt, formularz, koszyk, płatność i logowanie, jeśli występują. Sprawdź kontrast, nagłówki, obsługę klawiaturą, etykiety formularzy i komunikaty błędów. Te poprawki często usuwają najbardziej dotkliwe bariery.
-
Po większej zmianie tak. Nowa sekcja, formularz, popup, baner, wtyczka albo przebudowa menu mogą wprowadzić nowe problemy. Krótki test po wdrożeniu jest tańszy i szybszy niż duży audyt dopiero wtedy, gdy użytkownicy zaczną zgłaszać błędy.