WCAG 2.1 – Co to jest i kiedy musisz go wdrożyć?

Jedna wtyczka, dwa kliknięcia i strona podobno zgodna z WCAG. Brzmi wygodnie, ale w praktyce bardzo często jest to tylko pozorne rozwiązanie problemu. Dostępność cyfrowa nie polega na dodaniu paska z opcją zmiany kontrastu albo powiększania tekstu. To sposób projektowania, kodowania i prowadzenia strony tak, aby mogły z niej korzystać osoby z różnymi potrzebami.

WCAG 2.1 pomaga uporządkować ten proces. Pokazuje, jak tworzyć treści, formularze, nawigację, multimedia i elementy interfejsu, aby były postrzegalne, funkcjonalne, zrozumiałe i kompatybilne z technologiami wspomagającymi. Dla części firm to już nie tylko dobra praktyka, lecz realny obowiązek wynikający z przepisów o dostępności cyfrowej.

Ten artykuł jest rozwinięciem tematu, który poruszamy w filmie na naszym kanale YouTube. Jeśli nie widziałeś, to polecam obejrzeć. W artykule znajdziesz więcej szczegółowych informacji o WCAG 2.1.

Streszczenie artykułu:

• WCAG 2.1 to międzynarodowe wytyczne dostępności treści internetowych tworzone przez W3C.
• Standard opiera się na czterech zasadach: postrzegalności, funkcjonalności, zrozumiałości i solidności.
• W praktyce dla stron firmowych i sklepów najczęściej celem jest poziom AA, a nie pełne AAA.
• Od 28 czerwca 2025 r. Polski Akt o Dostępności obejmuje między innymi wybrane usługi handlu elektronicznego.
• Sama wtyczka dostępności nie wystarczy, ponieważ WCAG dotyczy kodu, treści, formularzy, procesów i obsługi strony.
• W WordPressie da się osiągnąć dobry poziom dostępności, ale wiele zależy od motywu, wtyczek, treści i jakości wdrożenia.

Ten artykuł jest dla właścicieli stron internetowych, sklepów online, firm usługowych, marketerów, specjalistów SEO, UX designerów, programistów i osób, które odpowiadają za stronę firmową. Przyda się szczególnie wtedy, gdy chcesz zrozumieć, czy WCAG dotyczy Twojej firmy, jak przygotować stronę do audytu i dlaczego szybkie „naprawienie dostępności” jedną wtyczką zwykle nie rozwiązuje problemu.

Czym jest WCAG 2.1?

WCAG to skrót od Web Content Accessibility Guidelines, czyli wytycznych dostępności treści internetowych. Standard został opracowany przez W3C, międzynarodową organizację odpowiedzialną za tworzenie standardów sieciowych. Jego celem jest ułatwienie korzystania ze stron i aplikacji osobom z różnymi ograniczeniami, w tym wzroku, słuchu, ruchu, funkcji poznawczych i neurologicznych.

Ważne jest to, że WCAG nie jest instrukcją dla jednego CMS-a, technologii albo rodzaju strony. Nie mówi, że dostępna strona musi być zbudowana w konkretnym systemie. Opisuje efekt, który powinien otrzymać użytkownik. Strona ma dać się odczytać, obsłużyć, zrozumieć i poprawnie działać z narzędziami wspomagającymi.

WCAG 2.1 rozwija wcześniejszy standard WCAG 2.0. Mocniej uwzględnia urządzenia mobilne, osoby słabowidzące oraz użytkowników z trudnościami poznawczymi. Obecnie istnieje także WCAG 2.2, który został opublikowany jako rekomendacja W3C 5 października 2023 r. i rozszerza wcześniejsze wersje standardu.

Nie oznacza to jednak, że WCAG 2.1 przestał mieć znaczenie. W wielu przepisach, audytach i projektach nadal jest podstawowym punktem odniesienia. Przy nowych wdrożeniach warto jednak myśleć szerzej i sprawdzać także wymagania WCAG 2.2, ponieważ standardy dostępności rozwijają się razem z internetem.

