Miksi automatisoitu saavutettavuustestaus ohittaa puolet ongelmistasi

Epämukava totuus automatisoidusta saavutettavuustestauksesta

Automatisoitu saavutettavuustestaus on yksi parhaista tavoista, joita verkkotiimi voi rakentaa. Se löytää puuttuvat lomakeotsikot, heikkokontrastisen tekstin, virheellisen ARIA:n, päällekkäiset ID:t, tyhjät painikkeet ja muut viat, joiden ei pitäisi koskaan päätyä tuotantoon.

Sitä myös ymmärretään jatkuvasti väärin.

Läpäisty automatisoitu saavutettavuusraportti ei tarkoita, että sivu on saavutettava. Se tarkoittaa, ettei työkalu löytänyt sitä ongelmien osajoukkoa, jonka se osaa havaita. Tämä osajoukko on arvokas, mutta rajallinen. Monet saavutettavuuspuutteet riippuvat merkityksestä, järjestyksestä, tarkoituksesta, kontekstista ja ihmisen vuorovaikutuksesta. Ohjelmisto voi tarkastaa merkintäkielen. Se ei voi luotettavasti ymmärtää, toimiiko kokemus ihmiselle, joka käyttää ruudunlukijaa, näppäimistöä, suurennusta, puheohjausta, tekstityksiä tai kognitiivista tukea.

Siksi väite, että automatisoitu testaus ohittaa noin puolet ongelmistasi, ei ole kyyninen. Se on antelias. Jotkin ongelmaluokat ovat hyvin automatisoitavissa. Toiset ovat tuskin automatisoitavissa lainkaan.

Käytännöllinen vastaus ei ole automatisoitujen työkalujen hylkääminen. Se on niiden sijoittaminen oikeaan paikkaan: varhain, usein ja osaksi laajempaa testausprosessia.

Missä automaattiset testit ovat hyviä

Automatisoidut työkalut ovat erinomaisia determinististen virheiden löytämisessä. Jos sääntö voidaan ilmaista koneellisesti luettavana ehtona, skanneri voi yleensä tarkistaa sen nopeasti ja johdonmukaisesti.

Yleisiä esimerkkejä ovat:

• Kuvat, joista puuttuu alt-attribuutti
• Lomakekentät ilman niihin liitettyjä otsikoita
• Painikkeet ilman saavutettavia nimiä
• Teksti, joka ei täytä kontrastikynnyksiä
• Virheelliset ARIA-attribuutit tai -roolit
• Otsikkotasot, jotka hyppäävät epäilyttävillä tavoilla
• Maamerkit, jotka puuttuvat tai toistuvat
• Linkit, joiden saavutettava nimi on tyhjä
• Taulukot ilman perusrakennetta

Nämä tarkistukset kannattaa automatisoida, koska ihmiset eivät ole hyviä toistuvassa tarkastamisessa. Kenenkään ei pitäisi tarkistaa käsin jokaista sivua puuttuvien otsikoiden varalta, jos työkalu voi löytää ne millisekunneissa.

Automaattiset tarkistukset tekevät saavutettavuudesta myös helpommin käsiteltävän osana ohjelmistokehityksen työnkulkuja. Epäonnistuva testi CI:ssä on konkreettinen. Varoitus pull requestissa tulee oikeaan aikaan. Mallipohjien yli kulkeva trendiviiva antaa tiimille jotain parannettavaa.

Ongelma alkaa, kun tiimit käsittelevät näitä tarkistuksia todisteena saavutettavuudesta eivätkä todisteena perushygieniasta.

Missä automaatio pettää

Saavutettavuus ei ole vain koodin ominaisuus. Se on käytön ominaisuus.

Työkalu voi kertoa, onko kuvalla vaihtoehtoinen teksti. Se ei yleensä voi kertoa, onko vaihtoehtoinen teksti hyödyllinen. Tuotteen kuva voi tarvita yksityiskohtaisen kuvauksen tuotesivulla, ei lainkaan kuvausta koristeellisessa hero-osiossa ja täysin erilaisen kuvauksen ohjeartikkelissa. Oikea vastaus riippuu kontekstista. Siksi tiimit tarvitsevat toimituksellista ohjeistusta, kuten käytännöllinen lähestymistapa kuvien vaihtoehtoisiin teksteihin, eivät vain linter-sääntöä.

Sama ongelma näkyy kaikkialla.

