Hyviä käytäntöjä palvelun määrittelyyn liittyen

Käytännön hankkeissa havaittuja haasteita

Saavutettavuusvaatimukset toteutuvat palvelukehityshankkeissa kustannustehokkaasti vain, jos saavutettavuus huomioidaan koko palvelukehitysprosessin ajan. Syynä on, että vaikka WCAG-kriteeristo pääsääntöisesti keskittyy toiminnallisiin vaatimuksiin, jotka näkyvät mm. apuvälinekäyttäjille palvelun teknisen toteutuksen kautta, suuri osa WCAG- ja käytettävyyspuutteista juontaa kuitenkin jo koodausta edeltävästä määrittelystä tai jopa sen puuttumisesta.

Puutteellinen määrittely

Heikko määrittelytyö johtaa tilanteisiin, joissa kehittäjät ja suunnittelijat joutuvat jopa hyvinkin spontaanisti ja vähäisin taustatiedoin tekemään varsin ratkaisevaa määrittelytyötä ja sitä kautta palvelumuotoilua, jotta haluttu toiminnallisuus saadaan jotenkin kasaan halutussa aikataulussa. Projektin johdon taholta oletetaan, että kehittäjä tietää, miten kukin toiminnallisuus tulee toteuttaa, kunhan yleiset raamit ovat tiedossa, koska sehän on hänen työtään. Kehittäjän tehtävänä ei kuitenkaan tulisi olla palvelumuotoilu silloin, kun se ei nimenomaisesti hänen toimenkuvaansa kuulu ja kun hänellä ei ole riittävää tietoa kaikesta palvelun määrittelyaineistosta.

Seuraa, että käyttöliittymäratkaisujen teko vain ”valuu” kehittäjälle asti, sillä hän on se viimeinen etappi, jossa moneen kysymykseen on pakko ottaa kantaa, jotta toiminnallisuus voidaan toteuttaa. Esimerkkejä tällaisista ratkaisuista ovat sisältöjen tekninen selausjärjestys, teknisen modaalirakenteiden käyttö, ja miten käyttäjän selainkohdistusta tulisi kohdella erilaisissa verkkolomakkeisiin liittyvissä toiminnoissa. Kehittäjä voi myös joutua päättämään, miten sivun eri loogiset sisältöalueet tulisi esittää apuvälineiden näkökulmasta, kun ennen koodausta kukaan ei ole osannut edes ajatella asiaa – ja yhtäkkiä maamerkit on vain kirjoitettava koodiin, jotta testiversio saadaan ulos.

Vaikutuksia

Tällaisilla päätöksillä on kuitenkin suuri vaikutus palvelun käytettävyyteen ja ne tulisi tehdä palvelun määrittelyn ja sitä kautta seuraavaan suunnittelutyön puitteissa, jotta kunkin vaatimuksen parhaiten tuntevat henkilöt ovat varmasti mukana päätöksenteossa. Ongelma näyttää pätevän yhtä lailla ketterässä kuin perinteisemmässäkin kehitysprosessissa.

Määrittelyn työjaossa voi olla laajemminkin epäselvyyttä. Jos esimerkiksi palvelumuotoilija on dokumentoinut tiettyyn toimintoon liittyvän käyttöliittymän rakenteen (looginen sisältöjen järjestys, elementtien tyypit, alueet), niin voiko visuaalinen suunnittelija poiketa ohjeistuksesta, ja jos voi, niin missä puitteissa ja kenen mandaatilla? Jos kumpikin suunnittelija on eri alihankkijoita, niin kummalla on auktoriteetti? jos graafikolla on oikeus ottaa erivapauksia palvelumuotoiluun nähden, niin riskit mm. saavutettavuusvaatimusten toteutumisessa ja palvelun käytettävyydessä voivat olla merkittäviä, sillä hänellä ei ole välttämättä tietoa niistä perusteista, joiden valossa palvelumuotoilu on kussakin tilanteessa tehty ja joiden vuoksi pienikin poikkeama voi olla kriittinen.

