Saavutettavuusauditointi ja saavutettavuusselosteen laatiminen

Moduuli 6

  • Saavutettavuusauditoinnissa palvelun saavutettavuutta arvioidaan kokonaisuutena yksittäisiä komponentteja tai käyttöpolkuja laajemmin.
  • Auditointi perustuu lainsäädännön asettamiin vaatimuksiin. Työkaluna on mm. WCAG (Web Content Accessibility Guidelines) -kriteeristö.
  • Saavutettavuusmallin mukainen auditointi tuottaa ajantasaisen, lain edellyttämän saavutettavuusselosteen.

Saavutettavuusselostepohjat

Esimerkkiseloste Osin saavutettava sivusto (Word-asiakirja)Lataa
Esimerkkiseloste Laki ei edellyta saavutettavuutta (Word-asiakirja)Lataa
Esimerkkiseloste Sivustoa ei ole arvioituLataa
Esimerkkiseloste Saavutettava sivustoLataa

Laki velvoittaa Helsinkiä tuottamaan saavutettavia digitaalisia palveluja

Suomessa on voimassa Laki digitaalisten palvelujen tarjoamisesta (Valtionvarainministeriö, 1.4.2019), joka pohjautuu EU:n saavutettavuusdirektiiviin. Se velvoittaa viranomaisia, kuten Helsingin kaupunkia, toteuttamaan kaikki julkisesti saatavilla olevat digitaaliset palvelut (verkkosivustot, mobiilisovellukset) saavutettavasti. Laki määrittää saavutettavuuden teknisen ja visuaalisen toteutuksen kriteereinä, jotka palvelun tulee täyttää; kriteerit perustuvat edelleen kansainväliseen saavutettavuusstandardiin (WCAG, Web Content Accessibility Guidelines).

Web Content Accessibility Guidelines

WCAG—standardi asettaa joukon kriteerejä, joiden avulla palvelun saavutettavuutta arvioidaan. Kriteerit ovat konkreettisia, pääasiassa tekniseen ja visuaaliseen toteutukseen liittyviä vaatimuksia, jotka sijoittuvat standardissa joko A, AA tai AAA –tasolle. Laki edellyttää, että julkisen sektorin palvelujen tulee täyttää WCAG:n AA –tasolla, kutienkin niin, että AA kriteeriä 1.2.4, ”Tekstitys suorissa lähetyksistä”, ei tarvitse täyttää.

Laissa on joitain WCAG:n ulkopuolisiakin vaatimuksia, kuten edellytys, että palvelu on tietoturvallinen ja suorituskykyinen. Käytännössä Helsingin kaupungin tuottaman palvelun saavutettavuutta testataan kuitenkin WCAG—standardin perusteella, sillä lain edellyttämä saavutettavuusseloste perustuu myös WCAG—kriteerien toteutumiseen.

Saavutettavuusauditointi ja saavutettavuusseloste

Jokaisen Helsingin kaupungin julkaiseman palvelun tulee sisältää lain (linkki edellä) asettama saavutettavuusseloste. Seloste on julkinen ja se tarjotaan palvelun käyttäjien tiedoksi. Selosteessa kuvataan muun muassa palvelun saavutettavuuden tila – siinä mahdollisesti esiintyvät puutteet, ja poikkeukset sekä tietoa korjaussuunnitelmista – sekä tarjotaan kanava, jonka kautta käyttäjät voivat antaa palvelun saavutettavuuteen liittyvää palautetta. Tarkempia tietoja selosteen lakisääteisestä sisällöstä löytyy vastaavan viranomaisen, Aluehallintoviraston (AVI), verkkosivulta (www.saavutettavuusvaatimukset.fi).

Saavutettavuusauditoinnilla tarkoitetaan Helsingin saavutettavuusmallissa testausta, jossa todetaan ja raportoidaan, miten palvelu vastaa WCAG—standardin vaatimuksiin. Auditoinnissa perusteella pitää voida tuottaa palvelun saavutettavuusseloste. Auditointiraportin sisällöstä on kerrottu tarkemmin myöhemmin tässä asiakirjassa.

Mikäli auditointi tilataan ulkopuoliselta toimittajalta, tulee tilauksessa sopia, kuka saavutettavuusselosteen laatii. Malli suosittelee, että auditoija tuottaa selosteen yhteistyössä palvelun omistajan kanssa, jonka asiantuntemus palvelun taustoista, rajoitteista ja jatkokehityssuunnitelmista on avuksi selosteen muotoilussa.

