Dostopnost, ki se preveri le enkrat letno, z enkratnim ročnim pregledom, skoraj vedno hitro izgine – vsaka majhna posodobitev kode lahko pokvari nekaj, kar je bilo že popravljeno. Rešitev: vgradite testiranje dostopnosti v sam razvojni proces (CI/CD) kot avtomatiziran korak, tako da se težave ujamejo, preden dosežejo proizvodnjo. Ta članek pojasnjuje, kako.

Na kratko – kaj zajema ta članek

  1. Zakaj enkratni ček ni dovolj
  2. Katera avtomatizirana orodja v cevovodu CI/CD lahko ujamejo
  3. Kjer je še vedno potrebno ročno testiranje
  4. Kako to izvesti v praksi

Zakaj enkratni ček ni dovolj

Razvojna skupina, ki pošilja posodobitve vsak teden ali včasih vsak dan, se ne more zanesti na letno revizijo dostopnosti, da bi ohranila stalno skladnost. Nova komponenta, dodana brez upoštevanja dostopnosti, ali sprememba CSS, ki pomotoma zmanjša kontrast, lahko prekine dostopnost, ki je bila že popravljena - in nihče tega ne opazi, dokler tega ne razkrije uporabnik ali pritožba. Enako načelo velja tudi za dokumente - glejte naš vodnikpreslikava pogostih napak.

Katera avtomatizirana orodja v cevovodu CI/CD lahko ujamejo

Orodja, kot so axe-core, Pa11y ali Lighthouse CI, se lahko samodejno zaženejo ob vsaki zahtevi za vleko ali pred vsako uvedbo – v nekaj sekundah preverijo stvari, kot so: barvni kontrast, nepravilne ali podvojene oznake ARIA, manjkajoče nadomestno besedilo, manjkajoče oznake obrazcev in napačen vrstni red naslovov. Če preverjanje ne uspe, je zahteva za vlečenje samodejno blokirana za združevanje - tako kot običajen pregled kode ali neuspešen test enote.

💡 Praktičen nasvet

Začnite v "opozorilnem načinu" (brez blokiranja) za nekaj tednov, da vidite, koliko težav že obstaja v zbirki kode, in šele po začetnem čiščenju spremenite preverjanje v blokator uvedbe - tako se ekipa ne "zatakne" pred stotinami napak prvi dan.

Kjer je še vedno potrebno ročno testiranje

Tako kot pri testiranju dokumentov avtomatizirana orodja v cevovodu CI/CD zajamejo jasne strukturne težave, vendar ne morejo oceniti dejanske uporabniške izkušnje: ali je navigacija s tipkovnico smiselna, ali bralnik zaslona "pripoveduje skladno zgodbo" na strani ali ali je komponenta po meri (kot je vrtiljak ali modal) resnično uporabna v resničnem svetu. Zato je vredno združiti tekoče avtomatizirane preglede z rednimi ročnimi pregledi – na primer četrtletno.

Kako to izvesti v praksi

  1. Izberite orodje za testiranje, ki ustreza vašemu tehnološkemu naboru (jedro axe za večino projektov JavaScript, Lighthouse CI za projekte, ki temeljijo na brskalniku).
  2. Zaženite ga kot korak v cevovodu CI – običajno kot dejanje GitHub, opravilo CI GitLab ali enakovreden korak v katerem koli orodju CI/CD, ki ga uporabljate.
  3. Nastavite jasen prag neuspeha (na primer: brez "kritičnih" težav na ravni axe-core), preden preverjanje postane blokator.
  4. Pokrijte tudi svoje datoteke PDF: če vaša organizacija samodejno ustvarja dokumente (račune, poročila), razmislite o dodajanju avtomatiziranega skeniranja tudi zanje kot del postopka objave.

Želite svojemu procesu dodati tudi samodejno testiranje PDF?

Naše orodje skenira datoteke PDF in vsakemu dokumentu dodeli oceno dostopnosti – zaženete ga lahko kot redno preverjanje skupaj s postopkom CI/CD.

Brezplačno preglejte svoje spletno mesto ←

Po skeniranju lahko omogočite dostop do najdenih dokumentov neposredno in brezplačno prekAccessiDoc.