Jakie są cztery zasady WCAG?

WCAG opiera się na czterech zasadach. To najprostszy sposób, aby zrozumieć, czym naprawdę jest dostępność cyfrowa. Strona powinna być postrzegalna, funkcjonalna, zrozumiała i solidna. W praktyce oznacza to, że użytkownik musi móc odebrać treść, wykonać działanie, zrozumieć interfejs i skorzystać ze strony także przy użyciu technologii wspomagających.

Postrzegalność oznacza, że treść nie może być dostępna tylko dla osób, które dobrze widzą ekran i słyszą dźwięk. Grafika informacyjna powinna mieć sensowny opis alternatywny. Film powinien mieć napisy, a tekst powinien mieć odpowiedni kontrast do tła. Strona musi też zachować czytelność po powiększeniu i na mniejszych ekranach.

Funkcjonalność dotyczy obsługi strony. Użytkownik powinien móc przejść przez menu, formularze, koszyk, płatność i inne kluczowe elementy bez użycia myszy. Osoba korzystająca z klawiatury musi widzieć, w którym miejscu strony się znajduje. Kolejność przechodzenia po elementach powinna być logiczna.

Zrozumiałość wymaga, aby użytkownik nie musiał zgadywać, co właśnie się stało. Formularz powinien jasno wskazywać błędy i podpowiadać, jak je poprawić. Nawigacja powinna być spójna. Przyciski i linki powinny mówić, dokąd prowadzą albo jakie działanie uruchamiają.

Solidność jest mniej widoczna dla przeciętnego użytkownika, ale bardzo ważna. Strona może wyglądać dobrze, a jednocześnie być źle zbudowana pod spodem. Jeżeli kod nie przekazuje właściwych nazw, ról i stanów elementów, czytnik ekranu może nie odczytać poprawnie formularza, przycisku, koszyka albo komunikatu po wysłaniu danych.

Co oznaczają poziomy A, AA i AAA?

WCAG dzieli kryteria sukcesu na trzy poziomy zgodności. Poziom A to minimum, które usuwa najbardziej podstawowe bariery. Poziom AA jest praktycznym standardem dla większości stron firmowych, sklepów i usług cyfrowych. Poziom AAA jest najwyższy, ale nie zawsze możliwy do osiągnięcia dla całego serwisu.

Poziom A obejmuje wymagania, bez których część użytkowników może w ogóle nie skorzystać ze strony. Przykładem są tekstowe odpowiedniki dla grafik, obsługa klawiaturą, możliwość pominięcia powtarzalnych bloków lub brak pułapki klawiaturowej. To fundament, którego nie warto traktować jako dodatku.

Poziom AA idzie dalej. Obejmuje między innymi odpowiedni kontrast tekstu do tła, widoczny fokus klawiatury, poprawną kolejność elementów, czytelne etykiety formularzy, działanie strony po powiększeniu i dostępność na urządzeniach mobilnych. Dla większości projektów to właśnie poziom AA powinien być realnym celem.

Poziom AAA jest najbardziej wymagający. Może obejmować na przykład wyższy kontrast tekstu, rozszerzoną audiodeskrypcję, tłumaczenie nagrań na język migowy albo bardzo zaawansowane wymagania dotyczące zrozumiałości. Brzmi dobrze, ale nie zawsze jest wykonalny dla całej strony.

Dlatego warto uważać na obietnice typu „pełne AAA dla całego serwisu w kilka dni”. Nawet W3C nie rekomenduje wymagania poziomu AAA jako ogólnej polityki dla całych serwisów, ponieważ część treści może nie dać się sensownie dostosować do wszystkich kryteriów. Znacznie lepiej rzetelnie wdrożyć poziom A i AA w kluczowych procesach niż deklarować nierealny poziom zgodności.

Kiedy musisz wdrożyć WCAG na stronie?

