Saavutettavuudella varmistat viestisi perillemenon

Design • Digitalisaatio • Teknologia

Valtiovarainministeriön mukaan “saavutettavuudella tarkoitetaan, että verkkosivut ja mobiilisovellukset sekä niiden sisällöt ovat sellaisia, että kuka tahansa voisi niitä käyttää ja ymmärtää, mitä niissä sanotaan”. Toisin sanoen verkkosivut ja mobiilisovellukset tulee toteuttaa teknisesti ja visuaalisesti siten, että toimintarajoitteiset käyttäjät pystyvät käyttämään palvelua ja sen sisältöä. Nämä vaatimukset pohjautuvat WCAG-kriteereihin.

Kun puhutaan saavutettavuudesta, usein ensimmäiseksi mieleen tulee ikäihmiset sekä näkö- ja kuulovammaiset. Näiden lisäksi esimerkiksi aisti- ja kehitysvammaiset sekä keskittymisvaikeuksista kärsivät luetaan ryhmiin, jotka hyötyvät saavutettavuudesta eniten. Nämä ovatkin tärkeitä ja huomionarvoisia käyttäjäryhmiä. Saavutettavuuden tarve voi kuitenkin olla myös tilapäinen: kenen tahansa havainnointi- ja toimintakyky voi olla väliaikaisesti rajoittunut esimerkiksi onnettomuudesta, mielentilasta tai olosuhteista johtuen.


Ennusteen mukaan vuoteen 2020 mennessä yli 120 miljoonalla ihmisellä, eli 20% Euroopan väestöstä on jonkinasteinen toimintarajoitus.

https://europa.eu/rapid/press-release_IP-15-6147_en.htm

Saavutettavuutta parantamalla varmistetaan se, että käyttäjäryhmästä riippumatta verkkopalvelun käyttö on helppoa ja sen sisältö ymmärrettävää. Huomioon otettavia asioita ovat esimerkiksi navigaation selkeys, värit ja kontrastit, sisältötekstin ymmärrettävyys, asettelu ja rakenne, sekä myös tekniset asiat erilaisia lukulaitteita varten.

Verkkopalvelun käyttö pitää olla mahdollista myös pelkän näppäimistön avulla. Ihmiset, joilla on rajoitteita näkemisessä tai käsien toiminnassa, eivät välttämättä pysty käyttämään hiirtä lainkaan. Näppäimistöselaaminen asettaa vaatimuksia teknisiin valmiuksiin sekä visuaaliseen palautteeseen: linkit on rakennettava siten, että ne toimivat loogisesti sarkaimella sekä tarjoavat riittävän visuaalisen palautteen käyttäjälle.

Vaatimukset eivät koske pelkästään verkkosivustoja ja mobiilisovelluksia. Myös sivustoilla jaettavien videoiden, äänilähetysten ja tiedostojen on oltava saavutettavuusvaatimusten mukaisia. Word- ja PDF-dokumenttien saavutettavuus ei ole itsestään selvää, vaan vaatii johdonmukaisuutta sekä selkeyttä rakenteen ja tekstisisällön suhteen. Videoiden ja äänitteiden mukana tulee tarjota sisältöä myös tekstimuodossa. Sosiaalisessa mediassa videoiden tekstitys on jo havaittu toimivaksi keinoksi katsoa videoita ilman ääniä.

Lisäksi kannattaa muistaa, että saavutettava verkkopalvelu on todennäköisesti käytettävämpi myös ei-rajoitteisille käyttäjille!

Paranna näkyvyyttä ja tuloksia saavutettavuudella

Saavutettavuudella on myös hakukoneoptimoinnin kannalta merkitystä. Googlen algoritmi arvostelee verkkopalvelua sekä teknisesti että kävijöiden käyttäytymisen perusteella. Huonosti saavutettavissa olevasta verkkopalvelusta poistutaan, jolloin Google tulkitsee sivussa olevan jotain vikaa.

Tutkimuksen mukaan 71% toimintarajoitteisista kävijöistä poistuu verkkopalvelusta välittömästi, jos se ei ole saavutettavissa. He hakeutuvat saavutettavien palveluiden äärelle ja kuluttavat mielellään jopa enemmän. Kun parannat verkkopalvelusi saavutettavuutta, et vain pidä nykyisiä käyttäjiäsi, vaan saat heidät käyttämään enemmän rahaa.