Skanneri voi vahvistaa, että jokaisella painikkeella on saavutettava nimi. Se ei aina voi kertoa, onko nimi järkevä. Sivu, jolla on viisi Submit-nimistä painiketta, voi läpäistä perussäännön ja olla silti ruudunlukijan käyttäjille tuskallinen. Modaalilla voi olla oikeat ARIA-attribuutit, mutta se voi hallita fokusta väärin. Mukautettu alasvetovalikko voi näyttää staattisessa merkintäkielessä vaatimustenmukaiselta ja epäonnistua heti, kun joku yrittää käyttää sitä näppäimistöllä.

Automaatio kamppailee tällaisten kysymysten kanssa:

• Vastaako fokusjärjestys visuaalista ja loogista järjestystä?
• Voiko jokaisen tehtävän suorittaa pelkällä näppäimistöllä?
• Ovatko virheilmoitukset täsmällisiä, oikea-aikaisia ja kenttiin liitettyjä?
• Toimiiko sivu edelleen, kun tekstin kokoa muutetaan tai sivua zoomataan?
• Onko lukujärjestys järkevä avustavalle teknologialle?
• Ovatko ohjeet ymmärrettäviä ilman väriin tai sijaintiin tukeutumista?
• Välittävätkö tekstitykset, litteroinnit ja nimilaput todella sisällön?
• Käyttäytyykö komponentti ennakoitavasti eri tiloissa?

Nämä eivät ole reunatapauksia. Ne ovat saavutettavuuden ydintä.

Korkean pistemäärän väärä turvallisuudentunne

Saavutettavuuspisteet ovat houkuttelevia, koska ne tiivistävät sotkuisen aiheen numeroksi. Kojelauta näyttää 98. Raportti näyttää vihreitä tarkistusmerkkejä. Julkaisu tuntuu turvallisemmalta.

Mutta pistemäärä mittaa vain sitä, mitä työkalu mittaa.

Tämä muistuttaa suorituskykytestausta. Lighthouse-raportti voi paljastaa tärkeitä ongelmia, mutta se ei ole sama asia kuin katsoa, kun todellinen käyttäjä kamppailee hitaan kassaprosessin läpi keskitason puhelimella. Jos tiimisi käyttää jo suorituskykyauditointeja, sama ajattelutapa pätee: lue raportti huolellisesti ja priorisoi sitten löydökset, jotka vaikuttavat todellisiin käyttäjiin. Olemme kirjoittaneet tästä erosta artikkelissa kuinka lukea Lighthouse-raporttia panikoimatta.

Saavutettavuusraportit vaativat samaa malttia. Puhdas automatisoitu skannaus on lähtökohta. Se ei ole sertifikaatti.

Riski on erityisen suuri, kun tiimit ajavat skannauksia vain staattisia sivuja vasten. Nykyaikaiset käyttöliittymät ovat tilallisia: valikot avautuvat, laatikot liukuvat esiin, ilmoitukset ilmestyvät, validointiviestit päivittyvät, välilehdet vaihtavat paneeleja, suodattimet kirjoittavat sisältöä uudelleen ja tunnistautuminen muuttaa kaiken. Monet vakavat saavutettavuuspuutteet elävät juuri näissä vuorovaikutuksissa.

Jos skannerisi näkee vain alkuperäisen DOM:n, se ei näe tuotetta.

Useimmin ohitetut kategoriat

1. Näppäimistön ja fokuksen toiminta

Näppäimistökäyttö on yksi selkeimmistä esimerkeistä siitä, miksi automaatio ei riitä.

Työkalu voi havaita, onko elementti fokusoitavissa. Se voi löytää positiivisia tabindex-arvoja tai ilmeisiä fokusansoja. Mutta se ei voi luotettavasti arvioida, tuntuuko sarkainjärjestys johdonmukaiselta, siirtyykö fokus oikeaan paikkaan toiminnon jälkeen tai palauttaako suljettu komponentti fokuksen laukaisijaan.

Tarvitaan ihminen painamaan Tab, Shift+Tab, Enter, Space, Escape ja nuolinäppäimiä todellisen työnkulun läpi.

Tämä on erityisen tärkeää mukautetuissa ohjaimissa. Natiivit HTML-elementit tuovat mukanaan vuosien saavutettavuuskäyttäytymisen ilmaiseksi. Painikkeiden, valintalistojen, valintaruutujen, valikoiden ja dialogien rakentaminen uudelleen div-elementeillä tarkoittaa, että tiimisi omistaa nyt myös tämän käyttäytymisen. Jos arvioit interaktiivisia komponentteja, aloita artikkelista lyhyt tarkistuslista saavutettaville verkkopainikkeille ja laajenna sama kurinalaisuus jokaiseen mukautettuun ohjaimeen.

