Coraz więcej właścicieli firm słyszy dziś o standardzie WCAG – często przy okazji rozmowy o nowej stronie internetowej, czasem przy piśmie od kontrahenta, a czasem dopiero wtedy, gdy ktoś zapyta wprost: „czy Wasza strona spełnia wymogi dostępności cyfrowej?”. Problem w tym, że większość dostępnych w sieci materiałów albo tonie w technicznym żargonie zrozumiałym tylko dla programistów, albo ogranicza się do jednego zdania o „dostępności dla niepełnosprawnych” i nie tłumaczy, kogo faktycznie dotyczy obowiązek i co grozi za jego brak.
Z naszej perspektywy – jako agencji, która na co dzień wdraża standardy dostępności cyfrowej u klientów z różnych branż – widzimy, że najwięcej zamieszania budzi właśnie pomieszanie dwóch różnych obowiązków prawnych: tego dla sektora publicznego (obowiązującego od 2019 roku) i tego dla biznesu prywatnego, które weszło w życie dopiero 28 czerwca 2025 roku wraz z Europejskim Aktem o Dostępności. To dwa różne reżimy, z różnymi karami i różnymi terminami, a w sieci często są opisywane, jakby to była jedna, wspólna sprawa.
W tym artykule wyjaśniamy krok po kroku, czym jest standard WCAG, jakie ma poziomy i wersje, kogo w Polsce faktycznie obowiązuje, jak wygląda audyt dostępności oraz jak zaplanować wdrożenie – bez encyklopedycznego żargonu, za to z konkretnymi liczbami i checklistą, którą możesz od razu wykorzystać.
Czym jest standard WCAG?
WCAG (Web Content Accessibility Guidelines) to międzynarodowy zbiór wytycznych opracowany przez konsorcjum W3C, a dokładniej działającą w jego ramach grupę Web Accessibility Initiative (WAI). Wytyczne opisują, jak projektować strony internetowe, sklepy online i aplikacje mobilne tak, by mogły z nich swobodnie korzystać wszystkie osoby – niezależnie od rodzaju i stopnia niepełnosprawności, wieku czy sposobu korzystania z internetu.
W praktyce chodzi o użytkowników z:
- niepełnosprawnością wzroku (osoby niewidome i słabowidzące),
- niepełnosprawnością słuchu (osoby niesłyszące i niedosłyszące),
- ograniczeniami ruchowymi (np. osoby korzystające wyłącznie z klawiatury),
- ograniczeniami poznawczymi, neurologicznymi lub trudnościami w uczeniu się.
Warto od razu obalić popularne uproszczenie: WCAG to nie jest standard „dla niepełnosprawnych”, z którego korzysta wąska grupa odbiorców. Strona zgodna z WCAG jest też wygodniejsza dla starszych użytkowników, dla osób korzystających z telefonu w słońcu (niski kontrast przeszkadza wszystkim), dla kogoś z chwilowo unieruchomioną ręką czy dla użytkownika w hałaśliwym miejscu, który nie może odsłuchać dźwięku. Według danych Światowej Organizacji Zdrowia z jakąś formą niepełnosprawności żyje ponad miliard ludzi na świecie – to nie jest niszowa grupa odbiorców, tylko realny fragment rynku, który dziś w wielu przypadkach po prostu omija strony niedostosowane do jego potrzeb.
Krótkie podsumowanie: WCAG to opracowany przez W3C zestaw wytycznych, dzięki którym strony i aplikacje są dostępne dla jak najszerszej grupy użytkowników – nie tylko osób z niepełnosprawnościami, ale w praktyce dla każdego, kto korzysta z internetu w niesprzyjających warunkach.
Cztery zasady WCAG – co oznacza POUR?
Cała filozofia standardu opiera się na czterech zasadach, określanych skrótem POUR. Zrozumienie ich znacznie ułatwia późniejszą pracę nad wdrożeniem – zamiast uczyć się dziesiątek pojedynczych kryteriów na pamięć, wystarczy wiedzieć, do której z czterech kategorii należy dany problem.
| Zasada | Co oznacza | Przykład w praktyce |
| Postrzegalność (Perceivable) | Treść musi być możliwa do odebrania zmysłami – wzrokiem, słuchem lub dotykiem (np. przez czytnik ekranu) | Tekst alternatywny dla obrazów, napisy do wideo, odpowiedni kontrast tekstu i tła |
| Funkcjonalność (Operable) | Interfejs musi dać się obsłużyć różnymi metodami, nie tylko myszką | Pełna nawigacja klawiaturą, brak „pułapek” blokujących fokus, wystarczająco duże obszary klikalne |
| Zrozumiałość (Understandable) | Treść i sposób działania strony muszą być przewidywalne i jasne | Prosty język, czytelne komunikaty błędów w formularzach, spójna nawigacja na każdej podstronie |
| Solidność (Robust) | Strona musi poprawnie współpracować z technologiami wspomagającymi | Zgodność kodu HTML/ARIA z czytnikami ekranu (NVDA, JAWS, VoiceOver) |
Krótkie podsumowanie: Jeśli strona jednocześnie spełnia wszystkie cztery zasady POUR, można ją uznać za realnie dostępną. Zabraknięcie choćby jednej – np. świetny kontrast, ale strona niedziałająca z klawiatury – oznacza, że część użytkowników i tak natrafi na barierę.
Poziomy zgodności WCAG – czym różnią się A, AA i AAA?
Każde kryterium sukcesu w WCAG jest przypisane do jednego z trzech poziomów zgodności. To nie są „stopnie trudności” w sensie jakości wykonania, tylko zakres barier, jakie dana strona eliminuje.
Poziom A (podstawowy) – absolutne minimum. Obejmuje najbardziej fundamentalne bariery: brak tekstu alternatywnego dla obrazów, niemożność obsługi strony klawiaturą, chaotyczną strukturę nagłówków. Spełnienie tylko poziomu A oznacza, że strona jest technicznie dostępna, ale w bardzo ograniczonym zakresie – W3C nie rekomenduje traktowania go jako celu docelowego.
Poziom AA (rekomendowany i najczęściej wymagany prawnie) – to właśnie ten poziom wskazują polskie i unijne przepisy jako obowiązkowy, zarówno dla instytucji publicznych, jak i – od 2025 roku – dla firm prywatnych objętych EAA. Obejmuje m.in. kontrast tekstu na poziomie minimum 4,5:1, widoczny fokus klawiatury, czytelne etykiety pól formularzy oraz zakaz przekazywania informacji wyłącznie za pomocą koloru.
Poziom AAA (rozszerzony) – najwyższy poziom zgodności, przewidziany głównie dla serwisów o szczególnym znaczeniu społecznym lub edukacyjnym (np. platformy dla osób niewidomych). Obejmuje m.in. kontrast na poziomie 7:1 czy tłumaczenie treści na język migowy. W3C sam zaznacza, że pełne wdrożenie AAA bywa w praktyce niemożliwe dla większości serwisów komercyjnych – zamiast tego firmy zwykle wybierają pojedyncze kryteria AAA, które mają sens biznesowy.
Krótkie podsumowanie: Dla zdecydowanej większości stron firmowych i sklepów internetowych realnym celem jest poziom AA – to on jest wymagany prawnie i to on stanowi rozsądny kompromis między dostępnością a kosztem wdrożenia.
WCAG 2.0, 2.1, 2.2 – czym się różnią poszczególne wersje?
To jedno z najczęstszych pytań, jakie słyszymy od klientów, i jednocześnie temat, który w większości dostępnych materiałów jest wyjaśniony niejasno. W uproszczeniu: każda kolejna wersja dodaje nowe kryteria do poprzedniej, zamiast ją zastępować – strona zgodna z WCAG 2.2 automatycznie spełnia też wymagania 2.1 i 2.0.
| WCAG 2.0 | WCAG 2.1 | WCAG 2.2 | |
| Rok publikacji | 2008 | 2018 | 2023 |
| Liczba kryteriów | 61 | +17 nowych (łącznie 78) | +9 nowych (jedno kryterium wycofane) |
| Główny nacisk | Fundament – teksty alternatywne, kontrast, obsługa klawiaturą | Dostępność mobilna, urządzenia dotykowe, użytkownicy z trudnościami poznawczymi | Osoby starsze, ograniczenia motoryczne, wygoda logowania i nawigacji |
| Status prawny w PL | Historyczny fundament | Wymagany prawnie (ustawa 2019 + EAA 2025) | Zalecany, jeszcze nieobowiązkowy |
WCAG 2.1 to obecnie jedyna wersja, na którą wprost powołują się polskie i unijne przepisy – zarówno ustawa o dostępności cyfrowej dla sektora publicznego, jak i Europejski Akt o Dostępności dla biznesu prywatnego wskazują poziom AA w wersji 2.1 jako wymagany minimum.
WCAG 2.2 zostało opublikowane 5 października 2023 roku i wprowadza dziewięć nowych kryteriów, m.in. minimalny rozmiar elementów klikalnych (24×24 px), obowiązek zapewnienia alternatywy dla funkcji „przeciągnij i upuść” oraz uproszczenie procesów logowania, tak by nie wymagały np. przepisywania captchy z pamięci. Jednocześnie wycofano jedno z dotychczasowych kryteriów (4.1.1 Poprawność kodu), uznane za nieaktualne wobec sposobu, w jaki dzisiejsze przeglądarki i czytniki ekranu interpretują kod strony. Choć WCAG 2.2 nie jest jeszcze wpisane do polskiego prawa, coraz więcej firm wdraża je od razu – to rozwiązanie na zapas, bo raz zrobione dobrze zabezpiecza jednocześnie pod obecne i przyszłe przepisy.
Na horyzoncie jest też WCAG 3.0 – wciąż wczesna wersja robocza W3C, która ma objąć nie tylko strony internetowe, ale też aplikacje mobilne i systemy IoT, a zamiast poziomów A/AA/AAA wprowadzić bardziej elastyczną skalę punktową. To temat na kolejne lata, ale warto o nim wiedzieć, planując długoterminową strategię cyfrową firmy.
Krótkie podsumowanie: Jeśli słyszysz dziś o obowiązku prawnym dotyczącym WCAG, w 99% przypadków chodzi o wersję 2.1 na poziomie AA. WCAG 2.2 warto wdrożyć z wyprzedzeniem, ale nie jest to jeszcze formalny wymóg w polskim prawie.
Kto musi wdrożyć standard WCAG w Polsce?
To sekcja, w której najczęściej pojawia się chaos – bo w Polsce funkcjonują obok siebie dwa niezależne obowiązki prawne, dotyczące różnych podmiotów, z różnymi karami i różnymi datami wejścia w życie. Warto je rozdzielić.
Sektor publiczny – ustawa z 2019 roku
Od 2019 roku obowiązuje ustawa o dostępności cyfrowej stron internetowych i aplikacji mobilnych podmiotów publicznych. Nakłada ona na urzędy, szkoły, uczelnie, szpitale i inne instytucje publiczne obowiązek zapewnienia zgodności ich stron i aplikacji ze standardem WCAG 2.1 na poziomie AA. Nadzór nad przestrzeganiem przepisów sprawuje Ministerstwo Cyfryzacji.
Biznes prywatny – Europejski Akt o Dostępności (EAA)
To temat, który w ostatnich miesiącach zdecydowanie zyskał na znaczeniu. Europejski Akt o Dostępności (European Accessibility Act) został przyjęty przez Unię Europejską w 2019 roku, a w Polsce wdrożono go ustawą z 26 kwietnia 2024 roku o zapewnieniu spełniania wymagań dostępności niektórych produktów i usług przez podmioty gospodarcze. Przepisy weszły w życie 28 czerwca 2025 roku i po raz pierwszy nakładają formalny obowiązek dostępności cyfrowej także na firmy prywatne.
Dotyczy to przede wszystkim podmiotów działających w obszarach takich jak:
- e-commerce (sklepy internetowe),
- bankowość i usługi płatnicze,
- telekomunikacja,
- transport pasażerski,
- niektóre usługi cyfrowe i urządzenia (np. terminale samoobsługowe, e-czytniki).
Podobnie jak w przypadku sektora publicznego, wymaganym standardem technicznym jest WCAG 2.1 na poziomie AA (w ramach szerszej normy EN 301 549). Nadzór nad przestrzeganiem przepisów sprawuje Prezes Zarządu PFRON oraz właściwe organy nadzoru rynku.
Kto jest zwolniony z obowiązku? Ustawa przewiduje wyjątek dla mikroprzedsiębiorstw świadczących usługi – czyli firm zatrudniających mniej niż 10 osób i osiągających roczny obrót poniżej 2 milionów euro. Przewidziano też okres przejściowy: usługi świadczone na podstawie umów zawartych przed 28 czerwca 2025 roku mogą być kontynuowane bez zmian aż do 28 czerwca 2030 roku.
Jakie kary grożą za brak zgodności?
Warto rozróżnić kary w obu reżimach – są zauważalnie różne pod względem konstrukcji.
| Sektor publiczny (ustawa 2019) | Biznes prywatny (EAA) | |
| Organ nadzoru | Ministerstwo Cyfryzacji | Prezes Zarządu PFRON i organy nadzoru rynku |
| Kara za brak deklaracji dostępności | do 5 000 zł | – |
| Kara za uporczywe niezapewnienie dostępności | do 10 000 zł | – |
| Kara finansowa | – | do dziesięciokrotności przeciętnego miesięcznego wynagrodzenia, nie więcej jednak niż 10% obrotu firmy z poprzedniego roku |
Na obecnym etapie wdrażania przepisów EAA organy nadzoru koncentrują się głównie na edukacji i budowaniu świadomości wśród przedsiębiorców, a nie na masowym nakładaniu kar. To jednak nie zmienia faktu, że ryzyko prawne – i finansowe – jest już realne, a każdy klient lub konkurent może zgłosić niezgodną ze standardami stronę do odpowiedniego organu.
Krótkie podsumowanie: Jeśli prowadzisz stronę instytucji publicznej, obowiązek WCAG 2.1 AA obowiązuje Cię od 2019 roku. Jeśli prowadzisz firmę prywatną działającą m.in. w e-commerce, finansach czy transporcie – obowiązek dotyczy Cię od 28 czerwca 2025 roku, chyba że jesteś mikroprzedsiębiorstwem.
Czym jest audyt WCAG i jak wygląda krok po kroku?
Audyt WCAG to szczegółowa analiza strony lub aplikacji pod kątem zgodności z wytycznymi standardu. To zwykle pierwszy, konieczny krok przed właściwym wdrożeniem – bez niego trudno ocenić realny zakres prac i ich koszt. Rzetelny audyt składa się z trzech uzupełniających się warstw.
1. Analiza automatyczna. Pierwszy etap to skanowanie strony narzędziami takimi jak axe, WAVE czy wbudowany w Chrome Lighthouse. Pozwalają one szybko wykryć oczywiste błędy – brak tekstów alternatywnych, zbyt niski kontrast, nieprawidłową strukturę nagłówków. Automatyczne narzędzia wykrywają jednak w praktyce tylko część problemów, zwykle szacowaną na 30-40% wszystkich barier.
2. Testy manualne. Audytor sprawdza stronę „ręcznie” – poruszając się po niej wyłącznie klawiaturą (Tab, Enter, strzałki), korzystając z czytnika ekranu (NVDA, JAWS, VoiceOver) oraz weryfikując zachowanie strony przy powiększonym tekście czy zmienionej rozdzielczości. To etap, który wychwytuje większość realnych barier pomijanych przez skanery.
3. Testy z udziałem użytkowników (opcjonalnie, ale zalecane). Najbardziej wartościowe, choć rzadziej stosowane uzupełnienie audytu – moderowane sesje, w których osoba z niepełnosprawnością wykonuje konkretne zadanie na stronie (np. znajduje produkt i dodaje go do koszyka), a moderator obserwuje, gdzie pojawiają się trudności. Ten etap ujawnia problemy, których nie wychwyci nawet doświadczony audytor – np. zbyt skomplikowany język komunikatów czy nieintuicyjną kolejność kroków w formularzu.
Efektem końcowym dobrego audytu jest raport zawierający listę błędów z odniesieniem do konkretnych kryteriów WCAG, priorytety wdrożeniowe (krytyczne, średnie, niskie) oraz konkretne rekomendacje naprawcze – najlepiej z przykładami kodu, a nie tylko ogólnymi wskazówkami.
Jeśli zastanawiasz się, jak wygląda to u nas, sprawdź naszą usługę wdrożenia WCAG – audyt jest zawsze pierwszym etapem współpracy, dzięki czemu dokładnie wiesz, ile pracy wymaga dostosowanie Twojej strony, zanim zaczniemy cokolwiek zmieniać.
Krótkie podsumowanie: Sam skaner automatyczny nigdy nie wystarczy – rzetelny audyt WCAG łączy analizę narzędziową z testami manualnymi, a w najlepszym wariancie także z testami z realnymi użytkownikami.
Jak wdrożyć standard WCAG na stronie – checklista i harmonogram
Wdrożenie WCAG nie musi oznaczać przebudowy całej strony od zera. Dla większości serwisów to praca punktowa – poprawki w konkretnych, dobrze zdefiniowanych obszarach. Poniżej przykładowy harmonogram, jak taki proces wygląda w praktyce.
| Etap | Działania | Co sprawdzić na koniec |
| 1. Audyt | Analiza automatyczna + testy manualne całej witryny | Pełna lista błędów z priorytetami |
| 2. Poprawki krytyczne | Nawigacja klawiaturą, kontrast, teksty alternatywne, struktura nagłówków | Strona w pełni obsługiwana bez myszki |
| 3. Poprawki treści i multimediów | Napisy do wideo, transkrypcje audio, czytelne etykiety formularzy | Brak treści dostępnych wyłącznie wizualnie lub dźwiękowo |
| 4. Testy z technologią wspomagającą | Weryfikacja czytnikiem ekranu (NVDA/VoiceOver), test powiększenia tekstu do 200% | Brak barier zgłaszanych przez czytnik ekranu |
| 5. Deklaracja dostępności | Przygotowanie i publikacja dokumentu zgodnego z wymogami ustawy | Deklaracja opublikowana i zaktualizowana |
| 6. Monitoring powdrożeniowy | Kontrola dostępności nowych treści publikowanych na stronie | Checklista dostępności w procesie publikacji treści |
Checklista przed startem wdrożenia WCAG
- Mam wykonany audyt WCAG i znam priorytety poprawek
- Wiem, czy moja strona podlega ustawie o dostępności cyfrowej, czy przepisom EAA
- Sprawdziłem nawigację klawiaturą na kluczowych ścieżkach (formularz kontaktowy, koszyk, logowanie)
- Wszystkie obrazy i grafiki mają uzupełnione teksty alternatywne
- Kontrast tekstu i tła spełnia minimum 4,5:1
- Materiały wideo mają napisy, a nagrania audio – transkrypcje
- Mam przygotowaną lub zaplanowaną deklarację dostępności
Krótkie podsumowanie: Wdrożenie WCAG to proces, a nie jednorazowa akcja – najskuteczniej działa, gdy poprawki wprowadza się według priorytetów z audytu, a dostępność staje się częścią standardowego procesu publikowania treści, a nie jednorazowym „sprintem”.
Najczęstsze błędy przy wdrażaniu WCAG
Z naszej praktyki – obserwując strony klientów, którzy podchodzili do tematu bez wsparcia specjalisty – powtarza się kilka konkretnych błędów.
- Poleganie wyłącznie na automatycznym skanerze – narzędzia typu WAVE czy Lighthouse wykrywają tylko część barier, resztę wychwytują wyłącznie testy manualne.
- Traktowanie WCAG jako projektu jednorazowego – strona spełnia wymogi w dniu wdrożenia, ale każda kolejna publikowana treść (nowy baner, wideo, artykuł) ponownie wprowadza błędy.
- Pomijanie deklaracji dostępności – sam brak tego dokumentu, niezależnie od realnego stanu strony, może skutkować karą.
- Mylenie obowiązku dla sektora publicznego z obowiązkiem EAA – firmy prywatne błędnie zakładają, że temat ich nie dotyczy, bo „to przepisy dla urzędów”.
- Poprawianie tylko strony głównej – audyt i wdrożenie muszą obejmować kluczowe ścieżki użytkownika (koszyk, formularz, logowanie), a nie tylko widoczną „wizytówkę” firmy.
- Brak testów z czytnikiem ekranu – wiele błędów (np. źle opisane przyciski) jest niewidocznych wizualnie i ujawnia się dopiero przy realnym użyciu technologii wspomagającej.
Krótkie podsumowanie: Większość błędów we wdrożeniach WCAG nie wynika ze złej woli, tylko z braku wiedzy o tym, że dostępność to proces ciągły, a nie jednorazowa lista do odhaczenia.
Ile kosztuje wdrożenie WCAG i ile to trwa?
To pytanie, na które trudno odpowiedzieć jedną liczbą – koszt i czas wdrożenia zależą od kilku konkretnych czynników:
- wielkości serwisu – strona wizytówka z kilkoma podstronami to zupełnie inny zakres pracy niż sklep internetowy z setkami produktów i złożonym procesem zakupowym,
- obecnego stanu dostępności – strona zbudowana od podstaw z myślą o WCAG wymaga innego zakresu prac niż serwis sprzed kilku lat, tworzony bez uwzględnienia standardu,
- docelowego poziomu zgodności – poziom AA (wymagany prawnie) wymaga mniej pracy niż pełne AAA,
- technologii, na której działa strona – dostosowanie gotowego motywu WordPress bywa szybsze niż praca na w pełni autorskim kodzie.
W praktyce dla niewielkiej strony firmowej realny zakres audytu i podstawowych poprawek to zwykle kilka do kilkunastu dni roboczych pracy zespołu, a dla rozbudowanego sklepu internetowego – proces wielotygodniowy, obejmujący też testy na kluczowych ścieżkach zakupowych. Najbardziej wiarygodną wycenę dostaniesz jednak dopiero po audycie – dlatego to zawsze pierwszy krok, zanim padnie jakakolwiek konkretna liczba.
Krótkie podsumowanie: Zamiast szukać uniwersalnej stawki za „wdrożenie WCAG”, warto zacząć od audytu – to on pokazuje realny zakres prac i pozwala wycenić projekt rzetelnie, zamiast szacować „na oko”.
Kiedy wdrożyć WCAG samodzielnie, a kiedy zlecić agencji?
Samodzielne wdrożenie ma sens, gdy masz w zespole osobę techniczną, niewielką stronę oraz czas na naukę wytycznych WCAG i ręczne testowanie każdej zmiany. Dla prostych, statycznych stron wizytówkowych to w pełni wykonalne.
Z drugiej strony, dla sklepów internetowych, serwisów z rozbudowanymi formularzami czy stron instytucji publicznych – gdzie błąd oznacza realne ryzyko prawne – samodzielne wdrożenie bywa ryzykowne. Łatwo poprawić widoczne błędy, a przeoczyć te, które ujawniają się dopiero w testach z czytnikiem ekranu.
| Kryterium | Wdrożenie samodzielne | Wdrożenie z agencją |
| Koszt | niski (czas własny zespołu) | wyższy, ale przewidywalny |
| Ryzyko przeoczenia błędów | wysokie – bez doświadczenia trudno wychwycić wszystkie bariery | niskie – audyt obejmuje testy manualne i narzędziowe |
| Czas do zgodności | dłuższy, zależny od dostępności zespołu | zwykle krótszy, oparty na sprawdzonym procesie |
| Dokumentacja (deklaracja dostępności) | trzeba przygotować samodzielnie | przygotowywana jako element usługi |
Niezależnie od wybranej ścieżki, fundament jest ten sam: rzetelny audyt, jasne priorytety poprawek i traktowanie dostępności jako stałego elementu utrzymania strony, a nie jednorazowego projektu. Jeśli wolisz mieć pewność, że nic nie zostanie przeoczone – sprawdź, jak wygląda wdrożenie WCAG z VAFYO.
Najczęstsze pytania o standard WCAG
Czym różni się WCAG od EAA?
WCAG to techniczny standard opisujący, jak projektować dostępne treści cyfrowe. EAA (Europejski Akt o Dostępności) to natomiast akt prawny, który – wraz z wdrażającą go polską ustawą – nakłada na firmy obowiązek stosowania tego standardu, wskazując konkretnie WCAG 2.1 na poziomie AA jako wymagane minimum.
Czy WCAG 2.2 jest już obowiązkowy w Polsce?
Nie. Obecnie obowiązującym prawnie standardem – zarówno dla sektora publicznego, jak i dla biznesu objętego EAA – pozostaje WCAG 2.1 na poziomie AA. WCAG 2.2 jest zalecane i warto je wdrażać z wyprzedzeniem, ale na razie nie zostało wpisane do polskich przepisów.
Kogo dotyczy obowiązek wdrożenia WCAG w biznesie prywatnym?
Przede wszystkim firm działających w e-commerce, bankowości, telekomunikacji i transporcie pasażerskim, a także dostawców niektórych usług i urządzeń cyfrowych. Obowiązek nie dotyczy mikroprzedsiębiorstw usługowych – zatrudniających mniej niż 10 osób i osiągających obrót poniżej 2 milionów euro rocznie.
Czy WordPress jest zgodny z WCAG „z automatu”?
Nie w pełni. Sam rdzeń WordPressa jest projektowany z uwzględnieniem dostępności, ale realna zgodność zależy przede wszystkim od wybranego motywu, wtyczek i sposobu, w jaki redaktorzy publikują treści – np. czy uzupełniają teksty alternatywne obrazów i zachowują logiczną strukturę nagłówków.
Ile trwa wdrożenie WCAG na stronie internetowej?
To zależy od wielkości i obecnego stanu strony – od kilku dni roboczych przy prostej stronie wizytówkowej po kilka-kilkanaście tygodni przy rozbudowanym sklepie internetowym. Punktem wyjścia zawsze powinien być audyt, który pokazuje realny zakres koniecznych prac.
Czym różni się audyt WCAG od pełnego wdrożenia?
Audyt to diagnoza – analiza strony i raport wskazujący konkretne błędy oraz ich priorytety. Wdrożenie to etap naprawczy, w którym te błędy są faktycznie poprawiane. Audyt jest zwykle pierwszym, koniecznym krokiem przed rozpoczęciem właściwego wdrożenia.
Standard WCAG i wynikające z niego obowiązki prawne to dziś jeden z tych tematów, w których łatwo o pozorną orientację – „coś tam słyszałem o dostępności” – a znacznie trudniej o pewność, czy Twoja strona faktycznie spełnia wymogi i czy w ogóle Cię one dotyczą. Jeśli chcesz to sprawdzić bez zgadywania, zacznij od audytu WCAG – pokaże dokładnie, na czym stoisz i ile pracy dzieli Cię od pełnej zgodności.