Dostępność (a11y) w pipeline'ie CI/CD: Jak nie przeoczyć EAA i nie zbankrutować na poprawkach

Meta: Dowiedz się, jak zautomatyzować testy a11y w Git workflow, aby spełnić wymogi EAA i uniknąć kar, bez spowalniania pracy zespołu deweloperskiego.

Wielu właścicieli sklepów e-commerce i lead developerów w Polsce traktuje dostępność (a11y) jako "dodatek" lub "projekt na przyszły rok". Jeśli tak myślicie, to mam dla Was kubeł zimnej wody: European Accessibility Act (EAA) wchodzi w życie w czerwcu 2025 roku. To nie jest kolejna "dobrowolna rekomendacja". To twarde prawo UE, które zostanie zaimplementowane w polskim ustawodawstwie.

Jako konsultant compliance, często widzę ten sam schemat: firma buduje świetny produkt, a potem, na miesiąc przed deadline'em regulacyjnym, wynajmuje zewnętrzną agencję, która znajduje 200 błędów krytycznych. Efekt? Panika, nadgodziny, budżet przepalony w dwa tygodnie i kod, który wygląda jak łata na łacie.

Moje podejście jest inne: pragmatyzm. Nie oczekuję od zespołu 5-10 osób, że każdy stanie się ekspertem od WCAG 2.1 na poziomie AAA. Oczekuję jednak, że nie wypuścicie na produkcję formularza, którego nie da się obsłużyć klawiaturą. To kosztuje 0 zł w narzędziach open-source i kilka godzin konfiguracji, a oszczędza dziesiątki tysięcy złotych w potencjalnych karach i kosztach refaktoryzacji.

Czym jest EAA i dlaczego to teraz Wasz problem?

European Accessibility Act (EAA) to dyrektywa, która ma sprawić, że produkty i usługi (w tym e-commerce) będą dostępne dla osób z niepełnosprawnościami. W praktyce oznacza to, że Wasz sklep, aplikacja webowa czy panel klienta muszą być zgodne z normą EN 301 549, która w dużej mierze opiera się na WCAG 2.1.

Jeśli sprzedajecie towary lub usługi online, brak zgodności po czerwcu 2025 roku to nie tylko ryzyko wizerunkowe. To ryzyko prawne. Choć UODO zajmuje się głównie RODO, mechanizmy kontroli zgodności z EAA będą podobnie rygorystyczne. Kara za niedopełnienie obowiązków dostępności może być dotkliwa, a co gorsza – możecie zostać zmuszeni do wycofania produktu z rynku do czasu naprawy błędów.

W świecie e-commerce "dostępność" to nie tylko altruizm. To ROI. Jeśli osoba niewidoma nie może przejść przez proces checkoutu, tracicie klienta. Jeśli starszy użytkownik nie może odczytać kontrastu przycisku "Kup teraz", tracicie konwersję.

Dlaczego manualne testy to pułapka?

Większość polskich software house'ów stosuje model "testowania na koniec". Deweloper koduje, QA sprawdza, a raz na kwartał przychodzi audytor z raportem PDF na 50 stron. To jest najdroższy możliwy sposób zarządzania jakością.

Błąd znaleziony w fazie projektowania kosztuje 1x. Błąd znaleziony podczas testów QA kosztuje 10x. Błąd znaleziony przez audytora po wdrożeniu na produkcję kosztuje 100x, bo wymaga zmiany architektury, ponownego testowania i ryzyka regresji.

Rozwiązaniem jest Shift-Left. Przesunięcie testów dostępności na samym początek procesu – do Waszego Git workflow.

Automatyzacja a11y: Co można, a czego nie można zautomatyzować?

Zanim przejdziemy do kodu, ustalmy jedną rzecz: automatyzacja nie zastąpi człowieka.

Według statystyk, automatyczne skanery wyłapują od 30% do 50% problemów z dostępnością. Nie sprawdzą, czy opis alternatywny (alt text) obrazka jest sensowny (czy opisuje produkt, czy jest tylko ciągiem znaków "foto123.jpg"), ani czy kolejność tabulacji jest logiczna dla użytkownika.

