Automatyczne skanowanie a wymogi EAA 2025: dlaczego sam raport z narzędzia nie uchroni MŚP przed karami UODO?

Meta: Dowiedz się, dlaczego automatyczne audyty dostępności to za mało, by spełnić wymogi EAA 2025 i jak uniknąć kar UODO w polskich realiach MŚP.

Cześć, tutaj Piotr. Jeśli prowadzisz zespół 5-10 programistów lub zarządzasz małym software housem, prawdopodobnie słyszałeś już o nadchodzącym terminie czerwcowym 2025 roku. Mowa o European Accessibility Act (EAA), który w polskim prawie zostanie zaimplementowany jako ustawa o dostępności.

Wielu moich znajomych CTO i właścicieli firm MŚP podchodzi do tego tematu w ten sam sposób: „Odpalimy jakiś automatyczny skaner, poprawimy błędy z raportu i jesteśmy kryci”. Jako osoba, która łączy światy kodu i compliance, muszę Was ostrzec: to podejście jest prostą drogą do problemów prawnych i finansowych.

Automatyzacja to świetny start, ale w starciu z organami nadzorczymi (takimi jak UODO czy potencjalne nowe organy nadzoru nad dostępnością) sam plik PDF z wynikiem "100% score" nie ma żadnej wartości dowodowej. Dlaczego? Bo dostępność to nie tylko brak błędów w kodzie, ale przede wszystkim doświadczenie użytkownika.

Czym właściwie jest EAA w praktyce dla polskiego dewelopera?

European Accessibility Act to nie jest kolejna „dobra rada”. To twarde prawo. W przeciwieństwie do wcześniejszych wytycznych, które często dotyczyły tylko sektora publicznego (WCAG 2.1 w administracji), EAA uderza w sektor prywatny: e-commerce, bankowość, usługi transportowe i wiele innych.

Dla zespołu deweloperskiego oznacza to, że Wasz produkt musi być dostępny dla osób z różnymi niepełnosprawnościami. Jeśli Wasz sklep internetowy nie pozwala osobie niewidomej na sfinalizowanie zakupu za pomocą czytnika ekranu, naruszacie prawo.

Wiele osób pyta mnie: „Piotr, przecież mamy Lighthouse i Axe. Czy to nie wystarczy?”. Odpowiedź brzmi: nie. Automatyczne narzędzia wykrywają średnio od 30% do 50% problemów z dostępnością. Reszta to kwestie logiczne, semantyczne i nawigacyjne, których żaden algorytm nie „zobaczy”.

Pułapka automatyzacji: Co skaner pomija?

Wyobraźcie sobie następującą sytuację. Wasz skaner raportuje, że każdy obrazek ma atrybut alt. Brawo, 100% zgodności w tej kategorii. Jednak gdy osoba niewidoma wchodzi na stronę, słyszy: „Obrazek 12345_final_v2.jpg”.

Technicznie? Atrybut jest. Semantycznie? To śmieć. Dla użytkownika to bariera, a dla kontrolera z urzędu – dowód na to, że dostępność została zaimplementowana „na papierze”, a nie w rzeczywistości.

Przykłady błędów, których nie wyłapie żaden automat:

1. Kolejność tabulacji (Focus Order): Skaner sprawdzi, czy element ma focus. Nie sprawdzi jednak, czy użytkownik przeskakuje z formularza kontaktu do stopki, omijając cały główny panel nawigacyjny.
2. Kontrast dynamiczny: Automaty sprawdzą statyczne kolory. Nie sprawdzą, czy w trybie „dark mode” kontrast tekstu w modalu nie spada poniżej poziomu AA.
3. Logika czytników ekranu (Screen Readers): Czy Wasz customowy dropdown jest oznakowany jako combobox z odpowiednimi relacjami aria-expanded i aria-controls? Skaner może nie zauważyć braku relacji, jeśli tagi istnieją, ale ich logika jest błędna.
4. Pułapki klawiaturowe (Keyboard Traps): Skaner nie powie Ci, że użytkownik, po wejściu do modala z regulaminem, nie może z niego wyjść za pomocą klawisza Esc, zostając uwięzionym wewnątrz elementu.

