Lähes jokainen auditoimamme saavutettavuusohjelma raportoi saman luvun: yli yhdeksänkymmentä prosenttia frontend-kehittäjistä sanoo “testaavansa ruudunlukuohjelmalla”. Pyydä heitä näyttämään, ja demo on yleensä sama kolme näppäinpainallusta — käynnistä, selaa sivua tabilla, sammuta. Se ei ole testaamista. Se on rastin laittamista ruutuun.

Tämä tapahtuu rakenteellisista syistä, ei laiskuudesta. Ruudunlukuohjelma ei ole työkalu, jonka voi ottaa käyttöön samoin kuin uuden lintterin. Se on erilainen vuorovaikutusmalli, jolla on oma modaalinen tilansa, oma pikanäppäinkielioppinsa ja joukko käytäntöjä, jotka alkavat olla mielekkäitä vasta useiden todellisen työn tuntien jälkeen. Ennen kuin ylität tuon kynnyksen, työkalu kertoo sinulle lähes mitään — ja mikä pahempaa, se kertoo sinulle vääriä asioita, koska kuulemasi ilmoitukset riippuvat lukijan tilasta, selaimen saavutettavuuspuusta ja alustan IME-kerroksesta tavoilla, jotka eivät ole ilmeisiä ulkopuolelta.

Sujuvuus tarkoittaa tässä yhteydessä pistettä, jossa voit antaa kollegalle rikkinäisen komponentin, ottaa heidän näppäimistönsä ja toistaa virheen ruudunlukuohjelman ollessa käynnissä — katsomatta näyttöä, viittaamatta huijauslappuun ja tekemättä ilmoitusta huonommaksi kuin se olisi oikeassa käytössä. Tuttuus on piste, jossa olet kuullut ruudunlukuohjelman. Näiden kahden välinen ero on suunnilleen kolmekymmentä tai kolmekymmentäviisi tuntia tietoista harjoittelua.

Markkinoilla on kolme ruudunlukuohjelmaa, joilla on merkitystä desktop-verkkokehityksessä: NVDA Windowsilla, VoiceOver macOS:ssä ja iOS:ssä sekä JAWS Windowsilla. Jokaisella on riittävän suuri käyttäjäkunta, ettei sen sivuuttaminen olisi neutraali valinta, ja jokainen ilmoittaa saman merkinnän hieman eri tavalla. Sujuva kehittäjä osaa ajaa vähintään kahta niistä.

Suosituksemme, seurattuamme kymmeniä kehittäjiä kynnyksen ylittäessä, on yksiselitteinen: aloita NVDA:lla Windowsilla ja VoiceOverilla macOS:ssä. Molemmat ovat ilmaisia. Molemmat ovat esiasennettuja (VoiceOver) tai asennettavissa alle viidessä minuutissa (NVDA). Molempia käyttää riittävästi oikeita käyttäjiä — NVDA:lla on approx. 65 % Windowsin ruudunlukuohjelmien markkinaosuudesta tuoreimmassa WebAIM-kyselyssä, VoiceOver hallitsee mobiilia ja merkittävää osaa macOS:stä — että oppimasi siirtyy välittömästi virheisiin, joihin voit toimittaa korjauksen. JAWS on kolmas työkalu, ei ensimmäinen, vaikka sillä onkin edelleen suurin yritysasennuskanta. Kolme syytä.

Kolme syytä jättää JAWS alkuvaiheessa sivuun ovat pedagogisia, eivät poliittisia. Ensiksi JAWS ja NVDA jakavat saman mentaalimallin — Windowsin selaustila vs. kohdistustila, sama Insert-pohjainen komentojen etuliite, sama virtuaalipuskuri — joten kun olet oppinut ajamaan NVDA:ta, yhdeksänkymmentä prosenttia JAWS-komennoista, joita oikeasti tarvitset, löytyy sanastohakuna. Toiseksi JAWS on kertynyt vuosikymmenien “älykäs” päättely: se yrittää korjata huonon merkinnän ennen kuin käyttäjä kuulee sen, mikä tarkoittaa, että JAWS:n peittämä virhe toimitetaan silti NVDA-käyttäjille. NVDA:n tarkoituksellisen konservatiivinen käyttäytyminen tekee siitä paremman referenssilukijan kun yrität oppia, mikä on rikki. Kolmanneksi JAWS:n lisenssihankala — aktivointi, neljänkymmenen minuutin kokeilutila, joka muistuttaa joka uudelleenkäynnistyksen yhteydessä — on oppimisrasitus, jota sinun ei tarvitse maksaa ennen kuin olet riittävän varma käyttämään sen.

