← Wszystkie poradniki

Strony i sklepy

Europejski Akt o Dostępności: od zakresu obowiązku do planu zmian

Pytanie o EAA powinno zaczynać się od rodzaju usługi i sytuacji przedsiębiorcy. Dopiero potem warto zamawiać audyt i poprawki. Sama obecność witryny w internecie nie uzasadnia identycznej listy obowiązków dla każdej firmy.

Redakcja DigiDraftAktualizacja: 8 min czytania

Najpierw sprawdź, czy i w jakim zakresie dotyczy Cię ustawa

Polska ustawa wdrażająca EAA zaczęła być stosowana do objętych nią produktów i usług od 28 czerwca 2025 r. Ministerstwo Cyfryzacji opisuje handel elektroniczny w kontekście zawierania umów z konsumentami. Usługi oferowane lub świadczone przez mikroprzedsiębiorców są wskazane jako wyłączenie.

Nie wyciągaj wniosku jedynie z wielkości strony czy liczby zamówień. Zbierz status przedsiębiorcy, rodzaj usługi, grupę odbiorców i sposób zawierania umowy. Wątpliwy przypadek oceniaj według aktualnych przepisów z osobą kompetentną w tej dziedzinie; ten poradnik służy przygotowaniu działań, nie indywidualnej kwalifikacji prawnej.

Przygotuj dane do oceny zakresu, zanim kupisz rozwiązanie

Zbierz opis usługi, regulamin, sposób zawierania umowy oraz informację, czy klientem jest konsument. Zapisz podmiot świadczący usługę, rynki działania i wykorzystywane kanały: stronę, aplikację, platformę sprzedażową lub rezerwacyjną. Ocena mikroprzedsiębiorcy powinna opierać się na właściwych kryteriach i dokumentach firmy, a nie potocznej ocenie „jesteśmy mali”. Dostawca strony nie musi dysponować tymi informacjami. Osoba prowadząca ocenę potrzebuje faktów, żeby nie utożsamiać małej liczby zamówień z ustawowym wyłączeniem.

Przykład: firma prezentuje ofertę dla przedsiębiorstw, ale osobny formularz umożliwia konsumentowi zamówienie usługi. Sam napis B2B na homepage nie opisuje całego procesu. Drugi przykład: sklep korzysta z zewnętrznego checkoutu, więc fragment umowy jest zawierany poza główną domeną. Zaznacz tę zależność. Nie rozstrzygaj automatycznie, że wszystko poza domeną pozostaje poza zainteresowaniem audytu. Wynikiem pierwszego etapu ma być pisemnie ustalony zakres oraz lista pytań wymagających fachowej oceny. Dopiero z nimi zamawiaj badanie, które obejmuje odpowiednie usługi, kanały i etapy kontaktu z klientem.

EAA, polska ustawa i WCAG pełnią różne role

EAA jest dyrektywą europejską. W Polsce wymagania wdraża ustawa z 26 kwietnia 2024 r. WCAG dostarcza technicznych kryteriów dla treści internetowych. Nie sprowadzaj całego obowiązku przedsiębiorcy do wyniku jednego skanera. W dokumentacji określ podstawę prawną i osobno standard, według którego prowadzisz badanie interfejsu. Jeśli wykonawca przywołuje normę EN 301 549, poproś o wersję, zakres zastosowania i podstawę powiązania z wymaganiami dotyczącymi konkretnej usługi. Sama nazwa normy w stopce raportu nie rozstrzyga tych kwestii.

Ministerstwo prowadzi wykaz norm i specyfikacji dotyczących e-handlu. Sprawdź jego aktualność oraz dokumenty źródłowe na dzień oceny. Zapowiedź nowej wersji nie jest dowodem, że już została opublikowana lub uzyskała wymagany status. To ważne przy umowie trwającej kilka miesięcy: datę i przyjętą podstawę zapisz w raporcie. Dla projektowania możesz przyjąć ambitniejszy cel techniczny, ale nie opisuj go jako uniwersalnego obowiązku każdej firmy bez sprawdzenia przepisów. Takie rozdzielenie porządkuje odpowiedzialność prawną, projektową i odbiór wykonanej pracy, a także ułatwia późniejszą aktualizację zakresu badania.

Rozpisz zakup na stany, które można sprawdzić

Przejdź drogę od znalezienia produktu do potwierdzenia zamówienia. Dodaj wybór wariantu, zmianę ilości, brak towaru, kod rabatowy, dane do dostawy i wybór płatności. Zapisz także wycofanie się, powrót z bramki oraz nieudany etap. Taki spis wyznacza zakres testów interfejsu; prawną ocenę usługi ustala się osobno. Jeśli odwzorujesz tylko idealny zakup, pominiesz miejsca, w których interfejs wymaga dodatkowej decyzji lub wyświetla komunikat. Właśnie te stany są często niewidoczne na statycznych makietach.