EAA a RODO: Gdzie te światy się przecinają?

Możecie pomyśleć: „Przecież EAA to tylko UX, co ma do tego UODO?”. Otóż w Polsce granica między dostępnością a ochroną danych jest cieńsza, niż się wydaje.

UODO (Urząd Ochrony Danych Osobowych) coraz częściej patrzy na to, jak projektujemy systemy. Jeśli Wasza aplikacja jest niedostępna, zmuszacie użytkownika do korzystania z niebezpiecznych obejść (np. przesyłania danych wrażliwych przez e-mail, bo formularz na stronie nie działa z czytnikiem ekranu). To tworzy luki w bezpieczeństwie i może prowadzić do naruszeń RODO.

Pamiętajmy o decyzjach UODO. Choć kary za brak dostępności będą nakładane w ramach nowych przepisów, UODO już teraz nakłada kary za brak transparentności i utrudnianie realizacji praw osób, których dane dotyczą. Jeśli panel zarządzania zgodami (cookie banner) jest niedostępny dla osoby z niepełnosprawnością, taka osoba nie może świadomie zarządzać swoimi danymi. To jest bezpośrednie naruszenie zasad RODO.

W historii decyzji UODO widzieliśmy kary rzędu od kilku do kilkudziesięciu tysięcy złotych za błędy w procesach przetwarzania danych w małych firmach. EAA wprowadza potencjał na kary, które mogą być znacznie bardziej dotkliwe, ponieważ dotyczą systemowo błędnie zaprojektowanych produktów.

Jak podejść do compliance przy ograniczonym budżecie MŚP?

Wiem, jak to wygląda. Macie 6 programistów, gonią Was deadliny, a biznes chce nowej funkcjonalności, a nie „poprawiania kolorów przycisków”. Jako konsultant compliance w Warszawie, zawsze rekomenduję podejście Risk-Based Approach. Nie próbujcie naprawić wszystkiego na raz.

Strategia "Quick Wins" dla zespołów deweloperskich:

1. Semantyka ponad wszystko: Przestańcie budować przyciski z <div>. Użyjcie <button>. To za darmo, a rozwiązuje 20% problemów z dostępnością w jedną godzinę.
2. Klawiatura to podstawa: Odłączcie myszkę na jeden dzień w tygodniu. Spróbujcie przejść cały proces zakupu/rejestracji używając tylko Tab, Enter i Space. To najtańszy audyt świata.
3. Krytyczne ścieżki (Critical Paths): Skupcie się na tzw. Happy Path. Jeśli użytkownik nie może przejść przez proces płatności lub rejestracji – to jest krytyczny błąd, który generuje największe ryzyko prawne.

Przykładowy fragment kodu – jak robić to źle vs. jak robić to dobrze:

// ❌ BŁĘDNE PODEJŚCIE: "Działa, bo klika się myszką"
const BadButton = () => {
  return (
    <div 
      onClick={() => console.log('Kliknięto!')} 
      style={{ backgroundColor: 'blue', color: 'white', cursor: 'pointer' }}
    >
      Zapisz dane
    </div>
  );
};

// ✅ POPRAWNE PODEJŚCIE: Dostępne, semantyczne i bezpieczne
const GoodButton = () => {
  return (
    <button 
      type="submit" 
      aria-label="Zapisz dane użytkownika"
      className="btn-primary"
    >
      Zapisz dane
    </button>
  );
};

W pierwszym przypadku osoba korzystająca z czytnika ekranu w ogóle nie dowie się, że ten element jest interaktywny. W drugim – systemy wspomagania natychmiast zidentyfikują element jako przycisk.

Dlaczego sam raport z narzędzia to za mało?

Kiedy przyjdzie kontrola, urzędnik nie zapyta o wynik z Lighthouse. Zapyta o Dokumentację Zapewnienia Dostępności.

Raport z narzędzia automatycznego jest tylko jednym z elementów. Prawdziwym dowodem na compliance jest:

• Wyniki testów manualnych przeprowadzonych przez osoby z niepełnosprawnościami.
• Dokumentacja opisująca, jakie bariery zostały zidentyfikowane i jak zostały rozwiązane.
• Deklaracja dostępności (Accessibility Statement), która jasno mówi, co działa, a co jest w trakcie poprawy.