VoiceOver paritetaan NVDA:n kanssa eikä kilpaile sen kanssa, koska kaksi lukijaa edustaa kahta hallitsevaa vuorovaikutusmallia. NVDA (ja JAWS) käyttää “PC-kohdistin”-mallia: virtuaalipuskuri, joka esittää sivun lineaarisena dokumenttina, ja erillinen kohdistus, joka seuraa sarkkausjärjestystä. VoiceOver käyttää yhtä VoiceOver-kohdistinta, joka on kohdistuksen päällä ja navigoidaan roottorin ja VO+nuolinäppäinten avulla. Kehittäjä, joka on sujuva vain yhdessä mallissa, kirjoittaa koodia, joka kuulostaa hyvältä omassa lukijassaan ja huonolta toisessa. Molempien oppiminen samanaikaisesti on ainoa luotettava tapa tuntea ero.

Ensimmäisen viikon ohjelmalla on yksi sääntö: sammuta näyttö. Ei himmennetty, ei minimoitu, ei “sulken silmäni” — fyysisesti pois päältä tai peitettynä pahvinpalalla jos näyttösi on huoneen ainoa. Tarkoitus on poistaa huijaamisen mahdollisuus. Näkevän kehittäjän vaisto, heti kun ruudunlukuohjelma sanoo jotain hämmentävää, on katsoa näyttöä ja ratkaista epäselvyys visuaalisesti. Tuo vaisto on suurin yksittäinen syy siihen, miksi “testasin ruudunlukuohjelmalla” ei nappaa oikeita virheitä.

Suunnittele ensimmäiselle viikolle kolme noin yhdeksänkymmenen minuutin istuntoa, vähintään päivän välein, jotta lihastottumuksella on aikaa vakiintua. Jokaisella istunnolla on yksi tehtävä. Ensimmäinen rakentaa perusnäppäinkielen. Toinen pakottaa todelliseen vuorovaikutukseen. Kolmas testaa pysyvyyttä pienen paineen alla.

Toisen ja neljännen viikon harjoittelun pitäisi kertyä noin kaksikymmentä tuntia — kaksi yhdeksänkymmenen minuutin istuntoa viikossa sekä pieni määrä satunnaiskäyttöä päivätyön ohessa. Tämän jakson tavoite on sisäistää kaksi asiaa, jotka hämmentävät uusia ruudunlukuohjelmien käyttäjiä enemmän kuin mikään muu: ero selaustilan ja kohdistustilan välillä sekä ero sen välillä, mitä roottori näkee ja mitä sarkkausjärjestys näkee.

Yleisin hämmennys toisella viikolla on hetki, jona kehittäjä painaa NVDA:ssa nuolinäppäintä, odottaa virtuaalipuskurin liikkuvan, ja kuulee sen sijaan kohdistuneen yhdistelmälaatikon avaavan vaihtoehtoluettelonsa. Tällöin selaustila vaihtuu automaattisesti kohdistustilaan, koska kohdistus on laskeutunut elementille, jonka NVDA luokittelee “sovellus”-widgetiksi. Uudet kehittäjät kokevat tämän lukijan virhetoimintana. Se ei ole sitä — lukija tekee täsmälleen mitä spesifikaatio pyytää. Kun olet kuullut tämän kymmenen tai viisitoista kertaa, se ei enää yllätä; siihen asti, suunnittele yllättyväsi suunnilleen joka toisessa istunnossa.

