Ruudunlukijoiden testaus: NVDA, JAWS, VoiceOver

Sivu voi läpäistä jokaisen automaattisen tarkistuksen, julkaistua kelvollisella HTML:llä ja silti olla käyttökelvoton jollekulle, joka navigoi verkossa kuulon avulla. Automaattiset työkalut löytävät vain noin kolmanneksen saavutettavuusongelmista; loput piilevät kuilussa sen välillä, mitä saavutettavuuspuu teknisesti sisältää ja mitä ruudunlukija todella ilmoittaa käyttäjälle. Tuon kuilun umpeen kuromiseksi sinun on vietävä käyttöliittymäsi samojen työkalujen eteen, joihin yleisösi luottaa — ja juuri sitä varten ruudunlukijoiden testaus on olemassa.

Tämä opas käy läpi, miten suuret ruudunlukijat eroavat toisistaan, miksi yhden testaaminen ei koskaan riitä, mitä tarkalleen ottaen tulee testata, mitä lukija- ja selainyhdistelmiä käyttää sekä sudenkuopat, joihin myös kokeneet tiimit lankeavat. Se on kirjoitettu kehittäjille, QA-insinööreille ja saavutettavuusasiantuntijoille, jotka haluavat testata harkitusti arvaamisen sijaan. Jos haluat mieluummin antaa työn asiantuntijoille, jotka käyttävät näitä työkaluja päivittäin, ruudunlukija-arviointipalvelumme tekee juuri sen.

Miksi ruudunlukija ei ole “ääneenlukutyökalu”

Yleisin väärinkäsitys on, että ruudunlukija yksinkertaisesti puhuu sivulla olevan tekstin. Se tekee paljon enemmän kuin sen, ja tuon eron ymmärtäminen on hyvän testauksen perusta. Ruudunlukija rakentaa rinnakkaisen, ei-visuaalisen mallin käyttöliittymästä selaimen saavutettavuuspuun pohjalta. Se ilmoittaa kunkin elementin nimen (“Lähetä, painike”), sen roolin (painike, linkki, otsikko, valintaruutu) ja sen tilan (valittu, laajennettu, poistettu käytöstä, pakollinen). Se antaa käyttäjän hypätä otsikoiden, maamerkkien, lomakekenttien ja linkkien välillä koskematta visuaaliseen asetteluun. Se puhuu dynaamiset muutokset — virheilmoitukset, hakutulokset, tilapäivitykset — kun nuo muutokset on tuotu esiin oikein.

Tämä eroaa olennaisesti tekstistä puheeksi -muunnoksesta, joka muuntaa tekstilohkon ääneksi ilman käsitystä rooleista, tiloista tai navigoinnista. Käsittelemme tätä eroa yksityiskohtaisesti artikkelissa teksti puheeksi vastaan ruudunlukijat, ja sillä on tässä merkitystä, koska toisen testaaminen ei testaa toista. Ruudunlukijan käyttäjä ei kuluta sivuasi ylhäältä alas; hän navigoi siinä rakenteellisesti ja odottaa jokaisen vuorovaikutteisen elementin ilmoittavan, mikä se on ja mitä se tekee.

Miten NVDA, JAWS, VoiceOver ja TalkBack eroavat

Ne neljä lukijaa, joista useimpien tiimien on välitettävä, käyttäytyvät riittävän eri tavoin, jotta “se toimii yhdessä” ei kerro sinulle juuri mitään muista.

NVDA (Windows)

NVDA on ilmainen, avoimen lähdekoodin lukija ja maailman laajimmin käytetty ruudunlukija. Se sopii luontevimmin yhteen Firefoxin ja Chromen kanssa. NVDA noudattaa yleensä ARIA- ja HTML-semantiikkaa tarkasti, mikä tekee siitä erinomaisen lähtötason: jos merkinnässäsi on jotain rikki, NVDA tuo sen usein selvästi esiin. Sillä on kaksi keskeistä tilaa — selaustila (lukemiseen ja rakenteelliseen navigointiin) ja kohdistustila (lomakkeisiin kirjoittamiseen ja komponenttien käyttämiseen) — ja yleinen virheiden lähde ovat komponentit, jotka eivät laukaise oikeaa tilanvaihtoa.