Jeśli przedstawicie tylko raport z automatu, kontroler może uznać, że wykazaliście rażące niedbalstwo, ignorując oczywiste bariery użytkownika, których automat nie widzi.

Realna ścieżka wdrożenia dla MŚP (Step-by-Step)

Jeśli chcecie uniknąć kar i realnie spełnić wymogi EAA 2025, sugeruję następujący workflow:

1. Skanowanie automatyczne (Szybki start): Użyjcie narzędzi takich jak Axe czy Lighthouse, aby wyczyścić „wiszące owoce” (braki w altach, zbyt niski kontrast).
2. Audyt manualny kluczowych ścieżek: Przejście przez procesy krytyczne (checkout, logowanie, kontakt) z użyciem klawiatury.
3. Testy z użytkownikami: To jedyny sposób, by mieć pewność, że produkt jest dostępny. Współpraca z jedną osobą korzystającą z czytnika ekranu (NVDA lub JAWS) powie Wam więcej niż 100 raportów z automatycznych skanerów.
4. Ciągły monitoring: Wprowadzenie testów dostępności do potoku CI/CD (np. za pomocą cypress-axe), aby nowe commity nie psuły tego, co już naprawiliście.

Gdzie szukać pomocy i jak zacząć?

Wiem, że dla wielu z Was temat dostępności wydaje się być "czarną magią" lub kolejnym nudnym wymogiem prawnym. Ale spójrzcie na to z perspektywy biznesowej: dostępność to po prostu lepszy UX dla każdego. Lepsza semantyka to lepsze SEO, a lepsza nawigacja to wyższa konwersja.

Jeśli nie wiecie, od czego zacząć i boicie się, że Wasz system jest "dziurawy" pod kątem EAA i RODO, nie czekajcie do czerwca 2025. Im później zaczniecie, tym droższe będą poprawki, bo będą wymagały refaktoryzacji architektury, a nie tylko zmiany kilku tagów HTML.

Polecam narzędzia, które łączą automatyzację z możliwością weryfikacji manualnej. Jeśli szukacie miejsca, gdzie możecie szybko sprawdzić stan swojego serwisu, odwiedźcie inspect-my-site.com. To dobry punkt wyjścia, aby zidentyfikować najsłabsze ogniwa w Waszej architekturze i zaplanować naprawy przed wejściem w życie nowych przepisów.

Podsumowanie dla zespołu

Zanim zamkniesz ten artykuł, zapamiętaj trzy rzeczy:

1. Automatyzacja to tylko 30-50% sukcesu. Reszta to semantyka i logika.
2. EAA 2025 to nie sugestia, to prawo. Kary będą realne i mogą być powiązane z naruszeniami ochrony danych (UODO).
3. Zacznij od "Happy Path". Napraw najpierw to, co uniemożliwia użytkownikowi zakup lub kontakt.

Kluczowe wnioski dla właścicieli MŚP:

• Automatyczne raporty nie chronią przed karami, jeśli użytkownik wciąż nie może korzystać z serwisu.
• Dokumentacja procesu naprawy jest ważniejsza niż pojedynczy wynik testu.
• Dostępność to inwestycja w UX i SEO, a nie tylko koszt compliance.
• Rekomenduję regularne testy manualne i korzystanie z narzędzi weryfikacyjnych typu inspect-my-site.com.

---

Zapraszam do dyskusji!
Czy w Waszych zespołach dostępność jest traktowana jako element definicji "Done", czy jako coś, co "naprawimy na koniec projektu"? Jakie macie doświadczenia z narzędziami do automatycznego skanowania? Czy faktycznie pomogły, czy tylko stworzyły złudne poczucie bezpieczeństwa? Dajcie znać w komentarzach!

javascript #webdev #accessibility #compliance

---

O autorze: Piotr Wiśniewski to full-stack developer i konsultant compliance z Warszawy. Specjalizuje się w pomaganiu polskim MŚP w implementacji RODO oraz nadchodzących wymogów EAA, łącząc świat techniczny z prawnym.