Przykład: klient dodaje produkt, otwiera koszyk, ale przy powiększeniu panel zasłania przycisk przejścia dalej. Inny klient wybiera paczkomat na mapie bez dostępnej listy lub wyszukiwarki. Jeszcze inny nie słyszy komunikatu o odrzuconej płatności. Zapisz każdy przypadek jako scenariusz z początkiem i oczekiwanym zakończeniem. Uwzględnij klawiaturę, czytnik ekranu, większy tekst i niewielki ekran. Do testów używaj danych oraz płatności testowych. Nie wykonuj prawdziwych transakcji ani nie kopiuj danych klientów tylko po to, żeby udokumentować wygląd procesu i pokazać problem w raporcie.

Rozdziel zadania między firmę, wykonawcę i dostawców

Dla każdego elementu ustal, kto może go zmienić. Teksty i fotografie zwykle mają innego właściciela niż checkout, a widżet płatności może być rozwijany przez zewnętrzny podmiot. Przygotuj prostą macierz: element, problem, dostawca, możliwa zmiana, osoba kontaktowa i termin weryfikacji. Nie zakładaj, że dowolna agencja poprawi kod usługi, do którego nie ma dostępu. Powinna natomiast rozpoznać zależność i wskazać drogę do jej rozwiązania, na przykład konfigurację, zgłoszenie lub zmianę integracji.

Zapytaj dostawcę o dowody dotyczące faktycznie używanej wersji, obsługiwane technologie wspomagające i sposób zgłaszania barier. Ogólna deklaracja marketingowa bez zakresu może nie odpowiadać Twojemu wdrożeniu. Przykład: moduł jest użyteczny w demonstracji, ale własny styl sklepu usuwa widoczny fokus. Wtedy trzeba sprawdzić integrację, nie tylko sam produkt. Inny przypadek to błąd po aktualizacji zewnętrznego skryptu. Ustal, kto wykryje regresję i jakie tymczasowe rozwiązanie jest realne dla klienta. Telefon do obsługi może pomagać, ale nie zakładaj bez oceny, że zastępuje wszystkie wymagania procesu cyfrowego.

Dokumentacja dla klienta powinna opisywać rzeczywistą usługę

Przepisy i wyjaśnienia Ministerstwa rozróżniają informowanie konsumenta o usłudze i jej dostępności od informowania właściwego organu o niespełnianiu wymagań oraz działaniach naprawczych. Nie kopiuj automatycznie deklaracji przeznaczonej dla podmiotów publicznych. Przygotuj dokument odpowiadający podstawie prawnej Twojej usługi i jej faktycznemu działaniu. Potwierdź treść z osobą odpowiedzialną za ocenę obowiązków. Samo opublikowanie dokumentu nie usuwa bariery, dlatego praca redakcyjna i techniczna muszą odnosić się do tego samego stanu witryny.

Z punktu widzenia użytkownika opis powinien jasno wskazywać, czego dotyczy, jak skorzystać z usługi i gdzie zgłosić trudność. Osoba obsługująca zgłoszenia potrzebuje sposobu przekazania problemu do wykonawcy. Zapisz datę oceny, badane elementy oraz odpowiedzialnego za aktualizację informacji. Przykład: po wymianie dostawcy płatności wcześniejszy opis może przestać odpowiadać temu, co rzeczywiście działa. Powrót do dokumentacji powinien być częścią odbioru zmiany. Nie dopisuj pełnej zgodności na podstawie planu przyszłych napraw. Opis aktualnego stanu i zaplanowane prace to różne informacje, które należy utrzymywać w porządku.

Ułóż plan napraw według wpływu i zależności

Najpierw nazwij bariery uniemożliwiające zadanie, potem błędy powtarzalnych komponentów i treści. Przy każdym zadaniu zapisz właściciela, zależność od dostawcy oraz dowód zakończenia. „Poprawić dostępność” nie jest zadaniem możliwym do odebrania. „Udostępnić wybór dostawy klawiaturą i potwierdzić zakończenie zamówienia w scenariuszu testowym” jest znacznie bardziej konkretne. Nie utożsamiaj liczby zamkniętych zgłoszeń z poprawą najważniejszych procesów. Dziesięć drobnych zmian może nie pomóc osobie zablokowanej przez jeden niedziałający krok.

Przykładowa kolejność organizacyjna to: odtworzenie barier, naprawa wspólnego komponentu, aktualizacja treści, sprawdzenie zewnętrznej integracji i ponowny test pełnego procesu. To schemat pracy, a nie ustawowy harmonogram ani obietnica czasu realizacji. Jeżeli komponent używany jest w wielu miejscach, kontroluj kilka reprezentatywnych zastosowań, także odmienne języki i dłuższe teksty. Poprawka nie powinna usuwać opisu, zmieniać znaczenia ceny czy psuć walidacji. Własne kryteria odbioru powiąż z zadaniem klienta i przyjętym zakresem audytu. Dzięki temu wykonawca wie, jaki dowód ma dostarczyć, a firma może sprawdzić konkretny rezultat zamiast oceniać zapewnienia.