JAWS (Windows)

JAWS on kauan vakiintunut kaupallinen lukija, joka on edelleen hallitseva yrityksissä, julkishallinnossa ja monilla työpaikoilla. Se sopii yhteen Chromen ja Edgen kanssa. JAWS on kuuluisa “avuliaisuudestaan”: se soveltaa heuristiikkoja, jotka arvaavat merkityksen, ilmoittaa joskus asioita, joista NVDA vaikenee, ja silottaa toisinaan merkintävirheitä, jotka pitäisi korjata. Tuo avuliaisuus leikkaa molempiin suuntiin — koodi, joka “toimii JAWS:ssa”, voi epäonnistua NVDA:ssa tai VoiceOverissa, koska JAWS peitti ongelman. Sillä on myös oma virtuaalikohdistin ja lomaketilan käyttäytyminen, joka eroaa hienovaraisesti NVDA:n vastaavasta.

VoiceOver (macOS ja iOS)

VoiceOver on sisäänrakennettuna jokaisessa Macissa, iPhonessa ja iPadissa, ja se sopii lähes yksinomaan yhteen Safarin kanssa. macOS:ssä navigointi tapahtuu roottorin ja VO-näppäinyhdistelmien kautta; iOS:ssä se on täysin eleohjattu — pyyhkäise liikkuaksesi, kaksoisnapauta aktivoidaksesi, roottori kahta sormea kiertämällä. VoiceOver on yleensä neljästä tiukin ARIA:n suhteen: se vaikenee usein arvaamisen sijaan, kun nimet tai roolit puuttuvat, joten ohjain, jonka JAWS ilmoittaa, ei välttämättä sano VoiceOverissa mitään. Pöytäkoneen ja mobiilin VoiceOver eroavat myös toisistaan, joten ne lasketaan kahdeksi erilliseksi testikohteeksi.

TalkBack (Android)

TalkBack on Androidin sisäänrakennettu lukija, joka on yhdistettynä Chromeen. Kuten iOS:n VoiceOver, sekin on elepohjainen, mutta sen eleet, kohdistuskäyttäytyminen sekä live-alueiden ja mukautettujen ohjainten käsittely eroavat VoiceOverin vastaavista. Mobiililukijat tuovat yleisesti esiin ongelmia, joita ei koskaan esiinny pöytäkoneella: kosketuskohteita, joita ei tavoiteta pyyhkäisemällä, kohdistuksen, joka hyppää odottamatta näytön vaihtumisen jälkeen, ja sisältöä, joka on visuaalisesti läsnä mutta jonka lineaarinen elejärjestys ohittaa kokonaan.

Miksi usean lukijan testaus on välttämätöntä

Koska nämä lukijat eroavat toisistaan siinä, miten ne tulkitsevat täsmälleen samaa merkintää, yhden lukijan testaus tuottaa väärän turvallisuudentunteen. Muutama konkreettinen kuvio nousee esiin yhä uudelleen:

Mukautettu yhdistelmäruutu (combobox), jonka JAWS ilmoittaa täydellisesti, voi vaieta täysin VoiceOverissa, koska VoiceOver kieltäytyy päättelemästä puuttuvaa role- tai aria-expanded-tilaa.
Live-alue, jonka NVDA ilmoittaa kohteliaasti kerran, voidaan ilmoittaa toistuvasti tai ei ollenkaan toisessa lukijassa riippuen siitä, miten aria-live ja DOM-lisäyksen ajoitus vaikuttavat toisiinsa.
Ohjain, jolla on tarpeeton tai ristiriitainen nimi (näkyvä otsikko plus aria-label plus title), voidaan ilmoittaa järkevästi yhdessä lukijassa ja sekavana kaksoiskappaleiden jonona toisessa.
Lukujärjestys, joka vastaa visuaalista järjestystä yhdessä selain/lukija-yhdistelmässä, voi poiketa toisessa, kun CSS järjestää sisällön uudelleen mutta DOM ei.

