Najważniejsze wnioski
- EAA nie nakłada automatycznie takich samych obowiązków na każdą stronę firmową. Zakres trzeba ocenić dla konkretnej usługi, produktu i roli przedsiębiorcy.
- W Polsce EAA wdraża ustawa z 26 kwietnia 2024 r. o zapewnianiu spełniania wymagań dostępności niektórych produktów i usług przez podmioty gospodarcze, często nazywana Polskim Aktem o Dostępności.
- W e-commerce należy badać całą usługę: wyszukiwarkę, filtry, kartę produktu, logowanie, koszyk, płatność, wiadomości transakcyjne, zwroty i kontakt.
- WCAG jest ważnym punktem technicznym dla stron i aplikacji, ale samo stwierdzenie zgodności z WCAG nie zastępuje oceny obowiązków wynikających z PAD i EN 301 549.
- Widget dostępności może być szybkim pierwszym krokiem wspierającym użytkowników, lecz nie zastępuje audytu, testów ani trwałych poprawek w kodzie i treści.
Dla zarządzającego
Potraktuj EAA jako zadanie operacyjne i produktowe, nie wyłącznie projekt dla działu IT. Najpierw ustal, czy firma oferuje usługę objętą ustawą, wskaż właściciela procesu, zaplanuj audyt krytycznych ścieżek i utrzymuj dowody wykonanych działań.
Dla sprzedaży
Dostępność ułatwia klientowi samodzielne przejście przez ofertę, formularz, koszyk i płatność. W rozmowach handlowych nie obiecuj pełnej zgodności po instalacji widgetu; komunikuj konkretne usprawnienia oraz plan audytu i napraw źródłowych.
EAA nie oznacza automatycznie obowiązku dostosowania każdej strony firmowej w identycznym zakresie. Dla właściciela sklepu, platformy lub usługi cyfrowej kluczowe jest ustalenie, czy dana usługa znajduje się w zakresie przepisów, a następnie sprawdzenie, czy użytkownik może samodzielnie wykonać najważniejsze działania.
W Polsce wymagania wynikające z Europejskiego Aktu o Dostępności wdraża ustawa z 26 kwietnia 2024 r. o zapewnianiu spełniania wymagań dostępności niektórych produktów i usług przez podmioty gospodarcze. W praktyce jest ona często nazywana Polskim Aktem o Dostępności (PAD). Niniejszy materiał ma charakter informacyjny, a nie indywidualnej porady prawnej. Stan opisanych przepisów należy każdorazowo potwierdzić w aktualnym tekście ustawy i źródłach urzędowych.
Najważniejsze wnioski
- Najpierw ustal zakres: produkt, usługa, kanał cyfrowy, odbiorca i rola firmy w łańcuchu dostaw.
- W e-commerce audytuj cały zakup, a nie wyłącznie stronę główną lub kartę produktu.
- Rozdziel działania natychmiastowe, takie jak funkcje wspierające dostępność, od napraw wymagających zmian w kodzie, treści i procesie obsługi.
- Traktuj WCAG jako ważny punkt techniczny, ale nie jako jedyny dowód spełnienia obowiązków związanych z EAA i PAD.
- Utrzymuj dokumentację, procedurę zgłoszeń oraz kontrolę dostępności po zmianach w serwisie.
Czym jest EAA i co oznacza dla firmy?
EAA, czyli European Accessibility Act, to unijna dyrektywa 2019/882 dotycząca wymagań dostępności wybranych produktów i usług. Jej celem jest ograniczanie barier dla użytkowników, w tym osób z niepełnosprawnościami i osób starszych, oraz ujednolicanie wymagań na rynku Unii Europejskiej.
Dyrektywa obejmuje między innymi określone urządzenia i terminale, usługi telekomunikacyjne, bankowość detaliczną, e-booki, wybrane usługi transportowe oraz handel elektroniczny. W odniesieniu do e-commerce znaczenie ma to, czy usługa jest świadczona na odległość, drogą elektroniczną, na indywidualne żądanie konsumenta i służy zawarciu umowy.
Nie należy jednak zakładać, że każda witryna informacyjna jest objęta identycznym zakresem wymagań. Ustawa przewiduje wyłączenia oraz warunki zależne między innymi od rodzaju usługi, produktu i statusu podmiotu. Przykładowo, wyłączenie dotyczące mikroprzedsiębiorców odnosi się do usług i nie powinno być automatycznie przenoszone na producentów produktów objętych ustawą.
Dostępność nie zaczyna się od deklaracji. Zaczyna się od pytania, czy użytkownik może bez pomocy znaleźć ofertę, podjąć decyzję i skutecznie zakończyć swoją sprawę.
Jak odróżnić EAA, PAD, EN 301 549 i WCAG?
Te pojęcia są powiązane, ale nie są synonimami. Ich rozróżnienie pomaga uniknąć kosztownych uproszczeń podczas planowania wdrożenia.
| Pojęcie | Rola | Znaczenie praktyczne |
|---|---|---|
| EAA | Dyrektywa UE 2019/882 | Wyznacza ramy wymagań dostępności dla określonych produktów i usług. |
| PAD | Polska ustawa wdrażająca EAA | Określa obowiązki, wyłączenia, procedury skargowe i nadzór w Polsce. |
| EN 301 549 | Europejska norma dla produktów i usług ICT | Obejmuje szerszy zakres technologii niż sama strona internetowa. |
| WCAG | Wytyczne W3C dla dostępności treści internetowych | Pomagają ocenić strony, aplikacje i komponenty cyfrowe. |
| Audyt WCAG | Praktyczna ocena serwisu | Wykrywa bariery oraz pozwala ustalić priorytety napraw. |
WCAGbot Accessibility Path: od zakresu do utrzymania
Zdanie „strona jest zgodna z WCAG” nie powinno zastępować analizy prawnej i technicznej. Zgodność z wybranymi kryteriami WCAG nie przesądza samodzielnie o pełnym spełnieniu wszystkich wymagań dotyczących produktu lub usługi. Więcej o praktycznym znaczeniu kryteriów znajdziesz w artykule WCAG 2.1 AA: co oznacza i jak wdrożyć na stronie.
Od czego zacząć wdrożenie EAA w e-commerce?
Najbezpieczniejsza kolejność to najpierw klasyfikacja zakresu, potem audyt rzeczywistych ścieżek użytkownika, a następnie poprawki oraz utrzymanie procesu. Ten porządek opisuje schemat WCAGbot Accessibility Path.
1. Zbuduj katalog usług i punktów kontaktu
Nie ograniczaj listy do domeny głównej. Zapisz wszystkie miejsca, w których użytkownik zawiera umowę, otrzymuje obsługę albo podejmuje ważną decyzję. Uwzględnij:
- sklep, marketplace lub platformę rezerwacyjną;
- aplikację mobilną;
- wyszukiwarkę, filtry i porównywarkę produktów;
- logowanie, rejestrację i odzyskiwanie hasła;
- koszyk, formularze, dostawę i płatność;
- e-maile transakcyjne, faktury, zwroty i reklamacje;
- zewnętrzne moduły, w tym płatności, czat i system zgód.
2. Oceń, gdzie użytkownik napotyka barierę
Audyt powinien obejmować proces, nie tylko pojedynczy widok. Dla sklepu szczególnie ważne są działanie klawiaturą, widoczny fokus, zrozumiałe etykiety formularzy, komunikaty o błędach, poprawna kolejność nagłówków, kontrast oraz obsługa czytnikiem ekranu.
Przydatnym punktem startu jest poradnik WCAG dla e-commerce: jak ułatwić zakupy online. Jeżeli problem dotyczy formularzy lub koszyka, zweryfikuj też semantykę HTML i komunikaty przekazywane technologiom asystującym. Pomocne będą materiały: HTML semantyczny: praktyczny poradnik wdrożenia oraz ARIA: praktyczny poradnik wdrożenia i testowania.
3. Testuj automatycznie i manualnie
Skanery automatyczne mogą szybko wskazać powtarzalne błędy, takie jak brak etykiety pola czy niski kontrast. Nie ocenią jednak wielu kluczowych kwestii: sensu tekstu alternatywnego, kolejności obsługi klawiaturą, zrozumiałości błędu w płatności czy poprawności procesu dla użytkownika czytnika ekranu.
Minimalny zestaw testów powinien zawierać test klawiaturą, test fokusu, sprawdzenie kontrastu, test powiększenia, test formularzy oraz test z czytnikiem ekranu. Praktykę testowania opisuje poradnik NVDA: praktyczny poradnik testowania dostępności. Warto też sprawdzić, czy fokus nie jest zasłonięty przez baner, nagłówek przyklejony do ekranu albo okno modalne: WCAG 2.4.11 Focus Not Obscured.
4. Ustal właściciela każdej poprawki
Nie wszystkie bariery naprawi ten sam zespół. Programista może poprawić semantykę, dostępność modala i obsługę klawiaturą. Content designer powinien dopracować etykiety, komunikaty błędów i instrukcje. Zespół e-commerce może przetestować integrację płatności, a obsługa klienta potrzebuje procedury przyjęcia zgłoszenia.
5. Udokumentuj decyzje i utrzymuj dostępność
Dokumentacja powinna pokazywać, co zostało sprawdzone, jakie bariery znaleziono, które poprawki wdrożono, jakie wyjątki rozważono i kto odpowiada za kolejne kontrole. Dla usługodawców znaczenie ma również przekazanie użytkownikowi informacji o usłudze i sposobie spełniania wymagań dostępności w formie wymaganej przez ustawę.
WCAG, EN 301 549 i EAA: różne elementy oceny
Co może zrobić widget dostępności, a czego nie zastąpi?
Widget dostępności może być rozsądnym pierwszym krokiem, szczególnie gdy firma chce szybko zaoferować użytkownikom dodatkowe ustawienia. WCAGbot pozwala uruchomić funkcje wspierające dostępność po dodaniu jednej linii kodu. Użytkownik może między innymi zwiększyć tekst i odstępy, uruchomić tryb kontrastu lub skali szarości, skorzystać z czytania treści, większego kursora, podświetlania nagłówków i linków czy zatrzymania animacji.
To realne wsparcie dla części użytkowników, ale nie naprawi źródłowo błędnej struktury formularza, nieopisanej kontrolki płatności, nieprawidłowej kolejności fokusu ani niezrozumiałego komunikatu o odrzuconej transakcji. Widget nie zastępuje audytu WCAG, testów z użytkownikami ani poprawek w kodzie i treści. Granice tego rozwiązania wyjaśnia artykuł Widget WCAG: co pomaga, a czego nie naprawi.
Doświadczeniowe CTA: otwórz panel WCAGbot na własnej stronie testowej, zwiększ tekst, włącz kontrast i sprawdź, czy najważniejszy formularz nadal pozostaje łatwy do wypełnienia klawiaturą.
Mini-scenariusz: sklep działa, ale zakup nie jest dostępny
Scenariusz ilustracyjny: sklep z kosmetykami ma poprawnie opisaną stronę główną i wdrożony przycisk do zmiany kontrastu. Podczas testu klawiaturą okazuje się jednak, że po otwarciu listy metod dostawy fokus przechodzi pod okno modalne. Użytkownik nie widzi aktywnego elementu, nie może łatwo zamknąć listy i nie dociera do płatności.
W tym przypadku funkcja kontrastu nadal wspiera część osób, ale problem wymaga naprawy źródłowej w komponencie wyboru dostawy. Zespół powinien poprawić zarządzanie fokusem, przetestować modal klawiaturą i czytnikiem ekranu oraz wykonać retest całej ścieżki zakupowej. Takie sytuacje pokazują, dlaczego warto planować audyt WCAG i wdrożenie krok po kroku, a nie ograniczać się do oceny strony głównej.
Jak przygotować procedurę zgłoszeń i skarg?
Ustawa przewiduje możliwość złożenia przez konsumenta skargi dotyczącej niespełniania wymagań dostępności. Firma powinna więc ustalić dostępny kanał kontaktu, właściciela sprawy, sposób rejestrowania zgłoszenia oraz model odpowiedzi. Procedura nie musi być skomplikowana, ale musi działać również wtedy, gdy problem dotyczy zewnętrznego dostawcy, na przykład bramki płatniczej.
Praktyczna checklista procedury:
- opisz kanały przyjmowania zgłoszeń i alternatywny sposób kontaktu;
- zapisz dane potrzebne do odtworzenia bariery: adres, urządzenie, przeglądarka, opis kroku i oczekiwany rezultat;
- oznacz sprawy blokujące zakup lub dostęp do kluczowej usługi jako pilne;
- przypisz zgłoszenie do właściciela biznesowego i technicznego;
- po poprawce wykonaj retest oraz zapisz wynik;
- sprawdź ustawowe terminy i wymagania bezpośrednio w aktualnym tekście ustawy.
Podsumowanie dla zarządzającego i sprzedaży
Wdrożenie EAA nie polega na zakupie pojedynczego narzędzia ani na publikacji krótkiej deklaracji. To proces obejmujący zakres usług, projektowanie, kod, treść, dostawców i obsługę klienta. Największą wartość daje skupienie na krytycznych zadaniach użytkownika: znalezieniu produktu, podjęciu decyzji, zakupie, płatności i uzyskaniu pomocy.
Mapa dostępnej ścieżki zakupowej
WCAGbot może szybko dodać funkcje poprawiające komfort korzystania ze strony i wesprzeć użytkowników w codziennym użyciu serwisu. Następny etap powinien obejmować audyt, priorytetyzację barier oraz trwałe poprawki w źródle.
Dodaj funkcje dostępności swojej strony i przetestuj WCAGbot jako pierwszy krok do dostępności cyfrowej.
FAQ: EAA i wdrożenie dostępności
Czy EAA dotyczy każdej strony internetowej?
Nie. EAA dotyczy określonych produktów i usług. W przypadku strony trzeba ustalić, czy jest ona elementem usługi objętej przepisami, na przykład usługi handlu elektronicznego, oraz czy podmiot nie korzysta z ustawowego wyłączenia.
Czy sklep internetowy jest usługą e-commerce w rozumieniu PAD?
Sklep internetowy może być objęty zakresem ustawy, jeżeli świadczy usługę handlu elektronicznego zgodnie z ustawową definicją. Ocena powinna uwzględniać konkretny model sprzedaży, odbiorcę usługi i rolę przedsiębiorcy.
Czy mikroprzedsiębiorca jest zwolniony z obowiązków EAA?
Ustawa przewiduje wyłączenie dla usług oferowanych lub świadczonych przez mikroprzedsiębiorców. Nie należy jednak automatycznie stosować tego wyłączenia do produktów ani zakładać jego zastosowania bez analizy definicji i konkretnej sytuacji firmy.
Czy zgodność z WCAG oznacza zgodność z EAA?
Nie automatycznie. WCAG pomaga ocenić dostępność treści i interfejsu cyfrowego, ale EAA oraz polska ustawa obejmują szersze wymagania dotyczące konkretnych produktów, usług, informacji i procedur.
Czy wystarczy audyt strony głównej?
Nie. Dla e-commerce najważniejsze są również wyszukiwanie, filtry, formularze, koszyk, płatność, zwroty, reklamacje i kontakt. Bariera w jednym z tych kroków może uniemożliwić skorzystanie z całej usługi.
Czy automatyczny skaner wystarczy do oceny dostępności?
Nie. Skaner pomaga wykryć część powtarzalnych problemów, lecz nie zastąpi testów klawiaturą, czytnikiem ekranu, powiększeniem ani oceny zrozumiałości komunikatów i całego procesu użytkownika.
Czy widget dostępności zapewnia pełną zgodność z WCAG lub PAD?
Nie. Widget może wspierać użytkownika przez funkcje takie jak kontrast, powiększenie tekstu, czytanie treści czy zatrzymanie animacji. Nie zastępuje jednak napraw źródłowych, audytu, testów i dokumentacji wymaganej dla konkretnej usługi.
Jakie elementy sklepu testować najpierw?
Najpierw sprawdź ścieżkę o największym znaczeniu biznesowym: wyszukanie produktu, wybór wariantu, dodanie do koszyka, dane dostawy, płatność i potwierdzenie zakupu. Następnie zbadaj logowanie, kontakt, zwroty i reklamacje.
Czy trzeba testować z czytnikiem ekranu?
Tak, test z czytnikiem ekranu jest ważnym elementem oceny dostępności interfejsu. Pozwala sprawdzić między innymi nazwy kontrolek, etykiety formularzy, komunikaty o błędach oraz kolejność odczytu treści.
Co dokumentować po audycie?
Warto zapisać zakres audytu, zastosowane kryteria, znalezione bariery, priorytety, plan naprawczy, właścicieli zadań, wyniki retestów oraz sposób obsługi zgłoszeń użytkowników. Dokumentacja ułatwia utrzymanie dostępności przy kolejnych zmianach.
Źródła i materiały
- EUR-Lex — Dyrektywa (UE) 2019/882
- ELI Sejmu — ustawa o zapewnianiu spełniania wymagań dostępności niektórych produktów i usług przez podmioty gospodarcze
- Gov.pl — Polski Akt o Dostępności: usługi handlu elektronicznego
- W3C Web Accessibility Initiative
- WebAIM Million 2025
- www.etsi.org
- webaim.org
- ses.jrc.ec.europa.eu
- webaim.org
- interoperable-europe.ec.europa.eu
- accessible-eu-centre.ec.europa.eu
- accessible-eu-centre.ec.europa.eu