Kolmannen viikon kaava on lomakkeet. Rakenna yksityinen testisivu kahdeksalla tai kymmenellä hallinnalla: pakollinen tekstikenttä inline-virheilmoituksella, päivämäärän valitsin, monivalinta, mukautettu tyylitelty valintaruutu, poistettu painike josta tulee aktiivinen, “näytä salasana” -vaihdin, puhelinnumerokenttä maakoodin valitsimella ja lähetys-painike, joka käynnistää palvelinpuolen validointiyhteenvedon. Näyttö pois, navigoi läpi viisi kertaa — ensin NVDA selaustilassa, sitten NVDA kohdistustilassa, sitten NVDA uudelleen ääniohjelman ilmoitusasetus nostettu (Insert+Z, lisää tästä viidennessä osiossa), sitten VoiceOver roottorin kanssa ja sitten VoiceOver ilman roottoria. Sama lomake kuulostaa erilaiselta viisi kertaa. Siltä sujuvuus tuntuu sisältäpäin: huomaat, että sama merkintä kertoo viisi eri tarinaa, ja pystyt ennustamaan etukäteen, mikä niistä soi.

Neljäs viikko on navigointi. Ota todellinen, monimutkainen sivusto — dokumentaatioportaali, työn hallintapaneeli, verkkokaupan kategoriasivu — ja yritä löytää tietty tieto käyttämällä vain ruudunlukuohjelman pikanäppäimiä. Käytä H otsikoiden välillä hyppimiseen. Käytä D (NVDA) tai VO+U ja “Maamerkit” (VoiceOver) maamerkissä hyppimiseen. Käytä 1–6 tiettyyn otsikkotasoon hyppimiseen. Neljännen viikon loppuun mennessä navigointipikanäppäinten pitäisi olla refleksejä eikä valintoja, samoin kuin tab ja shift-tab jo ovat.

Kun käyttäjätilan komennot ovat refleksejä, seuraava harppaus on kunkin lukijan kehittäjille suunnattuihin pintoihin. Nämä ovat tilat ja pikanäppäimet, jotka manuaalit hautaavat — osittain koska ne on suunnattu kehittäjille, osittain koska ne ovat niin äänekäs, että päivittäinen käyttäjä ei haluaisi niitä päällä. Kolme on syytä oppia heti.

Kaksi lisäkäytäntöä säästää enemmän aikaa kuin mikään yksittäinen pikanäppäin. Ensiksi, kiinnitä NVDA:n puheentarkkailija toiselle näytölle (tai yhden näyttösi kulmaan) kehityksen aikana. Sanasanainen loki jokaisesta ilmoituksesta on ruudunlukutyölle sitä, mitä kehitystyökalujen konsoli on JavaScriptille: ero arvaamisen ja tietämisen välillä. Toiseksi, oppi lukemaan saavutettavuuspuuta selaimesi kehitystyökaluissa — Chromen Accessibility-ruutu, Firefoxin Accessibility Inspector, Safarin Audit-välilehti. Lukija ilmoittaa mitä saavutettavuuspuu sisältää, ei mitä DOM sisältää, ja nämä kaksi poikkeavat riittävän usein, ettet voi debugata live-alueita, ARIAa tai shadow DOMia lukematta puuta suoraan.

Hämmennys on syytä merkitä nyt, koska se syö tunteja toisella ja kolmannella viikolla: lukutila vs. kohdistustila ei ole sama akseli kuin “sivu on interaktiivinen” vs. “sivu on dokumentti.” NVDA vaihtaa automaattisesti kohdistustilaan kun kohdistus laskeutuu hallinnalle, jolla on role=“application”, tai contenteditable-elementille, tai tietyille mukautetuille widgeteille, jotka lukija heuristisesti luokittelee interaktiivisiksi — riippumatta siitä, onko sivu enimmäkseen staattinen. Vastaavasti rikaslisäinen yksisivuinen sovellus, jonka juurielementti on main-maamerki ja jonka widgetit ovat hyvin merkittyjä natiivipainikkeita, pysyy selaustilassa lähes koko käyttäjäistunnon ajan. Tila on kohdistetun elementin ominaisuus, ei sivun ominaisuus.

Alla olevat luvut perustuvat noin kahdeksankymmenen kehittäjän epäviralliseen seurantaan — frontend-insinööreihin, laadunvarmistusvetäjiin, saavutettavuusasiantuntijoihin koulutuksessa — kolmen vuoden yritystyöpajoissa ja henkilökohtaisessa mentoroinnissa. Ne eivät ole tutkimus. Ne ovat riittävän hyviä suunnittelun pohjaksi. Kaksi oletusta: tietoinen harjoittelu (näyttö pois, todelliset tehtävät, ei “NVDA käynnissä taustalla kun koodaan”), ja kiinteä lukijayhdistelmä (NVDA Windowsilla ja VoiceOver macOS:ssä).