Jokainen lukija on myös sidottu eri selaimeen, joten testaat todellisuudessa lukija-plus-selain-yhdistelmiä, et lukijoita yksinään. Ainoa tapa tietää, että tuotteesi on johdonmukainen kaikille, on testata todelliset yhdistelmät, joita yleisösi käyttää. Tämä periaate on sama, joka on yleisesti manuaalisten saavutettavuusauditointien taustalla: työkalut kaventavat etsintää, ihmiset vahvistavat kokemuksen.

Mitä testata

Testaus on paljon tehokkaampaa, kun se on jäsenneltyä. Nämä ovat ulottuvuudet, joilla on merkitystä, suurin piirtein tärkeysjärjestyksessä, ja kukin liittyy tiettyihin WCAG 2.2 -onnistumiskriteereihin.

Ilmoitukset: nimi, rooli, arvo

Vahvista jokaisesta vuorovaikutteisesta elementistä, että lukija ilmoittaa tarkan nimen (mikä se on), oikean roolin (painike, linkki, valintaruutu, välilehti) ja tarvittaessa arvon tai tilan. Tämä on WCAG 4.1.2:n (Nimi, rooli, arvo) ydin. Kuuntele erityisesti: hiljaiset ohjaimet, ohjaimet jotka ilmoitetaan vain “klikattavana” tai “ryhmänä”, kuvakepainikkeet ilman saavutettavaa nimeä, ja nimet jotka luetaan raakoina tiedostopolkuina tai luokkaniminä.

Roolit ja tilat

Tilojen on päivityttävä käyttäjän vuorovaikuttaessa. Laajenevan paljastuselementin tulee vaihtua tilasta “kutistettu” tilaan “laajennettu”; valintaruudun tulee siirtyä tilasta “ei valittu” tilaan “valittu”; lajittelupainikkeen tulee ilmoittaa nykyinen suuntansa. Staattinen merkintä, joka ei koskaan päivitä aria-expanded-, aria-checked-, aria-selected- tai aria-pressed-arvoja, on yksi yleisimmistä vioista, ja se paljastuu vasta, kun käytät komponenttia lukijan ollessa käynnissä.

Kohdistusjärjestys ja kohdistuksen hallinta

Selaa koko käyttöliittymä läpi Tab-näppäimellä. Kohdistuksen on liikuttava loogisessa, ennustettavassa järjestyksessä (WCAG 2.4.3), sen on aina oltava näkyvä, eikä se saa koskaan jäädä loukkuun paitsi tarkoituksellisesti modaali-ikkunan sisällä. Vaikeat tapaukset ovat dynaamisia: kun dialogi avautuu, kohdistuksen tulee siirtyä siihen; kun se sulkeutuu, kohdistuksen tulee palata elementtiin, joka sen avasi. Tämän ohittaminen on yleisin syy siihen, miksi modaalivirta on käyttökelvoton.

Luku- ja navigointijärjestys

Kohdistuksen lisäksi ruudunlukijan käyttäjät navigoivat rakenteen mukaan. Varmista, että otsikot muodostavat loogisen rakenteen (WCAG 1.3.1), että maamerkit (header, nav, main, footer) antavat käyttäjien hypätä ympäriinsä, ja että listat ja taulukot on merkitty niin, että lukija voi navigoida ja laskea ne. Tarkista, että lukujärjestys vastaa visuaalista tarkoitusta ja että mitään tärkeää ei ilmoiteta väärässä järjestyksessä.

Live-alueet ja dynaamiset päivitykset

Asynkronisten muutosten — vahvistusvirheiden, “3 tulosta löytyi”, “tallennetaan…”, toast-ilmoitusten — on tavoitettava käyttäjä ilman, että ne hukuttavat hänet. aria-live="polite" ei-kiireellisille päivityksille, aria-live="assertive" vain aidosti kiireellisille, ja role="status" tai role="alert" yleisiin tapauksiin. Testaa, että alue on olemassa DOM:ssa ennen sisällön muuttumista, että päivitys ilmoitetaan täsmälleen kerran, ja että se ei keskeytä käyttäjää kesken lauseen. Tämä tukee WCAG 4.1.3:a (Tilaviestit).

