Kodėl automatizuotas prieinamumo testavimas nepastebi pusės jūsų problemų

Nepatogi tiesa apie automatizuotą prieinamumo testavimą

Automatizuotas prieinamumo testavimas yra vienas geriausių įpročių, kuriuos gali išsiugdyti žiniatinklio komanda. Jis pagauna trūkstamas formų etiketes, mažo kontrasto tekstą, neteisingą ARIA, pasikartojančius ID, tuščius mygtukus ir kitus defektus, kurie niekada neturėtų pasiekti produkcinės aplinkos.

Tačiau jis taip pat nuolat suprantamas neteisingai.

Sėkminga automatizuota prieinamumo ataskaita nereiškia, kad puslapis yra prieinamas. Ji reiškia, kad įrankis nerado tos problemų dalies, kurią moka aptikti. Ta dalis vertinga, bet ribota. Daugelis prieinamumo klaidų priklauso nuo prasmės, tvarkos, ketinimo, konteksto ir žmogaus sąveikos. Programinė įranga gali patikrinti žymėjimą. Ji negali patikimai suprasti, ar patirtis veikia žmogui, naudojančiam ekrano skaitytuvą, klaviatūrą, didinimą, valdymą balsu, titrus ar kognityvinę pagalbą.

Todėl teiginys, kad automatizuotas testavimas nepastebi maždaug pusės jūsų problemų, nėra ciniškas. Jis dosnus. Kai kurios problemų kategorijos labai gerai automatizuojamos. Kitos beveik visai neautomatizuojamos.

Praktiškas atsakymas nėra atsisakyti automatizuotų įrankių. Reikia juos padėti į tinkamą vietą: anksti, dažnai ir kaip platesnio testavimo proceso dalį.

Ką automatizuoti testai daro gerai

Automatizuoti įrankiai puikiai randa deterministines klaidas. Jei taisyklę galima išreikšti mašinai suprantama sąlyga, skeneris paprastai gali ją patikrinti greitai ir nuosekliai.

Dažni pavyzdžiai:

• Vaizdai be alt atributų
• Formos įvestys be susietų etikečių
• Mygtukai be prieinamų pavadinimų
• Tekstas, neatitinkantis kontrasto slenksčių
• Neteisingi ARIA atributai arba rolės
• Įtartinai praleidžiami antraščių lygiai
• Trūkstami arba pasikartojantys orientyrai
• Nuorodos su tuščiais prieinamais pavadinimais
• Lentelės be bazinės struktūros

Šias patikras verta automatizuoti, nes žmonėms prastai sekasi kartotinis tikrinimas. Niekas neturėtų rankiniu būdu peržiūrėti kiekvieno puslapio ieškodamas trūkstamų etikečių, jei įrankis gali jas pagauti per milisekundes.

Automatizuotos patikros taip pat palengvina prieinamumo aptarimą inžineriniuose procesuose. Nepavykęs testas CI yra konkretus. Įspėjimas pull request yra laiku. Tendencijos linija per šablonus suteikia komandai ką gerinti.

Problema prasideda tada, kai komandos šias patikras laiko prieinamumo įrodymu, o ne bazinės higienos įrodymu.

Kur automatizavimas palūžta

Prieinamumas nėra vien kodo savybė. Tai naudojimo savybė.

Įrankis gali pasakyti, ar vaizdas turi alt tekstą. Paprastai jis negali pasakyti, ar tas alt tekstas naudingas. Produkto vaizdui produkto puslapyje gali reikėti išsamaus aprašymo, dekoratyviniame hero bloke gali nereikėti jokio aprašymo, o pagalbos straipsnyje gali reikėti visiškai kitokio aprašymo. Teisingas atsakymas priklauso nuo konteksto. Todėl komandoms reikia redakcinių gairių, tokių kaip pragmatiškas požiūris į vaizdų alt tekstą, o ne vien linter taisyklės.

Ta pati problema matoma visur.