Linkkejä Papunetin tarkistuslistaan
https://papunet.net/saavutettavuus

Toimittajan tulee tuntea menetelmät. Voi tehdä omana työnä, jos on käytettävissä hyvin WCAG:n ja apuvälineet tuntevia henkilöitä.

Saavutettavuusauditoinnin tilaaminen

Saavutettavuusauditoinnin toimittaja vastaa testauksessa käytettävien työkalujen ja menetelmien valinnasta ja niiden soveltuvuudesta WCAG–yhdenmukaisuustestaukseen. Tilaajan ei tarvitse osata määrittää testausprosessin asiantuntijatyöosia, ellei hän niin erityisesti halua tehdä.

Toimittajan vastuulla on siten myös hankkia tarvittavat tiedot palvelun testauksen kattavuuden varmistamiseksi. Tällaisia tietoja ovat esimerkiksi, mitä kirjautumista vaativia mutta yleisölle avoimia osia palvelussa on, ja kuuluvatko verkkosivuilla mahdollisesti olevat asiakirjat, kuten PDF—dokumentit, myös kyseisen auditoinnin piiriin, vai ovatko ne esimerkiksi jonkin toisen testausprosessin alaisuudessa.

Tarkempia tietoja, mitkä asiakirja- ja mediasisällöt sekä organisaation intranetjärjestelmät kuuluvat saavutettavuuslainsäädännön piiriin, on AVIn verkkosivulla (www.saavutettavuusvaatimukset.fi). Tarkempia tietoja lisätään myös saavutettavuusmallin ohjeistukseen maaliskuun 2021 aikana.

Saavutettavuustestauksen tulosten raportointi

Saavutettavuusauditoinnin tuloksena tilaajalle toimitetaan raportti, jossa kerrotaan, miltä osin palvelu ei täytä WCAG—kriteerejä.

Jokaista yksittäistä WCAG—rikkomusta ei tarvitse eritellä, jos rikkomus toistaa jo raportoitua ilmentymää. Toisin sanoen riittää, että raportissa on tieto, missä palvelun osissa WCAG—rikkomus toistuu. Esimerkiksi havaittu puute voi koskea tietyllä sivupohjalla aina toistuvaa elementtiä, jolloin jokaista yksilöllistä sivua, jossa elementti on, ei tarvitse listata, vaan riittää tieto, että ongelma toistuu kaikkialla, missä elementtiä palvelussa käytetään.

WCAG—rikkomuksista raportoidaan ainakin alla olevat, vaadituksi merkityt tiedot. Suosituksiksi merkittyjä tietoja ei ole pakko raportoida.

  • Vaatimus: Missä rikkomus palvelussa esiintyy. Suositus: Raporttiin on liitetty kuvakaappaus, joka osoittaa ilmiön palvelussa.
  • Vaatimus: Mihin WCAG-kriteeriin tai kriteereihin havaittu puute liittyy.
  • Vaatimus: WCAG-rikkomus luokitellaan vaikuttavuuden mukaan. Mittarina on, miten merkittävä saavutettavuusongelman vaikutus on palvelun käyttäjiin. Kategorisoinnin tarkoituksena on auttaa palvelun omistajaa priorisoimaan mahdollisia korjaus- ja jatkokehitystöitä sen mukaan, miten palvelun tosiasiallinen saavutettavuus tehokkaimmin paranee. Kategoriat ovat: Kriittinen, merkittävä ja vähäinen.
    • Kriittinen saavutettavuuspuute: Ongelma voi kokonaan estää osaa palvelun käyttäjistä suorittamasta palvelun toimintoja. Esimerkiksi jos sivun banneriosan kielivalikkoa ei voi avata näppäimistöselauksessa, on puute (WCAG 2.1.1) kriittinen.
    • Merkittävä saavutettavuuspuute: Ongelma heikentää palvelun käytettävyyttä varsinkin erityisryhmille, mutta ei välttämättä estä sitä. Esimerkiksi jos palvelu tuottaa sivulle ilmoituksen, joka kertoo, että käyttäjälle on saapunut lukematon viesti, ja ilmoitusta ei välitetä avustavalle teknologialle live—, status—, tai alert –ilmoituksena, mutta ilmoitus on silti sivulta löydettävissä (WCAG 4.1.3), on kyseessä merkittävä, mutta ei kriittinen puute.
    • Vähäinen saavutettavuuspuute: Ongelma rikkoo WCAG—kriteeristöä ja on siten saavutettavuuslain piirissä, mutta sen vaikutus palvelun käytettävyyteen on lievä. Esimerkiksi jos sivustolla käytettäviä otsikoita olisi joiltain osin tarkennettava tai selkiytettävä, voi kyseessä olla WCAG 2.4.6 –kriteerin rikkomus, jonka vaikutus jää varsin vähäiseksi.
  • Vaatimus: Raportissa on kuvattava sanallisesti, millä perusteella raportoitu puute rikkoo WCAG:tä. Käytännössä lukijan tulee voida ymmärtää kuvauksesta, miten ongelma esiintyy ja miksi esiintymä ei ole osoitetun kriteerin mukainen. Siten pelkkä WCAG—rikkomusten listaaminen tai taulukointi (kriteeri ei täyty / täyttyy) ei riitä.
  • Suositus: Raportin olisi hyvä tarjota myös korjausehdotus jokaiselle raportoidulle saavutettavuuspuutteelle. Tilaajan kannalta korjausehdotukset- ja ohjeet voivat olla ensiarvoisen hyödyllisiä, etenkin, jos tilaajan käytössä ei ole vielä riittävää, kehittäjille tarjolla olevaa saavutettavuusasiantuntemusta.
  • Suositus: Toimeksiantoon sisällytetään raportin läpikäynti yhdessä testauksen tilaajan ja toimittajan kesken. Raporttityöpajassa tilaajan on mahdollista kysyä ja keskustella kirjatuista havainnoista ja mm. korjaustavoista, jotka kuhunkin tilanteeseen parhaiten sopivat.