Wyjątki i sankcje oceniaj na podstawie przepisów

Ustawa przewiduje nadzór i administracyjne kary pieniężne za wskazane naruszenia. Nie da się wyliczyć ryzyka konkretnej firmy na podstawie samego zrzutu strony. Rodzaj obowiązku, stan faktyczny i przebieg postępowania mają znaczenie. Zamiast opierać decyzję wyłącznie na maksymalnej kwocie z nagłówka, przygotuj dokumenty oraz ocenę zakresu. W sprawie otrzymanego pisma lub terminu działania potrzebna jest indywidualna analiza aktualnych przepisów i korespondencji. Techniczny audyt pomaga ustalić bariery, lecz nie zastępuje takiej oceny.

Podobnie twierdzenie, że naprawa jest kosztowna, nie stanowi samoistnego rozstrzygnięcia o nieproporcjonalnym obciążeniu. Ministerstwo opisuje ocenę, dokumentowanie i obowiązki informacyjne dotyczące powoływania się na wyjątki. Nie zamieniaj braku budżetu w nieudokumentowane zwolnienie. Oddziel decyzję wymagającą oceny prawnej od możliwych już usprawnień, na przykład naprawy etykiet lub porządku klawiatury. W rejestrze zapisz argumenty, wykorzystane materiały i datę ponownego sprawdzenia. To pozwala zachować ciągłość decyzji także wtedy, gdy zmienia się wykonawca, oferta firmy albo dostawca platformy sprzedażowej. Przy otwartych pytaniach wskaż osobę, która zbierze brakujące informacje.

Co przygotować do odbioru i dalszej obsługi

Na końcu zbierz zakres oceny, raport, listę zmian, wyniki powtórnych testów i znane ograniczenia. Odbiór powinien obejmować rzeczywistą wersję wdrożenia, a nie sam prototyp bez płatności i treści. Ustal, kto sprawdza zgłoszenia klientów, kiedy wraca się do testów oraz kto zatwierdza nowe komponenty. Zadbaj również o instrukcję dla redakcji: opisy obrazów, nazwy linków, dostępne dokumenty i zrozumiałe komunikaty. Dzięki temu naprawy nie znikną przy następnym imporcie produktów lub zmianie banera promocyjnego.

Jeżeli zaczynasz pracę nad dostępnością sklepu, przygotuj adres, opis modelu sprzedaży, dostawców kluczowych modułów i listę znanych problemów. Przekaż DigiDraft te informacje przez kontakt, żeby ustalić zakres badania i możliwe zadania techniczne. Ocenę prawną oprzyj na sytuacji przedsiębiorcy i aktualnych źródłach wymienionych poniżej. Nie musisz czekać na wielki redesign, żeby zidentyfikować podstawowe bariery. Potrzebujesz jednak uporządkowanego zakresu i weryfikacji po zmianach. Przy odbiorze wróć do zadań klientów: czy mogą złożyć zamówienie i rozwiązać napotkany problem? Dokumentacja powinna odpowiadać temu, co działa w sklepie.

Pytania i odpowiedzi

Jak przygotować firmę do oceny, czy obejmuje ją EAA?

Zbierz opis usługi, sposób zawierania umowy, informację o odbiorcach i dokumenty dotyczące statusu przedsiębiorcy. Uwzględnij wszystkie używane kanały, także zewnętrzną platformę sprzedaży. Na tej podstawie można zlecić ocenę właściwego zakresu obowiązków, zamiast wnioskować z samego wyglądu strony.

Czy audyt WCAG rozstrzyga wszystkie obowiązki związane z EAA?

Audyt WCAG dotyczy technicznych kryteriów dostępności treści internetowych. Ocena obowiązków firmy wymaga osobnego ustalenia podstawy prawnej i zakresu usługi. W zamówieniu badania zapisz, co obejmuje raport, a które kwestie potrzebują odrębnej oceny.

Które części sklepu uwzględnić w testach dostępności?

Prześledź całą drogę od wyboru produktu przez dostawę i płatność do potwierdzenia zamówienia. Dodaj błędy, brak towaru, powrót z bramki płatniczej i elementy dostawców zewnętrznych. Samo sprawdzenie strony głównej pomija miejsca, w których klient może utknąć.

Dobry projekt zaczyna się od rozmowy.

Opowiedz, co chcesz zmienić. Ustalimy punkt wyjścia, zakres i kolejny krok.

Opisz swój pomysł