Dev Tools & Workflow

Zašto automatizirano testiranje pristupačnosti propušta polovicu vaših problema

Automatizirane provjere korisne su, brze i nužne. Također su po svojoj namjeni nepotpune.

The Wux Webtools Team The Wux Webtools Team 10 min čitanja Pomoć AI, pregledano od strane ljudi
A developer comparing automated accessibility results with manual testing notes.
Sadržaj
  1. Neugodna istina o automatiziranom testiranju pristupačnosti
  2. U čemu su automatizirani testovi dobri
  3. Gdje automatizacija zakazuje
  4. Lažna utjeha visoke ocjene
  5. Kategorije koje se najčešće propuštaju
  6. 1. Ponašanje tipkovnice i fokusa
  7. 2. Smisleni nazivi i opisi
  8. 3. Rukovanje pogreškama
  9. 4. Vizualna prilagodba
  10. 5. Jasnoća sadržaja
  11. Bolji tijek testiranja
  12. Kontinuirano pokrećite automatizirane provjere
  13. Dodajte ručno testiranje tipkovnicom
  14. Testirajte s barem jednim čitačem zaslona
  15. Pregledajte sadržaj i stanja
  16. Uključite osobe s invaliditetom kada su ulozi visoki
  17. Kako odgovorno tumačiti automatizirane rezultate
  18. Praktičan standard: automatizirajte očito, ručno testirajte iskustvo

Neugodna istina o automatiziranom testiranju pristupačnosti

Automatizirano testiranje pristupačnosti jedna je od najboljih navika koje web tim može izgraditi. Otkriva nedostajuće oznake obrazaca, tekst s niskim kontrastom, nevaljan ARIA, duplicirane ID-jeve, prazne gumbe i druge nedostatke koji nikada ne bi smjeli doći do produkcije.

Također se redovito pogrešno shvaća.

Prolazno automatizirano izvješće o pristupačnosti ne znači da je stranica pristupačna. Znači da alat nije pronašao podskup problema koje zna otkriti. Taj je podskup vrijedan, ali ograničen. Mnogi problemi pristupačnosti ovise o značenju, redoslijedu, namjeri, kontekstu i ljudskoj interakciji. Softver može pregledati markup. Ne može pouzdano razumjeti funkcionira li iskustvo za osobu koja koristi čitač zaslona, tipkovnicu, povećanje, glasovno upravljanje, titlove ili kognitivnu podršku.

Zato tvrdnja da automatizirano testiranje propušta otprilike polovicu vaših problema nije cinična. Velikodušna je. Neke su kategorije problema vrlo prikladne za automatizaciju. Druge se gotovo uopće ne mogu automatizirati.

Praktičan odgovor nije napustiti automatizirane alate. Treba ih postaviti na pravo mjesto: rano, često i kao dio šireg tijeka testiranja.

U čemu su automatizirani testovi dobri

Automatizirani alati izvrsni su u pronalaženju determinističkih pogrešaka. Ako se pravilo može izraziti kao strojno čitljiv uvjet, skener ga obično može brzo i dosljedno provjeriti.

Uobičajeni primjeri uključuju:

  • Slike s nedostajućim atributima alt
  • Polja obrasca bez povezanih oznaka
  • Gumbe bez pristupačnih naziva
  • Tekst koji ne zadovoljava pragove kontrasta
  • Nevaljane ARIA atribute ili uloge
  • Razine naslova koje preskaču na sumnjiv način
  • Orijentire koji nedostaju ili su duplicirani
  • Poveznice s praznim pristupačnim nazivima
  • Tablice bez osnovne strukture

Te provjere vrijedi automatizirati jer ljudi nisu dobri u ponavljajućem pregledavanju. Nitko ne bi trebao ručno pregledavati svaku stranicu tražeći nedostajuće oznake ako ih alat može otkriti u milisekundama.

Automatizirane provjere također olakšavaju raspravu o pristupačnosti u inženjerskim tijekovima rada. Neuspjeli test u CI-ju konkretan je. Upozorenje u pull requestu pravodobno je. Linija trenda kroz predloške daje timu nešto što može poboljšati.

Problem počinje kada timovi te provjere tretiraju kao dokaz pristupačnosti, a ne kao dokaz osnovne higijene.

Gdje automatizacija zakazuje

Pristupačnost nije samo svojstvo koda. Ona je svojstvo upotrebe.

Alat vam može reći ima li slika alt tekst. Obično vam ne može reći je li taj alt tekst koristan. Slika proizvoda može trebati detaljan opis na stranici proizvoda, nikakav opis u dekorativnom hero elementu i potpuno drukčiji opis u članku pomoći. Točan odgovor ovisi o kontekstu. Zato timovima trebaju uredničke smjernice poput pragmatičnog pristupa alt tekstu slika, a ne samo pravilo lintera.

