Přístupnost v CI/CD: co kontrolovat při každém releasu a co musí ověřit člověk
Kontroly přístupnosti v CI/CD, tedy v procesu průběžné integrace a doručování změn, mohou upozornit na část nových bariér ještě před releasem. Samotný zelený běh nástroje však nepotvrzuje shodu s WCAG ani použitelnost webu pro lidi se zdravotním postižením. Užitečné nastavení proto spojuje rychlou strojovou kontrolu, důsledné vyhodnocení nálezů a plán ručního ověřování.
Proč sken jedné stránky nestačí
Nástroje jako axe-core nebo IBM Equal Access Accessibility Checker vyhodnocují pravidla, která lze spolehlivě zkontrolovat z kódu a vykresleného rozhraní. Mohou odhalit například chybějící název ovládacího prvku, neplatné použití vybraných atributů ARIA nebo některé problémy s kontrastem.
Nedokážou však posoudit celý význam obsahu, srozumitelnost postupu ani to, zda uživatel se čtečkou obrazovky pohodlně dokončí úlohu. W3C proto výslovně upozorňuje, že automatický nástroj nedokáže sám určit přístupnost ani shodu. Zelená pipeline znamená pouze to, že v testovaném stavu nebyla nalezena zvolená strojově rozpoznatelná porušení.
Další omezení představují dynamické stavy. Zavřená nabídka, modální okno, chyby po odeslání formuláře nebo další krok objednávkového procesu v úvodním HTML ještě nejsou. Kontrolu je třeba spustit až po interakci, kdy je příslušný stav skutečně zobrazen. I proto samotný skener přístupnosti nestačí.
Rozdělte kontroly podle rychlosti a rizika
Přístupnost nemusí být jedna velká úloha na konci pipeline. Praktické rozdělení může vypadat takto:
- Při změně komponenty spusťte rychlá pravidla nad jejími reprezentativními stavy. Vývojář dostane zpětnou vazbu u tlačítka, formuláře nebo dialogu, který právě upravil.
- Při integračním nebo prohlížečovém testu otevřete důležité stavy aplikace a v každém z nich spusťte zvolený nástroj. Patří sem prázdný i vyplněný formulář, validační chyba, otevřené modální okno a stav po přihlášení.
- Před releasem nebo podle plánu projděte širší vzorek klíčových cest. Tuto vrstvu lze sladit s tím, co už tým spouští v CI/CD, aby nevznikla druhá nesouvisející pipeline.
Každý běh musí znát přesnou URL, stav, rozsah DOM, verzi pravidel a očekávaný výsledek. Jinak nelze rozlišit novou bariéru od změny konfigurace nástroje.
Baseline nesmí být odpadkový koš
Pokud už web má známé nálezy, okamžité blokování všech výsledků by mohlo zastavit každý release bez ohledu na aktuální změnu. Dočasná baseline, tedy zaznamenaný výchozí stav, umožní zvýraznit nové nálezy. Nemá však znamenat trvalé ignorování starých.
Každá výjimka má mít identifikátor, důvod, vlastníka a termín dalšího posouzení. Při změně nástroje nebo verze pravidel nejprve porovnejte výsledky kontrolovaným během; nový nebo přesnější nález není automaticky chyba pipeline. Potlačení podle širokého selektoru je rizikové, protože může skrýt i budoucí problémy ve stejné části stránky.
Určete, co blokuje release
Potvrzený, reprodukovatelný nový nález v domluveném rozsahu má blokovat release, zejména pokud zasahuje kritickou cestu. Samotný název závažnosti z nástroje nestačí. Tým má vědět, které pravidlo selhalo, na kterém prvku, po jaké interakci a zda výsledek nevznikl kvůli chybějícím datům nebo nedokončenému načítání.
Výsledky označené k ručnímu posouzení, známé položky baseline nebo nestabilní technické selhání patří nejprve k prvotnímu vyhodnocení. „Informační“ však neznamená „bez vlastníka“: výsledek potřebuje rozhodnutí a záznam, ne tiché přeskočení.
Co musí doplnit člověk
Ruční ověření se soustředí na to, co stroj neumí spolehlivě rozhodnout: logické pořadí a smysl obsahu, kvalitu alternativních textů, ovládání klávesnicí, přesuny zaměření, oznamování chyb čtečce obrazovky a dokončení celé úlohy. Praktický první filtr nabízí testování webu klávesnicí.
Frekvence závisí na riziku a změnách. Nový checkout potřebuje lidskou kontrolu před releasem; stabilní informační stránka může mít jiný režim. CI/CD snižuje riziko opětovného zavedení některých bariér, ale nenahrazuje audit, uživatelské testování ani individuální právní posouzení. Je to průběžná vrstva mezi hlubšími kontrolami, ne důkaz úplné shody. Proto má smysl spojit ji s plánem, který vysvětluje, proč jednorázový audit nestačí.
Co tím získáte
Vývojář dostane konkrétní nález blíže ke změně, která jej způsobila. Tým dokáže odlišit novou regresi od technického šumu a kritické cesty nečekají na další velký audit. Specialisté se mohou věnovat chování a významu, které automat neumí posoudit.
Další krok
Vyberte jednu kritickou cestu a sepište její viditelné i dynamické stavy. U každého určete automatickou kontrolu, očekávaný výsledek a body určené k ručnímu posouzení. Takto ohraničený pilot nejprve ověřte v jedné části pipeline, aniž byste jej vydávali za úplný audit WCAG.