Esimerkki: WCAG—rikkomuksen raportointi

Ohjeen lopuksi on laadittu esimerkki, miten yksittäinen WCAG—puute voidaan raportoida edellä asetettujen vaatimusten mukaisesti. Tässä esitetty tapa on esimerkki, eikä sido toimittajaa jäsentelyn tai sisällön määrän osalta, mutta voi toimia tilaajalle ohjenuorana, minkä tyyppistä raportointitapaa testaukselta voi kohtuudella edellyttää.

Ennen raportointia

Saavutettavuusasiantuntija testaa verkkopalvelua työpöytänäkymässä. Hän havaitsee, että sivuston navigointivalikkoa ei voi lainkaan kohdistaa näppäimistöselauksessa sarkaimella. Kun hän tämän perusteella testaa valikkoa seuraavaksi ruudunlukuohjelmalla, huomaa hän, että sen avulla valikon voi kyllä avata, mutta valikon tilasta ei välity apuvälineelle tietoa eikä valikon sisältö seuraa painiketta selausjärjestyksessä. Lisäksi valikkopainikkeen saavutettava nimi (”Valikko”) poikkeaa painikkeessa visuaalisesta olevasta tekstistä (”Menu”).

Testaaja toteaa, että valikon toteutus rikkoo ensitutkimalta ainakin seuraavia WCAG—kriteerejä:

  • 2.1.1 Näppäimistö
  • 2.4.3 Kohdistusjärjestys
  • 2.5.3 Nimilappu nimessä
  • 4.1.2 Nimi, rooli, arvo

Testausraporttiin tehdään heti seuraavat havainnot.

Työpöytänäkymä / Sivuston päänavigointivalikko: Valikkopainiketta ei voi kohdistaa näppäimistöllä (kriittinen)

Kohde

Sivuston toistuva banneriosio > päänavigointivalikon avaava painike, jossa teksti ”Menu”.

Kuvaus

Kun käyttäjä toimii palvelussa pelkän näppäimistön varassa ilman hiirtä tai ruudunlukuohjelmaa, ja liikkuu sivulla sarkainnäppäimellä, navigointivalikkopainike ei ole kohdistettavissa.

Vaikutus

Ongelma on kriittinen, sillä se estää näppäimistöllä tai näppäimistörajapintaa käyttävien apuvälineiden varassa toimivia henkilöit avaamasta sivuston navigointivalikkoa, mikä edelleen estää palvelun hakutoiminnon suorittamisen sekä mahdollisesti myös pääsyn osaan palvelun alasivuista. Ongelma ei koske ruudunlukuohjelmia, sillä ne tuottavat painikkeelle hiiren tapaan onclick—tapahtuman.

WCAG

2.1.1. Näppäimistö (A)