2. Merkitykselliset nimet ja kuvaukset

Automatisoidut työkalut osaavat havaita puuttumisen. Ne ovat paljon huonompia laadun arvioinnissa.

Linkillä nimeltä Lue lisää voi teknisesti olla saavutettava nimi. OK-niminen painike voi olla validi. Lomakevihje voi olla olemassa. Mutta ovatko ne merkityksellisiä kontekstissa? Usein eivät.

Saavutettavien nimien pitäisi kertoa käyttäjille, mitä tapahtuu tai mitä elementti edustaa. Se vaatii harkintaa. Se vaatii myös testausta käyttöliittymän kanssa, ei vain koodin kanssa.

3. Virheiden käsittely

Lomakkeet ovat täynnä saavutettavuuspuutteita, joita skannerit löytävät vain osittain.

Työkalu voi merkitä kentän, jolta puuttuu otsikko. Se ei välttämättä huomaa, että validointiviesti ilmestyy liian myöhään, katoaa liian nopeasti, sitä ei ilmoiteta ruudunlukijoille tai siinä lukee Virheellinen syöte, vaikka pitäisi lukea Salasanan on oltava vähintään 12 merkkiä pitkä.

Hyvä virheiden käsittely on vuorovaikutussuunnittelua. Se vaatii manuaalista testausta ja mieluiten myös käyttäjätestausta.

4. Visuaalinen mukautuminen

WCAG sisältää vaatimuksia tekstin koon muuttamisesta, uudelleenjuoksutuksesta, kontrastista, välistyksestä ja siitä, ettei luoteta yhteen aistivihjeeseen. Osa tästä voidaan tarkistaa automaattisesti, mutta todellinen kysymys on, pysyykö käyttöliittymä käytettävänä muuttuneissa olosuhteissa.

Kokeile 200 % zoomausta. Kokeile selaimen tekstikoon muuttamista. Kokeile korkeaa kontrastia tai forced colors -tilaa. Kokeile kapeita näkymän leveyksiä. Kokeile vähennettyä liikettä. Monet sivustot, jotka näyttävät viimeistellyiltä oletusasetuksilla, hajoavat nopeasti, kun käyttäjät ottavat omat mieltymyksensä käyttöön.

5. Sisällön selkeys

Mikään automatisoitu saavutettavuustyökalu ei voi täysin arvioida, onko sisältö ymmärrettävää.

Se voi merkitä puuttuvat otsikot tai epämääräisen linkkitekstin. Se ei voi tietää, selittääkö sivu prosessin selkeästi, vastaavatko nimilaput käyttäjien odotuksia tai aiheuttaako tiivis teksti vältettävää kognitiivista kuormaa.

Saavutettavuus ei tarkoita vain yhteensopivuutta avustavan teknologian kanssa. Se tarkoittaa myös kitkan vähentämistä ihmisille, jotka ovat stressin alla, käyttävät vierasta kieltä, kamppailevat tarkkaavuuden rajoitteiden kanssa tai navigoivat monimutkaisissa tehtävissä.

Parempi testausprosessi

Tasapainoisessa saavutettavuusprosessissa on kerroksia.

Aja automaattisia tarkistuksia jatkuvasti

Käytä automaattisia testejä kehityksessä, pull requesteissa, komponenttien esikatseluissa ja CI:ssä. Niiden pitäisi olla tylsiä, nopeita ja neuvottelemattomia. Uusien puuttuvien otsikoiden ja virheellisen ARIA:n löytämisen ei pitäisi vaatia neljännesvuosittaista auditointia.

Käsittele näitä virheitä kuten linting-virheitä. Tavoitteena ei ole sankaruus, vaan regressioiden estäminen.

Lisää manuaalinen näppäimistötestaus

Testaa jokainen merkityksellinen käyttäjäpolku ilman hiirtä. Tämä sisältää navigoinnin, haun, tilin luomisen, kassaprosessin, suodatuksen, modaalit, valikot ja lomakkeen lähetyksen.

Varmista vähintään:

• Jokainen interaktiivinen elementti on saavutettavissa
• Fokus on näkyvissä koko ajan
• Fokusjärjestys on looginen
• Odotetut näppäimet toimivat
• Escape sulkee suljettavat peitteet
• Fokusta hallitaan komponenttien avaamisen ja sulkemisen jälkeen
• Näppäimistöansaa ei ole