Kun tällainen ”visu” tai proto sitten tulee kehittäjälle, voi hän joutua painimaan nyt puolestaan keskenään ristiriitaisen dokumentaation kanssa tai joutua tekemään jälleen täysin oman (nyt jo kolmannen eri henkilön) tulkinnan toiminnallisuuden vaatimuksista.

On selvää, että saavutettavuusvaatimusten toteutumista ei voida epäselvällä työjaolla ja määrittelyllä taata. Valitettavasti nämä ongelmat ovat yleisiä käytännön kehityshankkeissa.

Hyviä käytäntöjä

  1. Ota saavutettavuusvaatimukset mukaan heti alusta alkaen

Saavutettavuus ei ole erillinen saareke, tai projektin vaihe, joka suoritetaan muusta työstä erillään, vaan saavutettavuusvaatimukset muodostavat kiinteä osan palvelun normaalia vaatimusjoukkoa, johon lukeutuvat niin toiminnalliset (mitä yksittäisiä toimia palvelussa voi tehdä) kuin ei-toiminnalliset (esimerkiksi suorituskyky, responsiivisuus, selainversioiden tuki, jne.) vaatimukset.

  1. Hyödynnä käyttäjätarinoita ja tue määrittelyä käyttötapauksilla

Digipalveluiden määrittelyssä tehokas työkalu ovat käyttötapaukset ja käyttäjätarinat. Niistä on kerrottu tarkemmin moduulissa 2. Ne ovat oiva apu etenkin, jos tuntuu vaikealta hahmottaa, mitä eri saavutettavuusvaatimuksia palvelun kuhunkin toimintoon liittyy. Yleinen virhe onkin lähteä määrittämään vaatimuksia koko laajan WCAG-kriteeristön kautta ajatuksella, että ruksataanpa tästä kaikki, mitä tullaan tarvitsemaan. Se ei yleensä onnistu. Parempi tapa on miettiä vaatimuksia käyttäjien palvelussa tekemien toimintojen ja toimintopolkujen kautta. Silloin kriteerien löytäminen on paljon helpompaa.   

  1. Määritä roolit ja vastuut