Laskuesimerkki verkkokaupan saavutettavuuden vaikutuksesta:

  • 100 000 kävijää, keskiostos 100€, konversio 3%
  • Toimintarajoitteisia 20%, 20 000 kävijää
  • He kuluttavat 20 000 * 0,03 * 100€ = 60000€
  • Jos sivusto ei saavutettavissa, tästä 71% jää saamatta = 42600€

Lisää vaatimuksia verkkopalveluIlle

Saavutettavuus tuo mukaan myös oikeuksia verkkopalvelun käyttäjälle ja vaatimuksia ylläpitäjälle. Palvelusta täytyy tietosuojaselosteen lisäksi löytyä jatkossa myös saavutettavuusseloste, ja käyttäjän palautteeseen on vastattava kahden viikon kuluessa. Selosteen luomiseen on olemassa valmis työkalu, joka löytyy osoitteesta https://www.saavutettavuusvaatimukset.fi/saavutettavuusseloste/.

Aikataulullisesti vaatimukset ovat jo 23.9.2018 jälkeen julkaistujen verkkopalveluiden osalta voimassa. Sitä aiemmin julkaistujen palveluiden ja tiedostojen tulee olla saavutettavissa 23.9.2020.

Siirtymäajat

23.9.2019
Kaikkien julkishallinnon palveluiden, jotka on julkaistu 23.9.2018 jälkeen, on oltava vaatimusten mukaisia. Tämä koskee myös tiedostoja.

23.9.2020
Ennen 23.9.2018 julkaistujen julkishallinnon palveluiden ja tiedostojen tulee täyttää vaatimukset.

1.1.2021
Vaatimusten piiriin kuuluvien yksityisen sektorin toimijoiden (esim. pankki-, liikenne- ja vakuutusalojen) palvelut on oltava saavutettavuusvaatimusten mukaisia.

23.6.2021
Mobiilisovellusten tulee täyttää saavutettavuusvaatimukset.

Lisää aiheesta:

Saavutettavuusdirektiivi.fi
Saavutettavuusvaatimukset.fi
Valtiovarainministeriö
Lain saavutettavuusvaatimukset tuovat isoja muutostarpeita julkisen sektorin verkkosivustoihin (AVI)

PS. Tutustu myös Euroopan Unionin Esteettömyysdirektiiviin

Kirjoittajan Jukka Harkki kuva

Jukka Harkki

Selainpohjaisilla sovelluksilla tavoitat käyttäjäsi paremmin

Digitalisaatio • Teknologia

Mobiilisovellukset on jo jonkin aikaa voitu toteuttaa natiivisovelluksien lisäksi myös selainpohjaisesti. Näitä selainpohjaisia sovelluksia kutsutaan termillä progressive web app tai lyhyemmin PWA. Ne mahdollistavat lähes samankaltaisen käyttökokemuksen kuin natiivisovellukset ja tarjoavat tavanomaisia verkkosivuja kattavammat työkalut puhelimen muiden ominaisuuksien hyödyntämiseen.

PWA-logo

Verkkosivujen latausajoista puhutaan paljon. Jos sivun latautuminen kestää liian kauan, katsoja kyllästyy helposti ja siirtyy toiselle sivustolle. Sama koskee myös natiivisovelluksia, joiden käyttökynnyksenä on lisäksi asennus. Toisin sanoen sivun ja sovelluksen nopeuttaminen lisää kävijöiden määrää ja saa kävijät viihtymään sivustolla kauemmin, jolloin kävijät myös konvertoituvat paremmin – eli he toimivat sivuston tavoitteiden mukaisesti. Myös PWA-sovelluksia voidaan verkkosivujen tavoin optimoida hakukonenäkyvyyden kannalta, sillä PWA-sovellus on käytännössä verkkosivu laajennetuilla ominaisuuksilla.

Twitter toteutti sovelluksensa PWA-muotoisena ja huomasi, että käyttäjien sitoutuminen parani merkittävästi. Sovelluksen käynnistysaika parani 50% ja tarvittavan tallennustilan määrä tippui 3%:iin (23,5Mt vs 0,6Mt). PWA-sovellus latautuu myös hitaammassa verkossa nopeasti.

Hotellien vertailupalvelu Trivago etsii jatkuvasti keinoja parantaa käyttäjäkokemusta ja tavoittaa uusia käyttäjiä. Heidän PWA-sovelluksensa ansiosta käyttäjien sitoutuminen parani 150% ja konvertoituminen 97%. Samanlaisia tuloksia oli nähtävissä myös Forbesin projektissa. Heillä istuntojen määrä kasvoi 43% käyttäjää kohden ja mainosnäyttöjen lukumäärä nousi 20%. PWA:n hyödyntäminen heijastuu siten selkeästi myös liiketoiminnan tuloksiin.