Jeżeli jesteś podmiotem publicznym, temat dostępności cyfrowej nie jest nowy. Strony internetowe podmiotów publicznych muszą spełniać wymagania dostępności od 23 września 2020 r., a aplikacje mobilne od 23 czerwca 2021 r. Takie podmioty muszą również publikować deklarację dostępności, czyli oficjalną informację o stanie zgodności strony lub aplikacji.

W przypadku firm prywatnych sytuacja zależy od rodzaju działalności. Od 28 czerwca 2025 r. obowiązuje Polski Akt o Dostępności, który wdraża Europejski Akt o Dostępności. Przepisy obejmują między innymi usługi handlu elektronicznego, czyli sytuacje, w których klient może zawrzeć transakcję na odległość. Może to być zakup produktu, usługi, biletu, rezerwacja terminu albo inna forma sprzedaży online.

To ważna zmiana dla e-commerce. Jeżeli strona umożliwia konsumentowi przejście przez proces zakupowy, to dostępność nie dotyczy tylko tekstu na stronie głównej. Dostępne powinny być informacje o produkcie, formularze, koszyk, płatność, potwierdzenia i komunikaty. Polski Akt o Dostępności patrzy szerzej niż sama warstwa wizualna strony.

Są jednak wyjątki. Przepisy dotyczące usług nie obejmują mikroprzedsiębiorców, czyli firm, które co do zasady zatrudniają średniorocznie mniej niż 10 pracowników oraz mają roczny obrót albo sumę aktywów do równowartości 2 mln euro. To istotne wyłączenie, ponieważ dotyczy wielu małych działalności.

Wyłączenia mogą dotyczyć także wybranych treści. Chodzi między innymi o część materiałów, których firma nie finansuje, nie tworzy i nad którymi nie ma kontroli, na przykład niektóre elementy zewnętrzne. Przepisy mogą też inaczej traktować starsze multimedia i pliki dokumentów, które nie były aktualizowane po 28 czerwca 2025 r.

Ważne jest też rozróżnienie sprzedaży dla konsumenta i zamkniętych systemów B2B. Jeżeli usługa nie jest kierowana do konsumentów, obowiązki mogą wyglądać inaczej. W razie wątpliwości warto skonsultować konkretny przypadek, ponieważ sama obecność formularza lub panelu nie zawsze oznacza ten sam zakres wymagań.

Jak PAD łączy się z WCAG?

WCAG samo w sobie nie jest ustawą. To standard techniczny i projektowy. W praktyce jest jednak jednym z najważniejszych punktów odniesienia przy spełnianiu wymagań dostępności cyfrowej. Polski Akt o Dostępności nie sprowadza się wyłącznie do tego, czy strona ma poziom AA, ale WCAG pomaga sprawdzić dużą część wymagań dotyczących interfejsu internetowego.

W przypadku e-handlu trzeba patrzeć także na normę EN 301 549. To europejska norma opisująca wymagania dostępności dla produktów i usług ICT. W dużej mierze odwołuje się do WCAG 2.1, ale może obejmować też szerszy kontekst usługi, nie tylko samą stronę internetową. Materiały rządowe wskazują normy i specyfikacje techniczne jako ważny punkt odniesienia dla usług handlu elektronicznego.

To oznacza, że samo hasło „strona zgodna z WCAG” może być zbyt wąskie. Sklep internetowy powinien być dostępny jako usługa. Użytkownik musi móc znaleźć informacje, porównać ofertę, dodać produkt do koszyka, przejść przez formularz, wybrać metodę dostawy, zapłacić i otrzymać zrozumiałe potwierdzenie.

Teoretycznie przepisy przewidują możliwość odstąpienia od konkretnego wymagania, jeżeli jego spełnienie powodowałoby zasadniczą zmianę podstawowych właściwości usługi albo nieproporcjonalne obciążenie. Nie jest to jednak wygodna furtka do zignorowania dostępności. Taką decyzję trzeba uzasadnić, ocenić i udokumentować.