Jo ennen käyttötapausten laatimista tai iterointi tulisi varmistettava, että alussa kuvatun kaltaisia vastuuepäselvyyksiä ei synny, kun määrittely, suunnittelu ja prototypointi käynnistyvät (usein rinnakkain ketterässä kehityksessä). Pohdi ja kirjaa:

  • Määritä, miten palvelumuotoilu, visuaalinen suunnittelu ja tekninen toteutus jakautuvat eri toimittajien tai resurssien kesken
    • Aseta palvelumuotoilulle ylin auktoriteetti, jota graafisen ja teknisen toteutuksen on seurattava niin, että toteutuksessa havaitut puutteet suunnittelussa kierrätetään aina päivitetyn suunnittelun kautta, eikä toteutuksessa tehdä itsenäisiä merkittäviä variaatioita suhteessa palvelumuotoilun ohjeistukseen ilman suunnittelijan tai suunnittelijaa konsultoivan ohjausryhmän lupaa.
    • Vaikka palvelumuotoilija ja/tai kehittäjä ja/tai graafikko voivat olla sama henkilö, tulisi merkittävät kehityksen aikaiset muutokset silti aina dokumentoida, jotta projektin ylläpito ja jatkokehitys, joka voi olla muiden ammattilaisten käsissä, onnistuu tehokkaasti, eikä jatkokehityksessä jätetä huomioimatta esimerkiksi keskeisiä, saavutettavuuteen liittyneitä ratkaisutapoja, jotka toteutusvaiheessa olivat ”itsestään selviä”.
  • Pyri, että palvelumuotoilijat, graafikot ja kehittäjät istuvat saman pöydän ääressä, kun palvelua määritetään.
    • Olisi erittäin hyvä, että ammattilaisten kesken perustetaan lisäksi avoin viestintäkanava, esimerkiksi Slack, jonka kautta he voivat keskustella myös palaverien ulkopuolella ilman turhaa byrokratiaa asioista, jotka vaikuttavat palvelun kehityksessä tehtäviin päätöksiin. Esimerkiksi graafikon ja palvelumuotoilijan tulisi voida kysyä koodaajilta, liittyykö ehdotettuun suunnitelmaan toteutuksen kannalta ongelmia tai piirteitä, jotka vaikuttavat, kannattaako sen kanssa edetä prototyyppiin tai käyttäjätestaukseen; tai onko ratkaisutapa A kustannustehokkaampi kuin tapa B, jne. Jos taas kehittäjä kokee tavan C fiksuimmaksi, tulisi hänen voida nopeastikin varmistaa graafikolta, onko siihen liittyvä CSS—muutos OK, jne.
    • Työtapa voi edellyttää, että se huomidaan jo kilpailutuksen ja budjetoinnin yhteydessä niin ajankäytön kuin kalenterivaraustenkin osalta. Kaikkien osapuolten tulisi olla ainakin jollakin tavoin käytettävissä koko projektin ajan, ei vain yksittäisissä elinkaarivaiheissa, jotta yhteistyö on mahdollista.
    • Toisaalta kokemus on osoittanut, että mitä tiiviimmin projektin eri ammattilaiset voivat tehdä yhteistyötä, sitä tehokkaampaa kehitys on, joten kustannusvaikutus voi olla kokonaisuudessa hyvin positiivinen.
    • Erityisen iso tehokkuusvaikutus on aina, kun saavutettavuusrikkomuksia voidaan ennalta estää jo kehitysvaiheessa eikä niitä jää enää auditointivaiheessa korjattavaksi.
  • Tutustu moduulin 6 saavutettavuusauditointiohjeeseen. Varaudu auditoinnin toteuttamiseen. Määritä, kenelle mahdolliset saavutettavuuspuutteiden korjaustyöt- ja kustannukset kuuluvat.
  1. Varaudu saavutettavuuden ylläpitoon palvelun julkaisun jälkeen.
  • Nimeä palvelun saavutettavuudelle omistaja. Hän vastaa, että palvelun saavutettavuusvaatimukset eivät unohdu tai niitä ei laiminlyödä, kun palveluun luodaan sisältöjä ja palvelua kehitetään.
    • Kokemus on osoittanut, että palvelujen saavutettavuus ei automaattisesti pysy julkaisuvaiheen tasolla. Esimerkiksi uudet sisällöt, kuten uudet HTML—sivut tai PDF—asiakirjat, voivat tahattomasti rikkoa palvelun omaa määrittelyä. Toisaalta jatkokehitys tulisi olla aina yhtä huolellista, kuin palvelun alkuperäinenkin toteutus, sillä siihen pätevät yhtä lailla lainmukaisuusvaatimukset. Lopuksi on syytä muistaa, että palvelun saavutettavuusseloste on päivitettävä säännöllisesti.
    • Saavutettavuuden omistajan tehtävänä on huomioida, että palvelun sisällöntuotanto noudattaa sille asetettuja ohjeita, ja että palvelun mahdollinen jatkokehitys ei ohita saavutettavuuslain vaatimuksia.
    • Jos käytössä on automaattinen työkalu palvelun saavutettavuuden monitorointiin, omistajalla tulisi olla siihen käyttöoikeus ja koulutus.
    • Omistaja myös ensisijaisesti vastaanottaa ja käsittele saavutettavuusselosteen kautta toimitetun saavutettavuuspalautteen.
  • Arvioi, tarvitaanko palvelun ylläpitoon saavutettavuuden monitorointityökalua ja onko sellainen mahdollista saada esimerkiksi puitesopimuksen kautta vaivattomasti käyttöön.
    • Jos voit hyödyntää saavutettavuuden automaattista monitorointia, määritä, kuka työkalua käyttää ja mitä resursseja ja velvoitteita tähän liittyy.
    • Esimerkiksi jos seurantatyökalu ilmoittaa sisällöntuotannosta tapahtuneista määrittelyrikkomuksista (palveluun on luotu sivuja, joista puuttuvat tekniset otsikkomääritykset tai ulkopuoliseen palveluun vievää linkkiä ei ole jollakin uudella sivulla merkitty oikein, tms.), määritä etukäteen, miten työkalun käyttäjä, kuten palvelun saavutettavuuden omistaja, voi tilanteeseen puuttua.

Alkuperäinen versio: Tero Pesonen / Siteimprove
Luotu: 3.4.2021