Jos harkitset natiivisovelluksen hankkimista, ota selvää, voisiko sen toteuttaa selainpohjaisena PWA-sovelluksena. Kehitysaika lyhenee, ylläpidettävyys helpottuu, eikä useiden sovelluskauppojen kanssa hallinnointia tarvita. 

Pähkinänkuoressa:

  • Selainpohjainen, ei vaadi sovelluksen asentamista.
  • Sovellus toimii myös ilman verkkoyhteyttä.
  • Käyttäjiä voidaan lähestyä ilmoituksilla suoraan laitteeseen.
  • Löydettävyys paranee hakukoneoptimoinnin ansiosta.
  • Ei laitekohtaisia versioita tai sovelluskauppoja.
  • Päivitykset ovat välittömästi saatavilla, ei asennuksia.

PWA-sovelluksen rakentaminen

PWA-sovellus rakennetaan samaan tapaan kuin tavallinen nettisivu. Sovellus koostuu HTML:stä, JavaScriptistä, kuvista ja tyylitiedostoista. Toiminnallisuutta täydennetään Service worker -JavaScripteilla, jotka tekevät määriteltyjä toimintoja taustalla. Nämä mahdollistavat mm. tiedostojen latauksen välimuistiin. Tutustu yksinkertaiseen rakennusohjeeseen täällä, ja hieman seikkaperäisempään ohjeistukseen Googlen Code Labsissa. Jos sinulta löytyy tekstieditori, ohjelmisto tiedonsiirtoon palvelimelle ja vaikka Google Chrome-selain, on käytössäsi jo tarvittavat työkalut selainpohjaisen sovelluksen julkaisemiseen.

Sekä iPhone että Android tukevat PWA-sovelluksia, joten saat nopeasti ja vaivattomasti julkaistua alustariippumattoman, responsiivisen sovelluksen.

Haluatko kuulla lisää?

Kirjoittajan Jukka Harkki kuva

Jukka Harkki

Työ- ja elinkeinoministeriö

Caset • Teknologia

Työ- ja elinkeinoministeriö – Tehokkaampaa sovelluskehitystä mallinnuksen avulla

Read more
Kirjoittajan Jukka Harkki kuva

Jukka Harkki

React pähkinänkuoressa

Teknologia

Zoolander-kuva tekstillä "React.JS so hot right now"

Or should one say “React still so hot”? Onhan se kuitenkin julkaistu jo 6 vuotta sitten – 29. toukokuuta 2013.

  • Facebook loi Reactin, minkä vuoksi se sai paljon huomiota.
  • Se ratkaisi SPA:n ( Single Page Applications ) merkittäviä ongelmia.
  • Tänä päivänä React on suosittu yksinkertaisuutensa ja juostavuutensa vuoksi. Toki suosioon vaikuttaa myös se, että isot yritykset, kuten PayPal, Uber ja Instagram käyttävät tekniikkaa.

Mitä React on?

React on tapa rakentaa käyttöliittymiä. React tekee käyttöliittymien rakentamisen helpoksi pilkkomalla jokaisen sivun paloiksi. Näitä paloja kutsutaan komponenteiksi.

React -komponentti on pala koodia, joka kuvaa jotain tiettyä osaa sivusta. Jokainen komponentti on JavaScript -funktio, joka palauttaa palan koodia, joka puolestaan kuvaa osaa verkkosivusta.

Sivu siis muodostuu Reactilla siten, että näitä funktioita kutsutaan ja kasataan tietyssä järjestyksessä, ja näytetään tuo järjestys käyttäjälle.

React on JavaScript -kirjasto, joka käyttää JSX-syntaksia (JavaScript XML). React ei itsessään vaadi JSX:n käyttöä, eli sitä olisi mahdollista kirjoittaa suoraan JavaScriptinä, mutta useimmat kokevat JSX:n käytön hyödylliseksi. Yleisesti ottaen kukaan täysjärkinen ei kirjoita Reactia ilman JSX:ää.

