Tekstistä puheeksi vs. ruudunlukuohjelmat

Sisällölläsi on ääni

Tekstistä puheeksi (TTS) -tekniikka muuntaa kirjoitetun tiedon ääneksi. Se auttaa sokeita, näkövammaisia sekä lukihäiriöstä ja ADHD:sta kärsiviä ihmisiä kuluttamaan sisältöä heille sopivalla tavalla. TTS:ää käytetään myös laajasti kouluissa, kielten opiskelijoiden keskuudessa ja ammattilaisten parissa, jotka oikolukevat korvalla silmän sijaan.

Koska sekä TTS että ruudunlukuohjelmat tuottavat synteettisen äänen, ihmiset olettavat usein niiden olevan sama asia — tai että “lue ääneen” -painikkeen lisääminen verkkosivustolle tekee siitä saavutettavan sokeille käyttäjille. Tämä oletus on väärä, ja sen mukaan toimiminen voi jättää sinulle sivuston, joka kuulostaa saavutettavalta mutta jota monien on mahdotonta käyttää käytännössä. Tässä artikkelissa selitetään, miten kukin tekniikka toimii, kuka siihen luottaa, missä raja niiden välillä todella kulkee ja mitä ruudunlukuohjelmille rakentaminen kunnolla vaatii. Jos muistat vain yhden asian, muista tämä: lue ääneen -widget on mukavuusominaisuus, ei saavutettavuusominaisuus.

Miten TTS toimii?

TTS käsittelee tekstin kolmessa laajassa vaiheessa:

Tekstianalyysi — sävyn, kieliopin ja rakenteen määrittäminen, numeroiden ja symbolien avaaminen (“$5” muuttuu muotoon “viisi dollaria”) ja lauseiden segmentointi.
Kielellinen käsittely — ääntämyksen, painotuksen ja korostuksen laskeminen, usein ääntämyssanakirjaa sekä tuntemattomien sanojen sääntöjä käyttäen.
Äänisynteesi — puheen tuottaminen matemaattisista äänimalleista, yhä useammin neuroverkkojen avulla, jotka kuulostavat huomattavasti luonnollisemmilta kuin vanhemmat ketjuttavat moottorit.

Nykyaikaiset järjestelmät tarjoavat äänen mukauttamista, kuten nopeuden, sävelkorkeuden, äänipersoonan ja kielen valinnan. Ratkaiseva seikka on se, mitä TTS ottaa syötteeksi: tekstilohkon, jonka joku on jo valinnut, liittänyt tai osoittanut sille. TTS on pohjimmiltaan sisältö ulos -tekniikka. Se puhuu sen, mitä sille annetaan. Se ei tutki käyttöliittymää, eikä sillä ole käsitystä painikkeista, lomakekentistä tai sivun rakenteesta.

Mitä rajoituksia TTS-tekniikalla on?

TTS on aidosti hyödyllinen, mutta se ei ole täydellinen, ja sen rajat ovat merkityksellisiä tulevan vertailun kannalta:

Ääntämyspuutteet — se voi ääntää väärin harvinaisia sanoja, erisnimiä, lääketieteellisiä tai juridisia termejä sekä lyhenteitä.
Epätasainen kielituki — monet työkalut käsittelevät valtavirran kieliä hyvin mutta kamppailevat harvinaisempien kielten ja alueellisten murteiden kanssa.
Sävy ja vivahteet — TTS:llä on vaikeuksia sarkasmin, huumorin ja idiomaattisten ilmaisujen kanssa, joten sisältö voidaan välittää väärällä sävyllä.
Ei vuorovaikutusmallia — ja tämä on se suuri asia: TTS lukee; se ei anna sinun tehdä mitään. Et voi täyttää kassalomaketta, sulkea modaalia tai siirtyä valikkokohteiden välillä pelkällä TTS:llä.

Juuri viimeinen rajoitus on se, mistä sekaannus ruudunlukuohjelmien kanssa alkaa.