”Osittainen sujuvuus” on realistinen kohde useimmille näkeville kehittäjille ja on käytännössä kaikki mitä tarvitaan ollakseen hyvä saavutettavan tuotteen tekijä. Aito sujuvuus — taso, jolla voisi mahdollisesti korvata päivittäisen ruudunlukuohjelman käyttäjän käytettävyystarkastelun aikana — on pikemminkin sataviisikymmentä tuntia ja vuosi satunnaista harjoittelua, eikä useimmat työskentelevät kehittäjät tarvitse sitä. Tähtää osittaiseen sujuvuuteen, aikatauluta neljäkymmentä tuntia ja hyväksy, että kaiken sen tuolle puolelle jäävä tulee tekemällä päivätyötä lukija käynnissä ja halulla hidastaa tahtia.

Yksi viimeinen vertailuarvo asettamaan odotukset rehellisesti: kehittäjät, jotka tasaantuvat, tasaantuvat kokemuksemme mukaan kymmenen ja kahdenkymmenen tunnin välillä. Syy on lähes aina sama — he lakkaavat sammuttamasta näyttöä. He vakuuttavat itselleen olevansa nyt “riittävän hyviä” testaamaan näyttö päällä, ruudunlukuohjelma taustalla käynnissä ja visuaalinen vahvistus saatavilla aina kun ääni on epäselvä. He eivät ole. Kuusitoista tuntia “käyttökelpoisen” ja “mukavan” välillä vaativat näytön pois päältä, koska juuri siinä vaiheessa lukijan ilmoitukset muuttuvat informaatioksi melun sijaan. Ilman tuota painetta aivot palaavat visuaaliseen ja lukijan ääni katoaa taustahuminaan. Jos löydät itsesi hidastumasta, syy on lähes aina näyttö.

Syy siihen, miksi “testaa ruudunlukuohjelmalla” tuottaa niin heikkoja tuloksia koko alalla, ei ole se, että työkalu olisi vaikea oppia — neljäkymmentä tuntia ei todellakaan ole paljon — vaan se, että oppiminen on epämukavaa tietyllä tavalla. Näytön sammuttaminen saa näkevän kehittäjän tuntemaan itsensä kyvyttömäksi tavalla, joka on epätavallinen ammatissamme. Olemme tottuneet olemaan ihmisiä, jotka selvittävät asiat; ruudunlukuohjelma tekee meistä, muutaman tunnin ajan kerrallaan, aloittelijoita uudelleen. Se epämukavuus, eivät näppäinpainallukset, on varsinainen este.

Polku eteenpäin on edellä kuvattu: NVDA ja VoiceOver, kolme istuntoa ensimmäisellä viikolla näyttö pois, lomakkeet ja tilat viikoilla kaksi–neljä, kehittäjätilan pikanäppäimet heti kun käyttäjätilan pikanäppäimet ovat refleksejä, neljäkymmentä tuntia yhteensä ennen kuin voidaan luottaa vakavaan julkaisuedeltävään läpikäyntiin. Mikään tästä ei ole uutta. Työ, jota ala ei ole tehnyt, on sen kohteleminen työnä — tuntien aikatauluttaminen, niiden puolustaminen muilta sitoumuksilta, hyväksyminen, että ensimmäiset kymmenen tuntia tuntuvat hyödyttömiltä kunnes äkkiä eivät tunnu.

Jos julkaiset frontendiä, noiden neljänkymmenen tunnin tuolla puolella oleva sinä on huomattavasti parempi insinööri kuin lähtöpisteessä ollut, tavoilla, jotka näkyvät paitsi saavutettavuustyössäsi myös ymmärryksessäsi kohdistusjärjestyksestä, progressiivisesta parannuksesta ja siitä, mitä selain oikeasti tekee pinnan alla. Ruudunlukuohjelma on halvin hajautettujen järjestelmien oppitunti kenellä tahansa verkolle kirjoittavalle. Hinta on näyttö pois ja muutama viikonloppu.