Juurdepääsetavus, mida kontrollitakse vaid kord aastas ühekordse käsitsi ülevaatuse käigus, väheneb peaaegu alati kiiresti – iga väike koodivärskendus võib juba parandatud asja rikkuda. Lahendus: integreerige juurdepääsetavuse testimine arendusprotsessi endasse (CI/CD) automatiseeritud sammuna, nii et probleemid tekivad enne tootmisse jõudmist. See artikkel selgitab, kuidas.
Lühidalt – mida see artikkel hõlmab
Miks ühekordsest kontrollist ei piisa?
Arendusmeeskond, kes saadab värskendusi iga nädal või mõnikord iga päev, ei saa pideva vastavuse säilitamiseks toetuda iga-aastasele juurdepääsetavuse auditile. Uus komponent, mis on lisatud ilma juurdepääsetavust silmas pidades, või CSS-i muudatus, mis kogemata vähendab kontrasti, võib rikkuda juba parandatud juurdepääsetavuse – ja keegi ei märka seda enne, kui kasutaja või kaebus seda paljastab. Sama põhimõte kehtib ka dokumentide kohta – vaadake meie juhendittavaliste vigade kaardistamine.
Mida suudavad CI/CD konveieri automatiseeritud tööriistad kinni püüda
Tööriistad, nagu axe-core, Pa11y või Lighthouse CI, võivad käitada automaatselt iga tõmbetaotluse korral või enne iga juurutamist – mõne sekundi jooksul kontrollivad nad selliseid asju nagu: värvide kontrastsus, valed või dubleeritud ARIA sildid, puuduv alternatiivtekst, puuduvad vormisildid ja vale pealkirjade järjestus. Kui kontroll ebaõnnestub, blokeeritakse tõmbetaotluse ühendamine automaatselt – täpselt nagu tavaline koodiülevaade või ebaõnnestunud üksuse test.
💡 Praktiline nõuanne
Alustage mõneks nädalaks "hoiatusrežiimis" (mitteblokeerides), et näha, kui palju probleeme koodibaasis juba on, ja alles pärast esialgset puhastamist muutke kontroll juurutamise blokeerijaks – nii ei jää meeskond esimesel päeval sadade vigadega "kinni".
Kui käsitsi testimine on endiselt vajalik
Täpselt nagu dokumentide testimise puhul, tabavad CI/CD-konveieri automatiseeritud tööriistad selgeid struktuurseid probleeme, kuid nad ei suuda hinnata tegelikku kasutajakogemust: kas klaviatuuril navigeerimine on mõttekas, kas ekraanilugeja "räägib lehel ühtset lugu" või kas kohandatud komponent (nt karussell või modaal) on reaalselt kasutatav või reaalselt kasutatav. Sellepärast tasub käimasolevad automatiseeritud kontrollid siduda perioodilise manuaalse auditiga – näiteks kord kvartalis.
Kuidas seda praktikas rakendada
- Valige testimistööriist, mis sobib teie tehnoloogiavirnaga (enamiku JavaScripti projektide jaoks axe-core, brauseripõhiste projektide jaoks Lighthouse CI).
- Käitage seda CI-konveieri etapina – tavaliselt GitHubi toiminguna, GitLabi CI-tööna või samaväärse sammuna mis tahes kasutatavas CI/CD-tööriistas.
- Enne kontrolli blokeerijaks saamist määrake selge tõrkelävi (näiteks: "kriitiliste" taseme probleemideta kirvesüdamiku kohta).
- Katke ka oma PDF-failid: kui teie organisatsioon genereerib dokumente automaatselt (arveid, aruandeid), kaaluge avaldamisprotsessi osana ka nende jaoks automaatse skannimise lisamist.
Kas soovite lisada oma protsessile ka automatiseeritud PDF-testi?
Meie tööriist skannib PDF-faile ja annab igale dokumendile juurdepääsetavuse skoori – saate seda perioodilise kontrollina käitada koos CI/CD protsessiga.
Skannige oma saiti tasuta ←Pärast skannimist saate leitud dokumendid teha otse ja tasuta juurdepääsetavaks kaAccessiDoc.