W praktyce najbezpieczniejsze podejście jest proste. Najpierw warto sprawdzić, czy firma podlega przepisom. Następnie przeanalizować kluczowe procesy użytkownika. Dopiero później planować wdrożenie techniczne, redakcyjne i formalne. Dzięki temu dostępność nie będzie przypadkowym dodatkiem, tylko elementem jakości całej usługi.

Jakie wymagania WCAG są najważniejsze dla strony?

WCAG to nie jest krótka lista pod tytułem „dodaj alty i powiększ czcionkę”. To zestaw kryteriów, które dotyczą wielu obszarów strony. Obejmuje grafikę, tekst, formularze, multimedia, nawigację, responsywność, strukturę nagłówków, kod i zachowanie elementów interaktywnych.

Najczęściej warto zacząć od barier, które blokują wykonanie celu. Inny ciężar ma drobny błąd w dekoracyjnej grafice, a inny niedostępny przycisk „zamawiam i płacę”. W sklepie dostępność musi obejmować pełny proces zakupowy, ponieważ użytkownik nie może zatrzymać się na ostatnim kroku tylko dlatego, że formularz płatności nie działa z klawiatury.

Najważniejsze obszary do sprawdzenia:

• Treści i struktura, czyli poprawne nagłówki, proste akapity, sensowne linki i czytelna hierarchia informacji.
• Grafiki i multimedia, czyli opisy alternatywne, napisy, transkrypcje i brak informacji przekazywanych wyłącznie kolorem.
• Formularze, czyli etykiety, instrukcje, komunikaty błędów i możliwość poprawienia danych.
• Nawigacja, czyli obsługa klawiaturą, widoczny fokus, logiczna kolejność przechodzenia i możliwość pominięcia powtarzalnych bloków.
• Interfejs, czyli kontrast, responsywność, czytelność po powiększeniu i odpowiednie rozmiary elementów klikalnych.
• Kod, czyli poprawne role, nazwy, stany komponentów i zgodność z technologiami wspomagającymi.

Warto korzystać z oficjalnych materiałów W3C, zwłaszcza z narzędzia How to Meet WCAG, czyli Quick Reference. Pozwala ono filtrować kryteria według poziomu A, AA i AAA. Do zrozumienia poszczególnych punktów służą materiały Understanding WCAG, które wyjaśniają cel wymagań i pokazują przykłady wdrożenia.

Największy błąd polega na traktowaniu dostępności jak jednorazowej poprawki. Strona może przejść audyt, a po kilku miesiącach znowu mieć problemy, bo ktoś dodał nieczytelny PDF, film bez napisów, grafikę z tekstem albo nową wtyczkę, która psuje obsługę klawiaturą. Dostępność trzeba utrzymywać.

Czy wtyczka wystarczy do zgodności z WCAG?

Nie. Wtyczka może pomóc, ale nie zapewnia zgodności z WCAG sama z siebie. To jeden z najczęstszych mitów dostępności cyfrowej. Pasek z opcją zmiany kontrastu, powiększania tekstu albo podkreślania linków może być przydatnym dodatkiem, ale nie naprawi błędów w kodzie, formularzach, strukturze nagłówków, multimediach i procesie zakupowym.

Problem polega na tym, że część wykonawców używa wtyczki jako alibi. Instalują widget, pokazują kilka przełączników i mówią, że strona jest dostępna. Tymczasem użytkownik korzystający z klawiatury nadal może utknąć w menu, czytnik ekranu może nie odczytać formularza, a komunikat błędu może być całkowicie niezrozumiały.

Wtyczki nie ocenią też jakości treści. Nie stwierdzą, czy opis alternatywny naprawdę wyjaśnia sens grafiki. Nie rozpoznają, czy link „czytaj więcej” ma wystarczający kontekst. Nie zagwarantują, że plik PDF jest dostępny. Nie sprawdzą w pełni, czy użytkownik rozumie, co ma zrobić po odrzuceniu płatności.