Isti se problem pojavljuje posvuda.

Skener može potvrditi da svaki gumb ima pristupačan naziv. Ne može uvijek reći ima li taj naziv smisla. Stranica s pet gumba nazvanih Pošalji može proći osnovno pravilo, a i dalje biti mučna za korisnike čitača zaslona. Modal može imati ispravne ARIA atribute, ali pogrešno zarobiti fokus. Prilagođeni padajući izbornik može izgledati usklađeno u statičkom markupu i zakazati čim ga netko pokuša koristiti tipkovnicom.

Automatizacija se teško nosi s pitanjima poput:

  • Odgovara li redoslijed fokusa vizualnom i logičnom redoslijedu?
  • Može li se svaki zadatak dovršiti samo tipkovnicom?
  • Jesu li poruke o pogreškama konkretne, pravodobne i povezane s poljima?
  • Radi li stranica i dalje kada se tekst poveća ili zumira?
  • Je li redoslijed čitanja smislen za pomoćnu tehnologiju?
  • Jesu li upute razumljive bez oslanjanja na boju ili položaj?
  • Prenose li titlovi, transkripti i oznake doista sadržaj?
  • Ponaša li se komponenta predvidljivo u različitim stanjima?

To nisu rubni slučajevi. Oni su središnji za pristupačnost.

Lažna utjeha visoke ocjene

Ocjene pristupačnosti zavodljive su jer neurednu temu sažimaju u broj. Nadzorna ploča kaže 98. Izvješće prikazuje zelene kvačice. Izdanje djeluje sigurnije.

Ali ocjena mjeri samo ono što alat mjeri.

To je slično testiranju performansi. Lighthouse izvješće može otkriti važne probleme, ali nije isto što i gledati stvarnog korisnika kako se muči sa sporim checkoutom na telefonu srednje klase. Ako vaš tim već koristi revizije performansi, primjenjuje se isti način razmišljanja: pažljivo pročitajte izvješće, a zatim odredite prioritete nalaza koji utječu na stvarne korisnike. O toj smo razlici pisali u kako čitati Lighthouse izvješće bez panike.

Izvješća o pristupačnosti zahtijevaju isto suzdržavanje. Čisto automatizirano skeniranje početna je točka. Nije certifikat.

Rizik je osobito visok kada timovi pokreću skeniranja samo nad statičkim stranicama. Moderna su sučelja stanja: izbornici se otvaraju, ladice klize, toast poruke se pojavljuju, poruke validacije se ažuriraju, kartice prebacuju panele, filtri prepisuju sadržaj, a autentifikacija mijenja sve. Mnogi ozbiljni nedostaci pristupačnosti žive u tim interakcijama.

Ako vaš skener vidi samo početni DOM, propušta proizvod.

Kategorije koje se najčešće propuštaju

1. Ponašanje tipkovnice i fokusa

Pristup tipkovnicom jedan je od najjasnijih primjera zašto automatizacija nije dovoljna.

Alat može otkriti može li element primiti fokus. Može uhvatiti pozitivne vrijednosti tabindex ili očite zamke fokusa. Ali ne može pouzdano procijeniti djeluje li slijed tabulacije koherentno, pomiče li se fokus na pravo mjesto nakon radnje ili vraća li zatvorena komponenta fokus na okidač.

Potreban je čovjek koji će kroz stvarni tijek rada pritiskati Tab, Shift+Tab, Enter, Space, Escape i tipke sa strelicama.

To je osobito važno za prilagođene kontrole. Izvorni HTML elementi besplatno nose godine ponašanja pristupačnosti. Ponovna izgradnja gumba, odabirnika, potvrdnih okvira, izbornika i dijaloga elementima div znači da vaš tim sada posjeduje to ponašanje. Ako pregledavate interaktivne komponente, počnite s kratkim popisom za provjeru pristupačnih web gumba i proširite istu disciplinu na svaku prilagođenu kontrolu.

2. Smisleni nazivi i opisi

Automatizirani alati mogu otkriti odsutnost. Mnogo su slabiji u otkrivanju kvalitete.

Poveznica nazvana Pročitaj više tehnički može imati pristupačan naziv. Gumb označen OK može biti valjan. Napomena uz obrazac može biti prisutna. Ali jesu li smisleni u kontekstu? Često nisu.

Pristupačni nazivi trebali bi korisnicima reći što će se dogoditi ili što element predstavlja. To zahtijeva prosudbu. Također zahtijeva testiranje sa sučeljem, a ne samo s kodom.

