Case Otava: Organisaation täysi tuki saavutettavuudelle
01 | 2025 Mikko Suominen, Lead Front-end Developer & Partner Kipinä
Saavutettavuuteen intohimoisesti suhtautuvana kehittäjänä on ollut mahtavaa olla mukana rakentamassa Otavan uutta digitaalisen oppimisen alustaa. Projektissa on ollut erityisen palkitsevaa nähdä, kuinka tavallista haastavampi käyttöliittymä voidaan toteuttaa saavutettavasti.
Samalla on tullut selväksi, miten merkittävä vaikutus organisaation täysipainoisella sitoutumisella on onnistuneeseen lopputulokseen.
Otavalla saavutettavuuteen panostetaan merkittävästi, ja se nähdään yhtä tärkeänä osana sovelluskehitystä kuin mikä tahansa muu kehitysprosessin osa-alue. Sen myötä saavutettavuus otetaan huomioon ennakoivasti, eikä ongelmia tarvitse lähteä korjaamaan jälkeenpäin, mikä on aina työläämpää. Otavan palveluita käyttävät peruskoulun ja lukion oppilaat sekä opettajat, joiden tekniset taidot voivat vaihdella, lukutaito voi olla vasta kehittymässä, tai he voivat hyödyntää erilaisia apuvälineitä.
Kehittämämme palvelun saavutettavuusselosteessa todetaan: “Otavan tavoitteena on pyrkiä digitaalisten palveluiden saavutettavuudessa vähintään WCAG 2.2 -ohjeistuksen mukaiseen tasoon.” Saavutettavuusvaatimusten taustalla on myös digipalvelulaki, joka velvoittaa julkista sektoria sekä osaa yksityisen ja kolmannen sektorin toimijoista noudattamaan saavutettavuusstandardeja. Tämä sääntely luo vahvan perustan työllemme, mutta organisaation oma sitoutuminen tekee siitä aidosti merkityksellistä.
Digilisätehtävien saavutettavuushaasteita
Tiimimme Otavalla on keskittynyt toteuttamaan palvelussa käytettäviä tehtäviä, kuten esimerkiksi raahaus- ja aukkotehtävä. Kummassakin tehtävätyypissä on käyttöliittymä, joka ei ole verkkosivuille kovin tavanomainen. Raahaustehtävässä käyttäjän tulee nimensä mukaisesti raahaamalla yhdistää toisiinsa liittyviä elementtejä. Esimerkiksi kielten opiskelussa yhdistetään vieraskielinen sana sitä vastaavaan kuvaan. Aukkotehtävä puolestaan sisältää tekstin, jossa on tyhjiä kohtia, eli aukkoja, joihin käyttäjän täytyy kirjoittaa oikeat sanat tai lauseet.
Projektin aikana kävimme tiimimme kanssa läpi saavutettavuusvaatimusten uusimman version, WCAG 2.2, ja pohdimme, miten sen lisäykset vaikuttavat Otavan palveluun. Yksi merkittävä lisäys koski raahausliikkeitä: ohjeistuksen mukaan kaikki toiminnot, jotka vaativat raahausta, on voitava suorittaa myös yksinkertaisemmilla menetelmillä. Tämä asetti selkeän kehitystavoitteen raahaustehtävien uudistamiselle, ja projektitiimi seurasi muutoksen etenemistä tarkasti. Tällaiset saavutettavuusparannukset eivät pelkästään täytä vaatimuksia, vaan parantavat käytettävyyttä kaikille käyttäjille.
Raahaustoiminto voi yllättäen olla monille haastava käyttötapaus, erityisesti koulusta saaduilla Chromebookeilla, joiden touchpadin käyttöön ei välttämättä olla vielä totuttu. Tilannetta voi hankaloittaa entisestään, jos käyttäjän täytyy samalla vierittää näkymää raahatessaan elementtiä.
Uudessa ratkaisussa Otavan raahaustehtävä mahdollistaa elementtien yhdistämisen klikkaamalla: käyttäjä voi ensin klikata raahattavan kohteen aktiiviseksi ja sen jälkeen valita sille sopivan kohteen. Vaikka raahaaminen on yhä mahdollista, se ei enää ole ainoa vaihtoehto.
Kolmas osapuoli mukaan auditointiin
Projektitiimiin päätettiin muun tiimin tueksi ottaa myös ulkopuolinen, erityisesti saavutettavuuteen erikoistunut kumppani, Q-Factory, jonka tehtäväksi tuli arvioida tiimin toteuttamia ominaisuuksia ja ehdottaa niihin parannuksia.
Vaikka tiimissä oli ruudunlukijan käytön hallitsevia kehittäjiä, eivät heidän kokemuksensa koskaan täysin vastaa näkövammaisten ns. ‘natiivien ruudunlukija käyttäjien’ kokemuksia – eli henkilöitä, jotka todella käyttävät ruudunlukijaa ensisijaisena tai ainoana käyttöliittymänään.
Koko hankkeelle oli erityisen hyödyllistä, että projektin sisäisten kehittäjien lisäksi projektissa oli myös ulkopuolisia asiantuntijoita, joka pystyvät saavutettavuusominaisuuksien toimivuuden tarkistusten kautta antamaan niille hyväksynnän leiman. Oli arvokasta nähdä Q-Factoryn palautteiden kautta, että saavutettavuus on ollut jo lähtökohtaisesti keskimääräistä paremmalla tasolla. Tieto, joka kertoo, että saavutettavuus on ollut alusta asti keskeinen osa kaikkea kehitystyötä.
Älä luota valmiiden kirjastojen saavutettavuuslupauksiin
Q-Factoryn testaajien palautteesta saatu keskeisin oppi liittyi raahaustehtävän näppäimistö- ja ruudunlukijakäyttöön. Olimme alun perin toteuttaneet toiminnon käyttäen ulkoista kirjastoa, jonka dokumentaatiossa luvattiin tuki sekä näppäimistö- että ruudunlukijakäytölle. Kirjaston logiikka toimi siten, että elementin saatua fokuksen käyttäjän tuli aktivoida se painamalla Enter- tai välilyöntinäppäintä. Tämän jälkeen elementtiä voitiin siirtää kaksiulotteisesti nuolinäppäimillä.
Ruudunlukijatuki vaikutti aluksi lupaavalta. Käyttäjä sai äänipalautteen aina, kun elementtiä pystyi liikuttamaan; nuolinäppäimiä painaessa käyttäjä myös kuuli elementin siirtyvän vasemmalle, oikealle, ylös tai alas. Testauksessa ilmeni kuitenkin perustavanlaatuinen ongelma: käyttäjä, joka ei näe, ei voi mitenkään tietää, mihin suuntaan ja kuinka paljon elementtiä pitäisi liikuttaa.
Ratkaisuna päätimme luopua kirjaston tarjoamasta näppäimistötuesta ja yksinkertaistaa toteutusta. Käyttöliittymää muutettiin niin, että käyttäjän valitessa elementin näppäimistöllä, hän voi sen jälkeen navigoida vain niihin kohteisiin, joihin elementin voi yhdistää. Tämä muutos poisti tarpeen siirtää elementtejä vapaasti nuolinäppäimillä ja teki toiminnosta huomattavasti selkeämmän ja saavutettavamman.
Tämän esimerkin suurimpana oppina oli ehdottomasti se, ettei valmiiden kirjastojen saavutettavuuslupauksiin voi aina täysin luottaa. Monessa tapauksessa on tärkeää tarkistaa komponentin toimivuus saavutettavasti omassa palvelussa ja testata sen käyttö oikeilla käyttäjillä.
Näkevä kehittäjä ei ole sama kuin natiivi ruudunlukijakäyttäjä
Aluksi oletimme, että aukkotehtävän toteuttaminen saavutettavasti vaatisi monimutkaista koodiakrobatiaa. Keskellä lausetta olevien tekstikenttien esittäminen ruudunlukijan käyttäjälle tuntui erityisen haastavalta, koska lauseen konteksti on tärkeä tehtävän ymmärtämiseksi.
Q-Factoryn natiivin ruudunlukijakäyttäjän testit osoittivat, että aukkotehtävä toimi jo lähtökohtaisesti hyvin ja mitään merkittäviä muutoksia ei tarvittu.
Kokemus opetti, ettei oma ruudunlukijan käyttötaito kehittäjänä ole verrattavissa natiivikäyttäjien sujuvuuteen. Vaikka osaan käyttää ruudunlukijaa, en koskaan käytä sitä samalla tavalla kuin henkilöt, jotka tukeutuvat siihen päivittäin.
Saavutettavuus herättää kehittäjissä halun oppia
On ollut inspiroivaa työskennellä projektissa, jossa saavutettavuus on otettu vakavasti koko projektiryhmän tasolla. Saavutettavuus, kuten muutkin ohjelmistokehityksen osa-alueet, on taito, jossa kehittäjien osaamistaso voi vaihdella. Kuitenkin, kun projektissa onnistutaan välittämään kaikille osallistujille saavutettavuuden merkitys ja herättämään kehittäjissä halu oppia ja kehittyä tällä osa-alueella, tulokset näkyvät kaikille osapuolille. Lopputuloksena ei ainoastaan paranneta palvelun saavutettavuutta, vaan myös koko tiimi kehittyy ja pystyy tuottamaan parempia, käyttäjäystävällisempiä ratkaisuja.
Mikko Suominen, Senior front-end developer & Partner Kipinä
Mikko on kohta parinkymmenen vuoden kokemuksella varustettu frontend-kehittäjä, käyttöliittymäsuunnittelija sekä saavutettavuusasiantuntija. Urallaan Mikko on tehnyt kaikkea konseptisuunnitelusta raskaan teollisuuden datajärjestelmiin. Istumatyön vastapainoksi hän työmatkapyöräilee kaikkina vuodenaikoina ja harrastaa telinevoimistelua.