Dlatego proces wdrożenia WCAG powinien wyglądać inaczej. Najpierw audyt i identyfikacja barier. Potem poprawki techniczne i redakcyjne. Następnie testy ręczne, testy klawiaturą, testy na urządzeniach mobilnych i kontrola kluczowych procesów. Dopiero na końcu warto rozważyć dodatkowe narzędzia wspierające użytkownika.

Przykładowe narzędzia mogą pomóc redaktorom i administratorom. W WordPressie używa się między innymi wtyczek analizujących treści pod kątem dostępności albo dodatków, które ułatwiają zauważenie problemów w panelu. To dobry pierwszy krok, ale nadal tylko pierwszy krok. O zgodności decyduje cała strona, a nie obecność wtyczki.

Jak dostosować stronę do WCAG w praktyce?

Dostosowanie strony do WCAG najlepiej potraktować jako projekt jakościowy. Nie zaczyna się od wyboru widgetu, tylko od sprawdzenia, co użytkownik faktycznie robi na stronie. Inaczej wygląda audyt bloga eksperckiego, inaczej sklepu, a jeszcze inaczej systemu rezerwacji, bankowości albo panelu klienta.

Najpierw trzeba wybrać reprezentatywne podstrony i procesy. Strona główna, menu, formularz kontaktowy, wpis blogowy, karta produktu, koszyk, płatność, konto użytkownika i dokumenty do pobrania powinny być oceniane razem. W e-commerce zgodność dotyczy pełnego procesu, a nie tylko pojedynczej podstrony.

Praktyczny proces wdrożenia:

1. Audyt strony i procesów użytkownika. Sprawdź błędy techniczne, treści, formularze, multimedia, dokumenty i kluczowe ścieżki.
2. Priorytetyzacja problemów. Najpierw napraw bariery, które blokują zakup, kontakt, logowanie, płatność lub dostęp do informacji.
3. Poprawki techniczne. Uporządkuj nagłówki, etykiety, fokus, obsługę klawiaturą, popupy, komponenty i responsywność.
4. Poprawki redakcyjne. Uzupełnij opisy alt, zmień niejasne linki, uprość komunikaty, przygotuj napisy i dostępne pliki.
5. Testy ręczne i automatyczne. Połącz narzędzia z oceną człowieka, testem klawiaturą i sprawdzeniem na różnych urządzeniach.
6. Stałe utrzymanie. Wprowadź zasady publikacji treści, aby kolejne aktualizacje nie psuły dostępności.

Największe znaczenie mają kluczowe ścieżki użytkownika. Jeżeli prowadzisz sklep, użytkownik musi móc przejść od wyboru produktu do potwierdzenia zamówienia. Jeżeli prowadzisz stronę usługową, musi móc znaleźć ofertę, zrozumieć ją i skontaktować się z firmą. Jeżeli oferujesz rezerwacje, cały formularz rezerwacyjny musi być dostępny.

Wdrożenie WCAG wymaga współpracy kilku osób. Programista odpowiada za kod i komponenty. Projektant za interfejs i zachowanie elementów. Redaktor za treści, linki, opisy i dokumenty. Właściciel strony za decyzje, priorytety i utrzymanie standardu po wdrożeniu. To ważne, bo odpowiedzialność nie kończy się w momencie odebrania strony od wykonawcy.

Czy WordPress da się dostosować do WCAG?

Tak, WordPress da się dostosować do WCAG. Sam system nie jest przeszkodą. Problemy najczęściej wynikają z motywu, page buildera, źle dobranych wtyczek, zewnętrznych formularzy, popupów, osadzonych map, sliderów albo treści dodawanych bez zasad dostępności. WordPress może być dostępny, ale nie staje się taki automatycznie.

Dobry motyw powinien mieć poprawną strukturę HTML, sensowną obsługę nagłówków, dostępne menu, widoczny fokus i komponenty działające z klawiatury. Warto zwracać uwagę na oznaczenia typu accessibility-ready, ale nie należy traktować ich jako gwarancji zgodności z WCAG AA. To raczej sygnał, że motyw spełnia pewne podstawowe wymagania.