3. Rukovanje pogreškama

Obrasci su puni problema pristupačnosti koje skeneri samo djelomično hvataju.

Alat može označiti polje bez oznake. Možda neće uhvatiti da se poruka validacije pojavljuje prekasno, nestaje prebrzo, ne najavljuje se čitačima zaslona ili kaže Nevaljan unos kada bi trebala reći Lozinka mora imati najmanje 12 znakova.

Dobro rukovanje pogreškama dizajn je interakcije. Treba ručno testiranje i, idealno, korisničko testiranje.

4. Vizualna prilagodba

WCAG uključuje zahtjeve oko promjene veličine teksta, reflowa, kontrasta, razmaka i neoslanjanja na jedan osjetilni znak. Dio toga može se provjeriti automatski, ali pravo je pitanje ostaje li sučelje upotrebljivo u promijenjenim uvjetima.

Isprobajte zumiranje od 200%. Isprobajte promjenu veličine teksta u pregledniku. Isprobajte način visokog kontrasta ili prisilnih boja. Isprobajte uske širine viewporta. Isprobajte smanjeno kretanje. Mnoga web-mjesta koja izgledaju dotjerano na zadanim postavkama brzo se raspadnu kada korisnici nametnu svoje preferencije.

5. Jasnoća sadržaja

Nijedan automatizirani alat za pristupačnost ne može u potpunosti procijeniti je li sadržaj razumljiv.

Može označiti nedostajuće naslove ili nejasan tekst poveznice. Ne može znati objašnjava li stranica proces jasno, odgovaraju li oznake očekivanjima korisnika ili stvara li zgusnut tekst izbježno kognitivno opterećenje.

Pristupačnost nije samo kompatibilnost s pomoćnom tehnologijom. Ona je i smanjenje trenja za ljude pod stresom, koji koriste nepoznat jezik, suočavaju se s ograničenjima pažnje ili prolaze kroz složene zadatke.

Bolji tijek testiranja

Uravnotežen tijek rada za pristupačnost ima slojeve.

Kontinuirano pokrećite automatizirane provjere

Koristite automatizirane testove u razvoju, pull requestovima, pregledima komponenti i CI-ju. Trebali bi biti dosadni, brzi i neupitni. Nove nedostajuće oznake i nevaljan ARIA ne bi trebali čekati kvartalnu reviziju da budu otkriveni.

Tretirajte te pogreške kao pogreške lintinga. Cilj nisu herojski pothvati; cilj je spriječiti regresije.

Dodajte ručno testiranje tipkovnicom

Za svaki smisleni korisnički tijek testirajte bez miša. To uključuje navigaciju, pretraživanje, izradu računa, checkout, filtriranje, modale, izbornike i slanje obrazaca.

U najmanju ruku provjerite:

  • Svaki interaktivni element je dosegljiv
  • Fokus je uvijek vidljiv
  • Redoslijed fokusa je logičan
  • Očekivane tipke rade
  • Escape zatvara prekrivne slojeve koji se mogu zatvoriti
  • Fokus se upravlja nakon otvaranja i zatvaranja komponenti
  • Ne postoji zamka tipkovnice

Sama ova navika otkriva veliku klasu problema koje automatizirana skeniranja propuštaju.

Testirajte s barem jednim čitačem zaslona

Ne morate postati stručni korisnik čitača zaslona da biste naučili korisne stvari. Treba vam poniznost. Testiranje čitačem zaslona ima krivulju učenja, a početnici mogu pogrešno dijagnosticirati probleme.

Ipak, osnovno testiranje s VoiceOverom, NVDA-om ili JAWS-om može otkriti neispravne nazive, zbunjujući redoslijed čitanja, nenajavljena ažuriranja i probleme s orijentirima koje skener možda neće uhvatiti.

Uparite to sa semantičkim HTML-om. Što više izvornih elemenata koristite, to vaša pristupačnost postaje manje krhka.

Pregledajte sadržaj i stanja

Provjerite prazna stanja, stanja učitavanja, stanja pogreške, onemogućena stanja, poruke uspjeha i neuspjehe dozvola. Greške pristupačnosti često se skrivaju izvan sretnog puta.

Također pregledajte stvarne riječi. Oznake, naslovi, upute i poruke o pogreškama dio su sučelja.

Uključite osobe s invaliditetom kada su ulozi visoki

Za kritične tijekove ručna stručna revizija nije dovoljna. Korisničko testiranje s osobama s invaliditetom pronalazi probleme koje timovi ne predviđaju. To je osobito važno za javne usluge, zdravstvo, financije, obrazovanje i svaki tijek u kojem isključenje ima ozbiljne posljedice.

