Automatyzacja EAA w CI/CD: Jak wdrożyć testy dostępności w małym budżecie przed czerwcem 2025?

Meta: Dowiedz się, jak wdrożyć automatyczne testy dostępności (a11y) w CI/CD, aby spełnić wymogi EAA przed czerwcem 2025 bez przepalania budżetu.

Cześć, tutaj Piotr. Jako full-stack developer i konsultant compliance, codziennie widzę ten sam schemat: zespoły deweloperskie traktują dostępność (accessibility) jako "nice-to-have", dopóki prawnik nie rzuci hasłem "EAA" (European Accessibility Act). Jeśli zarządzasz zespołem 5-10 osób w polskim software house lub prowadzisz małe przedsiębiorstwo, prawdopodobnie czujesz, że termin czerwiec 2025 zbliża się nieubłaganie.

Europejski Akt o Dostępności (EAA) to nie jest kolejna "miękka" rekomendacja. To twarde prawo, które wprowadza wymogi dostępności dla szerokiego spektrum produktów i usług cyfrowych. Co to oznacza w praktyce? Jeśli Twoja aplikacja e-commerce, bankowość elektroniczna czy platforma usługowa nie będzie dostępna dla osób z niepełnosprawnościami, ryzykujesz nie tylko utratą klientów, ale przede wszystkim wysokimi karami administracyjnymi, które w polskim systemie prawnym będą egzekwowane z podobną surowością, jak kary nakładane przez UODO.

Pamiętajmy, że UODO nie bierze jeńców. Choć EAA to nowa regulacja, mechanizmy nadzorcze będą podobne do tych, które znamy z RODO. Widzieliśmy już kary rzędu setek tysięcy złotych za brak odpowiednich zabezpieczeń danych lub brak przejrzystości procesów. W przypadku EAA, brak dostępności cyfrowej będzie traktowany jako dyskryminacja i uchybienie wymogom prawnym.

Pytanie brzmi: jak to zrobić, mając ograniczony budżet, bez zatrudniania armii audytorów i bez blokowania każdego sprintu przez miesiące poprawek? Odpowiedź brzmi: przesunięcie testów dostępności w lewo (Shift-Left Accessibility).

Dlaczego ręczne testy to pułapka dla małego zespołu?

Wielu z Was myśli: "Przejdę przez stronę czytnikiem ekranu (Screen Reader) raz na kwartał i będzie OK". To najprostsza droga do katastrofy. W dynamicznym środowisku, gdzie merge'ujecie kod codziennie, jedna zmiana w strukturze DOM lub dodanie nowego komponentu UI bez odpowiedniego labela może sprawić, że aplikacja stanie się całkowicie nieużyteczna dla osoby niewidomej.

Ręczne testowanie jest:

1. 
   Nieskalowalne – nie sprawdzisz każdego stanu aplikacji w każdym przeglądarce.


2. 
   Kosztowne – audyt zewnętrzny przed samym deadlinem to koszt rzędu kilkunastu-kilkudziesięciu tysięcy złotych, a i tak znajdą 200 błędów, które trzeba będzie naprawić na "wczoraj".


3. 
   Reaktywne – naprawianie błędów w produkcji jest 10x droższe niż ich unikanie na etapie kodowania.

Kluczem jest automatyzacja. Oczywiście, automatyzacja nie wykryje 100% błędów (nie sprawdzi, czy logika nawigacji jest intuicyjna), ale wyłapie około 30-50% najczęstszych błędów (brak kontrastu, brak altów, brak ról ARIA), które stanowią fundamenty zgodności z WCAG 2.1, na którym opiera się EAA.

Stos technologiczny za zero złotych (lub prawie zero)

Nie potrzebujecie drogich korporacyjnych narzędzi. Większość z nas ma już w swoim stacku wszystko, czego potrzeba. Podstawą jest silnik axe-core. To standard przemysłowy, który zasila większość narzędzi a11y.

Oto jak wdrożyć automatyzację w zależności od Waszego stacku:

1. Lintery – pierwsza linia obrony

Zanim kod w ogóle trafi do repozytorium, linter powinien go zatrzymać. Jeśli używacie Reacta lub Vue, koniecznie zainstalujcie eslint-plugin-jsx-a11y.

npm install eslint-plugin-jsx-a11y --save-dev

W konfiguracji .eslintrc.json dodajcie:

{

  "plugins": ["jsx-a11y"],

  "extends": ["plugin:jsx-a11y/recommended"]

}

To proste narzędzie zapobiegnie takim błędom jak <img> bez alt czy <div> z funkcją kliknięcia, który nie ma przypisanej roli clavierowej.

2. Testy E2E z Playwright lub Cypress

Tutaj zaczyna się prawdziwa magia. Zamiast ręcznie klikać, możemy wstrzyknąć axe-core do naszych testów integracyjnych.

Przykład dla Playwright z użyciem @axe-core/playwright:

const { test, expect } = require('@playwright/test');

const AxeBuilder = require('@axe-core/playwright').default;



test('Strona główna powinna być dostępna', async ({ page }) => {

  await page.goto('https://twoja-aplikacja.pl');



  const accessibilityScanResults = await new AxeBuilder({ page }).analyze();



  // Jeśli znajdzie jakiekolwiek błędy, test kończy się niepowodzeniem

  expect(accessibilityScanResults.violations).toEqual([]);

});