JSX lyhyesti:

  • JSX muistuttaa hyvin pitkälti HTML:ää.
  • JSX on XML:n kaltainen syntaksi, eli jokainen tagi täytyy sulkea.
  • JSX:n käyttö sallii Reactin näyttää hyödyllisempiä virhe -ja varoitusilmoituksia.
  • JSX mahdollistaa dynaamisen sisällön luomisen helposti kirjoittamalla JavaScriptiä aaltosulkeiden sisälle.

Komponentit ja propsit

Komponentit siis sallivat käyttöliittymän erottelun itsenäisiin ja uudelleen käytettäviin lohkoihin. Komponentteja voidaan luoda funktioiden lisäksi “ES6 class:ia” käyttämällä. Lisätietoa ES6 luokista: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Classes.

Props on lyhenne sanasta “Properties”. Propseja käytetään tiedonvälitykseen komponenttien välillä. Perusidea propseissa on se, että voit kirjoittaa yksittäisen komponentin, jota voidaan käyttää useassa eri paikassa sovellustasi. ”Parent” -komponetti, voi antaa sen sisällä olevalle ”Child”-komponentille propsit. ”Child”-komponentti voi siis sijaita myös eri tiedostossa kuin ”Parent”-komponentti. Periaatteessa propsit auttavat kirjoittamaan uudelleenkäytettävää koodia.

Reactin yksi ainoita tiukkoja sääntöjä on se, että luokkien tai funktioiden ei ole koskaan tarkoitus muokata omia propsejaan suoraan. Sen sijaan, että propsien arvoa muutettaisiin, muutetaan tilan arvoa eli ”State”. Tästä tarkemmin seuraavassa kappaleessa.

Tila eli ”State”

Tila initialisoidaan luokan konstruktorissa. Konstruktori on ainoa paikka, missä tilan arvo voidaan asettaa suoraan ilman siihen tarkoitettua setState()-funktiota tai hook:ia.

Sovelluksen tila voidaan siis päivittää käyttämällä setState()-funktiota tai State hook:ia käyttämällä. State hook:stä lisätietoa löytyy: https://reactjs.org/docs/hooks-state.html

Tila lyhyesti:

  • Tilaa ei saa päivittää suoraan, vaan siihen käytetään setState()-funktiota tai State hook:ia.
  • Konstruktori on ainoa paikka, jossa tilaan voidaan suoraan päivittää jokin arvo.
  • Tilaa voidaan päivittää asynkronisesti.
  • Tilan arvoja päivittämällä voidaan uudelleenrenderöidä komponentteja.

Yhteenveto

Tässä oli lyhyehkö katsaus Reactin perusteisiin, joiden on tarkoitus antaa lukijalle pientä näkemystä Reactin käytöstä teoriatasolla. Teille, joita React kiinnostaa enemmän ja haluatte käytännön esimerkkejä tai harjoituksia, voin suositella Helsingin yliopiston tarjoamaa Full Stack MOOC -kurssia. Kurssin sisältö on laaja ja tarjoaa hyvät perustaidot moderniin websovelluskehitykseen.

https://fullstackopen.com/

Lähteet ja lisää luettavaa

https://joinex.fi/react-hooks-react-blogi-part-2/

https://fullstackopen.com/osa1/reactin_alkeet

https://reactjs.org/docs/getting-started.html

https://reactjs.org/docs/introducing-jsx.html

https://reactjs.org/docs/state-and-lifecycle.html

https://medium.com/@thinkwik/why-reactjs-is-gaining-so-much-popularity-these-days-c3aa686ec0b3

Kirjoittajan Jukka Harkki kuva

Jukka Harkki

Fujitsu Technology Solutions

Caset • Teknologia

Fujitsu Technology Solutions – Jakeluketjun hallintaa

Read more
Kirjoittajan Jukka Harkki kuva

Jukka Harkki

Käyttöliittymien suunnittelu ja prototyyppaus Adobe XD:llä

Design • Teknologia

Käyttöliittymän suunnittelu on helppoa. Aluksi.

Kaikki lähtee asiakkaan ideasta, jossa käyttäjälle on kaavailtu uusia mahdollisuuksia. Kokenut koodari hahmottelee ajatusta hetken päässään, piirtelee karkeita kulkukaavioita siitä, mitä dataa kulkee minnekin, ja avaa lopulta koodieditorin. Käyttöliittymä ottaa muotoaan, mutta hetken päästä edessä on jokin seuraavista tilanteista:

  1. Käyttöliittymä ei näytä hyvältä.
  2. Haluttu toiminnallisuus onkin odotettua monimutkaisempi.
  3. Jokin toiminto on unohtunut.
  4. Asiakas ei pidä käyttöliittymästä.