Mitä eroa on tekstistä puheeksi -tekniikalla ja ruudunlukuohjelmatekniikalla?

Tässä syntyy yleinen väärinkäsitys. Tekstistä puheeksi lukee tekstiä ääneen — se on sen ensisijainen tehtävä. Ruudunlukuohjelma tekee paljon enemmän: se mahdollistaa käyttäjien navigoida ja käyttää koko tietokonetta tai mobiililaitetta korvalla ja näppäimistöllä (tai kosketuseleillä).

Ruudunlukuohjelmat ilmoittavat käyttöliittymän nimiöt, lomakekentät, painikkeet ja linkit; ne lukevat kuvien tekstivastineet, jotta käyttäjät ymmärtävät visuaalisen sisällön; ja ne tuovat esiin komponenttien tilan — onko valintaruutu valittu, onko valikko laajennettu, onko välilehti valittu vai onko virhe ilmestynyt. Ne muuttavat visuaalisen, hiirellä ohjattavan käyttöliittymän lineaariseksi, kuultavaksi ja käytettäväksi käyttöliittymäksi.

Nopea tapa tuntea ero: TTS vastaa kysymykseen “Mitä tässä kappaleessa sanotaan?” Ruudunlukuohjelma vastaa kysymykseen “Missä olen, mitä voin tehdä täällä ja mitä juuri tapahtui?” Ensimmäinen koskee sisällön kuluttamista. Toinen koskee ohjelmiston hallintaa.

Miten ruudunlukuohjelman käyttäjä todella liikkuu sivulla

Näkevät käyttäjät silmäilevät sivun sekunneissa. Ruudunlukuohjelman käyttäjä rakentaa mielikuvan peräkkäin ja luottaa rakenteeseen liikkuakseen tehokkaasti. Käytännössä he:

Hyppäävät otsikoiden välillä ymmärtääkseen sivun rakenteen (siksi oikea otsikkohierarkia on niin tärkeää).
Avaavat luettelon kaikista linkeistä tai kaikista lomakekentistä navigoidakseen maamerkkien mukaan sen sijaan, että lukisivat ylhäältä alas.
Käyttävät maamerkkialueita (banneri, navigointi, pääsisältö, alatunniste) hypätäkseen suoraan haluamaansa sisältöön.
Liikkuvat interaktiivisten elementtien läpi sarkainnäppäimellä ja odottavat kohdistuksen laskeutuvan johonkin näkyvään ja loogiseen.
Kuuntelevat reaaliaikaisia ilmoituksia, kun jokin muuttuu ilman koko sivun uudelleenlatausta.

Mikään tästä ei toimi, ellei taustalla oleva merkintä kuvaa sivua rehellisesti. “Lue ääneen” -ominaisuus ei tarjoa mitään näistä navigointimahdollisuuksista — se vain kertoo, mitä tekstiä näytöllä on, visuaalisessa järjestyksessä, ilman mahdollisuutta käyttää säätimiä.

Kuka kumpaakin käyttää, ja miksi sillä on merkitystä

TTS:ää käyttää laaja yleisö, usein tilannekohtaisesti: lukihäiriöiset, ADHD:sta tai heikkonäköisyydestä kärsivät; moniajajat; kielten opiskelijat; ja kuka tahansa, joka yksinkertaisesti pitää kuuntelusta. Useimmat näistä käyttäjistä voivat edelleen nähdä näytön ja käyttää hiirtä.

Ruudunlukuohjelman käyttäjiin kuuluu sokeita tai vakavasti näkövammaisia ihmisiä sekä joitakin kognitiivisesti tai motorisesti vammaisia ihmisiä, jotka ovat riippuvaisia tekniikasta voidakseen ylipäätään käyttää laitetta. Heille se ei ole mieltymyskerros käytettävän käyttöliittymän päällä — se on käyttöliittymä. Yleisimmät työkalut ovat NVDA ja JAWS Windowsissa, VoiceOver Applen laitteissa ja TalkBack Androidissa. Kukin tulkitsee saman verkkosivun hieman eri tavalla, mikä on yksi syy siihen, miksi testaaminen niiden kaikilla on tärkeää.