Skeneris gali patvirtinti, kad kiekvienas mygtukas turi prieinamą pavadinimą. Jis ne visada gali pasakyti, ar tas pavadinimas prasmingas. Puslapis su penkiais mygtukais, pavadintais Pateikti, gali praeiti bazinę taisyklę ir vis tiek būti varginantis ekrano skaitytuvų naudotojams. Modalinis langas gali turėti tinkamus ARIA atributus, bet neteisingai įkalinti fokusą. Pasirinktinis išskleidžiamasis sąrašas statiniame žymėjime gali atrodyti atitinkantis reikalavimus ir sugriūti tą akimirką, kai kas nors pabando juo naudotis klaviatūra.

Automatizavimui sunku atsakyti į tokius klausimus:

• Ar fokuso tvarka atitinka vizualią ir loginę tvarką?
• Ar kiekvieną užduotį galima atlikti vien klaviatūra?
• Ar klaidų pranešimai yra konkretūs, pateikiami laiku ir susieti su laukais?
• Ar puslapis vis dar veikia padidinus tekstą arba pritaikius mastelį?
• Ar skaitymo tvarka prasminga pagalbinėms technologijoms?
• Ar instrukcijos suprantamos nepasikliaujant spalva ar padėtimi?
• Ar titrai, transkriptai ir etiketės iš tikrųjų perteikia turinį?
• Ar komponentas elgiasi nuspėjamai skirtingose būsenose?

Tai nėra kraštiniai atvejai. Tai prieinamumo esmė.

Klaidinga aukšto balo paguoda

Prieinamumo balai vilioja, nes sudėtingą temą suspaudžia į skaičių. Skydelyje rodoma 98. Ataskaitoje matosi žalios varnelės. Leidimas atrodo saugesnis.

Tačiau balas matuoja tik tai, ką matuoja įrankis.

Tai panašu į našumo testavimą. Lighthouse ataskaita gali atskleisti svarbias problemas, bet tai nėra tas pats, kas stebėti realų naudotoją, kovojantį su lėtu atsiskaitymu vidutinės klasės telefone. Jei jūsų komanda jau naudoja našumo auditus, taikomas tas pats mąstymas: atidžiai perskaitykite ataskaitą, tada prioritetizuokite radinius, kurie veikia tikrus naudotojus. Apie šį skirtumą rašėme straipsnyje kaip skaityti Lighthouse ataskaitą nepanikuojant.

Prieinamumo ataskaitoms reikia tokio pat santūrumo. Švari automatizuota patikra yra pradžios taškas. Tai nėra sertifikatas.

Rizika ypač didelė, kai komandos skenuoja tik statinius puslapius. Šiuolaikinės sąsajos yra būseninės: meniu atsidaro, stalčiai išslenka, pranešimai pasirodo, validavimo pranešimai atsinaujina, kortelės perjungia skydelius, filtrai perrašo turinį, o autentifikacija keičia viską. Daug rimtų prieinamumo defektų gyvena būtent šiose sąveikose.

Jei jūsų skeneris mato tik pradinį DOM, jis nemato produkto.

Kategorijos, kurios dažniausiai praleidžiamos

1. Klaviatūros ir fokuso elgsena

Prieiga klaviatūra yra vienas aiškiausių pavyzdžių, kodėl automatizavimo nepakanka.

Įrankis gali aptikti, ar elementas gali gauti fokusą. Jis gali pagauti teigiamas tabindex reikšmes arba akivaizdžius fokuso spąstus. Tačiau jis negali patikimai įvertinti, ar tabuliavimo seka atrodo nuosekli, ar po veiksmo fokusas pereina į tinkamą vietą, arba ar uždarytas komponentas grąžina fokusą į aktyviklį.

Reikia žmogaus, kuris realiame procese spaustų Tab, Shift+Tab, Enter, Space, Escape ir rodyklių klavišus.

Tai ypač svarbu pasirinktiniams valdikliams. Gimtieji HTML elementai nemokamai atsineša metų metus kurtą prieinamumo elgseną. Mygtukų, select, checkbox, meniu ir dialogų perkūrimas naudojant div reiškia, kad jūsų komanda dabar atsako už tą elgseną. Jei peržiūrite interaktyvius komponentus, pradėkite nuo trumpo prieinamų žiniatinklio mygtukų kontrolinio sąrašo ir tą pačią discipliną taikykite kiekvienam pasirinktiniam valdikliui.