Mukautetut ARIA-komponentit

Kaikki, mitä olet itse rakentanut — valikot, välilehdet, yhdistelmäruudut, päivämäärävalitsimet, karusellit, dataruudukot, puunäkymät — vaatii eniten tarkkaavaisuutta. Testaa ARIA Authoring Practices -ohjeita vasten odotettua näppäimistövuorovaikutusta ja ilmoituksia varten, ja vahvista sitten, että oikeat lukijat todella käyttäytyvät niin. APG kuvaa ihanteen; lukijat toteuttavat sen epätäydellisesti, minkä vuoksi toimivakin kuvio on silti varmistettava jokaisessa lukijassa.

Konkreettinen esimerkki: saavuttamaton vs. saavutettava kytkin

Tarkastellaan asetuskytkintä. Visuaalisesti tyylitelty mutta semanttisesti tyhjä versio:

<div class="toggle" onclick="setNotifications()">
  <span class="dot"></span> Notifications
</div>

Ruudunlukijalle tämä on parhaimmillaankin pala staattista tekstiä. Roolia ei ole, joten sitä ei ilmoiteta ohjaimena; tilaa ei ole, joten käyttäjä ei voi tietää, ovatko ilmoitukset päällä vai pois; eikä se ole sarkainjärjestyksessä, joten näppäimistö- tai ruudunlukijan käyttäjä ei voi tavoittaa tai käyttää sitä lainkaan. Testattaessa NVDA lukee “Notifications” ja jatkaa eteenpäin; VoiceOver saattaa ohittaa sen kokonaan.

Saavutettava vastine käyttää natiivielementtiä ja tuo tilan esiin:

<button type="button" aria-pressed="false" id="notif">
  Notifications
</button>

const btn = document.getElementById('notif');
btn.addEventListener('click', () => {
  const on = btn.getAttribute('aria-pressed') === 'true';
  btn.setAttribute('aria-pressed', String(!on));
});

Nyt jokainen lukija ilmoittaa “Notifications, vaihtopainike, ei painettu”, se on tavoitettavissa Tabilla, käytettävissä Enterillä tai välilyönnillä, ja tila vaihtuu kuuluvasti aktivoitaessa. Opetus yleistyy: suosi natiivisemantiikkaa, ja kun sinun on käytettävä ARIA:a, testaa, että jokainen lukija todella kunnioittaa roolia ja tilaa. Tämänkaltaiset puuttuvan tilan viat kuuluvat yleisiin saavutettavuusongelmiin, joita kannattaa välttää.

Suositellut lukija- ja selainyhdistelmät

Testaa yhdistelmät, joita oikeat käyttäjät käyttävät, eivät satunnaisia pareja. Käytännöllinen matriisi, joka kattaa suuren enemmistön ruudunlukijan käyttäjistä:

NVDA + Firefox (Windows) — puhtain lähtötaso merkintäongelmien havaitsemiseen
NVDA + Chrome (Windows) — yleisin ilmaislukijan yhdistelmä käytännössä
JAWS + Chrome (Windows) — hallitseva yritys- ja julkishallintoympäristöissä
VoiceOver + Safari (macOS) — ainoa täysin tuettu pöytäkoneen VoiceOver-yhdistelmä
VoiceOver + Safari (iOS) — elepohjainen mobiili, erillinen kohde pöytäkoneesta
TalkBack + Chrome (Android) — vakio-Android-yhdistelmä

Yhdistelmillä on merkitystä, koska lukijat on viritetty tiettyjä selaimia varten; VoiceOver Chromen kanssa tai JAWS Firefoxin kanssa tuottaa käyttäytymistä, joka ei heijasta sitä, miten yleisösi todella kokee sivun. Kun analytiikkasi näyttää tietyn yleisön — vaikkapa julkisen sektorin tuotteen, jossa JAWS:ia käytetään paljon, tai kuluttajasovelluksen, joka painottuu mobiiliin — painota matriisia sen mukaisesti. Ruudunlukija-arviointipalvelumme virittää tämän matriisin kunkin asiakkaan analytiikkaan kiinteän listan testaamisen sijaan.