Miksi lue ääneen -widgetit eivät korvaa saavutettavuutta

Kasvava määrä verkkosivustoja kiinnittää sivuilleen “kuuntele tämä sivu” -painikkeen tai kolmannen osapuolen widgetin, joka korostaa ja puhuu tekstiä. Nämä työkalut voivat auttaa joitakin lukijoita, eikä sellaisen tarjoamisessa mukavuutena ole mitään väärää. Ongelma on sen kohteleminen aidon ruudunlukuohjelmatuen korvaajana. Se ei sitä ole, useista konkreettisista syistä.

Ne vain lukevat; ne eivät käytä. Lue ääneen -widget kertoo hinnoittelutaulukkosi, mutta se ei voi antaa sokean käyttäjän valita tilausta, avata ostoskoria, syöttää maksutietoja ja saattaa ostosta loppuun. Todelliset tehtävät vaativat käytettäviä säätimiä, eivät kerrontaa.
Ne eivät voi tuoda esiin tilaa tai rooleja. Onko painike painettu, onko kenttä pakollinen, onko osio kutistettu vai ilmestyikö juuri virheilmoitus — mitään tästä ei välitetä lukemalla näkyvää tekstiä. Ruudunlukuohjelmat luottavat merkinnän rooleihin, nimiin ja tiloihin ilmoittaakseen siitä.
Ruudunlukuohjelman käyttäjillä on jo työkalu. Sokeat käyttäjät tuovat oman ruudunlukuohjelmansa, hienosäädetyn heidän mieltymyksiinsä ja lihasmuistiinsa. Sivutason widget kilpailee sen kanssa, joskus häiritsee sitä, eikä tee mitään korjatakseen virheellistä merkintää, johon heidän ruudunlukuohjelmansa kompastuu.
Ne peittävät ongelmia sen sijaan, että korjaisivat ne. Jos lomakekentällä ei ole nimiötä, widget ohittaa sen aivan kuten ruudunlukuohjelma tekisi — mutta nyt puuttuva nimiö on piilotettu hyödylliseltä näyttävän ominaisuuden taakse. Taustalla oleva vika säilyy.

Sama logiikka pätee, vieläkin voimakkaammin, niin sanottuihin saavutettavuusylityksiin (overlay) — skripteihin, jotka lupaavat välitöntä vaatimustenmukaisuutta kerrostamalla automaattisia korjauksia ja työkalupalkin olemassa olevan sivuston päälle. Ne eivät korjaa taustalla olevaa koodia, ne ovat usein ristiriidassa käyttäjien oman apuvälineteknologian kanssa, eivätkä ne voi tuottaa aitoa vaatimustenmukaisuutta. Luotettava tie on korjata lähde. Saadaksesi kattavamman selityksen siitä, miksi pintatason korjaukset jäävät vajaiksi, katso oppaamme aidosta digitaalisesta saavutettavuudesta.

Konkreettinen esimerkki: kassa, joka “puhuu”

Kuvittele verkkokauppa, joka on lisännyt lue ääneen -widgetin ja on varma, että sivusto on nyt saavutettava. Sokea asiakas saapuu oma ruudunlukuohjelmansa käynnissä. Tuotekuvaus luetaan hyvin — se osa on vain tekstiä. Mutta “Lisää ostoskoriin” -säädin on muotoiltu div, jossa on klikkauskäsittelijä oikean painikkeen sijaan, joten ruudunlukuohjelma ei koskaan ilmoita sitä painikkeena eikä näppäimistö pääse siihen. Määränvalitsin päivittää summan ilman reaaliaikaista aluetta, joten muutos on äänetön. Alennuskoodikentällä on paikkamerkkiteksti mutta ei siihen liitettyä nimiötä, joten se ilmoitetaan vain muodossa “muokkaa tekstiä”. Toimituslomake näyttää visuaalisesti punaisen virheen, mutta virhettä ei ole liitetty kenttään eikä sitä ilmoiteta lainkaan. Lue ääneen -widget kertoo iloisesti näkyvän tekstin eikä muuta tästä mitään. Asiakas voi kuulla markkinointitekstin mutta ei voi saattaa ostosta loppuun. Tuo kuilu — sisällön kuulemisen ja tuotteen käyttämisen välillä — on koko ero mukavuusominaisuuden ja saavutettavuuden välillä.