2. Prasmingi pavadinimai ir aprašymai

Automatizuoti įrankiai gali aptikti nebuvimą. Kokybę jie aptinka daug prasčiau.

Nuoroda pavadinimu Skaityti daugiau techniškai gali turėti prieinamą pavadinimą. Mygtukas su etikete OK gali būti galiojantis. Formos užuomina gali būti pateikta. Bet ar jie prasmingi kontekste? Dažnai ne.

Prieinami pavadinimai turėtų pasakyti naudotojams, kas įvyks arba ką elementas reiškia. Tam reikia sprendimo. Taip pat reikia testuoti sąsają, o ne tik kodą.

3. Klaidų tvarkymas

Formose pilna prieinamumo klaidų, kurias skeneriai pagauna tik iš dalies.

Įrankis gali pažymėti lauką be etiketės. Jis gali nepastebėti, kad validavimo pranešimas pasirodo per vėlai, dingsta per greitai, nėra paskelbiamas ekrano skaitytuvams arba sako Netinkama įvestis, kai turėtų sakyti Slaptažodį turi sudaryti bent 12 simbolių.

Geras klaidų tvarkymas yra sąveikos dizainas. Jam reikia rankinio testavimo ir, idealiu atveju, naudotojų testavimo.

4. Vizualinis prisitaikymas

WCAG apima reikalavimus, susijusius su teksto dydžio keitimu, persiliejimu, kontrastu, tarpais ir nepasikliovimu vienu sensoriniu signalu. Dalį to galima patikrinti automatiškai, bet tikrasis klausimas yra, ar sąsaja išlieka naudojama pasikeitus sąlygoms.

Išbandykite 200% mastelį. Išbandykite naršyklės teksto dydžio keitimą. Išbandykite didelį kontrastą arba priverstinių spalvų režimą. Išbandykite siaurus peržiūros srities pločius. Išbandykite sumažintą judesį. Daugelis svetainių, kurios atrodo nugludintos su numatytaisiais nustatymais, greitai lūžta, kai naudotojai pritaiko savo nuostatas.

5. Turinio aiškumas

Joks automatizuotas prieinamumo įrankis negali iki galo įvertinti, ar turinys suprantamas.

Jis gali pažymėti trūkstamas antraštes arba neaiškų nuorodų tekstą. Jis negali žinoti, ar puslapis aiškiai paaiškina procesą, ar etiketės atitinka naudotojų lūkesčius, arba ar tankus tekstas sukuria išvengiamą kognityvinę apkrovą.

Prieinamumas nėra vien suderinamumas su pagalbinėmis technologijomis. Tai taip pat trinties mažinimas žmonėms, patiriantiems stresą, vartojantiems jiems nepažįstamą kalbą, susiduriantiems su dėmesio ribojimais arba naršantiems sudėtingas užduotis.

Geresnis testavimo procesas

Subalansuotas prieinamumo procesas turi sluoksnius.

Nuolat vykdykite automatizuotas patikras

Naudokite automatizuotus testus kūrimo metu, pull request, komponentų peržiūrose ir CI. Jie turėtų būti nuobodūs, greiti ir nediskutuotini. Naujos trūkstamos etiketės ir neteisinga ARIA neturėtų laukti ketvirtinio audito, kad būtų aptiktos.

Šias klaidas traktuokite kaip linting klaidas. Tikslas nėra heroizmas; tikslas yra regresijų prevencija.

Pridėkite rankinį testavimą klaviatūra

Kiekvienam reikšmingam naudotojo srautui testuokite be pelės. Tai apima navigaciją, paiešką, paskyros kūrimą, atsiskaitymą, filtravimą, modalinius langus, meniu ir formos pateikimą.

Mažiausiai patikrinkite:

• Kiekvienas interaktyvus elementas pasiekiamas
• Fokusas visada matomas
• Fokuso tvarka logiška
• Veikia tikėtini klavišai
• Escape uždaro uždaromus perdangos elementus
• Fokusas valdomas atidarant ir uždarant komponentus
• Nėra klaviatūros spąstų

Vien šis įprotis pagauna didelę dalį problemų, kurių automatizuoti skenavimai nepastebi.

