Parin viime vuoden aikana monissa organisaatioissa on tehty urakalla töitä verkkosivustojen saavutettavuuden kanssa. Urakointi on tarpeen myös mobiilisovellusten julkaisijoilla, sillä digipalvelulain mobiilisovelluksia koskeva siirtymäaika alkaa kovasti kolkutella ovia. Saavutettavuustyö mobiilissa ei kuitenkaan pääty 23.6.2021, vaan siitä se vasta kunnolla alkaa.

Mitä ihmettä ovat mobiilisovellusten saavutettavuusvaatimukset?

Ylätasolla lain edellytykset ovat yksinkertaiset: kaikkien pitäisi voida käyttää sovelluksia riippumatta aisti- tai liikuntarajoitteista, avustavien ohjelmien kanssa ja sellaisilla asetuksilla, jotka kullekin sopivat parhaiten. Mobiilisovellusten saavutettavuusvaatimukset noudattelevat varsin pitkälti WCAG 2.1 -ohjeistuksen tasoja A ja AA. 

Lähdetäänpä tutkimaan tarkemmin, mitä tämä tarkoittaa.

Käyttöliittymän visuaalisuus

Sovelluksen käyttöliittymässä olevien elementtien pitää olla sellaisia, että niiden ulkonäöstä tunnistaa elementin, ja toisaalta erottaa ne toisistaan: käyttäjänä tietää siis, lisääkö tökkäys ruksin ruutuun vai vaihtuuko siitä näkymä kokonaan toiseksi. Elementtien pitäisi olla myös saman sovelluksen sisällä yhdenmukaisesti saman näköisiä, jos niistä tehdään sama toiminto. 

Jotta sovelluksen käyttäminen onnistuu myös aurinkoisessa säässä ulkona tai värisokeana, on kontrastien oltava kunnossa. Käytännössä tekstin tulee erottua riittävästi taustasta, painikkeiden ja muiden käyttöliittymäelementtien pelkästä tekstistä ja niin edelleen. Riittävää erottuvuutta ei onneksi tarvitse vain itsekseen pohtia, vaan siihen on olemassa tarkat numeeriset arvot ja lukuisia laskureita, jotka kertovat suoraan, ovatko kaksi väriä keskenään riittävän erilaiset.

Monissa mobiililaitteissa tekstin kokoa pystyy säätämään laitteen asetuksista itselleen mieluisaksi. Jos asetuksista vääntää tekstikoon kaksinkertaiseksi, pitää vaatimusten mukaan sovelluksen noudattaa asetusta vielä niin, että käyttöliittymän ymmärrettävyys ei kärsi. Tekstit eivät saisi siis mennä päällekkäin tai paisua yli näytön reunojen.

Osalle käyttäjistä on väliä sillä, toimiiko sovellus pysty- vai vaakasuunnassa, koska laitteen kääntely ei välttämättä ole mahdollista tai sen käyttö on helpointa vain tietyssä asennossa. Tästä syystä sovelluksen käyttöliittymän pitäisi skaalautua ruudulle molemmilla tavoilla, eikä pakottaa käyttämään vain yhdessä suunnassa. Tästä lain vaatimuksesta on poikkeuksena sellaiset sovellukset, joiden toiminta ehdottomasti vaatii tietyn asennon – mutta ne ovat harvassa.

Miltä konepellin alla näyttää?

Koska mobiililaitteitakin käytetään myös erilaisten avustavien ohjelmien kanssa, saavutettavalla ulkoasulla emme ole vielä täysin maalissa. Käyttöliittymän pitäisi tällöin olla kaikin puolin myös ohjelmallisesti selkeä, jotta sen ja käyttäjän välissä oleva avustava ohjelma pystyy toimimaan oikein. Eli mitä häh?

Sen lisäksi, että tyhjä alue ruudussa näyttää kirjoitusta kaipaavalta tekstikentältä, pitää sen olla ohjelmallisesti määritelty tekstikentäksi. Jotta voisi vielä komentaa puhelintaan ääneen, "Kirjoita kenttään lempiruoka: fetapasta", täytyy kenttä ja sen nimilappu ("label") yhdistää toisiinsa.

Aivan vastaavasti myös painikkeet, valintaruudut ja muut vuorovaikutuselementit pitää koodatessa varustaa tiedolla siitä, mitä ne oikein ovat, eikä painikkeiden nimiäkään sovi unohtaa – vaikka siinä olisikin näyttävä symboli.

Symboleista puheenollen: kuvasisältö tarvitsee ns. tekstivastineen, eli sanallisen kuvauksen kuvan, symbolin tai muun visuaalisen sisällön merkityksestä ohjelmallisessa muodossa. Kun sokea käyttäjä kohtaa ruudunlukuohjelman kanssa visuaalista sisältöä, tekstivastine auttaa kertomalla, mitä se on.

Vuorovaikutus sovelluksen kanssa

Mobiililaite mahdollistaa pöytäkonetta monipuolisemmat vuorovaikutustavat, kun laitetta voi ravistaa ja kosketusnäytöllä tehdä erilaisia raahaus-, nipistys- tai pyörityseleitä. Kaiken tämän hyödyntäminen on varsin ok, kunhan ne eivät ole ainoita tapoja suorittaa toiminto.

Kaikkien motoriikka ei taivu vaikkapa kartan koon muuttamiseen sormia nipistämällä, joten saman asian tekemiseen käyttöliittymässä pitäisi olla myös yksinkertaisesti painettavia painikkeita. Yleistettynä: jos toiminta vaatii useampaa kuin yhtä sormea, laitteen ravistamista tai sormen kuljettamista moneen suuntaan, pitää sille olla tarjolla myös toinen tapa. (Tästäkin voi poiketa, jos toiminto on esimerkiksi käsin kirjoittamista tai piirtämistä.)

Joillekin on tarpeen käyttää mobiililaitetta myös pelkän näppäimistön kanssa, koskemattakaan kosketusnäyttöön. Mobiilisovelluksissa tämänkin tulee olla mahdollista, eli kaikkiin sovelluksen toimintoihin täytyy päästä käsiksi myös perinteistä näppäimistöä käyttämällä.

Paljon vaatimuksia, miten näistä selvitään?

Jos teillä on mobiilisovellus, on alkuun tarpeen tietää, millä tolalla sen saavutettavuus tällä hetkellä on. Parhaimmassa tapauksessa sille ei tarvitsekaan tehdä mitään muuta kuin liittää sovelluksen kylkeen lain edellyttämä saavutettavuusseloste siitä, kuinka hyvin sovellus täyttää vaatimukset. Jos sovelluksessa havaitaan puutteita saavutettavuudessa, selosteessa kerrotaan puutteet sekä arvio siitä, milloin ne on saatu korjattua.

Uutta sovellusta suunnittelevilla tai kehittävillä onkin pikkuisen helpommat asetelmat: on yksinkertaisempaa tehdä mahdollisimman alusta asti oikein kuin lähteä korjaamaan ehkä vuosienkin takaisia rakennusvirheitä.

Oli tilanne sitten kumpi tahansa – vanha sovellus kaipaa saavutettavuushuoltoa tai uutukainen on vasta suunnittelupöydällä – kannattaa palata Eficoden blogiin keväällä vielä uudestaan, sillä mobiilisovellusten saavutettavuudesta on myöhemmin luvassa kirjoitus, jossa päästään työntämään enemmän käsiä saveen. Siinä avaamme tarkemmin sitä, kuinka saavutettavuuden vaatimukset taklataan.

Paranna sovelluksesi saavutettavuutta ja käytettävyyttä