Mitä ruudunlukuohjelmille rakentaminen todella vaatii

Ruudunlukuohjelmien tukeminen ei ole ominaisuuden lisäämistä — kyse on sivujesi rakentamisesta niin, että merkitys, rakenne ja toiminta ovat ohjelmiston saatavilla, ei vain ihmissilmän. Keskeiset ainekset:

Semanttinen, jäsennelty HTML

Käytä oikeita otsikoita (h1–h6) loogisessa järjestyksessä, natiiveja painikkeita ja linkkejä oikeisiin tarkoituksiin, luetteloita luetteloille ja maamerkkielementtejä sivun alueille. Semanttinen HTML kantaa saavutettavuustietoa ilmaiseksi; muuri yleisluonteisia säiliöitä ei kanna mitään.

Tekstivastineet ei-tekstuaaliselle sisällölle

Jokainen merkityksellinen kuva tarvitsee tarkan tekstivastineen, ja koristekuvat tulisi merkitä niin, että ne ohitetaan. Painikkeina toimivat kuvakkeet tarvitsevat saavutettavat nimet. Kaaviot ja infografiikat tarvitsevat tekstivastineen, joka välittää saman tiedon.

Saavutettavat nimet, roolit ja tilat

Lomakekentät tarvitsevat ohjelmallisesti liitetyt nimiöt. Mukautetut komponentit — välilehdet, haitarit, yhdistelmäruudut, modaalit — tarvitsevat oikeat roolit ja tilat, jotta ruudunlukuohjelma ilmoittaa, mitä ne ovat ja miten ne käyttäytyvät. Siellä missä natiivi HTML ei riitä, ARIA täyttää aukon, mutta sitä on käytettävä täsmällisesti; virheellinen ARIA on huonompi kuin ei mitään.

Näppäimistökäytettävyys ja kohdistuksen hallinta

Kaiken mikä toimii hiirellä, on toimittava näppäimistöllä, kohdistusjärjestyksen on oltava looginen, kohdistuksen ilmaisimen on oltava näkyvä ja dynaamisten muutosten (valintaikkunan avaaminen, virheen paljastaminen) on siirrettävä tai ilmoitettava kohdistus asianmukaisesti. Näppäimistötuki ja ruudunlukuohjelmatuki ovat syvästi kietoutuneet toisiinsa.

Dynaamisten muutosten ilmoittaminen

Kun sisältö päivittyy ilman sivun uudelleenlatausta — lomakkeen vahvistusviesti, ostoskorin laskuri, latauksen tila — käytä reaaliaikaisia alueita, jotta ruudunlukuohjelma kertoo käyttäjälle, että jotain tapahtui. Äänettömät päivitykset ovat näkymättömiä ihmisille, jotka eivät näe näyttöä.

Kaikki nämä odotukset on kodifioitu WCAG 2.2 -onnistumiskriteereihin, jotka muodostavat European Accessibility Actin ja verkkoon sovellettavan ADA:n teknisen selkärangan. Jos haluat käytännön yksityiskohdat, ruudunlukuohjelman testausoppaamme käy vaihe vaiheelta läpi, miten kukin näistä käyttäytymisistä todennetaan oikeilla työkaluilla.

Miksi “minulle se luetaan hyvin” on harhaanjohtavaa