Yleisiä sudenkuoppia

Jopa huolelliset tiimit kompastuvat samoihin asioihin. Varo näitä:

Testaaminen silmät auki. Jos näet näytön, kompensoit alitajuisesti sitä, mitä lukija ei kerro sinulle. Sammuta näyttö tai ainakin katso pois, ja navigoi pelkän äänen avulla.
Vain yhden lukijan testaaminen. Käsitelty edellä — se on suurin yksittäinen väärän luottamuksen lähde.
Lomake-/kohdistustilan ohittaminen. NVDA:ssa ja JAWS:ssa mukautetut komponentit vaativat usein, että käyttäjä on oikeassa tilassa. Jos testaat vain selaustilassa, jäävät huomaamatta vuorovaikutukset, jotka rikkoutuvat kohdistustilassa.
aria-label:n liikakäyttö. ARIA-otsikoiden lisääminen kaikkialle voi ohittaa näkyvän tekstin, irrottaa saavutettavan nimen näytetystä, ja hämmentää ääniohjauksen käyttäjiä. Suosi natiivimerkintää; tartu ARIA:an vain, kun HTML ei voi ilmaista suhdetta.
Olettaminen, että APG takaa onnistumisen. ARIA Authoring Practices kuvaa tarkoitettua käyttäytymistä, ei sitä, mitä jokainen lukija tekee. Varmista aina oikeita lukijoita vasten.
Overlay-komponenttien luottaminen. Overlay- ja “tekoälysaavutettavuus”-komponentit, jotka väittävät korjaavansa ruudunlukijan pääsyn ajonaikaisesti, eivät tarjoa luotettavaa kokemusta ja tekevät navigoinnista usein huonomman juuri niille ihmisille, joita ne väittävät auttavansa. Saavutettavalle merkinnälle, joka on vahvistettu oikealla testauksella, ei ole korvaajaa. Auditoi todellinen DOM ja ilmoitukset, älä overlayn markkinointia.
Mobiilin kohteleminen jälkiajatuksena. iOS:n VoiceOver ja Androidin TalkBack tuovat esiin omat ele-, kohdistus- ja live-alueongelmansa, joita pöytäkonetestaus ei koskaan paljasta.

Miksi vammaisten ihmisten tekemä testaus tuo lisäarvoa

Lukijan ajaminen itse löytää paljon — mutta teknisen läpäisyn ja aidosti käyttökelpoisen välillä on merkityksellinen ero, ja juuri siinä erossa kokemusperäisellä asiantuntemuksella on eniten merkitystä. Päivittäinen ruudunlukijan käyttäjä navigoi refleksinomaisesti: hän liikkuu otsikoittain, selailee roottorilla, tunnistaa, kun ilmoitus on pitkäveteinen tai tarpeeton, ja aistii välittömästi, kun virta pakottaa hänet tehottomalle polulle, vaikka jokainen yksittäinen elementti olisi “vaatimustenmukainen”.

Ensimmäistä kertaa testaava näkevä kehittäjä pyrkii varmistamaan läsnäolon — “painike ilmoitetaan” — kun taas asiantuntijakäyttäjä arvioi kokemuksen — “painike ilmoitetaan, mutta otsikko on epäselvä, vahvistusta ei puhuta, ja tänne pääseminen vaati kaksitoista ylimääräistä pyyhkäisyä”. Nuo käytettävyyshavainnot esiintyvät harvoin vaatimustenmukaisuuden tarkistuslistassa, ja silti juuri ne ratkaisevat, voiko joku todella suorittaa tehtävän. Tämän vuoksi QualiBooth yhdistää automaattisen saavutettavuuden skannausohjelmiston ja saavutettavuustyökalupakkimme vammaisten ihmisten tekemiin auditointeihin: työkalut löytävät ilmeisen, asiantuntijat löytävät sen, mikä todella rikkoo kokemuksen. Usein muuttuville tuotteille toistuvat saavutettavuusauditoinnit pitävät tuon kattavuuden ajantasaisena julkaisujen välillä.

Mihin ruudunlukijoiden testaus sopii ohjelmassasi