Najczęstsze problemy w WordPressie dotyczą dodatków. Page builder może generować niepoprawną strukturę nagłówków. Wtyczka formularza może nie tworzyć prawidłowych etykiet. Popup może przechwytywać fokus. Slider może zmieniać treść zbyt szybko. Moduł rezerwacji może nie działać z klawiatury. Każdy taki element trzeba sprawdzić w praktyce.

Drugi problem to treść. Nawet dobrze zakodowana strona zaczyna tracić dostępność, gdy redaktorzy publikują grafiki z tekstem zamiast zwykłego tekstu, dodają linki „kliknij tutaj”, wrzucają skany PDF, publikują filmy bez napisów albo tworzą chaotyczną strukturę nagłówków. Dostępność WordPressa zależy więc także od codziennej pracy osób dodających treści.

Poziom AA jest w WordPressie jak najbardziej osiągalny. Wymaga jednak przemyślanego wdrożenia, testów i procedur utrzymania. Pełne AAA dla całej strony nie powinno być standardowym celem projektu. Lepiej zbudować solidny, użyteczny i realnie dostępny serwis na poziomie AA niż obiecywać coś, czego nie da się utrzymać.

Kto odpowiada za dostępność strony?

To jedno z najważniejszych pytań praktycznych. Wykonawca może przygotować stronę zgodną z określonym zakresem wymagań, ale właściciel strony odpowiada za to, co dzieje się później. Jeżeli po wdrożeniu ktoś doda niedostępny PDF, film bez napisów albo nową wtyczkę psującą formularz, dostępność może zostać naruszona.

Dlatego w projekcie warto jasno ustalić zakres odpowiedzialności. Agencja lub freelancer powinni wskazać, co obejmuje wdrożenie, jaki poziom WCAG jest celem, jakie podstrony i procesy będą testowane oraz jakie elementy są poza zakresem. Właściciel strony powinien natomiast zadbać o treści, procedury publikacji i regularne kontrole.

W praktyce przydaje się krótka instrukcja dla redaktorów. Powinna wyjaśniać, jak pisać opisy alternatywne, jak tworzyć nagłówki, jak nazywać linki, jak przygotowywać pliki do pobrania i kiedy trzeba dodać napisy do filmu. Bez tego nawet najlepiej zaprojektowana strona będzie stopniowo tracić jakość.

Dostępność nie jest stanem osiągniętym raz na zawsze. To standard pracy ze stroną. Każda większa aktualizacja motywu, wtyczek, formularzy, koszyka lub systemu płatności może wymagać ponownych testów. Szczególnie dotyczy to sklepów internetowych, gdzie zmiana jednego komponentu potrafi wpłynąć na cały proces zakupowy.

Dlaczego warto wdrożyć WCAG nawet bez obowiązku?

Część firm nie będzie objęta obowiązkami w takim samym zakresie jak podmioty publiczne albo większe sklepy internetowe. Nie oznacza to jednak, że dostępność nie ma dla nich sensu. WCAG porządkuje stronę, poprawia użyteczność, ułatwia korzystanie z treści i wzmacnia profesjonalny wizerunek marki.

Podobnie było kiedyś z certyfikatem SSL. Teoretycznie najważniejszy był tam, gdzie strona przetwarzała dane. Dzisiaj strona bez SSL wygląda nieprofesjonalnie i budzi nieufność. Z dostępnością może być podobnie. Coraz więcej użytkowników, klientów i partnerów biznesowych będzie oczekiwać, że firma nie wyklucza osób z różnymi potrzebami.

Dostępność wspiera też SEO i UX. Logiczna struktura nagłówków, opisowe linki, czytelne treści, transkrypcje, dobre etykiety i szybciej zrozumiałe formularze pomagają nie tylko osobom z niepełnosprawnościami. Ułatwiają korzystanie ze strony każdemu użytkownikowi, także na telefonie, w pośpiechu albo w trudnych warunkach.

