Prieinamumas, kuris tikrinamas tik kartą per metus, atliekant vienkartinę rankinę peržiūrą, beveik visada greitai pablogėja – bet koks nedidelis kodo atnaujinimas gali sugadinti tai, kas jau buvo pataisyta. Sprendimas: pritaikymo neįgaliesiems testavimą įtraukite į patį kūrimo procesą (CI/CD) kaip automatizuotą veiksmą, todėl problemos užfiksuojamos dar nepasiekus gamybos. Šiame straipsnyje paaiškinama, kaip.
Trumpai tariant – apie ką šis straipsnis skirtas
Kodėl vienkartinio patikrinimo neužtenka
Kūrimo komanda, kuri siunčia atnaujinimus kiekvieną savaitę, o kartais ir kasdien, negali pasikliauti metiniu prieinamumo auditu, kad išlaikytų nuolatinį atitiktį. Naujas komponentas, pridėtas negalvojant apie pritaikymą neįgaliesiems, arba CSS pakeitimas, kuris netyčia sumažina kontrastą, gali pažeisti jau ištaisytą pasiekiamumą – ir niekas to nepastebės, kol vartotojas ar skundas to neatskleidžia. Tas pats principas taikomas ir dokumentams – žr. mūsų vadovądažniausių klaidų atvaizdavimas.
Ką gali sugauti automatiniai įrankiai CI/CD konvejeryje
Įrankiai, tokie kaip axe-core, Pa11y arba Lighthouse CI, gali veikti automatiškai gavus kiekvieną ištraukimo užklausą arba prieš kiekvieną diegimą – per kelias sekundes jie patikrina tokius dalykus kaip: spalvų kontrastas, neteisingos arba pasikartojančios ARIA žymos, trūksta alternatyvaus teksto, trūksta formų etikečių ir neteisinga antraščių tvarka. Jei patikrinimas nepavyksta, ištraukimo užklausa automatiškai blokuojama, kad ji nebūtų sujungta – kaip ir atliekant įprastą kodo peržiūrą ar nepavykusį įrenginio testą.
💡 Praktinis patarimas
Kelias savaites pradėkite „įspėjimo režimu“ (neblokuodami), kad pamatytumėte, kiek problemų jau yra kodų bazėje, ir tik atlikę pradinį išvalymą paverskite patikrinimą diegimo blokavimo priemone – taip komanda „neužstrigs“ susidurdama su šimtais klaidų pirmą dieną.
Kai vis dar reikia rankinio testavimo
Kaip ir tikrinant dokumentus, automatiniai įrankiai CI/CD konvejeryje užfiksuoja aiškias struktūrines problemas, tačiau jie negali įvertinti tikrosios naudotojo patirties: ar klaviatūros naršymas yra prasmingas, ar ekrano skaitytuvas „papasakoja nuoseklią istoriją“ puslapyje, ar pasirinktinis komponentas (pvz., karuselė ar modalas) yra tikrai tinkamas naudoti realiai. Štai kodėl verta susieti vykstančius automatinius patikrinimus su periodiniu rankiniu auditu, pavyzdžiui, kas ketvirtį.
Kaip tai įgyvendinti praktiškai
- Pasirinkite testavimo įrankį, atitinkantį jūsų technologijų krūvą (daugumai „JavaScript“ projektų – „Axe-core“, naršyklės projektams – „Lighthouse CI“).
- Vykdykite jį kaip CI konvejerio veiksmą – paprastai kaip „GitHub“ veiksmą, „GitLab“ CI užduotį arba lygiavertį veiksmą bet kokiame CI / CD įrankyje, kurį naudojate.
- Nustatykite aiškų nesėkmės slenkstį (pavyzdžiui: nėra „kritinių“ lygio problemų viename ašies šerdyje), kol patikrinimas tampa blokatoriumi.
- Taip pat uždenkite PDF failus: jei jūsų organizacija automatiškai generuoja dokumentus (sąskaitas faktūras, ataskaitas), apsvarstykite galimybę įtraukti ir automatinį jų nuskaitymą, kaip paskelbimo proceso dalį.
Norite į savo procesą įtraukti automatinį PDF testavimą?
Mūsų įrankis nuskaito PDF failus ir kiekvienam dokumentui suteikia prieinamumo balą – galite jį atlikti kaip periodinę patikrą kartu su CI / CD procesu.
Nuskaitykite savo svetainę nemokamai ←Po nuskaitymo taip pat galite padaryti rastus dokumentus pasiekiamus tiesiogiai ir nemokamai perAccessiDoc.