W ten sposób każdy Pull Request, który wprowadza krytyczny błąd dostępności, po prostu nie przejdzie przez CI/CD.

Integracja z CI/CD: Budowanie "strażnika" dostępności

Aby automatyzacja miała sens, musi być częścią pipeline'u. Jeśli używacie GitHub Actions, możecie dodać krok, który uruchamia testy a11y przy każdym pushu.

Oto przykład prostego workflow w GitHub Actions:

name: Accessibility Check

on: [push, pull_request]



jobs:

  a11y-test:

    runs-on: ubuntu-latest

    steps:

      - uses: actions/checkout@v3

      - name: Install dependencies

        run: npm install

      - name: Run Playwright Tests

        run: npx playwright test tests/a11y.spec.js

Dla małych zespołów to jedyny sposób, by utrzymać standardy bez konieczności dedykowanego "Accessibility Lead".

Gdzie automatyzacja zawodzi? (i jak to załatać)

Jako praktyk muszę być z Wami szczery: automatyzacja to tylko połowa sukcesu. Narzędzia nie powiedzą Wam, że:

• Kolejność tabulacji jest nielogiczna.


• Teksty alternatywne są bezużyteczne (np. alt="obrazek123.jpg" przejdzie test, ale jest bezwartościowe dla użytkownika).


• Kontrast jest poprawny, ale czcionka jest zbyt mała dla osób słabowidzących.

Dlatego rekomenduję strategię 80/20:

• 80% błędów wyłapujecie automatycznie w CI/CD (tanie i szybkie).


• 20% (krytyczne ścieżki użytkownika) sprawdzacie ręcznie raz w miesiącu.

Strategia dla SME: Priorytetyzacja budżetu

W małej firmie nie możecie naprawić wszystkiego naraz. Jeśli macie dług techniczny, nie próbujcie "wyzerować" wszystkich błędów w jednym sprincie. To zabije Wasz velocity i doprowadzi do frustracji zespołu.

Zastosujcie hierarchię ważności:

1. 
   Krytyczne ścieżki (Happy Path): Rejestracja, koszyk, płatność, kontakt. Te strony muszą być w 100% zgodne z WCAG.


2. 
   Nawigacja główna: Menu i stopka.


3. 
   Treści statyczne: Blogi, strony "O nas".

Jeśli budżet jest naprawdę napięty, skupcie się na tzw. "low hanging fruits" – rzeczach, które są łatwe do naprawienia, a mają ogromny wpływ na dostępność (np. poprawne nagłówki <h1>-<h6> zamiast stylizowanych <div>).

Ryzyko prawne i finansowe – lekcja z UODO

Choć EAA to nowość, spójrzcie na decyzje UODO w zakresie RODO. Często kary nie wynikały z samego faktu wycieku danych, ale z braku wykazania należytej staranności.

W kontekście EAA, posiadanie wdrożonego pipeline'u z testami axe-core, dokumentacji z wyników tych testów oraz historii naprawianych błędów jest Waszą polisą ubezpieczeniową. Jeśli w razie kontroli pokażecie, że macie zautomatyzowany proces monitorowania dostępności, jesteście w znacznie lepszej pozycji niż firma, która "myślała, że jest OK". To dowód na wdrożenie procedur compliance, co w oczach regulatora drastycznie zmienia postać rzeczy.

Szybsza droga do zgodności

Wiem, że powyższe kroki wymagają czasu deweloperów. Jeśli nie macie mocy przerobowej, by pisać własne testy w Playwright, lub chcecie szybko sprawdzić, w którym miejscu jesteście przed wdrożeniem automatyzacji, warto skorzystać z gotowych skanerów.

Zamiast ręcznie konfigurować środowisko, polecam narzędzie inspect-my-site.com. Pozwala ono szybko zmapować błędy dostępności na stronie i przekuć je w listę zadań (backlog) dla deweloperów. To najszybszy sposób, by przejść od "nie wiemy, co jest nie tak" do "mamy listę 15 poprawek do wdrożenia w tym sprincie".

Podsumowanie i kluczowe wnioski

Kluczowe wnioski:

• 
  Zacznijcie od linterów (jsx-a11y) – to darmowe i natychmiastowe.


• 
  Wdróżcie axe-core w CI/CD, aby blokować nowe błędy.


• 
  Skupcie się na krytycznych ścieżkach (konwersja i płatności).


• 
  Dokumentujcie proces – historia testów w CI/CD to Wasz dowód zgodności przed organami nadzorczymi.

Czerwiec 2025 wydaje się odległy, ale w świecie developmentu to mgnienie oka. Automatyzacja to jedyny sposób, by nie obudzić się w maju z paniką i tysiącem błędów do naprawy.

A jak u Was wygląda podejście do dostępności? Czy macie już jakieś testy w pipeline, czy polegacie na "intuicji" i okazjonalnych testach ręcznych? Zapraszam do dyskusji w komentarzach – chętnie pomogę z konfiguracją linterów lub testów!

O autorze:

Piotr Wiśniewski to full-stack developer i konsultant compliance z Warszawy. Specjalizuje się w tłumaczeniu skomplikowanych regulacji cyfrowych (RODO, EAA) na język kodu, pomagając małym zespołom deweloperskim budować bezpieczne i dostępne produkty bez przepalania budżetu.

javascript #webdev #accessibility #compliance