Ruudunlukijoiden testaus on yksi tieteenala laajemman käytännön sisällä. Se sopii luontevasti yhteen pelkän näppäimistön testauksen ja niiden mukautuvien verkkotyökalujen kanssa, joihin käyttäjäsi luottavat, ja se tuottaa sellaista näyttöä, joka tukee oikeudellisia velvoitteita EAA:n, ADA:n ja Section 508:n mukaisesti. Havainnot syöttävät myös suoraan dokumentaatiota: tiimimme kääntää lukijakohtaiset tulokset VPAT-raporteiksi ja priorisoiduiksi korjaussuunnitelmiksi, jotka toimitamme saavutettavuuskonsultoinnin kautta. Jos rakennat pitkäaikaista ohjelmaa kertaluonteisen tarkistuksen sijaan, juuri tuo integraatio estää saavutettavuutta taantumasta.

Yhteenveto

Ruudunlukijat eivät ole keskenään vaihdettavissa, eikä puhdas automaattinen raportti ole käyttökelpoinen tuote. NVDA, JAWS, VoiceOver ja TalkBack tulkitsevat kukin merkintäsi eri tavalla, sopivat yhteen eri selainten kanssa ja paljastavat eri vikoja — joten testaaminen niiden todellisten yhdistelmien yli, joita yleisösi käyttää, on ainoa tapa olla varma. Jäsennä testauksesi ilmoitusten, roolien ja tilojen, kohdistuksen, lukujärjestyksen, live-alueiden ja mukautettujen komponenttien ympärille; suosi natiivisemantiikkaa ARIA-paikkausten sijaan; jätä overlayt huomiotta; ja anna aina kun mahdollista niiden ihmisten, jotka käyttävät näitä työkaluja päivittäin, kertoa sinulle, mikä todella toimii.

Kun haluat tuon varmuuden asiantuntijoiden vahvistamana, QualiBoothin ruudunlukija-arviointi testaa kaikkien suurten lukijoiden yli ja palauttaa havainnot tarkkojen merkintäkorjausten kera. Voit myös aloittaa ilmaisella skannauksella tai pyytää esittelyä nähdäksesi, missä käyttöliittymäsi on tänään.

UKK

Kuinka monta ruudunlukijaa minun todella tarvitsee testata?

Testaa vähintään NVDA, JAWS ja VoiceOver pöytäkoneella, sekä VoiceOver iOS:ssä ja TalkBack Androidissa, jos toimitat mobiilikokemuksen. Vähempien testaaminen jättää sokeita pisteitä, koska lukijat eroavat toisistaan siinä, miten ne käsittelevät ARIA:a ja dynaamista sisältöä.

Voivatko automaattiset työkalut korvata ruudunlukijoiden testauksen?

Eivät. Automaattiset työkalut löytävät luotettavasti vain osan ongelmista — puuttuvan alt-tekstin, jotkin kontrastiongelmat, tietyt rakenteelliset virheet — mutta ne eivät voi arvioida, onko ilmoitus selkeä, liikkuuko kohdistus järkevästi, vai onko tehtävä todella suoritettavissa pelkän äänen avulla. Nämä vaativat oikean lukijan ja, mieluiten, oikean käyttäjän.

Poistavatko overlay- tai “tekoälysaavutettavuus”-komponentit testauksen tarpeen?

Eivät. Overlayt eivät tuota luotettavaa ruudunlukijakokemusta ja tuovat usein mukanaan uusia ongelmia. Kestävä korjaus on saavutettava merkintä, joka on vahvistettu oikealla lukijatestauksella, ja juuri sitä ruudunlukija-arviointipalvelumme tarjoaa.

Mitä WCAG-kriteerejä ruudunlukijoiden testaus kattaa?

Se tukee suoraan kriteerejä 1.3.1 (Tieto ja suhteet), 2.4.3 (Kohdistusjärjestys), 4.1.2 (Nimi, rooli, arvo) ja 4.1.3 (Tilaviestit) muiden ohella. Jokainen jäsennellystä arvioinnista saatu havainto voidaan kytkeä relevanttiin WCAG 2.2 -onnistumiskriteeriin.