Automatizirano testiranje skalira. Ljudsko testiranje razumije.

Kako odgovorno tumačiti automatizirane rezultate

Ne pitajte: Jesmo li prošli?

Postavite bolja pitanja:

  • Koje kategorije problema ovaj alat može otkriti?
  • Koje je predloške i stanja skenirao?
  • Je li pokrenut nakon interakcija ili samo pri početnom učitavanju?
  • Jesu li kršenja grupirana prema temeljnom uzroku ili se opetovano broje?
  • Koje pogreške sprječavaju korisnike da dovrše zadatke?
  • Što još zahtijeva ručni pregled?

Ovaj okvir mijenja razgovor. Automatizirani alati postaju dokaz, a ne autoritet.

Također pomaže timovima izbjeći besposlen rad. Ispravak jedne komponente može ukloniti stotine ponovljenih kršenja. Suprotno tome, stranica sa samo jednim prijavljenim problemom može i dalje sadržavati ozbiljnu zamku tipkovnice. Brojevi nisu utjecaj.

Praktičan standard: automatizirajte očito, ručno testirajte iskustvo

Najbolji timovi za pristupačnost nisu protiv alata. Protiv su fantazije.

Automatiziraju ono što strojevi mogu pouzdano otkriti. Ručno testiraju ono što ovisi o ponašanju i značenju. Koriste standarde poput WCAG-a kao zajedničku osnovu, a ne kao zamjenu za korištenje proizvoda.

Ako je vaš trenutačni proces samo automatizirano skeniranje prije lansiranja, poboljšajte ga ovim redoslijedom:

  1. Dodajte automatizirane provjere ranije u razvoju.
  2. Ručno testirajte tipkovnicom ključne tijekove.
  3. Pregledajte nazive, oznake, pogreške i upute.
  4. Testirajte uobičajene komponente čitačem zaslona.
  5. Uključite stručno i korisničko testiranje za visokorizična putovanja.

To nije savršen proces. Realističan je. I pronaći će mnogo više nego što će to ikada moći zelena ocjena pristupačnosti.

Često postavljana pitanja

Koliko automatizirano testiranje pristupačnosti zapravo može uhvatiti?
Ovisi o alatu, stranici i pravilima koja se testiraju. Automatizirani alati snažni su u otkrivanju nedostajućih atributa, nevaljanog ARIA-ja, problema s kontrastom i strukturnih problema. Mnogo su slabiji u procjeni funkcioniraju li oznake, ponašanje fokusa, redoslijed čitanja i tijekovi zadataka za stvarne korisnike.
Znači li prolazak automatiziranog skeniranja da zadovoljavamo WCAG?
Ne. Prolazno skeniranje znači da alat nije pronašao otkrivljiva kršenja u stanjima koja je testirao. Usklađenost s WCAG-om zahtijeva ljudsku prosudbu za mnoge kriterije, osobito one koji uključuju značenje, interakciju, slijed, upute i upotrebljivost.
Koji je najvažniji ručni test koji treba prvo dodati?
Testiranje tipkovnicom. Prođite kroz ključne tijekove pomoću Tab, Shift+Tab, Enter, Space, Escape i tipki sa strelicama. Provjerite je li fokus vidljiv, je li redoslijed logičan, rade li komponente i ne postoje li zamke. To brzo hvata mnoge ozbiljne probleme.
Trebaju li mala web-mjesta testiranje čitačem zaslona?
Da, barem na osnovnoj razini za važne stranice i obrasce. Mala web-mjesta često se oslanjaju na teme, dodatke i prilagođene komponente koje uvode probleme pristupačnosti. Čak i kratak pregled čitačem zaslona može otkriti zbunjujuće nazive, lošu strukturu naslova ili neispravne najave.
Trebaju li automatizirani testovi pristupačnosti blokirati implementaciju?
Za jasne pogreške visoke pouzdanosti, da. Nedostajuće oznake, prazni gumbi, nevaljan ARIA i ozbiljni problemi s kontrastom ne bi se smjeli olako isporučivati. Ali automatizirane rezultate treba upariti s ručnim pregledom, a ne tretirati ih kao cijeli proces pristupačnosti.

Izvori i daljnje čitanje

  1. W3C Web Accessibility Initiative: WCAG-EM Overview
  2. W3C Web Accessibility Initiative: Easy Checks
  3. WebAIM: The WebAIM Million
  4. GOV.UK Service Manual: Testing for accessibility
O autoru
The Wux Webtools Team

Zadnje ažurirano:

Nastavite čitati