Viime vuosien aikana on julkishallinnon verkkopalveluihin ilmestynyt jälleen lisää näkyviä ”Kuuntele”-nappeja. Sitä klikkaamalla käyttäjä voi käynnistää automaattisen puhesyntetisaattorin, joka lausuu sivun sisältötekstit ääneen. Nappien tarkoituksena on epäilemättä ystävällinen kädenojennus sivujen saavutettavuuden parantamiseen, mutta useimmille käyttäjille ne taitavat olla vain häiritsevää hälyä käyttöliittymässä?
North Patrol on suunnitteluun erikoistunut konsulttitoimisto. Suunnittelemme, autamme teknologiavalinnoissa, kilpailutamme. Emme myy toteutusprojekteja, emmekä lisenssejä, olemme aidosti asiakkaan puolella.

Käyttöliittymässä näkyvä ”Kuuntele”-nappi on kolmannen osapuolen kaupallinen sovellus, joka on asetettu verkkosivuille. Suomessa eniten myytyjä sovelluksia näyttävät tarjoilevan kansainvälinen ReadSpeaker ja kotimainen Voice Intuitive.
Molempien yhtiöiden myyntipuheissa nostetaan esiin sovelluksen kykyä parantaa verkkosisältöjen saavutettavuutta, mutta saavutettavuutta kenelle?
Näkövammainen ei käytä Kuuntele-nappia
Kun saavutettavuuden haasteita ratkotaan, ehkä tärkeimpänä kohderyhmänä ovat näkökyvyltään vakavasti rajoittuneet: siis sokeat tai ne tosi huonosti näkevät, jotka eivät käytä graafista käyttöliittymää lainkaan.
Tälle kohderyhmälle verkossa käytettävät digipalvelut ovat erityisen hyödyllisiä, ja tälle ryhmälle myös verkkosivujen selailu on tyypillisesti erityisen kamalaa: keskiverto verkkosivu on suunniteltu ja testattu näkemistä, ei kuuntelemista varten.
Tästä syystä verkkosivujen käyttömahdollisuus ja ymmärrettävyys kuuntelemalla on ehkä tärkein varmistettava ja testattava asia saavutettavuuden kannalta. Mutta ei se Kuuntele-nappi tähän vaikuta mitenkään!
Sokea ja vakavasti näkövammainen kuuntelee verkkosivuja omalla ruudunlukuohjelmistollaan, jolla kuuntelee (tai vaikkapa tunnustelee Braille-pistenäytöltään) oman laitteensa käyttöjärjestelmää ja avaa sieltä tottuneesti oman selaimensa.
Sokea ”silmäilee” verkkosivun käyttämällä oman ruudunlukuohjelmistonsa komentoja ja selailutoimintoja. Hänelle siis Kuuntele-nappi ei tarjoa mitään lisäarvoa eikä paranna saavutettavuutta — se on vain turha elementti käyttöliittymässä.
Kuuntele-nappi sivun lukemisen vaihtoehtona?
Graafisessa käyttöliittymässä näytettävät Kuuntele-napit onkin tarkoitettu näkeville käyttäjille. Ajatuksena on tarjota käyttäjälle helppo mahdollisuus kuunnella sivu ääneen luettuna sen sijaan että sen tekstejä tankkaisi ruudulta itse.
Kohderyhmät, joille verkkosisällön saavutettavuutta pyritään näin parantamaan, ovat vaikkapa keskittymishäiriöiset, lukihäiriöiset, huonosti näkevät tai huonosti kieltä osaavat.
Kuuntelemisen hyödyt ovat hyvin kuviteltavissa: Kuuntele-nappia klikkaava käyttäjä vapautuu ruudun ääreltä vaikkapa tiskaamaan, hoitamaan lasta tai puuhaamaan omiaan, ja verkkosivun sisältö valuu korviin äänen kautta. Lukihäiriöinen tai kielitaidostaan epävarma (esim. maahanmuuttaja) saattaa ymmärtää suomea paremmin kuultuna kuin luettuna. Heikosti näkevälle tai vaikkapa silmälasinsa unohtaneelle voi sivun kuunteleminen olla tervetullut vaihtoehto tekstipiperryksen syynäämisen sijaan.
Mutta onko se verkkosivulla näkyvän tekstin ääneenlukeminen pakko tarjota päälleliimatulla kaupallisen sovelluksen Kuuntele-nappulalla?
Puhesynteesi selaimen toimintona
Internet-selaimet kaikissa käyttöjärjestelmissä tarjoavat myös selaimeen sisäänrakennettua ”Lue ääneen”-työkalua, jolla verkkosivuilla näkyvää tekstiä voi kuunnella puhesyntetisaattorin lukemana.
Jos käyttäjä haluaa kuunnella verkkosivuja niiden lukemisen sijaan, eikö olisi hyvien käytettävyysperiaatteiden mukaista se, että käyttäjä saa itse valita tähän käytettävän työkalun? Käyttäjä oppii omassa hallinnassaan omalla selaimellaan olevan kuuntelutyökalun, jonka ominaisuuksia voi itse säätää halutunlaisiksi.
Tämä selaimen natiivityökalu on sitten käyttäjällä koko ajan käytössään ja pysyy samanlaisena välineenä kaikkien erilaisten verkkosivujen kuunteluun.
Hyvän käytettävyyden ja saavutettavuuden yleisperiaate on se, että käyttäjä pystyy ennakoimaan verkkopalvelujen toimintoja ja säilyttää itsellään toimintojen hallinnan. Tämän periaatteen mukaista on antaa käyttäjälle itselleen valinta ruudun lukemisen työkaluista.
Jos keskittymishäiriöisille, lukihäiriöisille tai heikosti näkeville yritetään saada verkkosisällöt helpommin saavutettaviksi, eikö heitä kannattaisi ohjata löytämään oman selaimensa kuuntelutoiminnot jonkin sivustosta toiseen vaihtelevan ”Kuuntele”-napin opettelun sijaan?
Selaintoimintoja ei tarvitse toistaa käyttöliittymässä
Hyvässä käyttöliittymäsuunnittelussa vältetään kaikkea turhaa, ja näkymissä keskitytään esittämään vain tarpeelliset, käyttäjälle aidosti lisäarvoiset asiat. Jos sivulla näkyvän tekstin kuunteleminen on mahdollista tehdä selaimen toiminnolla, miksi sitä varten pitäisi esittää erillinen nappi?
Mieleen tulee väkisinkin muistikuvia takavuosilta, kun jokaisesta verkkosivunäkymästä löytyi tyylitelty ”Tulosta sivu”-nappula tai ”Lähetä kaverille”-nappula. Nyttemmin on yhteisesti jaettu käsitys se, että sivun tulostuksen tai www-osoitteen kopioinnin sähköpostiin osaa jokainen käyttäjä tehdä omilla työvälineillään: erillistä toimintonappia ei näitä varten tarvitse sivuille laittaa.
Mutta ”Kuuntele”-nappi on vain yleistynyt — liekö syynä se yleinen harhakäsitys, että se olisi saavutettavuuden kannalta jotenkin erityisen suotavaa?
Samasta virheellisestä oletuksesta varmaankin kumpuaa myös edelleen siellä täällä näkyvien tekstikoon suurennusnappien esittäminen? Huomasin jo miltei 10 vuotta sitten motkottaneeni siitä, että ”Tekstikokoa suurennetaan selaimella, ei erillisillä nappuloilla” .
Siis: jos jokin verkkosivujen näkymään tai hallinnointiin liittyvä toiminnallisuus on tehtävissä selaimen natiivitoiminnoilla, ei näitä ole syytä toisintaa toimintoina verkkosivujen sisällä.
No onko siitä jotain haittaa?
Jos nyt olenkin tässä kelannut perusteluja sille, ettei ”Kuuntele”-napista ole juuri hyötyä, sopii tietysti kysyä että onko siitä mitään haittaakaan.
Aika monessa ilmenemismuodossaan nappi on suurehko, kömpelö käyttöliittymäelementti keskeisellä paikalla verkkopalvelun jokaisella sisältösivulla. Se siis vie huomiota ja käyttöliittymätilaa olennaisemmalta informaatiolta.
Vaikka nappi näyttää helposti klikattavalta, eivät sen kontrollit ole mitenkään pläkkiselviä käyttää, jos sitä sattuukin klikkaamaan. ReadSpeakerin hallintapalkki avautuu aika raskaana, vaikeasti tulkittavana elementtinä, ja Voice Intuitiven hallintapalkki voi olla vaikeaa bongata sivulta. Käyttäjä saattaa hyvinkin joutua virhetilanteeseen, josta ei löydä tietään ulos.
Ja tietysti napin taustalla on kaupallinen tuote, josta seuraa rahallisia kustannuksia verkkosivuston tuottajalle. Jos julkiset palveluntarjoajat haluavat panostaa sivustonsa palvelevuuden tai saavutettavuuden parantamiseen, en ole ollenkaan vakuuttunut siitä, että Kuuntele-nappi olisi hyötysuhteeltaan ihanteellisin investointikohde.
Ja jos ajatellaan ylevästi ja kaukonäköisesti sitä, ”mihin käyttäjät opetetaan”, niin kyllähän käyttäjät pitäisi ohjata hyödyntämään oman selaimensa toimintoja. Kuuntele-napin sijaan käyttäjien pitäisi löytää oman selaimensa kuuntelutoiminnot.
Mutta osaavatko käyttäjät käyttää oman selaimensa kuuntelutoimintoa? Enpä usko, että se huonosti näkevä eläkeläinen tai lukemiseen keskittymiskyvytön ADHD-teini avaisi selaimensa ”Lue ääneen”-työkalun. Mutta en myöskään usko, että he kovin usein klikkaisivat näkemäänsä ”Kuuntele”-nappia. Mikähän osuus käyttäjistä tähän toimintoon tarttuu?
Jos sivustolle laitetaan erillinen kuuntelusovellus sillä odotuksella, että toiminnolla tuotetaan parempaa palvelua joillekin erityisille kohderyhmille, kannattaisi ainakin seurata, täyttyykö tuo odotus. Käyttävätkö oletetut kohderyhmät toimintoa, onko siitä hyötyä, ja kuinka suurelle osalle käyttäjiä? Painaako potentiaalinen hyötyodotus vaakakupissa enemmän kuin se käyttöliittymähäly, joka muille käyttäjille tuotetaan?
Kuuntele-napin klikkaukset kannattaisi siis saada mukaan jonkinlaiseen seurantaan. Sovelluksen hyödyllisyys voidaan näin punnita suoraan suhteessa siihen, miten suosittu se on käyttäjien keskuudessa.
Käytettävyys on aina muodikasta
North Patrolin suunnittelutyössä kiinnitetään johdonmukaisesti huomiota siihen, että digipalveluista tulee mahdollisimman ymmärrettäviä, opittavia, tehokkaita, asiakaskunnalle saavutettavia ja kaikin puolin miellyttäviä käyttää. Palvelumuotoilulla ja prototyypeillä haetaan toimivat ratkaisut, joiden havainnollista esittelyä organisaation sisällä tuetaan osuvilla mallinnuksilla.
PS. Sinua voisi kiinnostaa tulossa oleva ilmainen webinaarimme: Webinaari: CRM-järjestelmät Suomessa ja vinkit onnistuneeseen CRM-valintaan (7.5.2025 klo 10:00). Ilmoittaudu webinaariin