Sorrun omassa työssäni valitettavan usein näihin tilanteisiin johtavaan ylimielisyyteen. Kuvittelen hahmottavani käyttöliittymään tarvittavat elementit ja niiden väliset vuorovaikutukset riittävän hyvin. Kuitenkin löydän itseni aina asettelemasta lomakkeiden virhe-elementtejä ja muita helposti unohdettavia komponentteja paikoilleen.

Sitten näytän lopputulosta asiakkaalle ja kaikki menee uusiksi.

Monen odottamattoman lisäyksen ja korjauksen jälkeen on alkuperäinen visio usein hämärtynyt ja koodipohja nopeiden korjausten jäljiltä hutera. Refaktorointiin palaa aikaa ja energiaa, eikä voi olla ajattelematta, miksi taas kerran jätti suunnittelun väliin.

Älä suinkaan koodaa käyttöliittymää suunnitelman pohjalla. Suunnittele käyttöliittymä mielummin epäonnistuneiden koodausyritysten pohjalta.

Mielekästä suunnittelua Adobe XD:llä

Suunnittelun mieltää usein liian raskaana prosessina. Toteutettava käyttöliittymä on kuitenkin yksinkertainen ja vastaavia on tullut tehtyä jo monia. Näkymiä ei vaivauduta piirtämään paperille, hitaasti aukeavan kuvankäsittelyohjelman käynnistämisestä puhumattakaan. Jonkinlaisista leiskoista olisi tietysti apua, kunnes niiden implisiittisiä interaktioita pitää alkaa erittelemään asiakkaalle.

Kevyeeseen suunnitteluun on onneksi olemassa työkaluja — sellaisia, joilla käyttöliittymien prototyyppauksesta on oikeasti hyötyä itselle, omalle tiimille ja asiakasinteraktiolle. Käsittelen tässä kirjoituksessa ilmaista Adobe XD ohjelmaa, joka on käytettävissä sekä Windows että MacOS laitteilla. Samat periaatteet pätevät varmasti sen kilpailijoihin, kuten Sketch, inVision ja Figma.

Adobe XD:llä työskentelyn tuloksena on käyttöliittymän interaktiivinen prototyyppi, jonka voi lähettää asiakkaalle arvioitavaksi tai kehittäjätiimille työn tueksi. Tein esimerkkinä kolmesta näkymästä koostuvan pyöräkaupan. Sen arviointiversiota voi kokeilla niin kuin se olisi valmis sovellus. Painikkeet johtavat oikeisiin näkymiin ja siirtymät ovat ainakin havainnollistavassa muodossa paikoillaan. Kehittäjäversiosta ilmenee mm. käytetyt värit, fontit, kuvat ja näkymien väliset siirtymät.

Kolme sovelluksen näkymää esitettynä rinnakkain. Kolmannesta näkymästä kulkee nuolia muihin näkymiin.
Esimerkkinä luodun pyöräkaupan prototyypin kehittäjäversio.

Kullanarvoista prototyypeissä on asiakkaan mahdollisuus kommentoida niitä täsmällisesti. Jos painikkeen väri häiritsee, asiakas voi kiinnittää siihen merkin ja ilmaista huolensa lyhyesti tekstillä. Enää ei tarvitse murehtia siitä, kuinka olette pitkään puhuneet samasta asiasta eri nimillä tai eri asioista samalla nimellä. Merkki näyttää täsmällisesti mistä on kyse.

Vasemmalla on kuva käyttöliittymästä, johon on kiinnitetty kaksi numeroitua merkkiä. Oikealla on merkkien numeroita vastaavat asiakkaan kommentit, joissa on parannusehdotuksia.
Kommentteja voi kohdistaa käyttöliittymään kiinnitettyihin merkkeihin.

Konkreettinen prototyyppi poistaa omista ajatusprosesseista ”näyttääköhän tämä hyvältä” vaiheen. Keskittymisen voi ohjata ratkaisemaan miten asiat toteutetaan eikä miltä ne näyttävät toteutettuna. Kun tietää mihin on menossa, koodia menee merkittävästi vähemmän hukkaan.

Seuraavassa Adobe XD artikkelissa sukelletaan sovelluksen perusteisiin ja opetellaan käyttöliittymän prototyypin luomista käytännössä!

Kirjoittajan Jukka Harkki kuva

Jukka Harkki