Dostupnosť, ktorá sa kontroluje iba raz za rok pri jednorazovej manuálnej kontrole, sa takmer vždy rýchlo naruší – každá malá aktualizácia kódu môže pokaziť niečo, čo už bolo opravené. Riešenie: zabudujte testovanie prístupnosti do samotného vývojového procesu (CI/CD) ako automatizovaný krok, aby sa problémy zachytili skôr, ako sa dostanú do výroby. Tento článok vysvetľuje ako.
Stručne povedané – o čom je tento článok
Prečo jednorazová kontrola nestačí
Vývojový tím, ktorý dodáva aktualizácie každý týždeň alebo niekedy aj každý deň, sa nemôže spoliehať na každoročný audit prístupnosti, aby udržal priebežné dodržiavanie predpisov. Nový komponent pridaný bez ohľadu na dostupnosť alebo zmena CSS, ktorá náhodne zníži kontrast, môže narušiť dostupnosť, ktorá už bola opravená – a nikto si to nevšimne, kým to neodhalí používateľ alebo sťažnosť. Rovnaký princíp platí aj pre dokumenty – pozrite si našu príručkumapovanie bežných chýb.
Čo dokážu zachytiť automatizované nástroje v potrubí CI/CD
Nástroje ako axe-core, Pa11y alebo Lighthouse CI sa môžu automaticky spustiť pri každej požiadavke na stiahnutie alebo pred každým nasadením – v priebehu niekoľkých sekúnd skontrolujú napríklad: farebný kontrast, nesprávne alebo duplicitné značky ARIA, chýbajúci alternatívny text, chýbajúce menovky formulárov a nesprávne poradie nadpisov. Ak kontrola zlyhá, žiadosť o stiahnutie sa automaticky zablokuje pred zlúčením – rovnako ako pri bežnej kontrole kódu alebo pri neúspešnom teste jednotky.
💡 Praktický tip
Začnite na niekoľko týždňov vo „režime varovania“ (neblokuje sa), aby ste videli, koľko problémov už existuje v kódovej základni, a až po počiatočnom vyčistení premeňte kontrolu na blokovanie nasadenia – tak tím nezostane „zaseknutý“ pred stovkami chýb v prvý deň.
Tam, kde je stále potrebné manuálne testovanie
Rovnako ako pri testovaní dokumentov, automatizované nástroje v reťazci CI/CD zachytávajú jasné štrukturálne problémy, ale nedokážu posúdiť skutočnú používateľskú skúsenosť: či má zmysel navigácia pomocou klávesnice, či čítačka obrazovky „rozpráva súvislý príbeh“ na stránke, alebo či je vlastný komponent (ako karusel alebo modal) skutočne použiteľný v reálnom svete. Preto sa oplatí spojiť prebiehajúce automatizované kontroly s pravidelným manuálnym auditom – napríklad štvrťročným.
Ako to implementovať v praxi
- Vyberte si testovací nástroj, ktorý vyhovuje vášmu technologickému balíku (axe-core pre väčšinu projektov JavaScript, Lighthouse CI pre projekty založené na prehliadači).
- Spustite to ako krok vo svojom CI kanáli – zvyčajne ako akciu GitHub, úlohu GitLab CI alebo ekvivalentný krok v akomkoľvek nástroji CI/CD, ktorý používate.
- Nastavte jasnú prahovú hodnotu zlyhania (napríklad: žiadne „kritické“ problémy na úrovni jadra sekery) predtým, ako sa kontrola stane blokujúcou.
- Zakryte aj svoje súbory PDF: ak vaša organizácia generuje dokumenty automaticky (faktúry, správy), zvážte pridanie automatického skenovania aj pre tieto dokumenty ako súčasť procesu publikovania.
Chcete do svojho procesu pridať aj automatické testovanie PDF?
Náš nástroj skenuje súbory PDF a priraďuje každému dokumentu skóre prístupnosti – môžete ho spustiť ako pravidelnú kontrolu spolu s procesom CI/CD.
Naskenujte svoju stránku zadarmo ←Po naskenovaní môžete nájdené dokumenty sprístupniť priamo a bezplatne cezAccessiDoc.