Jednak te 40%, które można zautomatyzować, to zazwyczaj najczęstsze i najbardziej rażące błędy:

• Brak etykiet w polach formularzy (<label>).
• Zbyt niski kontrast tekstu.
• Brak atrybutów aria-label w elementach interaktywnych.
• Brak odpowiedniej hierarchii nagłówków (<h1> -> <h2> -> <h3>).

Jeśli zautomatyzujecie te podstawy w swoim pipeline'ie, audytor nie będzie miał się do czego przyczepić w 80% przypadków.

Implementacja: Integracja axe-core w Git workflow

Najbardziej sprawdzonym standardem w branży jest axe-core od Deque Systems. Jest darmowy, precyzyjny i ma minimalną liczbę wyników fałszywie pozytywnych (co jest kluczowe, żeby deweloperzy nie zaczęli ignorować alertów).

Oto jak wdrożyć testy dostępności w trzech krokach.

Krok 1: Testy w środowisku lokalnym (Linting)

Zanim kod trafi do Git, powinien zostać sprawdzony w IDE. Jeśli używacie Reacta, Vue lub zwykłego HTML, zainstalujcie eslint-plugin-jsx-a11y.

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

Dodajcie go do swojego .eslintrc.json:

{
  "plugins": ["jsx-a11y"],
  "extends": ["plugin:jsx-a11y/recommended"]
}

Teraz każdy deweloper w zespole dostanie czerwony podkreślnik w VS Code, jeśli zapomni o alt w obrazku. To jest ten moment, w którym oszczędzacie pierwsze 15 minut pracy QA i 1 godzinę pracy dewelopera w przyszłości.

Krok 2: Testy E2E w Cypress lub Playwright

Sama analiza statyczna to za mało. Musimy sprawdzić, jak strona zachowuje się po wyrenderowaniu. Jeśli używacie Cypressa, integracja z cypress-axe jest banalnie prosta.

npm install cypress-axe

W pliku cypress/support/e2e.js dodajcie:

import 'cypress-axe';

A w swoim teście:

describe('Checkout Page Accessibility', () => {
  it('should have no detectable a11y violations on checkout page', () => {
    cy.visit('/checkout');
    cy.injectAxe();
    cy.checkA11y();
  });
});

To proste cy.checkA11y() przeskanuje całą stronę i wyrzuci błąd w pipeline'ie, jeśli znajdzie naruszenia WCAG. Jeśli budujecie sklep na Shopify lub PrestaShop, możecie w ten sposób pilnować, aby customowe modyfikacje szablonu nie zepsuły dostępności.

Krok 3: Integracja z GitHub Actions / GitLab CI

To jest moment, w którym compliance staje się "wymuszalne". Konfigurujemy pipeline tak, aby Pull Request nie mógł zostać zmergowany, jeśli testy a11y nie przejdą pomyślnie.

Przykład prostego workflow dla GitHub Actions:

name: Accessibility Check
on: [pull_request]

jobs:
  a11y:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Install dependencies
        run: npm install
      - name: Run Cypress tests
        run: npm run cy:run # uruchamia testy z cy.checkA11y()

Dzięki temu proces jest transparentny. Jeśli test nie przechodzi, PR jest blokowany. To wymusza dyscyplinę bez konieczności ciągłego przypominania przez Project Managera.

Koszt vs. Zysk: Podejście pragmatyczne

Wiem, co myślicie: "Nie mamy czasu na pisanie testów dla każdego widoku". Słusznie. W małym zespole nie możecie pokryć 100% aplikacji. Zastosujcie zasadę Pareto (80/20).

Skoncentrujcie się na krytycznych ścieżkach konwersji:

1. Strona główna (Pierwsze wrażenie i nawigacja).
2. Karta produktu (Dostęp do informacji o produkcie).
3. Koszyk i Checkout (To tutaj błędy a11y bezpośrednio przekładają się na utratę pieniędzy).
4. Formularz kontaktowy i reklamacyjny (Wymogi prawne dotyczące kontaktu z konsumentem).

