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:
- Nieskalowalne – nie sprawdzisz każdego stanu aplikacji w każdym przeglądarce.
- 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".
- 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:
- Krytyczne ścieżki (Happy Path): Rejestracja, koszyk, płatność, kontakt. Te strony muszą być w 100% zgodne z WCAG.
- Nawigacja główna: Menu i stopka.
- 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
| Element | Podejście tradycyjne (ryzykowne) | Podejście nowoczesne (bezpieczne) |
|---|---|---|
| Testowanie | Ręczny audyt raz w roku | Automatyzacja w CI/CD + cykliczne testy ręczne |
| Koszt | Wysoki koszt naprawy na koniec | Rozłożony koszt w procesie developmentu |
| Ryzyko | Wysoka szansa na kary EAA/UODO | Dowód należytej staranności w dokumentacji |
| Wdrożenie | "Zrobimy to przed czerwcem 2025" | Lintery $\rightarrow$ Testy E2E $\rightarrow$ Monitoring |
Kluczowe wnioski:
-
Zacznijcie od linterów (
jsx-a11y) – to darmowe i natychmiastowe. -
Wdróżcie
axe-corew 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.
Top comments (0)