Kodėl automatinis testas nepakeičia rankinio prieinamumo audito?

Automatiniai prieinamumo įrankiai yra naudingi. Jie greiti, nuoseklūs ir gali būti paleidžiami kiekvieno leidimo metu. Problema prasideda tada, kai jų rezultatas pateikiamas kaip visas svetainės prieinamumo auditas.

Skeneris analizuoja tai, ką gali nuskaityti iš kodo ir apskaičiuoti pagal iš anksto apibrėžtas taisykles. Žmogus vertina, ar sąsaja iš tikrųjų suprantama, valdoma ir tinkama realiai užduočiai atlikti.

Ką automatiniai įrankiai randa gerai?

Priklausomai nuo įrankio ir puslapio būsenos, automatinis testas gali aptikti:

• kai kuriuos spalvų kontrasto neatitikimus;
• formos laukus be programiškai susieto pavadinimo;
• vaizdus be alternatyvaus teksto atributo;
• tuščias nuorodas ar mygtukus;
• pasikartojančius identifikatorius;
• kai kurias neteisingas ARIA reikšmes ir vaidmenų kombinacijas;
• puslapio kalbos arba dokumento pavadinimo trūkumą.

Šios išvados svarbios, ypač kai ta pati problema kartojasi bendrame šablone. Automatinis testas taip pat tinka regresijoms: pavyzdžiui, perspėti komandą, jei naujame leidime atsirado nepažymėtas formos laukas.

Ko skeneris patikimai neįvertina?

Ar fokusavimo tvarka logiška?

Įrankis gali matyti interaktyvius elementus, tačiau ne visada supranta, ar jų seka atitinka naudotojo užduotį. Pavyzdžiui, fokusas gali peršokti į puslapio apačią, nors vizualiai naudotojas ką tik atidarė meniu viršuje.

Ar dialogas veikia kaip dialogas?

Modalinis langas gali turėti tinkamą vaidmenį, bet atsidarius fokusas likti už jo. Uždarius langą fokusas gali negrįžti į jį atidariusį mygtuką. Tokios problemos dažniausiai išryškėja tik atliekant realius veiksmus klaviatūra.

Ar formos klaida suprantama?

Automatinis įrankis gali patvirtinti, kad laukas turi etiketę. Tačiau jis nepasakys, ar klaidos tekstas „Neteisinga reikšmė“ padeda žmogui suprasti, kokio formato duomenų reikia ir kaip tęsti.

Ar alternatyvus tekstas prasmingas?

Skeneris gali patikrinti, ar yra alt atributas, bet ne visuomet įvertina jo kokybę. Tekstas „image123“ techniškai egzistuoja, tačiau naudotojui nepadeda.

Ar galima užbaigti svarbiausią veiksmą?

Atskiri puslapiai gali surinkti aukštus balus, nors produkto varianto pasirinkimas, datos valdiklis arba mokėjimo langas vis tiek blokuoja pirkimą.

Kodėl aukštas balas gali klaidinti?

Daugelyje įrankių rezultatas pateikiamas skaičiumi. Toks skaičius patogus stebėti komandos viduje, tačiau jis nėra prieinamumo sertifikatas.

Vienas rimtas fokuso spąstas gali visiškai sustabdyti klaviatūros naudotoją, nors likę šimtai patikrinimų sėkmingi. Prieinamumo rizika nepriklauso tik nuo klaidų kiekio. Svarbu, kur problema atsiranda ir kokią užduotį ji blokuoja.

Kaip teisingai naudoti automatinius testus?

1. Paleiskite juos kūrimo metu. Tikrinkite ne tik viešą puslapį, bet ir komponentų būsenas, klaidas bei prisijungus matomą turinį.
2. Įtraukite į CI procesą. Automatiniai testai gali perspėti apie akivaizdžias regresijas dar prieš leidimą.
3. Grupuokite pasikartojančias klaidas. Viena bendro komponento problema neturėtų virsti šimtu atskirų užduočių.
4. Patvirtinkite išvadas rankiniu būdu. Ypač kai įrankis pateikia abejotiną ar konteksto reikalaujančią rekomendaciją.
5. Testuokite naudotojo kelius. Klaviatūra, mobili būsena ir pasirinkti ekrano skaitytuvo scenarijai turi papildyti skenavimą.

Ką turėtų apimti rankinis patikrinimas?

• Judėjimą per puslapį klaviatūra ir matomą fokusą.
• Meniu, dialogų, išskleidžiamų laukų ir kitų nestandartinių valdiklių elgesį.
• Formų instrukcijas, validaciją ir fokusą po klaidos.
• Teksto didinimą, mobilų išdėstymą ir turinio persitvarkymą.
• Antraščių, orientyrų, nuorodų ir turinio prasmę.
• Pasirinktus scenarijus su ekrano skaitytuvu.

Išvada

Automatinis testas ir rankinis auditas nėra konkuruojantys metodai. Jie sprendžia skirtingas užduotis. Automatika suteikia greitį ir pakartojamumą, o žmogaus vertinimas – kontekstą ir realios sąveikos patikrinimą.

Jei tikslas yra ne gražus balas, o veikianti svetainė, reikia abiejų.