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. 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 tekemään nopeita ratkaisuja määrittelytyön ja sitä kautta palvelumuotoilun suhteen vailla tarvittavia taustatietoja. Projektin johto saattaa olettaa kehittäjien tietävän, miten kukin toiminnallisuus tulee toteuttaa, kunhan yleiset raamit ovat tiedossa. 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.

Seurauksena on, että käyttöliittymäratkaisujen tekeminen päätyy kehittäjille, sillä tässä vaiheessa ongelmat ovat ratkaistava ennen toiminnallisuuden toteuttamista. Esimerkkejä tällaisista ratkaisuista ovat sisältöjen tekninen selausjärjestys, teknisten modaalirakenteiden käyttö, ja miten käyttäjän selainkohdistusta tulisi kohdella erilaisissa verkkolomakkeisiin liittyvissä toiminnoissa. Kehittäjät voivat myös joutua päättämään, miten sivun eri loogiset sisältöalueet tulisi esittää apuvälineiden näkökulmasta, kun asiaa ei oltu harkittu ennen koodausta. Yhtäkkiä nämä ratkaisut on kirjoitettava koodiin, jotta testiversio saadaan valmiiksi.

Vaikutuksia

Tällaisilla päätöksillä on suuri vaikutus palvelun käytettävyyteen. Päätökset tulisi tehdä palvelun määrittelyn ja sitä kautta seuraavaan suunnittelutyön puitteissa. Tällöin 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ä kehitysprosessissa.

Määrittelyn työnjako voi olla epäselvää. Esimerkiksi, jos palvelumuotoilija on luonut käyttöliittymäsuunnitelman, joka yksityiskohtaisesti kuvaa sisällön loogisen järjestyksen, elementtityypit ja alueet, voiko visuaalinen suunnittelija tehdä muutoksia näihin ohjeisiin? Jos voi, missä määrin ja kenen hyväksynnällä? Jos kummatkin suunnittelijat ovat eri alihankkijoita, niin kummalla on auktoriteetti? Jos visuaaliselle suunnittelijalle annetaan lupa tehdä muutoksia, se voi vaarantaa palvelun saavutettavuuden ja käytettävyyden. Visuaalinen suunnittelija ei ehkä ymmärrä palvelusuunnittelun päätösten taustalla olevaa logiikkaa. Pienet poikkeamat voivat aiheuttaa merkittäviä vaikutuksia.

Kun tällainen visuaalinen suunnitelma tai prototyyppi toimitetaan kehittäjälle, hän saattaa joutua tulkitsemaan ristiriitaista dokumentaatiota tai ratkaisemaan nämä konfliktit itse, mikä johtaa taas uuteen tulkintaan toiminnallisista vaatimuksista.

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

Hyviä käytäntöjä

1. Ota saavutettavuusvaatimukset mukaan heti alusta alkaen

Saavutettavuus ei ole muusta työstä erillinen projektin vaihe. 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.

2. 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 niin, että kaikki vaatimukset pyritään sisällyttämään palveluun. 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.   

3. Määritä roolit ja vastuut

Jo ennen käyttötapausten laatimista 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. Toteutuksessa havaitut puutteet suunnittelussa kierrätetään aina päivitetyn suunnittelun kautta. Toteutuksessa ei tulisi tehdä merkittäviä muutoksia suhteessa palvelumuotoilun ohjeistukseen ilman suunnittelijan tai suunnittelijaa konsultoivan ohjausryhmän lupaa.
    • Vaikka palvelumuotoilija, kehittäjä ja graafikko voivat olla sama henkilö, tulisi merkittävät muutokset kehitystyön aikana silti aina dokumentoida. Tämä mahdollistaa tehokkaan ylläpidon ja tulevan kehityksen, johon saattaa osallistua muita ammattilaisia. Lisäksi dokumentointi auttaa välttämään tärkeiden saavutettavuusratkaisujen unohtumista, jotka saattavat tuntua itsestäänselviltä toteutusvaiheessa.
  • Pyri, että palvelumuotoilijat, graafikot ja kehittäjät istuvat saman pöydän ääressä, kun palvelua määritetään.
    • On suositeltavaa, että ammattilaisten välillä luodaan avoin viestintäkanava, kuten Slack. Tämän kautta he voivat keskustella myös palaverien ulkopuolella ilman turhaa byrokratiaa palvelun kehitykseen liittyvistä päätöksistä.
    • Esimerkiksi graafikon ja palvelumuotoilijan tulisi voida kysyä koodaajilta, liittyykö ehdotettuun suunnitelmaan toteutuksen kannalta ongelmia tai piirteitä, jotka vaikuttavat siihen, kannattaako suunnitelman kanssa edetä prototyyppiin tai käyttäjätestaukseen. Samoin heidän tulisi voida tiedustella, onko ratkaisutapa A kustannustehokkaampi kuin tapa B. Jos kehittäjä puolestaan kokee tavan C fiksuimmaksi, hänen tulisi voida nopeasti varmistaa graafikolta, onko siihen liittyvä CSS-muutos hyväksyttävä.
    • Työtapa voi edellyttää, että kilpailutuksen ja budjetoinnin yhteydessä otetaan huomioon esimerkiksi ajankäyttö ja kalenterivaraukset. Kaikkien osapuolten tulisi olla ainakin joillain tavoin käytettävissä koko projektin ajan, jotta yhteistyö on toimivaa. Saatavuus tulee huomioida projektin aikataulutuksessa ja resursoinnissa.
    • Toisaalta kokemus on osoittanut, että mitä tiiviimmin projektin eri ammattilaiset voivat tehdä yhteistyötä, sitä tehokkaampaa kehitys on. Työtavan kustannusvaikutus voi siis olla kokonaisuudessaan hyvin positiivinen.
    • Erityisen suuri kustannustehokkuus syntyy saavutettavuusrikkomusten ennaltaehkäisystä, joka tapahtuu kehitysvaiheessa. Muutoin rikkomukset jäävät auditointivaiheessa korjattavaksi.
  • Tutustu moduulin 6 saavutettavuusauditointiohjeeseen. Varaudu auditoinnin toteuttamiseen. Määritä, kenelle mahdolliset saavutettavuuspuutteiden korjaustyöt- ja kustannukset kuuluvat.

4. 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.
    • 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ä. Jatkokehityksen tulisi kuitenkin olla aina yhtä huolellista, kuin palvelun alkuperäinen 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 pitää huolta, 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äsittelee 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 havaitsee määrittelyrikkomuksia sisällöntuotannossa (kuten puuttuvat tekniset otsikkomääritykset tai väärin merkityt ulkopuoliset linkit uusilla sivuilla), määrittele etukäteen, miten työkalun käyttäjä, kuten palvelun saavutettavuusvastaava, voi korjata nämä ongelmat.

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