Jeśli zautomatyzujecie testy dla tych czterech obszarów, jesteście w bezpieczniejszym miejscu niż 90% polskich e-commerce'ów.

Pułapka "Perfekcyjnego Compliance"

Jako konsultant często spotykam się z lękiem przed "nieidealną" zgodnością. "Piotrze, a co jeśli audytor znajdzie jeden błąd w stopce?".

Odpowiadam: Dążcie do "wystarczająco dobrego", a nie do perfekcji.

W prawie UE (i w podejściu UODO przy RODO) liczy się wykazanie "należytej staranności". Jeśli macie wdrożony automatyczny pipeline, regularne raporty z testów i udokumentowany proces naprawy błędów, jesteście w znacznie lepszej sytuacji niż firma, która twierdzi, że "wszystko jest ok", a nie ma ani jednego testu.

W razie kontroli, pokazanie logów z GitHub Actions, które udowadniają, że każdy commit jest sprawdzany pod kątem WCAG, jest potężnym argumentem łagodzącym. To dowód na to, że dostępność jest częścią Waszego cyklu życia oprogramowania (SDLC), a nie przypadkowym zdarzeniem.

Jak sprawdzić stan obecny w 5 minut?

Zanim zaczniecie przebudowywać cały workflow, musicie wiedzieć, gdzie jesteście. Nie zaczynajcie od pisania testów, tylko od szybkiego skanu.

Zamiast ręcznie przeczesywać każdą stronę, polecam narzędzia, które dają natychmiastowy wgląd w luki bezpieczeństwa i dostępności. Moim rekomendowanym rozwiązaniem jest Tessera, a konkretnie ich narzędzie do głębokiego skanowania stron.

Dla przykładu, w jednym z moich ostatnich projektów dla średniej wielkości skleka z odzieżą, szybki skan wykazał, że 12 kluczowych przycisków w procesie płatności nie miało etykiet dla czytników ekranu. Deweloperzy o tym nie wiedzieli, bo "wizualnie wszystko działało". Naprawa zajęła jedną osobę 30 minut, a zapobiegła potencjalnym skargom i ryzyku kar z EAA.

Możecie zrobić to samo. Wejdźcie na https://inspect-my-site.com, wrzućcie adres swojego sklepu i zobaczcie, co wypada poprawić w pierwszej kolejności. To najszybszy sposób, aby przestać zgadywać i zacząć naprawiać to, co faktycznie generuje ryzyko.

Podsumowanie i plan działania dla Twojego zespołu

Jeśli chcesz, aby Twój produkt był zgodny z EAA i bezpieczny, nie czekaj do 2025 roku. Oto Twoja lista zadań na najbliższy sprint:

1. Zainstaluj eslint-plugin-jsx-a11y – zablokuj najprostsze błędy już w edytorze.
2. Wprowadź cypress-axe lub playwright-axe – dodaj testy a11y do procesu checkoutu.
3. Zautomatyzuj to w CI/CD – spraw, by testy uruchamiały się przy każdym PR.
4. Zrób szybki audyt zewnętrzny – użyj inspect-my-site.com, aby znaleźć "low-hanging fruits", które możecie naprawić w jeden wieczór.

Dostępność to nie tylko kwestia prawa – to kwestia jakości kodu. Czysty, dostępny HTML jest zazwyczaj lepszym, szybszym i bardziej stabilnym HTML-em. To inwestycja, która zwraca się w postaci lepszego SEO i wyższej konwersji.

A jak to wygląda u Was? Czy w Waszych pipeline'ach są już testy dostępności, czy wciąż polegacie na manualnych sprawdzeniach "na oko"? Zapraszam do dyskusji w komentarzach!

---

O autorze:
Piotr Wiśniewski – Full-stack developer i konsultant ds. compliance z siedzibą w Warszawie. Specjalizuje się w wdrażaniu RODO i EAA w polskich e-commerce, pomagając startupom i MŚP łączyć wymogi prawne z pragmatyką biznesową. Były specjalista w centrum operacyjnym eBay w Warszawie.