Ajankohtaista

Pakkopullaa vai kaikkien etu? Näin kehität verkkopalvelusi saavutettavuutta tehokkaasti

Kirjoittanut Jussi Rajaniemi | 13.10.2021

Digitaalisten palveluiden, eli verkkosivujen ja mobiilisovellusten, tulisi olla kaikkien ulottuvilla. Kolme vuotta sitten astui voimaan digipalvelulaki, jonka myötä saavutettavuudesta tulikin pakollista julkisen hallinnon ja tiettyjen muiden toimijoiden verkkopalveluissa.

Saavutettavuus ei ole vain pienen väestön ongelma, vaan se koskee tavalla tai toisella noin 15 prosenttia väestöstä. Saavutettavuus on kuitenkin ennen kaikkea hyvää palvelua kaikille – myös ihminen, jolla ei ole aistirajoitteita, hyötyy merkittävästi saavutettavuudesta. Esimerkiksi mobiililaitteilla auringon paisteessa suuri fontti- ja kontrasti parantaa tekstin luettavuutta.

Mutta mistä sitten tietää, onko saavutettavuudessa onnistuttu? Olemme havainneet, että saavutettavuusvaatimusten arviointiin eli saavutettavuusauditointeihin liittyy melkoisia ristiriitaisuuksia. 

Joten me auditoimme saavutettavuusauditoinnit. Tässä tekstissä kerromme löydöksistämme ja siitä, kuinka hoidat saavutettavuutta jatkossa entistä tehokkaammin.


Saavutettavuuden auditointi ja löydösten arvottaminen

Web Content Accessibility Guidelines (WCAG), eli suomeksi verkkosisällön saavutettavuusohjeet, on kansainvälinen ohjeistus verkkosisältöjen saavutettavuudesta. WCAG-kriteerit on jaettu kolmeen tasoon eli A-, AA- ja AAA-tason kriteereihin. Lain mukaan julkisten toimijoiden verkkopalveluiden on täytettävä kriteerit A- ja AA-tasoilla.

Saavutettavuuden auditoinnit perustuvat WCAG-kriteereille ja etenevät yleensä viidessä vaiheessa:

  1. Verkkopalvelu esitellään ulkoiselle auditoijalle 
  2. Auditoija suorittaa verkkopalvelulle saavutettavuusauditoinnin
  3. Auditoija esittelee löydökset ja korjausehdotukset. Korjausehdotukset on merkitty tasokriteereillä 1–4:
    • 4 taso on erittäin tärkeä ja se estää palvelun keskeisen toiminnon käytön täysin
    • 3 taso on tärkeä ja se häiritsee tai hidastaa merkittävästi palvelun käyttöä
    • 2 taso on kohtalainen ongelma, joka häiritsee tai hidastaa palvelun miellyttävää käyttöä
    • 1 taso on vähäinen ongelma, joka häiritsee tai hidastaa palvelun miellyttävää käyttöä
  4. Kaikki 3–4  tason ja yleensä myös useimmat 1–2 tason saavutettavuusongelmista korjataan
  5. Lopuksi tehdään tarkistusauditointi, jolla varmistetaan, että kaikki korjaukset on tehty

 

Kolmannes auditointien löydöksistä jää huomaamatta

Toteutimme kolme erillistä projektia, joissa käytettiin samoja käyttöliittymäkomponentteja. Ensimmäisessä projektissa kaikki käyttöliittymän komponentit korjattiin auditoijan ohjeiden mukaisesti saavutettaviksi. Näin ollen näiden komponenttien pitäisi tulevissa projekteissa läpäistä saavutettavuusauditoinnit heittämällä.

Seuraava projekti käynnistyi ja valmistui aikataulussa, mutta suurin yllätys tuli saavutettavuusauditoinnissa: aikaisemmin toteutetut saavutettavat komponentit eivät täyttäneet enää WCAG AA-kriteerejä? Kun sama ongelma toistui myös kolmannessa projektissa, päätimme tehdä oman saavutettavuusauditointien auditoinnin, jossa tutkittiin, miksi komponentit eivät läpäisseet uusia auditointeja. Tässä havainnot tutkimuksesta:

  • 50 % oli oikeita ja korjausta vaativia löydöksiä
  • 21 % oli ulkoisesta tai muuten perusteltavasta syystä johtuvia löydöksiä
  • 29 % oli löydöksiä, joita ei aikaisemmin löydetty tai pidetty merkittävinä

Oikeiden ja korjausta vaativien löydösten (50 %) tyypillisin syy oli palvelun semanttisen rakenteen muutokset. Eli vaikka yksittäinen komponentti oli saavutettava, ei HTML5-toteutuksen rakennetta, kuten otsikointia tai lista- ja taulukkomuotoiluja, oltu muutoksen jälkeen enää toteutettu oikein. Näiden korjausten tekeminen oli ehdottomasti tärkeää.

Ulkoisista tai muista perustelluista syistä (21 %) johtuvat ongelmat liittyivät tyypillisesti kielikäännöksiin tai esimerkiksi päivämäärä- ja aikakomponentteihin, joissa oli jouduttu tekemään kompromisseja eri tavoin toimivien verkkoselaimien takia. Kielikäännökset ovat ongelmallisia siinä tapauksessa, jos rajapinnasta eli APIsta ei saada tietoa siitä, millä kielellä teksti on tuotettu. Niinpä suomenkielisessä palvelussa voi olla englanninkielistä tekstiä, jota ruudunlukija lukee “suomeksi”.