Korjausehdotus

  • Asetetaan valikkopainikkeelle tabindex=”0” -attribuutti, joka tekee <span>–elementin näppäimistökohdistettavaksi.
  • Varmistetaan samalla (koska tätä ei testauksessa voitu todeta), että painikkeella on näppäimistötapahtumakäsittelijä, joka suorittaa valikon avaamisen, kun käyttäjä painaa Enteriä (keyCode 13) tai välilyöntiä (keyCode 32). Varmistetaan myös, että välilyönti ei painikkeen kohdalla aktivoi selaimen oletustoimintoa, joka on sivun vieritys alaspäin (event.preventDefault()).
  • Tarkistetaan, että valikkopainike osoittaa näppäimistökohdistuksen joko järjestelmän oletusindikaattorilla, tai jos indikaattoria on räätälöity sivun tyyleissä, tavalla, joka näkyy CSS :focus –tilassa (esim. outline –property). Räätälöidyn kehysindikaattorin tulee tuottaa 3:1 –tummuuskontrastisuhde sivun taustan kanssa. Jos indikaattorina on pelkkä painikkeen taustavärin muutos, on värieron oltava 3:1—tummuuskontrastisuhteen suuruinen.

Työpöytänäkymä / Sivuston päänavigointivalikko: Avattu valikko sijoittuu epäloogisesti sivun selausjärjestyksessä (merkittävä)

Kohde

Sivuston toistuva banneriosio > päänavigointivalikko, joka on avattuna > valikkopaneeli.

Kuvaus

Avatun valikon sisältö (valikkopaneeli) sijoittuu sivun selausjärjestyksessä vasta banneriosion jälkeen, eikä seuraa heti valikkopainiketta, kun käyttäjä selaa sivua eteenpäin. Sen sijaan painiketta seuraa välittömästi kielivalikko (joka on bannerissa painikkeen oikealla puolen). Navigointivalikko sijoittuu DOMissa vasta kelivalikon jälkeen, banneriosion ulkopuolelle. Syynä ongelmaan on, että avustavat teknologiat ja näppäimistöselaus noudattavat sivun DOM—järjestystä, eivät sen visuaalista taittoa (CSS asetteluja), ja valikon toteutuksessa tätä ei ole ehkä osattu huomioida.

Vaikutus

Ongelma hankaloittaa palvelun käyttöä selvästi henkilöille, jotka toimivat sivulla näppäimistöön perustuvan ohjauslaitteen tai ruudunlukuohjelman varassa. Ilman näönvaraista kontekstia toimiva käyttäjä voi jopa luulla, että valikko ei avautunut lainkaan, tai että kielivalikko on sen sisässä, mikä poikkeaa sivun todellisesta jäsennyksestä. Toisaalta valikko on löydettävissä sivulta heti bannerin jälkeen, joten sen käyttö ei kokonaan esty.

WCAG

  • 2.4.3 Kohdistusjärjestys (A)

Korjausehdotus

Valikkopaneeli tulee sijoittaa DOM—järjestyksessä heti painikkeen jälkeen, kun valikko on avattuna. Esimerkiksi seuraava rakenteellinen muutos pitäisi korjata ongelman:

Valikkopainike suljettuna:

<nav class=”navigation-region”>
<span id=”navigation-menu-button” …>Manu<img ..></span>
</nav> 

Valikkopainike avattuna:

<nav class=”navigation-region”>
<span id=”navigation-menu-button” …>Manu<img ..></span>
<div class=”navigation-menu-panel”>
<ul><li><a …>… <li>…</ul>
</div>
</nav>

Toisin sanoen luodaan valikkopainikkeelle ja -paneelille yhteinen vanhempi, jonka DOMiin kummatkin sijoitetaan, kuitenkin niin, että valikkopaneeli ei ole painikkeen lapsitägi vaan samalla DOM—tasolla sen kanssa (element sibling). Tällöin selausjärjestys on automaattisesti oikea, eikä mikään valikon ulkopuolinen sisältö pääse ”kiilaamaan niiden väliin” ja siten sotkemaan järjestystä. Samalla navigointialue saa myös oman maamerkin (nav—tägi, joka vastaa role=”navigation” –roolia) eikä kumpikaan elementti vahingossa vuoda maamerkin ulkopuolelle.

Loput edellä kuvatut puutteet (aria-expanded –attribuutin puuttuminen, ja nimilappu nimessä) raportoidaan vastaavasti.

Sinua saattaa kiinnostaa myös

Saavutettavuuden käyttäjätestaus

Toteutus ja ohjelmistotestaus

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