To także kwestia zaufania. Firma, która dba o dostępność, pokazuje, że traktuje użytkowników poważnie. Nie buduje strony tylko dla idealnego scenariusza, w którym każdy ma świetny wzrok, sprawną rękę, szybki internet i najnowszy sprzęt. Buduje usługę, z której naprawdę da się korzystać.

Podsumowanie

WCAG 2.1 to nie formalność i nie ozdobnik do strony. To zestaw zasad, które pomagają tworzyć dostępne, użyteczne i bardziej przewidywalne serwisy internetowe. Standard obejmuje treści, multimedia, formularze, nawigację, interfejs, kod i całe procesy użytkownika. Dlatego nie da się go rzetelnie wdrożyć jedną wtyczką.

Dla podmiotów publicznych dostępność cyfrowa jest obowiązkiem od kilku lat. Dla części firm prywatnych, szczególnie działających w e-commerce, znaczenie ma Polski Akt o Dostępności obowiązujący od 28 czerwca 2025 r. W praktyce warto patrzeć nie tylko na samą stronę, ale na całą usługę, w tym informacje, koszyk, płatność, formularze i komunikaty.

Najrozsądniejszym celem dla większości stron jest poziom AA. Daje realną poprawę dostępności i jest możliwy do wdrożenia w dobrze zaplanowanym projekcie. Poziom AAA może być wartościowy dla wybranych treści, ale nie powinien być obietnicą składaną bez analizy. Dostępność trzeba wdrożyć, przetestować i utrzymywać przy każdej kolejnej aktualizacji strony.

FAQ – Najczęściej zadawane pytania

Czy WCAG 2.1 jest obowiązkowe dla każdej strony?

Nie dla każdej strony w takim samym zakresie. Obowiązki dotyczą podmiotów publicznych oraz wybranych firm i usług objętych Polskim Aktem o Dostępności. W e-commerce szczególnie ważne są usługi pozwalające konsumentowi zawrzeć transakcję online.

Czy mikroprzedsiębiorca musi dostosować sklep do PAD?

Wymagania dotyczące usług nie obejmują usług oferowanych lub świadczonych przez mikroprzedsiębiorców. Mikroprzedsiębiorca to co do zasady firma zatrudniająca mniej niż 10 pracowników i mieszcząca się w limicie 2 mln euro obrotu albo sumy aktywów.

Czy wtyczka dostępności wystarczy do WCAG?

Nie. Wtyczka może wspierać użytkownika, ale nie naprawi błędów w kodzie, formularzach, treściach, multimediach i procesach. Zgodność z WCAG wymaga audytu, poprawek technicznych, korekty treści i testów.

Jaki poziom WCAG powinien mieć sklep internetowy?

Najczęściej praktycznym celem jest poziom AA. Obejmuje on wymagania, które realnie wpływają na korzystanie ze sklepu, w tym kontrast, obsługę klawiaturą, formularze, responsywność i czytelność interfejsu.

Czy WordPress może być zgodny z WCAG?

Tak. WordPress może być dostosowany do WCAG, ale zależy to od motywu, wtyczek, jakości kodu i sposobu publikowania treści. Najczęstsze problemy wynikają z dodatków, page builderów, popupów, formularzy i niedostępnych treści.

Czy poziom AAA jest wymagany?

Zwykle nie. Poziom AAA jest najwyższym poziomem zgodności i nie zawsze da się go sensownie osiągnąć dla całego serwisu. W praktyce lepszym celem dla większości stron jest rzetelne spełnienie poziomu AA.

Czy dostępność trzeba sprawdzać po wdrożeniu?

Tak. Dostępność może zostać zepsuta przez aktualizację motywu, nową wtyczkę, zmianę formularza, nowy PDF albo film bez napisów. Dlatego potrzebne są regularne testy i zasady publikowania treści.