Näkevä kehittäjä voi kytkeä päälle lue ääneen -ominaisuuden, kuulla siistejä lauseita ja päätellä, että sivu on saavutettava. Ansa on siinä, että lue ääneen toistaa näkyvän lukujärjestyksen ja näkyvän tekstin, jotka molemmat ovat jo järkeviä näyttöä katsovalle. Se ei kerro mitään siitä, ilmoittaako mukautettu pudotusvalikko vaihtoehtonsa, onko kohdistus loukussa avatun valintaikkunan sisällä, onko vain kuvakkeen sisältävällä painikkeella nimi vai vastaako sarkainjärjestys visuaalista asettelua. Juuri nämä asiat menevät rikki ruudunlukuohjelman käyttäjillä ja juuri näitä asioita lue ääneen -esittely ei voi paljastaa. Ainoa tapa tietää on testata niin kuin todelliset käyttäjät tekevät.

Miten testata molempia — ja miksi pelkkä automaatio ei riitä

Et voi vahvistaa, että sivu toimii ruudunlukuohjelman käyttäjille, kuuntelemalla lue ääneen -painiketta. Vahvistat sen tarkistamalla rakenteen, nimet, roolit, tilat, näppäimistökäytön ja todellisen ruudunlukuohjelmakokemuksen useilla työkaluilla ja alustoilla.

Hyvä prosessi yhdistää kolme kerrosta:

Automaattinen skannaus korkean volyymin, koneellisesti havaittavien ongelmien havaitsemiseksi — puuttuvat tekstivastineet, tyhjät nimiöt, rikkinäiset ARIA-viittaukset, kontrastivirheet. Saavutettavuuden skannausohjelmistomme ja ilmainen saavutettavuusskannaus ovat nopea tapa kartoittaa lähtötilanteesi.
Asiantuntijoiden manuaalinen testaus kaiken sen arvioimiseksi, mitä automaatio ei voi arvioida: onko nimi merkityksellinen, onko kohdistusjärjestys järkevä, onko mukautettu widget aidosti käytettävä. Tämän kerroksen taustalla oleva päättely käsitellään manuaalisten saavutettavuusauditointien oppaassamme.
Testaus oikealla apuvälineteknologialla ja oikeilla käyttäjillä. Mikään ei korvaa sivun käyttämistä NVDA:lla, JAWS:lla, VoiceOverilla ja TalkBackilla — ja, ihanteellisesti, näitä työkaluja päivittäin käyttävien ihmisten tarkkailua. Vammaisten ihmisten tekemät auditointimme tuovat juuri tuota elettyä asiantuntemusta.

Automaattiset työkalut havaitsevat tyypillisesti vain osan WCAG 2.2 -onnistumiskriteereistä; loput vaativat inhimillistä arviointia. Läpäisseen automaattisen skannauksen kohteleminen saavutettavuuden todisteena on samaa virhekategoriaa kuin lue ääneen -widgetin kohteleminen ruudunlukuohjelmatukena.

Mihin QualiBooth sopii

QualiBooth testaa verkkosivustoasi sekä TTS- että ruudunlukuohjelman käyttötapauksia vasten, jotta sisältösi on saavutettava käyttäjille, jotka luottavat kumpaan tahansa tekniikkaan — ja jotta ruudunlukuohjelmasta riippuvaiset ihmiset voivat paitsi kuulla sisältösi myös todella käyttää tuotettasi. Saavutettavuustyökalupakkimme ja Agora-alusta yhdistävät skannauksen jäsenneltyyn manuaaliseen arviointiin, ja saavutettavuuskonsultointitiimimme auttaa korjaamaan sen, mitä testit paljastavat, ja saavuttamaan WCAG 2.2-, EAA- ja ADA-vaatimustenmukaisuuden.

Lopputulos on yksinkertainen. Äänen lisääminen sisältöösi on mukava lisä. Sisältösi tekeminen ruudunlukuohjelmalle navigoitavaksi, käytettäväksi ja oikein ilmoitetuksi on saavutettavuutta — ja vain toinen näistä täyttää lain ja sen suojaamat ihmiset.