Tämä yksi tapa löytää suuren joukon ongelmia, jotka automatisoidut skannaukset ohittavat.

Testaa vähintään yhdellä ruudunlukijalla

Sinun ei tarvitse tulla ruudunlukijan asiantuntijakäyttäjäksi oppiaksesi hyödyllisiä asioita. Tarvitset kuitenkin nöyryyttä. Ruudunlukijatestauksessa on oppimiskäyrä, ja aloittelijat voivat diagnosoida ongelmia väärin.

Silti perustason testaus VoiceOverilla, NVDA:lla tai JAWSilla voi paljastaa rikkinäisiä nimiä, hämmentävän lukujärjestyksen, ilmoittamattomia päivityksiä ja maamerkkiongelmia, joita skanneri ei välttämättä löydä.

Yhdistä tämä semanttiseen HTML:ään. Mitä enemmän käytät natiiveja elementtejä, sitä vähemmän hauraaksi saavutettavuutesi muuttuu.

Arvioi sisältö ja tilat

Tarkista tyhjät tilat, lataustilat, virhetilat, käytöstä poistetut tilat, onnistumisviestit ja käyttöoikeusvirheet. Saavutettavuusvirheet piiloutuvat usein onnistuneen polun ulkopuolelle.

Arvioi myös varsinaiset sanat. Nimilaput, otsikot, ohjeet ja virheilmoitukset ovat osa käyttöliittymää.

Ota vammaiset käyttäjät mukaan, kun panokset ovat suuret

Kriittisissä poluissa asiantuntijan manuaalinen arviointi ei riitä. Käyttäjätestaus vammaisten osallistujien kanssa löytää ongelmia, joita tiimit eivät osaa ennakoida. Tämä on erityisen tärkeää julkisissa palveluissa, terveydenhuollossa, rahoituksessa, koulutuksessa ja kaikissa poluissa, joissa ulossulkemisella on vakavia seurauksia.

Automatisoitu testaus skaalautuu. Ihmistestaus ymmärtää.

Miten automatisoituja tuloksia tulkitaan vastuullisesti

Älä kysy: Läpäisimmekö?

Kysy parempia kysymyksiä:

• Mitä ongelmaluokkia tämä työkalu voi havaita?
• Mitkä mallipohjat ja tilat se skannasi?
• Ajettiinko se vuorovaikutusten jälkeen vai vain alkulatauksessa?
• Onko rikkomukset ryhmitelty juurisyyn mukaan vai laskettu toistuvasti?
• Mitkä virheet estävät käyttäjiä suorittamasta tehtäviä?
• Mikä vaatii edelleen manuaalista arviointia?

Tämä kehystys muuttaa keskustelun. Automatisoiduista työkaluista tulee todistusaineistoa, ei auktoriteetteja.

Se auttaa tiimejä myös välttämään turhaa työtä. Yhden komponentin korjaaminen voi poistaa satoja toistuvia rikkomuksia. Toisaalta sivu, jolla on vain yksi raportoitu ongelma, voi silti sisältää vakavan näppäimistöansan. Lukumäärät eivät ole vaikutusta.

Käytännön standardi: automatisoi ilmeinen, testaa kokemus käsin

Parhaat saavutettavuustiimit eivät ole työkaluvastaisia. Ne ovat harhakuvien vastaisia.

Ne automatisoivat sen, minkä koneet voivat havaita luotettavasti. Ne testaavat käsin sen, mikä riippuu käyttäytymisestä ja merkityksestä. Ne käyttävät WCAG:n kaltaisia standardeja yhteisenä perustasona, eivät tuotteen käytön korvikkeena.

Jos nykyinen prosessisi on vain automatisoitu skannaus ennen julkaisua, paranna sitä tässä järjestyksessä:

1. Lisää automaattiset tarkistukset aiemmin kehitykseen.
2. Testaa keskeiset polut käsin näppäimistöllä.
3. Arvioi nimet, nimilaput, virheet ja ohjeet.
4. Testaa yleiset komponentit ruudunlukijalla.
5. Ota asiantuntija- ja käyttäjätestaus mukaan korkean riskin käyttäjäpolkuihin.

Se ei ole täydellinen prosessi. Se on realistinen. Ja se löytää paljon enemmän kuin vihreä saavutettavuuspistemäärä koskaan löytää.