Testuokite bent su vienu ekrano skaitytuvu

Nereikia tapti ekrano skaitytuvų ekspertu, kad išmoktumėte naudingų dalykų. Tačiau reikia nuolankumo. Ekrano skaitytuvų testavimas turi mokymosi kreivę, o pradedantieji gali neteisingai diagnozuoti problemas.

Vis dėlto bazinis testavimas su VoiceOver, NVDA arba JAWS gali atskleisti sugedusius pavadinimus, painią skaitymo tvarką, nepaskelbiamus atnaujinimus ir orientyrų problemas, kurių skeneris gali nepastebėti.

Derinkite tai su semantiniu HTML. Kuo daugiau gimtųjų elementų naudojate, tuo mažiau trapus tampa jūsų prieinamumas.

Peržiūrėkite turinį ir būsenas

Patikrinkite tuščias būsenas, krovimo būsenas, klaidų būsenas, išjungtas būsenas, sėkmės pranešimus ir leidimų nesėkmes. Prieinamumo klaidos dažnai slepiasi už laimingojo kelio ribų.

Taip pat peržiūrėkite tikruosius žodžius. Etiketės, antraštės, instrukcijos ir klaidų pranešimai yra sąsajos dalis.

Įtraukite žmones su negalia, kai rizika didelė

Kritiniams srautams rankinės ekspertų peržiūros nepakanka. Naudotojų testavimas su negalią turinčiais dalyviais randa problemų, kurių komandos nenumato. Tai ypač svarbu viešosioms paslaugoms, sveikatos priežiūrai, finansams, švietimui ir bet kuriam srautui, kuriame atskirtis turi rimtų pasekmių.

Automatizuotas testavimas plečiasi. Žmonių testavimas supranta.

Kaip atsakingai interpretuoti automatizuotus rezultatus

Neklauskite: ar praėjome?

Klauskite geresnių klausimų:

• Kokias problemų kategorijas šis įrankis gali aptikti?
• Kokius šablonus ir būsenas jis nuskenavo?
• Ar jis veikė po sąveikų, ar tik pradinio įkėlimo metu?
• Ar pažeidimai sugrupuoti pagal šakninę priežastį, ar suskaičiuoti pakartotinai?
• Kurios klaidos trukdo naudotojams užbaigti užduotis?
• Ką vis dar reikia peržiūrėti rankiniu būdu?

Toks rėminimas keičia pokalbį. Automatizuoti įrankiai tampa įrodymais, o ne autoritetu.

Tai taip pat padeda komandoms išvengti beprasmiško darbo. Vieno komponento pataisymas gali pašalinti šimtus pasikartojančių pažeidimų. Priešingai, puslapis, kuriame pranešta tik apie vieną problemą, vis tiek gali turėti rimtus klaviatūros spąstus. Skaičiai nėra poveikis.

Praktinis standartas: automatizuokite akivaizdžius dalykus, rankiniu būdu testuokite patirtį

Geriausios prieinamumo komandos nėra nusiteikusios prieš įrankius. Jos nusiteikusios prieš fantaziją.

Jos automatizuoja tai, ką mašinos gali patikimai aptikti. Jos rankiniu būdu testuoja tai, kas priklauso nuo elgsenos ir prasmės. Jos naudoja tokius standartus kaip WCAG kaip bendrą bazinį lygį, o ne kaip produkto naudojimo pakaitalą.

Jei jūsų dabartinis procesas yra tik automatizuotas skenavimas prieš paleidimą, gerinkite jį tokia tvarka:

1. Pridėkite automatizuotas patikras anksčiau kūrimo procese.
2. Rankiniu būdu patikrinkite pagrindinius srautus klaviatūra.
3. Peržiūrėkite pavadinimus, etiketes, klaidas ir instrukcijas.
4. Ištestuokite dažnus komponentus su ekrano skaitytuvu.
5. Didelės rizikos kelionėms pasitelkite ekspertų ir naudotojų testavimą.

Tai nėra tobulas procesas. Tai realistiškas procesas. Ir jis ras kur kas daugiau nei kada nors ras žalias prieinamumo balas.