Přístupnost, která se kontroluje pouze jednou ročně při jednorázové ruční kontrole, se téměř vždy rychle naruší – jakákoli malá aktualizace kódu může narušit něco, co již bylo opraveno. Řešení: zabudujte testování přístupnosti do samotného vývojového procesu (CI/CD) jako automatizovaný krok, takže problémy budou zachyceny dříve, než se dostanou do výroby. Tento článek vysvětluje, jak na to.
Ve zkratce – o čem tento článek pojednává
Proč jednorázová kontrola nestačí
Vývojový tým, který dodává aktualizace každý týden nebo někdy i každý den, se nemůže spolehnout na každoroční audit přístupnosti, aby zajistil průběžnou shodu. Nová komponenta přidaná bez ohledu na přístupnost nebo změna CSS, která náhodně sníží kontrast, může narušit dostupnost, která již byla opravena – a nikdo si toho nevšimne, dokud to neodhalí uživatel nebo stížnost. Stejný princip platí i pro dokumenty – viz náš průvodcemapování běžných chyb.
Co mohou automatizované nástroje v potrubí CI/CD zachytit
Nástroje jako axe-core, Pa11y nebo Lighthouse CI se mohou automaticky spustit při každém požadavku na stažení nebo před každým nasazením – během několika sekund zkontrolují například: barevný kontrast, nesprávné nebo duplicitní značky ARIA, chybějící alternativní text, chybějící štítky formulářů a nesprávné pořadí nadpisů. Pokud kontrola selže, požadavek na stažení je automaticky zablokován proti sloučení – stejně jako běžná kontrola kódu nebo neúspěšný test jednotky.
💡 Praktický tip
Začněte na několik týdnů ve „režimu varování“ (neblokování), abyste viděli, kolik problémů již v kódové základně existuje, a teprve po počátečním vyčištění přeměňte kontrolu na blokovač nasazení – tak tým nezůstane „zaseknutý“ před stovkami chyb v první den.
Tam, kde je stále potřeba ruční testování
Stejně jako u testování dokumentů zachycují automatizované nástroje v kanálu CI/CD jasné strukturální problémy, ale nedokážou posoudit skutečnou uživatelskou zkušenost: zda má smysl navigace pomocí klávesnice, zda čtečka obrazovky „vypráví na stránce souvislý příběh“ nebo zda je vlastní komponenta (jako karusel nebo modal) skutečně použitelná v reálném světě. Proto se vyplatí spojit probíhající automatizované kontroly s pravidelným manuálním auditem — například čtvrtletně.
Jak to zavést v praxi
- Vyberte si testovací nástroj, který vyhovuje vašemu technologickému balíčku (axe-core pro většinu projektů JavaScript, Lighthouse CI pro projekty založené na prohlížeči).
- Spusťte jej jako krok ve svém kanálu CI – obvykle jako akci GitHub, úlohu GitLab CI nebo ekvivalentní krok v jakémkoli nástroji CI/CD, který používáte.
- Nastavte jasný práh selhání (například: žádné "kritické" problémy na úrovni jádra osy), než se kontrola stane blokátorem.
- Zakryjte i své soubory PDF: pokud vaše organizace generuje dokumenty automaticky (faktury, sestavy), zvažte přidání automatického skenování i pro ně jako součást procesu publikování.
Chcete do svého procesu přidat také automatizované testování PDF?
Náš nástroj skenuje soubory PDF a uděluje každému dokumentu skóre přístupnosti – můžete jej spustit jako pravidelnou kontrolu spolu s procesem CI/CD.
Naskenujte svůj web zdarma ←Po naskenování můžete nalezené dokumenty také zpřístupnit přímo a zdarma prostřednictvímAccessiDoc.