Kiinnostavinta on kuitenkin tuo kolmas ryhmä. Kaikista löydöksistä 29 % oli löydöksiä, joista ei tullut kommenttia aikaisemmissa auditoinneissa. Yksi erikoisimmista esimerkeistä oli hakutoiminnallisuuteen tehty kolmostason löydös, jota ei havaittu kahdessa aikaisemmassa auditoinnissa. Auditointien taso saattaa siis auditoijasta riippuen vaihdella merkittävästi.

Osassa löydöksiä auditoijien näkemykset vaihtelivat hieman. Esimerkkinä tästä mainittakoon tapaus, jossa ensimmäinen auditoija arvioi löydöksen kakkostason ongelmaksi, mikä ei tällöin aiheuttanut toimenpiteitä. Seuraava auditoija nosti löydöksen kolmostason tärkeäksi ongelmaksi. Tämä osoittaa, että auditoinneissa saatetaan tulkita WCAG-kriteerejä hieman eri tavoin.

Design-systeemillä tehokkuutta saavutettavuuteen

Onko saavutettavuusauditointi siis vain rahastusta, jossa löydöksiä tehdään vain löydösten takia? 

Me emme usko näin. Näin koodarin näkökulmasta kaikki auditointien löydökset olivat kyllä objektiivisesti aitoja ongelmia. Silti niiden merkittävyyden määrittäminen on tulkinnanvaraista. Lisäksi se, että vasta kolmas auditointi paljastaa komponentin toimivan väärin, kuvastaa täydellisesti saavutettavuuden vaikeutta: virheet ovat hyvinkin konkreettisesti piilossa silmiltä. 

On luonnollisesti jo pelkästään verkkopalvelun budjetoinnin näkökulmasta erittäin vaikeaa, jos auditoinneissa löytyy aina kolmannes uusia havaintoja, kun odotat kaiken olevan jo kunnossa. 

Saavutettavuuden kehitystä voi kuitenkin merkittävästi tehostaa, kun muistaa seuraavat vinkit:

  1. Varmista tiimin senioriteetti: Saavutettavuus kehittyy jatkuvasti, kun kehittäjät löytävät yhä monipuolisempia teknisiä ratkaisuja saavutettavien komponenttien toteuttamiseksi. Esimerkiksi eräs Alfamen kehittäjistä ratkaisi saavutettavan verkkopalvelun kestohaasteen eli saavutettavan karusellin.

    Kokeneet kehittäjät keräävät kasvavaa henkilökohtaista tietopankkiaan siitä, kuinka tyylikäs ja helppokäyttöinen komponentti toteutetaan saavutettavasti. He ovat oppineet kiertämään tietyt sudenkuopat ja voivat auttaa nuorempia kehittäjiä välttämään samat virheet. Saavutettavuus ei siis ole projekti vaan subjektiivinen oppimisprosessi, joka ei tule koskaan valmiiksi.
  2. Älä keksi pyörää uudelleen: Jos saavutettavuus on oppimisprosessi, miksi antaisit kehittäjiesi lyödä yksi kerrallaan päänsä samaan seinään? Organisaatiosi verkkopalveluiden käyttöliittymäsuunnittelu tehostuu pitkällä aikavälillä merkittävästi, kun investoit design-systeemiin.

    Design-systeemi, kuten esimerkiksi suomi.fi Design System, kerää organisaatiosi verkkopalvelusuunnittelun parhaat käytännöt ja saavutettavuudeltaan testatut komponentit samaan paikkaan. Käytännössä design-systeemi on siis uudelleenkäytettävien komponenttien kirjasto sekä ohjeistus siitä, miten komponentteja käytetään erilaisissa tilanteissa.

    Design-system ei siis palvele pelkästään yksittäisiä verkkopalveluita, vaan sen avulla koko yrityksen komponenttikirjasto on kaikkien eri verkkopalveluiden parissa työskentelevien kehittäjien hyödynnettävissä.

    Toisin sanoen: saavutettavuus on subjektiivinen oppimisprosessi, mutta design-systeemin avulla varmistat, että organisaatiosi parhaat opit tulevat hyödynnettyä verkkopalveluissa kauttaaltaan, eikä samaa ongelmaa ratkota toisaalla päivästä ja vuodesta toiseen.
  3. Muista maalaisjärki ja verkkopalvelun tarkoitus: Vaikka saavutettavuus on olennainen osa moderneja verkkopalveluita, on kuitenkin hyvä muistaa maalaisjärki ja muodostaa oman organisaatiosi prioriteetit saavutettavuudelle.

    Olemme jo todenneet, että saavutettavuuden arviointi on aina tulkinnanvaraista. WCAG-kriteerien pilkuntarkka noudattaminen ei myöskään aina palvele käyttäjiä parhaiten, vaan usein pitkälle viety saavutettavuus aiheuttaa kompromisseja palvelun käytettävyyteen.

    Verkkopalvelua pitäisikin aina tarkastella kyseisen palvelun tarkoituksesta käsin: ketä varten ja mihin tarkoitukseen palvelu on luotu? Jos siis puhutaan kuviin perustuvasta palvelusta, kuten Instagramista, ei sivuston saavutettavuuteen ruudunlukijalla kannata välttämättä panostaa, kerran palvelun sisältö itsessään on kuvamuodossa.