WCAG-kriteerit ym­mär­ret­tä­väs­ti – näin teet si­vus­tos­ta­si saa­vu­tet­ta­van

Tässä oppaassa käyn läpi kaikki Digipalvelulain piirissä olevat 49 WCAG-kriteeriä. Kriteerit ovat WCAG-ohjeistuksen matalinta A-tasoa sekä keskitasoa AA. Selvennän, mitä kullakin kriteerillä tarkoitetaan, ja annan esimerkkejä siitä, miksi kriteeri on tärkeä, sekä siitä, miten kriteerin asettamiin tavoitteisiin päästään.

Muista, että lainsäädäntö ei velvoita tekemään sivustosta heti täydellisesti saavutettavaa. On myös ymmärrettävää, mikäli jokin korjaus aiheuttaisi kohtuuttoman rasitteen olemassa olevan sivuston ylläpitäjälle.

Se, mitä jokaisen lain piirissä olevan sivuston kohdalla kuitenkin täytyy tehdä, on selvittää kriteerien valossa sivustolla olevat saavutettavuusongelmat, ja kertoa niistä kävijöille saavutettavuusselosteessa. Lisäksi kävijöille tulee tarjota mahdollisuus raportoida kohtaamiaan haasteita. Kun haasteet ovat tiedossa, sivuston ylläpitäjän tulee arvioida niiden korjaamisen kohtuullisuus sekä aikataulu, jossa korjaukset olisivat mahdollisia. Lisää lain vaatimuksista AVI:n sivuilla.

Huomioi, että ohjeet perustuvat kirjoitushetkellä voimassaolevaan WCAG 2.1 -kriteeristöön. W3C työstää tällä hetkellä uutta, WCAG 2.2 -ohjeistusta, mutta sen julkaisuaikataulusta ei ole tarkkaa tietoa. Kirjoitimme aiheesta aiemmin täällä.

Kriteerien osa-alueet

Kriteerit on jaettu neljään osa-alueeseen: Havaittava, Hallittava, Ymmärrettävä ja Toimintavarma.

Havaittava ottaa nimensä mukaisesti eniten kantaa visuaalisiin asioihin ja siihen, että käyttäjä saa sivuston kaikista elementeistä riittävästi informaatiota riippumatta siitä, millä tavalla hän sivustoa lukee.

Tällä tarkoitetaan sekä omin silmin sivua katselevaa ja lukevaa kävijää että kävijää, joka hyödyntää apunaan ruudunlukijaa – ohjelmaa, joka kirjaimellisesti lukee käyttäjälle ääneen, mitä sivulla on. Tämä osa-alue on ehdottomasti kaikista raskain, niin kriteeristön kuin auditointienkin osalta. Vedä henkeä välillä, loppuosa kirjoituksesta on lyhyempi.

Hallittava osa-alue perehtyy erityisesti sivuston näppäimistökäyttöön sekä tekstisisältöön, kuten hyvään otsikointiin ja linkkiteksteihin. Tarkoituksena on, että kävijä tietää, mitä esimerkiksi linkeistä ja painikkeista tapahtuu, niitä painamatta. Kaiken sisällön tulee olla yhtä lailla käytettävissä sekä hiirellä että pelkällä näppäimistöllä.

Ymmärrettävä ja Toimintavarma ovat osa-alueita, jotka liittyvät enimmäkseen kooditason asioihin, jotka eivät aina ole kävijöille näkyviä. Siitä huolimatta kyse on tärkeistä asioista, sillä myös ne vaikuttavat kävijän kokemukseen olennaisesti. Näissä osa-alueissa on eniten teknistä sisältöä, jota voi olla vaikea ymmärtää, ellei osaa koodata. Mikäli lukijana on sivustokehittäjä, tieto voi kuitenkin olla kullanarvoista.

• Siirry suoraan osa-alueeseen Hallittava tästä
• Siirry suoraan osa-alueeseen Ymmärrettävä tästä
• Siirry suoraan osa-alueeseen Toimintavarma tästä
• Siirry kirjoituksen lopun vinkkeihin tästä

1. Havaittava

Informaatio ja käyttöliittymäkomponentit pitää esittää tavoilla, jotka käyttäjä voi havaita.

Tämä osa-alue käsittää tasolla AA (Digipalvelulaki) seuraavat kriteerit:

• 1.1 Tekstivastineet
• 1.2 Aikasidonnainen media
• 1.3 Mukautettava
• 1.4 Erottuva

1.1 Tekstivastineet

Tarjoa tekstivastineet kaikelle ei-tekstuaaliselle sisällölle siten, että sisältö voidaan muuttaa muihin tarvittaviin muotoihin, kuten isokokoiseksi tekstiksi, pistekirjoitukseksi, puheeksi, symboleiksi tai yksinkertaisemmaksi kieleksi.

Käytännössä tällä tarkoitetaan mm. kuvia, hymiöitä ja tekstiä esittäviä kuvia eli kuvamuodossa olevaa tekstiä.

Kriteeri 1.1.1. Ei-tekstuaalinen sisältö (A)

Kaikki käyttäjälle esitettävä ei-tekstuaalinen sisältö on varustettu saman tarpeen täyttävällä tekstivastineella. Katso lista poikkeuksista W3C:n sivuilta.

Tämä on mielestäni (ainakin sivuston auditoinnin kannalta) hieman hassu kriteeri, koska se sisältää useita asioita. Käytännössä lista vaatimuksista on tämä:

1. Olennaista informaatiota sisältäville kuville on tarjottu tekstivastine. Olennaista informaatiota on esimerkiksi tieto, jota kävijä tarvitsee ymmärtääkseen sivuston sisältöä, ohjeen sisältävä kuva tai havainnollistava kuvitus. Hyvä esimerkki tällaisesta kuvasta on kartta: jos et tiedä, mitä kartassa on, jäät paitsi todella olennaista tietoa.Vinkki: yritä päätellä kuvan olennaisuus miettimällä, mitä informaatiota kuva välittää lukijalle. Kun informaatio on tunnistettu, arvioi sen tärkeyttä. Saako saman informaation myös muualta tekstimuotoisena? Jos kuva ei ole ainoa saman informaation lähde, sen tärkeys informaationvälittäjänä vähenee.
2. Sisällöllisesti epäolennaisille kuville on annettu tyhjä vaihtoehtoinen teksti tai toteutettu ne taustakuvina. Epäolennainen kuva ei sisällä kävijälle mitään tärkeää tietoa, vaan toimii esimerkiksi koristeena tai tunnelmanluojana. Nykyaikana suurin osa nettisivustoilla olevista kuvista on tällaisia.
3. Linkitetyillä kuvilla tai kuvapainikkeilla on tekstivastine.
4. Lomakkeiden kentät on nimetty oikealla tavalla (label-arvot). Label on lomakekentän yhteydessä näkyvä kentän nimi tai otsikko. Kentästä tulee siis saada tekstimuodossa tieto siitä, mitä mihinkin kenttään on tarkoitus kirjoittaa.
5. Muulle ei-tekstimuotoiselle sisällölle on annettu tekstivastine. Ota huomioon kaikki erilaiset toiminnot, joita sivustolla on. Esimerkiksi sivustohaun hakukenttä on usein sellainen, jonka yhteydessä ei ole näkyvää tekstiä; oletetaan kävijän ymmärtävän, mitä tyhjä kenttä sivuston oikeassa yläreunassa tarkoittaa. Kaikki kävijät eivät tätä kuitenkaan ymmärrä. Toiset eivät sivulla vieraillessaan tiedä kentän sijaintia, eivätkä voi sen avulla tehdä päätelmiä.
6. Lomakeroskapostia eliminoiva ns. CAPTCHA-toiminto on toteutettu saavutettavasti tai se on pois käytöstä. CAPTCHAn toteuttaminen saavutettavasti on käsittääkseni tällä hetkellä lähes mahdotonta. Odotan innolla, että 3. osapuolen jättiyritykset, joiden palvelut ovat laajasti käytössä, huomioisivat saavutettavuuden tekemisissään. Tätä saamme vielä odottaa.

Tekstivastine voidaan toteuttaa, elementistä riippuen, esimerkiksi…

1. Vaihtoehtoisena tekstinä (alt text). Tämä ei ole sama asia, kuin kuvateksti: vaihtoehtoinen teksti ei oletuksena näy visuaalisesti sivustolla, paitsi jos kuvaa ei jostain syystä voitu ladata. Sisällönsyöttäjä pääsee tyypillisesti tähän käsiksi sivustolla jokaisen kuvan osalta, poislukien somejakopainikekuvat ja muut vastaavat, jotka tulevat sivustolle automaattisesti koodista. Huomattavaa on, että vaihtoehtoinen teksti on yksi erittäin tärkeä osa sivuston SEOa. Vaihtoehtoista tekstiä syöttäessä tulisi siis miettiä sekä saavutettavuutta että SEO-näkökulmaa toimivan tekstin löytämiseksi. Koska saavutettavuusnäkökulmasta vain olennaista sisältöä sisältävillä kuvilla tulee olla tämä teksti, tällaisia kuvia, joissa kuvailevaa tekstiä mietitään molemmista näkökulmista, on tyypillisellä asiakkaamme sivustolla varsin vähän. Toisaalta, saavutettavuusnäkökulmasta ei-olennaisilla kuvilla ei tulisi olla vaihtoehtoista tekstiä lainkaan – tässä saavutettavuus ja SEO menevät siis eri suuntiin. Neuvoni on miettiä tapauskohtaisesti, kumpi on minkäkin kuvan kohdalla tärkeämpää: se, ettei kuva häiritse ruudunlukijakäyttäjää, vai se, että kuva nostaa sivuston SEO-arvoa.
2. ARIA-labelina. Tämä tulee syöttää käsin koodissa jokaiselle elementille erikseen. ARIA-label ei näy visuaalisesti sivustolla mitenkään, ja sen tarkoitus onkin palvella ruudunlukijakäyttäjiä.
3. Tekstimuotoinen ohje tai kuvailu kuvan yhteydessä. Vaihtoehtoiseen tekstiin ei kannata änkeä kokonaista ohjeistusta – toteuta se mieluummin omana tekstikappaleenaan kuvan yhteyteen. Myös näkevä kävijä arvostaa tiedon sanallistamista.
4. Ääniraita tai video. Mikäli kuvan selittäminen tekstimuodossa vie valtavasti tilaa sivulta, kannattaa harkita saman tiedon ilmaisemista ääniraidan tai videon avulla. Esimerkiksi kartan kuvailu puhtaassa tekstimuodossa ei välttämättä ole järkevää (ellei kyse ole todella yksinkertaisesta kartasta). Tällöin äänitetty sanakartta on oivallinen vaihtoehto. Linkitä kuvailutiedosto tai lisää video heti kuvan yhteyteen, jotta tieto on kaikille kävijöille samassa järjestyksessä ja helposti saatavilla. Huom! Ota tätä toteuttaessasi huomioon aikasidonnaisen median kriteerit (1.2).

1.2 Aikasidonnainen media

Tarjoa vastine aikasidonnaiselle medialle. Aikasidonnaisella medialla tarkoitetaan esimerkiksi liikkuvaa kuvaa tai ääntä. Tallennetulla medialla tarkoitetaan ei-live-muotoista mediaa, eli tiedostoa, joka on tehty valmiiksi ja tuotu sitten sivustolle.

Suorien lähetysten tekstitystä koskeva AA-tason kriteeri 1.2.4 ei kuulu Digipalvelulain piiriin. Tämänhetkinen lainsäädäntö ei siis velvoita tekstittämään suoria lähetyksiä.

Kriteeri 1.2.1 Pelkkä audio tai pelkkä video (tallennettu) (Taso A)

Mikäli audio tai video on tekstin mediavastine (kts. kriteeri 1.1.1), ja selvästi merkitty sellaiseksi, tätä kriteeriä ei tarvitse ottaa huomioon kyseisen mediaelementin osalta – vastine toimii molempiin suuntiin.

Tallennettu pelkkä audio

Tarjolla on vastine aikasidonnaiselle medialle, joka esittää vastaavan sisällön kuin tallennettu pelkkä audiosisältö. Toisin sanoen ääniraita, esim. podcast-jakso, tulisi litteroida tekstimuotoon.

Kokeile: Jos et kuule, mitä äänitiedostossa tapahtuu, saatko saman informaation luettavassa muodossa?

Tallennettu pelkkä video

Tarjolla on joko vastine aikasidonnaiselle medialle tai audiotiedosto, joka esittää vastaavan informaation kuin tallennettu pelkkä videosisältö. Toisin sanoen videosisältö tulisi kirjoittaa auki tekstimuotoon tai lisätä äänite videolla visuaalisesti tapahtuvista asioista.

Videolla tarkoitetaan tässä yhteydessä mediaa, jonka välittämä informaatio on esitetty pelkästään kuvamuodossa. Esimerkkinä animaatiovideo ilman ääniraitaa.

Ideana on siis, että pelkästään visuaalisesti esitetty informaatio tulee tarjota myös muussa muodossa. Jos et näe, mitä videolla tapahtuu, saatko saman tiedon ääniraidasta tai ruudunlukijan lukemasta tekstistä?

Kriteeri 1.2.2 Tekstitys (tallennettu) (Taso A)

Kaikelle synkronoidussa mediassa olevalle tallennetulle audiosisällölle on tarjolla tekstitys. Synkronoidulla medialla tarkoitetaan mediakokonaisuutta, joka sisältää sekä kuvaa että ääntä. Esimerkiksi animaatiovideo, jossa on ääniselostus.

Tämän kriteerin tarkoituksena on mahdollistaa kaiken informaation välittyminen myös niille ihmisille, joilla on vaikeuksia kuulla ääntä. Kaikki äänisisältö, mukaan lukien kuuluvat äänet, jotka eivät ole puhetta, tulee esittää videon tekstityksenä.

Huom! Tekstitystä ei tulisi polttaa kiinni videoon. Mikäli videoalusta sen vain mahdollistaa, tekstitys tulee liittää videolle erillisenä tekstitystiedostona, joka synkronoidaan videosisältöön. Tämä on mahdollista ainakin YouTubessa. Mikäli tekstitys on toteutettu suosittelemallani tavalla, se on saavutettavissa myös esim. ruudunlukijaohjelmalla.

Mikäli media on tekstin mediavastine (kts. kriteeri 1.1.1), ja selvästi merkitty sellaiseksi, tätä kriteeriä ei tarvitse ottaa huomioon kyseisen mediaelementin osalta – vastine toimii molempiin suuntiin.

Kriteeri 1.2.3 Kuvailutulkkaus tai mediavastine (tallennettu) (Taso A)

Digipalvelulain sisältäessä myös tason AA, tämä kriteeri käytännössä korvautuu kriteerillä 1.2.5.

Synkronoidulle medialle on tarjolla aikasidonnaisen median vastine tai tallennetun videosisällön kuvailutulkkaus. Kun edeltävä kriteeri huolehti kuulohaasteiden kanssa elävistä, tämän tarkoituksena on välittää kaikki informaatio myös ihmisille, joilla on haasteita näkökyvyn kanssa. Sekä kuvaa että ääntä sisältäville videoille tulee siis lisätä tekstitys, mutta myös vastine, jossa kuvataan tekstimuodossa kaikki videolla tapahtuva.

Aikasidonnaisen median vastineessa välitetään lukijalle kaikki videolla tapahtuva informaatio. On tärkeää, että videon tapahtumat – niin äänessä kuin kuvassa – on järjestetty vastineeseen samalla tavalla, kuin ne tapahtuvat videolla. Kuvailutulkkaus on ääniraidalle lisätty kerronta, joka välittää kaiken sen informaation, joka pelkän alkuperäisen ääniraidan varassa jäisi puuttumaan.

Huom! Kuvailutulkkauksen voi toteuttaa myös tekstitysraidalle, mikäli tekstitys on toteutettu edellisessä kriteerissä suosittelemallani tavalla. Tärkeintä on, että kaikki informaatio välittyy joko lisätyn ääniraidan tai ruudunlukijan välityksellä.

Mikäli videon ääniraita sisältää jo kaiken visuaalisesti välittyvän tiedon tai media on tekstin mediavastine (kts. kriteeri 1.1.1), ja selvästi merkitty sellaiseksi, tätä kriteeriä ei tarvitse ottaa huomioon kyseisen mediaelementin osalta.

Kriteeri 1.2.5 Kuvailutulkkaus (tallennettu) (Taso AA)

Kaikelle synkronoidussa mediassa olevalle tallennetulle videosisällölle on tarjolla kuvailutulkkaus. Katso lisätietoja edellisestä kriteeristä.

1.3 Mukautettava

Tuota sisältöä, joka voidaan esittää eri tavoin (esimerkiksi yksinkertaisemman asettelun avulla), ilman sisällön tai rakenteen menettämistä.

Kriteeri 1.3.1 Informaatio ja suhteet (Taso A)

Esitystavassa välittyvät informaatio, rakenne ja suhteet voidaan selvittää ohjelmallisesti tai ne ovat saatavilla tekstinä.

Tällä viitataan pääasiassa koodipuolen asioihin. Tarkemmin sanottuna esimerkiksi otsikointiin sekä lomakkeen pakollisiin kenttiin, linkkeihin, listauksiin ja muihin tapoihin esittää sisältöä ja eritellä sitä toisistaan. Kooditasolla kyse on semanttisista elementeistä ja niiden oikeasta käytöstä.

Tärkeää on kuitenkin myös huolehtia siitä, että kullakin sivulla otsikkohierarkia on merkitty oikein, eikä otsikoita ole otsikkotyylin sijaan merkitty esimerkiksi boldaamalla. Samaten mitään, mikä ei ole otsikko, ei tulisi sellaiseksi merkitä – tekstiä korostamaan voi käyttää tekstityylejä, kuten boldausta tai kursiivia. Tämä on sisällönsyöttäjien käsissä.

Oikea otsikkojärjestys on H1, H2, H3, H4 jne. Yhden pääotsikon (H1) alla voi toki olla useampi H2-väliotsikko ja samaten väliotsikoiden alla voi olla useampia lisäotsikointeja. Olennaista on, että otsikkotyylien järjestys on looginen ja se tukee sisällön ymmärtämistä.

Kriteeri 1.3.2 Merkitykseen vaikuttava järjestys (Taso A)

Kun sisällön esitysjärjestys vaikuttaa sisällön merkitykseen, oikea lukemisjärjestys voidaan selvittää ohjelmallisesti.

Tämä liittyy myös koodiin, eikä juurikaan vaikuta sisällönsyöttäjien tekemisiin. Poikkeuksena se, että sisältöä järjestäessä numeroituihin luetteloihin tai kappaleisiin, järjestyksen tulee olla looginen: toinen kappale tulee ensimmäisen jälkeen, jne.

Koodissa asioita ei saisi järjestää vain tyylittämällä, koska tällöin esimerkiksi ruudunlukijakäyttäjä ei saa tietoa sisällön oikeasta järjestyksestä. Mikäli sisältö on oikeassa järjestyksessä HTML-koodissa, asia on tämän kriteerin osalta ok.

Kriteeri 1.3.3 Aistinvaraiset ominaispiirteet (Taso A)

Ohjeet sisällön ymmärtämiseksi ja hallitsemiseksi eivät riipu yksinomaan komponenttien aistinvaraisista ominaispiirteistä kuten muoto, koko, visuaalinen sijainti, suunta tai ääni.

Tämä liittyy nimenomaan sisällöntuotantoon ja -syöttöön. Kun ohjeistat käyttäjää esimerkiksi tiedon löytämisestä tai jonkin elementin käytöstä, älä jätä ohjetta vain aistinvaraisten elementtien varaan. Mikäli esimerkiksi haluat käyttäjän painavan painiketta, joka on sininen ja jossa lukee ”Kirpputorilöydöt”, muista kirjoittaa myös painikkeen teksti ohjeeseen auki – älä pelkästään painikkeen väriä. Näin ihminen, joka ei näe tai ymmärrä painikkeen väriä, erottaa sen muista elementeistä ja löytää etsimänsä.

Huom! Jotta logiikka toimii, on tärkeää, että kullakin elementillä on uniikki teksti. Tästä lisää osiossa 2.4 Navigoitava.

Kriteeri 1.3.4 Asento (Taso AA)

Sisältöä ei ole rajoitettu vain tiettyyn näyttölaitteen asentoon kuten pysty- tai vaakasuuntaan, lukuun ottamatta tapausta, jossa tietty asento on olennainen. Tapauksia, joissa tietty näyttölaitteen asento on olennainen, ovat esimerkiksi šekki, pianosovellus, esitysdiat projektoria tai televisiota varten tai virtuaalitodellisuuden sisältö, joihin kahdensuuntainen näyttölaitteen asento ei sovellu.

Tämä kriteeri on aika yksiselitteinen: huolehdi siitä, että sisältöä voi katsella laitteiden eri asennoissa. Kokeile katsella sivua esimerkiksi mobiililaitteella, ja ota näkymän automaattinen kääntö käyttöön asetuksista. Jos sisältö mukautuu erilaisiin asentoihin, kaikki on kunnossa.

Miksi tämä on tärkeää? Kriteeri ottaa huomioon esimerkiksi käyttäjän, jolla älypuhelin on kiinnitetty pyörätuoliin niin, että sen asentoa ei voi vaihtaa selaillessa.

Vähemmän tärkeä, mutta mielestäni hieno vaikutus on, että kriteeri antaa käyttäjälle mahdollisuuden valita, millä tavalla tämä haluaa milläkin hetkellä sivustoa selata. Itse pidän kokkaillessa puhelinta usein vaaka-asennossa, koska reseptin teksti on suurempaa (responsiivisella sivustolla se asemoituu koko näkymän levyiseksi) ja puhelin on helpompi asetella pysymään paikallaan lukuasennossa. Mikäli sivusto toimii vain pystyasennossa, teksti on puhelimen näytöllä kauempaa katsottuna kohtuuttoman pientä, ja sormin zoomaaminen epäkätevää jokaisen rivin kohdalla.

Kriteeri 1.3.5 Määrittele syötteen tarkoitus (Taso AA)

Käyttäjän tietojen keräämiseen tarkoitettujen syötekenttien tarkoitus voidaan selvittää ohjelmallisesti. Kriteeri tulee ottaa huomioon silloin, kun käyttötarkoitus on listattu W3C:n Syötteen tarkoitukset käyttöliittymäkomponenteissa -osiossa (englanniksi) ja kun sisällön toteutuksessa on käytetty teknologiaa, joka mahdollistaa syöte-elementin tarkoituksen kuvaamisen.

Lomakkeet on rakennettava niin, että jokaisella yksittäisellä kentällä on koodissa merkittynä kentässä kysyttävän informaation tarkoitus. Tämä helpottaa avustavaa teknologiaa käyttävän kävijän lisäksi myös tietojen automaattista täyttöä selaimessa.

Lue lisää eri toteutustapojen eroista täältä (englanniksi).

1.4 Erottuva

Helpota käyttäjiä näkemään ja kuulemaan sisältö sekä erota etuala taustasta.

Kriteeri 1.4.1 Värien käyttö (Taso A)

Väriä ei käytetä ainoana visuaalisena keinona informaation välittämisessä, toiminnon esittämisessä, vastauksen pyytämisessä tai visuaalisen elementin erottamisessa.

Värin lisäksi elementin eri tiloja, kuten hoverointia (kursori elementin päällä) ja tehtyä valintaa voi esittää esimerkiksi alleviivauksella tai elementin isommalla koolla. Sama pätee erilaisiin elementteihin: esimerkiksi linkeissä on usein alleviivaus erottamassa sen muusta, ympäröivästä tekstisisällöstä.

Kriteeri 1.4.2 Audion kontrollointi (Taso A)

Jos jokin ääni verkkosivulla soi automaattisesti kauemmin kuin kolme sekuntia, käytettävissä on joko mekanismi äänen keskeyttämiseen tai pysäyttämiseen tai mekanismi äänen voimakkuuden säätämiseksi koko järjestelmän äänenvoimakkuuden tasosta riippumatta.

Koska mikä tahansa sisältö, joka ei täytä tätä onnistumiskriteeriä, voi haitata käyttäjän mahdollisuuksia käyttää koko sivua, täytyy kaiken verkkosivun sisällön (riippumatta siitä käytetäänkö sitä täyttämään muita onnistumiskriteereitä vai ei) täyttää tämä onnistumiskriteeri. Katso W3C:n sivuilta ohjeidenmukaisuuden vaatimus 5: Häiriöttömyys.

Henkilökohtaisesti välttäisin automaattisesti soivan äänen käyttöä sivustolla viimeiseen asti. Mikäli tällainen toteutus tarvitsee kuitenkin tehdä, anna kävijälle mahdollisuus pysäyttää ääni. Helpoiten tämä onnistuu siihen tarkoitetulla painikkeella, joka on helposti huomattavissa ja ymmärrettävissä.

Kriteeri 1.4.3 Kontrasti (minimi) (Taso AA)

Tekstin ja tekstiä esittävien kuvien visuaalisen esitystavan kontrastisuhde on vähintään 4,5:1.

Poikkeukset:

• Isokokoisessa tekstissä ja isokokoista tekstiä esittävissä kuvissa kontrastisuhde on vähintään 3:1
• Oheissisältö
• Logotyypit

Huono kontrasti estää elementtien erottamisen toisistaan esimerkiksi värisokeilla ja huononäköisillä kävijöillä. Kahden värin välisen kontrastisuhteen voi tarkistaa näppärästi esimerkiksi tällä työkalulla.

Kriteeri 1.4.4 Tekstin koon muuttaminen (Taso AA)

Lukuun ottamatta tekstitystä ja tekstiä esittäviä kuvia, tekstin kokoa voidaan muuttaa ilman avustavaa teknologiaa aina 200 prosenttiin asti ilman sisällön tai toiminnallisuuden menettämistä.

Huomaa, että kriteerillä tarkoitetaan nimenomaisesti vain tekstisisällön kokomuutosta, ei koko sivun zoomausta. Kriteeri pätee niin valikkolinkkeihin kuin painikkeen teksteihinkin, ei siis pelkästään leipätekstiin. Tekstin suurennus auttaa erityisesti heikkonäköisiä, mutta myös muita kävijöitä tilanteessa, jossa verkkosivuille valittu tekstifontti on kooltaan poikkeuksellisen pientä.

Osassa selaimista, kuten Firefoxissa, tekstikoon suurentaminen onnistuu helposti selaimen asetuksista. Itse käytän tätä työkalua sivujen testaamiseen tämän ja kriteerin 1.4.12 osalta, koska työkalu ottaa huomioon molemmat kriteerit. Työkalu on kokeellinen, mutta on ainakin toistaiseksi tuntunut toimivalta omassa käytössä.

Kriteeri 1.4.5 Tekstiä esittävät kuvat (Taso AA)

Jos käytetty teknologia voi tuottaa visuaalisen esityksen, informaation välittämiseen käytetään ennemmin tekstiä kuin tekstiä esittäviä kuvia.

Poikkeukset:

• Tekstiä esittävä kuva voidaan visuaalisesti mukauttaa käyttäjän vaatimusten mukaisesti
• Tietty tekstin esitystapa on olennainen välitettävän informaation kannalta

Kapulakielisen kriteerin ydin on tässä: vältä tekstiä esittäviä kuvia. Logoja saa käyttää normaalisti.

Kriteeri 1.4.10 Responsiivisuus (Taso AA)

Sisältö voidaan esittää ilman sisällön tai toiminnallisuuden menettämistä ja ilman kahdensuuntaista vierittämistä, kun

• pystysuuntaan vieritettävän sisällön leveys on 320 CSS-pikseliä
• Vaakasuuntaan vieritettävän sisällön korkeus on 256 CSS-pikseliä

Poikkeuksena sisällön osat, jotka vaativat kahdensuuntaista esitystapaa käytön tai merkityksen vuoksi.

Huolehdi siitä, että kaikki sisältö on samalla tavalla käytettävissä (responsiivinen) ilman ylimääräistä vierityspalkkia, vaikka sivua zoomaisi 400 % asti. Tässä kriteerissä on kyse koko sivun, ei pelkän tekstin, zoomauksesta.

Vierityspalkki on sallittu esimerkiksi taulukoissa, kuvissa, kartoissa ja diagrammeissa.

Kriteeri 1.4.11 Ei-tekstimuotoisen sisällön kontrasti (Taso AA)

Seuraavanlaisten elementtien visuaalisessa esitystavassa kontrastisuhde viereiseen väriin/väreihin on vähintään 3:1:

• Visuaalinen informaatio, joka vaaditaan käyttöliittymäkomponentin ja sen eri tilojen tunnistamiseen, lukuun ottamatta inaktiivisia komponentteja tai jos käyttäjäagentti määrittelee uuden sisällön visuaalisen esitystavan ja sisällön tuottaja ei ole sitä muokannut
• Grafiikan osat, joita vaaditaan sisällön ymmärtämiseksi, lukuun ottamatta tapauksia, joissa ulkoasu on olennainen tietosisällön välittämiseksi

Nyt tarkoitetaan siis elementtejä, jotka eivät ole tekstiä, mutta ovat olennaisia sisällön hahmottamisen kannalta. Esim. painikkeen taustaväri – jos et näe, minkä kokoinen painike on, et tiedä, miltä alueelta klikata sitä. Tarkista eri elementtien värikontrastisuhde esimerkiksi sivun taustaan ja muihin viereisiin väreihin. Tekstien osalta asia on jo tarkistettu kriteerissä 1.4.3, joten tekstiin ei tarvitse enää verrata.

Huono kontrasti estää elementtien erottamisen toisistaan esimerkiksi värisokeilla ja huononäköisillä kävijöillä. Kahden värin välisen kontrastisuhteen voi tarkistaa esimerkiksi tällä työkalulla.

Kriteeri 1.4.12 Tekstin välistys (Taso AA)

Sisällössä, joka on toteutettu käyttäen merkkauskieliä ja joka tukee seuraavia tekstin muotoilun ominaisuuksia, sisältöä tai toiminnallisuutta ei menetetä, jos asetetaan kaikki seuraavat muuttamatta mitään muuta tyylimääritystä:

• Riviväliksi (rivin korkeudeksi) vähintään 1,5 kertaa kirjasinkoko
• Kappaleen jälkeisen tyhjän tilan kooksi vähintään 2 kertaa kirjasinkoko
• Kirjainväliksi vähintään 0,12 kertaa kirjasinkoko
• Sanojen väliksi vähintään 0,16 kertaa kirjasinkoko

Katso poikkeus kriteeriin W3C:n sivuilta.

Tekstin tulee olla responsiivista myös välistyksen osalta. Nämä asetukset voivat auttaa esimerkiksi lukihäiriöistä tekstin lukemisessa ja ymmärtämisessä. Tarkista, että kokemus säilyy eheänä myös näillä muutoksilla.

Itse käytän tätä työkalua sivujen testaamiseen tämän ja kriteerin 1.4.4 osalta, koska työkalu ottaa huomioon molemmat kriteerit. Työkalu on kokeellinen, mutta on ainakin toistaiseksi tuntunut toimivalta omassa käytössä.

Kriteeri 1.4.13 Sisältö osoitettaessa tai kohdistettaessa (Taso AA)

Jos osoittimen vieminen elementin päälle tai kohdistuksen siirtäminen elementtiin tuo näkyviin lisää sisältöä ja osoittimen tai kohdistuksen pois siirtäminen piilottaa sisällön, seuraavat ehdot pätevät:

• On olemassa mekanismi, jolla näkyviin tulleen sisällön saa piilotettua siirtämättä osoitinta tai kohdistusta, lukuun ottamatta tapausta, jossa sisältö on syötevirheestä kertova teksti tai se ei peitä tai korvaa muuta sisältöä
• Jos osoittimen vieminen elementin päälle tuo näkyviin uutta sisältöä, osoitin voidaan viedä ilmestyneen sisällön päälle aiheuttamatta sen katoamista
• Uusi sisältö pysyy näkyvissä, kunnes osoitin tai kohdistus on siirretty pois, käyttäjä on piilottanut sisällön tai sen sisältö ei enää päde

Poikkeus: käyttäjäagentti määrittelee uuden sisällön visuaalisen esitystavan, eikä sisällön tuottaja ole sitä muokannut. Käyttäjäagentin määrittämä esitystapa on esimerkiksi selaimen työkaluvihjeet, jotka on toteutettu HTML:n title-attribuutin avulla.

Muokatut työkaluvihjeet, alavalikot ja muut ei-modaaliset ponnahdusikkunat ovat esimerkkejä sisällöstä, joka kuuluu tämän kriteerin alaan.

Kursorin vieminen jonkin elementin päälle saattaa tuoda esiin lisätietoikkunan (tooltip). Mikäli näin on, lisätietoikkunan käyttäytyminen tulee toteuttaa tässä kriteerissä määritellyllä tavalla. Yleinen tapa piilottaa lisätietoikkuna on näppäimistön Esc-painike.

Usein se kohta kriteerissä, joka tarvitsee eniten huomiota, on listan keskimmäinen. Käytännössä se tarkoittaa sitä, että lisätietoikkunalle on joko asetettu viive, tai määritetty alue, jolla se pysyy näkyvissä. Tämä on tärkeä huomioida erityisesti niitä kävijöitä ajatellen, joilla on jokin hienomotoriikkaan liittyvä haaste. Mikäli käsi esimerkiksi tärisee, on todella turhauttavaa yrittää saada pienestäkin liikkeestä katoava lisätietoikkuna pysymään esillä niin pitkään, että sen ehtii lukea.

Kannattaa varautua siihen, että kriteereihin liittyvä teksti on hyvin lakitekstimäistä ja paikoitellen vaikeaselkoista. Tulkinta-apua kannattaa pyytää asiantuntijoilta konsultoinnin muodossa.

2. Hallittava

Käyttöliittymäkomponenttien ja navigoinnin pitää olla hallittavia.

Tämä osa-alue käsittää tasolla AA (Digipalvelulaki) seuraavat kriteerit:

• 2.1 Käytettävissä näppäimistöltä
• 2.2 Tarpeeksi aikaa
• 2.3 Sairauskohtaukset
• 2.4 Navigoitava
• 2.5 Syötetavat

2.1 Käytettävissä näppäimistöltä

Toteuta kaikki toiminnallisuus siten, että se on käytettävissä näppäimistöltä.

Kriteeri 2.1.1 Näppäimistö (Taso A)

Kaikki sisällön toiminnallisuus on hallittavissa näppäimistön välityksellä ilman vaatimusta yksittäisten näppäinpainallusten erityisestä ajoittamisesta. Poikkeuksena tilanne, jossa taustalla oleva toiminnallisuus vaatii syötettä, joka riippuu käyttäjän liikkeiden reitistä eikä vain päätepisteistä, esim. piirtäminen.

Toisin sanoen, sivustoa ja sen kaikkia elementtejä on pystyttävä käyttämään pelkällä näppäimistöllä.

Kriteeri 2.1.2 Ei näppäimistöansaa (Taso A)

Jos kohdistus voidaan siirtää sivun komponenttiin näppäimistön kautta, niin kohdistus voidaan siirtää myös pois kyseiseltä komponentilta pelkästään näppäimistörajapintaa käyttämällä.

Mikäli tämä vaatii muuta kuin pelkkien nuoli- tai tab-näppäimien tai muiden standardinmukaisten poistumismenetelmien käyttämistä, käyttäjälle neuvotaan menetelmä kohdistuksen poissiirtämiseksi.

Koska mikä tahansa sisältö, joka ei täytä tätä onnistumiskriteeriä, voi haitata käyttäjän mahdollisuuksia käyttää koko sivua, täytyy kaiken verkkosivun sisällön (riippumatta siitä, käytetäänkö sitä täyttämään muita onnistumiskriteereitä vai ei) täyttää tämä onnistumiskriteeri. Katso W3C:n sivuilta ohjeidenmukaisuuden vaatimus 5: Häiriöttömyys.

Tämän kriteerin tarkoituksena on estää tilanne, jossa pelkkää näppäimistöä käyttämällä jää johonkin kohtaan sivustolla jumiin.

Kriteeri 2.1.4 Yhden merkin pikanäppäimet (Taso A)

Jos sisältöön on toteutettu näppäinoikotie, joka käyttää vain yhtä kirjain- (mukaan lukien pienet ja isot kirjaimet), välimerkki-, numero- tai symbolinäppäintä, vähintään yksi seuraavista pätee:

• On olemassa mekanismi, jolla näppäinoikotien voi ottaa pois käytöstä
• On olemassa mekanismi, jolla näppäinoikotie voidaan määritellä uudelleen käyttämään yhtä tai useampaa komentonäppäintä (Ctrl, Alt jne.)
• Tietylle käyttöliittymäkomponentille tarkoitettu näppäinoikotie on käytössä vain, kun kohdistus on kyseisessä komponentissa

Pikanäppäimet, joissa käytetään vain yhtä painiketta, saattavat mennä päällekkäin esimerkiksi tietokoneen, selaimen tai ruudunlukijan toimintojen kanssa. Kävijä saattaa myös vahingossa painaa väärää näppäintä, etenkin, jos käsissä on vapinaa.

2.2 Tarpeeksi aikaa

Anna käyttäjille tarpeeksi aikaa lukea ja käyttää sisältöä.

Kriteeri 2.2.1 Säädettävä ajoitus (Taso A)

Jokaiselle sisällön asettamalle aikarajalle ainakin yksi seuraavista pitää paikkansa:

• Käyttäjä voi kytkeä aikarajan pois päältä ennen sen täyttymistä
• Käyttäjän sallitaan säätää aikarajaa ennen sen kohtaamista laajalla asteikolla, joka on vähintään kymmenen kertaa oletusasetuksen pituus
• Käyttäjää varoitetaan ennen ajan loppumista, annetaan vähintään 20 sekuntia aikaa aikarajan jatkamiseen yksinkertaisen toiminnon avulla (esimerkiksi, ”paina välilyöntiä”) ja käyttäjän sallitaan jatkaa aikarajaa vähintään kymmenen kertaa

Poikkeukset:

• Aikaraja on reaaliaikaisen tapahtuman vaadittu osa (esimerkiksi huutokaupan), ja vaihtoehto aikarajalle ei ole mahdollinen
• Aikaraja on olennainen, ja sen pidentäminen mitätöisi toiminnon
• Aikaraja on yli 20 tuntia

Kriteeri auttaa varmistamaan, että käyttäjät voivat saattaa tehtävät valmiiksi, ilman odottamattomia, aikarajasta johtuvia muutoksia sisällössä tai kontekstissa. Tätä onnistumiskriteeriä tulisi tarkastella yhdessä Onnistumiskriteerin 3.2.1:n kanssa, joka rajoittaa käyttäjän toiminnasta johtuvia sisällön tai kontekstin muutoksia.

Kehitysvammaliiton Papunet-palvelun sanoin: jos sivulla tai sovelluksella on aikaraja, onko käyttäjän mahdollista kytkeä aikaraja pois päältä, säätää sitä tai jatkaa sitä?

Mikäli aikarajan jälkeen sivulle tapahtuu jotain, esimerkiksi käyttäjä kirjataan ulos sivustolta, sivuston tulisi aikarajan loputtua kysyä, tarvitseeko käyttäjä lisää aikaa. Mikäli käyttäjä ei vastaa kysymykseen, käyttäjän voi kirjata ulos. Mitään ei saisi tapahtua automaattisesti, ilman, että käyttäjällä on mahdollisuus vaikuttaa tapahtumaan.

Kriteeri 2.2.2 Tauota, pysäytä, piilota (Taso A)

Kaikki seuraavat pitävät paikkansa liikkuvalle, vilkkuvalle, vierivälle tai automaattisesti päivittyvälle informaatiolle:

• Kaikelle liikkuvalle, vilkkuvalle tai vierivälle informaatiolle, joka (1) käynnistyy automaattisesti, (2) kestää yli viisi sekuntia ja (3) esitetään rinnakkain muun sisällön kanssa, on olemassa mekanismi, jonka avulla käyttäjä voi tauottaa, pysäyttää tai piilottaa sen, paitsi silloin kun liikkuminen, vilkkuminen tai vieriminen on olennainen osa toimintoa ja
• Kaikelle automaattisesti päivittyvälle informaatiolle, joka (1) käynnistyy automaattisesti ja (2) esitetään rinnakkain muun sisällön kanssa, on olemassa mekanismi, jonka avulla käyttäjä voi keskeyttää, pysäyttää tai piilottaa sen tai hallita sen päivitystiheyttä, paitsi silloin kun automaattinen päivittyminen on olennainen osa toimintoa

Koska mikä tahansa sisältö, joka ei täytä tätä onnistumiskriteeriä, voi haitata käyttäjän mahdollisuuksia käyttää koko sivua, täytyy kaiken verkkosivun sisällön (riippumatta siitä, käytetäänkö sitä täyttämään muita onnistumiskriteereitä vai ei) täyttää tämä onnistumiskriteeri. Katso W3C:n sivuilta ohjeidenmukaisuuden vaatimus 5: Häiriöttömyys.

Sellaisesta sisällöstä, jota ohjelmisto ajoittain päivittää tai jota käyttäjäagentti lataa syötevirrasta, ei vaadita tallentamaan tai esittämään informaatiota, joka on luotu tai vastaanotettu tauon ja jatkamisen välissä, koska tämä saattaisi olla teknisesti mahdotonta ja monessa tilanteessa harhaanjohtavaa.

Animaatiota, joka näytetään osana esilatausvaihetta tai vastaavaa tilannetta, voidaan pitää olennaisena, jos kyseisen vaiheen aikana ei voi tapahtua vuorovaikutusta kenenkään käyttäjän kanssa, ja jos toiminnon edistymistä osoittavan animaation poisjättäminen saattaisi hämätä käyttäjiä tai saada heidät ajattelemaan, että sisältö on jämähtänyt tai vioittunut.

Papunet tiivistää asian oivallisesti: voidaanko automaattisesti käynnistyvä liikkuva, välkkyvä tai vierivä sisältö keskeyttää, pysäyttää tai piilottaa käyttäjän toimesta? Poikkeuksena tilanteet, joissa sisällön kesto on vähemmän kuin 5 sekuntia tai kyseessä on osa prosessia, joka on sisällön esittämisen kannalta välttämätön.

Jos kyseessä on esimerkiksi automaattisesti käynnistyvä video, tulee siihen sisällyttää pysäytyspainike. Mikäli kuitenkin kyseessä olisi esim. mainos, joka täytyy katsoa ennen muun sisällön lataamista, kriteerin osalta asia on ok. Tämä johtuu siitä, että mainoksen katsomista edellytetään kaikilta käyttäjiltä, eikä sitä esitetä rinnakkain muun sisällön kanssa. Sitä ei siis voi pitää häiritsevänä.

2.3 Sairauskohtaukset

Älä suunnittele sisältöä tavalla, jonka tiedetään aiheuttavan sairauskohtauksia.

Kriteeri 2.3.1 Kolme välähdystä tai alle raja-arvon (Taso A)

Verkkosivut eivät sisällä mitään, joka milloinkaan välähtäisi useammin kuin kolme kertaa sekunnissa, tai välähdys on alle yleisen välähdyksen ja punaisen välähdyksen raja-arvojen.

Koska mikä tahansa sisältö, joka ei täytä tätä onnistumiskriteeriä, voi haitata käyttäjän mahdollisuuksia käyttää koko sivua, täytyy kaiken verkkosivun sisällön (riippumatta siitä, käytetäänkö sitä täyttämään muita onnistumiskriteereitä vai ei) täyttää tämä onnistumiskriteeri. Katso W3C:n sivuilta ohjeidenmukaisuuden vaatimus 5: Häiriöttömyys.

Kriteerin tarkoituksena on estää kävijää saamasta esimerkiksi epilepsiakohtaus tai migreeni.

2.4 Navigoitava

Tarjoa käyttäjille tapoja navigoida, etsiä sisältöä ja määrittää sijaintinsa.

Kriteeri 2.4.1 Ohita lohkot (Taso A)

Tarjolla on mekanismi sellaisten sisällön lohkojen ohittamiseen, jotka toistuvat useilla verkkosivuilla.

Yleinen käytäntö on esimerkiksi lisätä sivun alkuun ”Hyppää pääsisältöön” -niminen linkki, jonka avulla ohitetaan päävalikko kokonaan. Linkin saa esiin näppäimistöä tai ruudunlukijaa käyttäessä, eikä se näin häiritse muita käyttäjiä.

Toistuvien elementtien ohittaminen on tärkeää, sillä esimerkiksi päävalikon jokaisen linkin läpikäynti jokaisella sivulla on varsin turhauttavaa, jos tarkoituksenasi on vain lukea katselemasi sivu. Mikäli lukemasi sivun alusta kävisikin ilmi, että etsimäsi tieto onkin jollain toisella sivulla, ja joudut taas selaamaan päävalikon läpi ennen seuraavan sivun sisältöön pääsemistä, alkaa koko sivusto nopeasti tympimään. Tällaista selauskokemusta ei jaksa pitkään, joten kävijä todennäköisesti poistuisi sivustolta varsin nopeasti.

Kriteeri 2.4.2 Sivuotsikot (Taso A)

Verkkosivuilla on otsikot, jotka kuvailevat aiheen tai merkityksen.

Kriteeri ottaa kantaa yhden yksittäisen sivun (esim. Yhteystiedot) pääotsikkoon (title), joita jokaisella sivulla on vain yksi. Sen olisi järkevää olla jokaisella sivulla eri (myös SEO-näkökulmasta). Tämä on se otsikko, jonka perusteella sivun osoite (URL) muodostuu.

Sisällöntuotannossa tulee olla tarkkana. On tärkeää, että otsikon perusteella on helppo ymmärtää, mitä aihetta sivu käsittelee. On todella turhauttavaa lukea sivukaupalla epärelevanttia sisältöä ja etsiä hakuammunnalla sivua, josta haluamasi tieto mahdollisesti löytyy. Tämä kriteeri palveleekin aivan jokaista kävijää.

Kriteeri 2.4.3 Kohdistusjärjestys (Taso A)

Jos verkkosivu voidaan navigoida järjestyksessä ja navigointijärjestys vaikuttaa merkitykseen tai toimintoon, kohdistettavissa olevat komponentit saavat kohdistuksen järjestyksessä, joka säilyttää merkityksen ja toimivuuden.

Kohdistuksella tarkoitetaan näppäimistöllä navigoidessa elementtiä, joka osoittaa kävijälle, missä kohtaa sivustoa ollaan menossa. Sivun elementtien tulisi olla näppäimistökäytössä samassa järjestyksessä, kuin missä silmä ne sivustolla näkee, jotta kävijä saa sivustolla saman kokemuksen.

Kriteeri 2.4.4 Linkin tarkoitus (kontekstissa) (Taso A)

Jokaisen linkin tarkoitus voidaan selvittää yksin linkkitekstistä tai linkkitekstistä yhdessä ohjelmallisesti selvitettävissä olevan linkkikontekstin avulla, paitsi tilanteissa, joissa linkki olisi yleisesti ottaen epäselvä käyttäjille.

Linkkikonteksti voi olla esimerkiksi:

• Ympäröivä kappale
• Listaelementti
• Taulukon solu
• Taulukon otsikko

Ruudunlukijalla sivua selaavat kävijät saattavat lukea sivulta pelkästään linkit. Tämä helpottaa ja nopeuttaa sivujen selaamista, etenkin, mikäli tekstiä on paljon. Mikäli linkin yhteydestä ei selviä linkin tarkoitusta, kävijän on vaikea navigoida ja käyttää sivustoa.

Käytännössä, kun ruudunlukijaa käyttävä henkilö listaa sivulta pelkät linkit, hänelle ei ole hyötyä siitä, että listalla on viisi “Lue lisää” -linkkiä. Hyvä tapa testata kriteeriä onkin kuvitella, että näkisi vain linkkitekstin. Tietäisikö silloin, kannattaako linkkiä klikata, ja mitä sen klikkaamisesta seuraa?

Linkistä pitäisi myös käydä ilmi, jos siitä ladataan tiedosto (mielellään myös tiedostomuoto), jos se vie sivuston ulkopuolelle ja jos se avautuu uuteen välilehteen. Samaan kohteeseen johtavilla linkeillä tulisi olla sama linkkiteksti, kun taas eri kohteisiin johtavilla linkeillä eri.

Selkeästi ilmaistut linkit ovat hyödyllisiä myös ihan kaikkia kävijöitä ajatellen, ja parantavat sivuston käytettävyyttä.

Kriteeri 2.4.5 Useita tapoja (Taso AA)

Käytettävissä on enemmän kuin yksi tapa paikallistaa yksi verkkosivu verkkosivujen joukosta, paitsi silloin kun verkkosivu on prosessin lopputulos tai vaihe.

Sivu löytyy vähintään kahdella tapaa esimerkiksi seuraavista, Papunetin listaamista vaihtoehdoista:

• Sivuston päänavigaatiorakenteesta
• Linkeistä muille aiheeseen liittyville sivuille
• Sivustokartasta
• Sisällysluettelosta
• Sivuston kattavan hakutoiminnon avulla

Kriteeri 2.4.6 Otsikot ja nimilaput (Taso AA)

Otsikot ja nimilaput kuvailevat aiheen tai merkityksen.

Kun kriteeri 2.4.2 käsitteli sivun pääotsikkoa, tässä kriteerissä tarkastellaan kaikkia muita sivulla olevia otsikkoelementtejä. Ovatko väliotsikot (H2, H3, jne.) kuvaavia ja informatiivisia? Entä esimerkiksi lomakekenttien näkyvät nimilaput (labels)?

Otsikon tai nimilapun ei tarvitse kriteeristä huolimatta olla pitkä; tärkeää on, että ne antavat ymmärrettävän vihjeen sisällössä navigoimiseen, sisällön löytämiseen ja lomakkeiden täyttämiseen.

Kriteeri 2.4.7 Näkyvä kohdistus (Taso AA)

Kaikilla näppäimistöltä käytettävillä käyttöliittymillä on käyttötila, jossa näppäimistön kohdistuksen ilmaisin on näkyvissä.

Näkyvä kohdistus (focus) on visuaalisesti havaittava elementti, joka kertoo näppäimistökäyttäjälle, missä kohtaa sivustoa ollaan kullakin hetkellä menossa. Se näkyy myös hiirtä käyttävälle silloin, kun jotain elementtiä on klikattu.

Useimmiten selain esittää kohdistuksen ympyröimällä elementin ohuella pisteviivalla, mutta joillain sivustoilla se piilotetaan, koska se koetaan rumaksi. Näin ei tämän kriteerin mukaan saisi tehdä, ellei tee tilalle toista esitystapaa. Tällainen voisi olla vaikkapa yhtenäinen, brändivärillä kuvattu viiva.

Huomaa, että väreihin liittyvät vaatimukset (tarkemmin sanottuna kriteerit 1.4.1 ja 1.4.11) tulee ottaa huomioon myös näkyvän kohdistuksen toteuttamisessa.

2.5 Syötetavat

Tee toimintojen käyttämisestä käyttäjille helpompaa, erilaisilla syötetavoilla näppäimistön lisäksi.

Kriteeri 2.5.1 Osoitineleet (Taso A)

Kaikkia toimintoja, joissa hyödynnetään monipiste- tai reittiin perustuvia ohjauseleitä, voidaan käyttää myös yhdellä osoittimella ja ilman reittiin perustuvaa elettä, paitsi jos kyseinen ohjaustapa on olennainen.

Tämä vaatimus koskee verkkosisältöä, joka vastaanottaa ja tulkitsee osoitinlaitteen toimintoja (ts. tämä ei koske toimintoja, joilla ohjataan käyttäjäagenttia tai avustavaa teknologiaa).

Kriteerissä tarkoitetaan esimerkiksi pyyhkäisyeleitä, elementin raahausta hiiren nappi pohjaan painettuna ja näytön nipistämistä sormilla. Jos sivustolla on käytetty tällaisia tekniikoita, samaan lopputulokseen tulee päästä myös muilla tavoin. Syy kriteerin tärkeyteen on parhaiten selitetty Papunetin sivuilla: Henkilöillä, joilla on motorisia rajoitteita, tarkat pyyhkäisyeleet, kohdistimen liikuttaminen tarkasti tai hiiren liikuttaminen nappi pohjassa painettuna (raahaus) voivat olla vaikeita. Sen lisäksi kävijät, jotka käyttävät osoitinkynää (stylus) tai muuta osoitinta kosketusnäytön käyttämiseen, eivät voi käyttää monen pisteen ohjauseleitä kosketusnäytöllä. Monimutkaiset pyyhkäisyeleet eivät myöskään välttämättä ole kaikkien käyttäjien tiedossa.

Reittiin perustuva, perusteltu ohjausele on esimerkiksi tilanne, jossa sivuston alavalikko aukeaa, kun hiiren vie valikkokohteen päälle, ja sen jälkeen hiiri täytyy siirtää tarkkaa reittiä alavalikon päälle, ettei aktivoida vahingossa toista valikkokohdetta tai ettei alavalikko poistu näkyvistä. Saavutettavinta olisi kuitenkin toteuttaa valikko niin, että se aukeaa ja sulkeutuu vasta klikkaamalla. Tällöin kävijän ei tarvitse huolehtia tarkasta hiiren reitistä.

Kriteeri 2.5.2 Osoitinlaitteella tehdyn valinnan peruuttaminen (Taso A)

Toimintoihin, joita voidaan käyttää yhden osoittimen avulla, pätee vähintään yksi seuraavista:

• Mikään osa toiminnallisuudesta ei tapahdu alas-tapahtuman yhteydessä
• Toiminnon päättäminen tapahtuu ylös-tapahtuman yhdeydessä, ja on olemassa mekanismi, jolla toiminto voidaan perua ennen päättämistä tai kumota päättämisen jälkeen
• Ylös-tapahtuma kumoaa edeltävän alas-tapahtuman aiheuttaman toiminnon
• Toiminnon päättäminen alas-tapahtuman yhteydessä on olennaista

Toimintoja, jotka jäljittelevät näppäimistön tai numeronäppäimistön painalluksia, pidetään olennaisina. Tämä vaatimus koskee verkkosisältöä, joka vastaanottaa ja tulkitsee osoitinlaitteen toimintoja (ts. tämä ei koske toimintoja, joilla ohjataan käyttäjäagenttia tai avustavaa teknologiaa).

Ylös-ja alas-tapahtumat tarkoittavat näppäimen tai hiiren painikkeen klikkauksen aikana tapahtuvia liikkeitä: alas-tapahtuma on näppäimen painaminen pohjaan, ylös-tapahtuma näppäimen vapauttaminen, eli painalluksen päättäminen.

Tarkoituksena on, että kävijä ei tule tehneeksi sivustolla asioita vahingossa. Kun valinta on peruttavissa painalluksen aikana, kävijä välttyy ylimääräisiltä tapahtumilta. Tämä toki edellyttää melko nopeita refleksejä tai hidasta painallusta ja sitä, että kävijä ylipäätään huomaa painaneensa jotakin.

Kriteeri 2.5.3 Nimilappu nimessä (Taso A)

Tapauksissa, joissa käyttöliittymäkomponentin nimilapussa (label) on tekstiä tai tekstiä esittävä kuva, komponentin nimi sisältää sen tekstin, joka on visuaalisesti näkyvissä. Hyvä käytäntö on sijoittaa nimilapun teksti nimen alkuun.

Komponenteille määritellään kaksi nimeä: se, joka on visuaalisesti näkyvissä, ja toinen, joka ei näy visuaalisesti sivustolla, mutta on määritelty sivuston koodiin.

Papunet selventää tämän kriteerin tarkoitusta seuraavalla tavalla:

”Henkilöille, jotka käyttävät tietokonetta puheella, on tärkeää, että nämä kaksi vastaavat toisiaan, jotta he voivat aktivoida komponentin sanomalla ääneen näytöllä näkyvän tekstin. Myös henkilöille, jotka käyttävät ’teksti puheeksi’ -ominaisuutta ja kuuntelevat ja katsovat verkkosivun sisältöä samanaikaisesti, voi olla hämmentävää, jos kuultu ei vastaa visuaalisesti näkyvillä olevaa tekstiä.”

Kriteeri 2.5.4 Käyttö liikkeen avulla (Taso A)

Toiminnallisuus, jota voidaan käyttää liikuttamalla laitetta, voidaan käyttää myös käyttöliittymäkomponenttien avulla, ja liikeaktivointi voidaan ottaa pois päältä, jotta vältetään toiminnan aktivoiminen vahingossa.

Tämä ei koske seuraavia tapauksia:

• Liikeaktivointi on toteutettu sellaisen rajapinnan kautta, joka on saavutettavuudeltaan tuettu
• Liike on toiminnon kannalta olennainen, ja sen poistaminen mitätöisi toiminnon

Papunet kertoo kriteerin tarpeellisuudesta näin:

”Mobiililaitteissa on monenlaisia liikeantureita, joita voidaan käyttää laitteen ohjaamiseen. Esimerkiksi laitteen ravistaminen voi aktivoida kumoa-toiminnon.

Osalla käyttäjistä mobiililaite on kiinnitetty esimerkiksi pyörätuoliin niin, että sen asentoa ei voi vaihtaa. Laitteen kääntäminen eri asentoon voi olla hankalaa myös muiden motoristen tai tilanteeseen liittyvien rajoitteiden vuoksi. Toiminto saattaa aktivoitua myös vahingossa, esimerkiksi vapinan tai pyörätuolin tärinän vuoksi.”

3. Ymmärrettävä

Informaation ja käyttöliittymän toiminnan pitää olla ymmärrettävää.

Tämä osa-alue käsittää tasolla AA (Digipalvelulaki) seuraavat kriteerit:

• 3.1 Luettava
• 3.2 Ennakoitava
• 3.3 Syötteen avustaminen

3.1 Luettava

Tee tekstisisällöstä luettavaa ja ymmärrettävää.

Kriteeri 3.1.1 Sivun kieli (Taso A)

Jokaisen verkkosivun oletusarvoinen luonnollinen kieli voidaan selvittää ohjelmallisesti. Luonnollisella kielellä tarkoitetaan ihmisen puhumia kieliä, ei esimerkiksi koodikieliä.

Yksinkertaisimmillaan tämän voi toteuttaa käyttämällä HTML-elementissä lang-attribuuttia (esim. html lang=”fi”).

Kriteeri 3.1.2 Osien kieli (Taso AA)

Sisällön jokaisen tekstikatkelman tai ilmaisun luonnollinen kieli voidaan selvittää ohjelmallisesti. Poikkeukset: erisnimet, tekniset termit, määrittämättömän kielen sanat sekä sanat tai ilmaisut, jotka ovat muuttuneet läheisen tekstiympäristön kielen murteelliseksi osaksi.

Toteuta tämä esimerkiksi lang-attribuutilla (HTML).

Sisällöntuotannossa tulisi välttää tilanteita, joissa eri kielistä tekstiä on runsaasti samalla sivulla. Sen lisäksi, että tällaisilla sivuilla tulee määrittää jokaisen tekstikatkelman kieli, joka poikkeaa sivuston yleisestä kielestä, on tällainen menettelytapa myös kävijän kannalta huono. Jos esimerkiksi kyse on sivusta, jossa on jokin ohje monella eri kielellä, miten sivu otsikoidaan niin, että mitä tahansa kyseisistä kielistä puhuva henkilö löytää ohjeen? Suosi toisistaan erillisiä kieliversioita, vähintään sivutasolla.

3.2 Ennakoitava

Tee verkkosivuista sellaisia, että niiden ilmiasu ja toiminta ovat ennakoitavia.

Kriteeri 3.2.1 Kohdistaminen (Taso A)

Kun mikä tahansa käyttöliittymäkomponentti saa kohdistuksen, se ei aiheuta kontekstin muutosta.

Tämä tarkoittaa:

• Sivu ei merkittävästi muutu
• Pop-up-ikkuna ei avaudu
• Näppäimistön fokus ei siirry loogisesta paikastaan
• Ei tapahdu mitään muutakaan, joka voisi hämmentää käyttäjää

Lue lisää kontekstin muuttumisesta W3C:n sivuilta.

Esimerkki tilanteesta, jossa konteksti muuttuisi, on päävalikon pudotusvalikko, jossa valikossa oleva sivu avautuu ilman klikkausta, pelkästä kohdistuksesta. Käyttäjän tulisi voida selata valikon linkkejä vapaasti omaan tahtiinsa, ja valita sitten erikseen haluamansa sivu esim. klikkaamalla tai painamalla enter-näppäintä, käyttötavasta riippuen.

Kriteeri 3.2.2 Syöte (Taso A)

Minkään käyttöliittymäkomponentin asetuksen muuttaminen ei automaattisesti aiheuta kontekstin muutosta, ellei käyttäjää ole ohjeistettu tällaisesta toiminnosta ennen komponentin käyttöä.

Tämä tarkoittaa:

• Sivu ei merkittävästi muutu
• Pop-up-ikkuna ei avaudu
• Näppäimistön fokus ei siirry loogisesta paikastaan
• Ei tapahdu mitään muutakaan, joka voisi hämmentää käyttäjää, ellei tästä ole kerrottu käyttäjälle etukäteen

Jos esimerkiksi lomakkeella valinnan tekeminen lisää kenttiä lomakkeelle, se on kriteerin puolesta ok, kunhan kohdistus ei automaattisesti siirry muualle ilman ilmoitusta asiasta.

Kriteeri 3.2.3 Johdonmukainen navigointi (Taso AA)

Verkkosivujen joukon useilla verkkosivuilla toistuvat navigointimekanismit esiintyvät aina samassa järjestyksessä suhteessa toisiinsa, ellei käyttäjä toisin valitse.

Toisin sanoen, toistuvat valikot ja muut vastaavat elementit tulisi aina esittää samassa paikassa, saman sisältöisinä. Tämä ei tarkoita, etteikö tietyissä sivun osissa voisi olla omia osiovalikoita tai muita lisäelementtejä. Jokainen osiovalikko on oma navigaatioelementtinsä. Sen sijaan päävalikko on yksi elementti, jonka tulee olla läpi sivuston samanlainen.

Eri laitteilla käytettäessä elementit voivat toki olla eri paikoissa toisiinsa nähden, kunhan käytettävyys pysyy samana. Esimerkiksi päävalikko voi mobiilissa olla ns. hampurilaisvalikko, joka esitetään sivun vasemmassa reunassa ennen sivuston logoa, vaikka työpöytänäkymässä sivuston logo olisi ennen päävalikkoa. Saman näkymän sisällä valikon tulee kuitenkin olla aina samassa paikassa.

Kriteeri 3.2.4 Johdonmukainen merkitseminen (Taso AA)

Komponentit, joilla on sama toiminnallisuus verkkosivujen joukossa, merkitään johdonmukaisesti.

Yksinkertaisemmin tämän voisi ilmaista vaikka näin: saman toiminnon toteuttavat komponentit merkitään sivustolla johdonmukaisesti. Jos sivustolla on esimerkiksi mahdollisuus tulostukseen, kaikissa tällaisissa paikoissa käytetään samaa symbolia. Sivustohaussa olisi tärkeää käyttää hakemiseen kaikkialla samaa termiä: esimerkiksi hae tai etsi. Ei kumpaakin sekaisin.

Määrittele kaikki toiminnot tarkasti, ja pitäydy määritellyssä muodossa läpi sivuston.

3.3 Syötteen avustaminen

Auta käyttäjiä välttämään ja korjaamaan virheitä.

Kriteeri 3.3.1 Virheen tunnistaminen (Taso A)

Jos syötevirhe havaitaan automaattisesti, virheellinen kohta osoitetaan ja virhe kuvataan käyttäjälle tekstimuotoisena.

Mikäli lomakkeessa sivusto tunnistaa automaattisesti virheen, sanotaan vaikkapa puhelinnumerossa, virheellinen kohta tulee korostaa ja kuvata sanallisesti, mistä virheessä on kyse. Esimerkiksi, puhelinnumero on väärässä muodossa.

Kriteeri 3.3.2 Nimilaput tai ohjeet (Taso A)

Kun sisältö edellyttää käyttäjän syötettä, tarjolla on nimilappuja (label) tai ohjeita.

Lomakkeella tulisi ohjeistaa käyttäjää tai vähintään nimetä kentät niin, että kävijä osaa täyttää lomakkeen halutulla tavalla.

Kriteeri 3.3.3 Virheen korjausehdotus (Taso AA)

Jos syötevirhe havaitaan automaattisesti ja korjausehdotuksia tiedetään, ehdotukset esitetään käyttäjälle, paitsi jos tämä vaarantaisi tietoturvan tai sisällön merkityksen.

Tämä on parannus kriteeriin 3.3.1. Käytetään samaa esimerkkiä: mikäli puhelinnumero on sivustolla määritelty muotoon +358, tämä kerrotaan virheen kuvauksessa. Voidaan myös antaa lista kaikista sallituista muodoista. Tai mikäli käyttäjä olisi syöttänyt puhelinnumerokenttään vahingossa @-merkin, ja lomakekenttään on määritelty, että se saa sisältää vain numeroita, virheen korjausehdotus kertoisi tästä.

Tietoturvan vaarantamisella tarkoitetaan esimerkiksi sitä, että väärin syötetylle salasanalle ei ehdoteta sivuston tiedoista löytyvää, oikeaa salasanaa. Sisällön merkitys voisi vaarantua esimerkiksi kokeessa, jossa kenttä ehdottaisi oikeaa vastausta.

Kriteeri 3.3.4 Virheiden ennaltaehkäisy (oikeudellinen, taloudellinen, data) (Taso AA)

Verkkosivuille, joista seuraa käyttäjälle oikeudellisia sitoumuksia tai taloudellisia transaktioita, jotka muokkaavat tai poistavat käyttäjän hallinnoimaa dataa tietovarastossa tai jotka lähettävät käyttäjän koevastauksia, ainakin yksi seuraavista pitää paikkansa:

• Lähetykset ovat peruttavissa
• Käyttäjän syöttämä data tarkastetaan syötevirheiden varalta ja käyttäjälle tarjotaan mahdollisuus virheiden korjaamiseen
• Käytettävissä on mekanismi informaation tarkistamiseen, vahvistamiseen ja korjaamiseen ennen lopullista lähettämistä

Kun on kyse tärkeästä tietojen lähetyksestä sivustolla, esimerkiksi verkkokaupan tilauksesta tai osoitteenmuutoksesta, käyttäjällä tulee olla mahdollisuus estää virheellisten tietojen lähetys.

4. Toimintavarma

Sisällön pitää olla riittävän toimintavarmaa, jotta se voidaan luotettavasti tulkita laajalla joukolla käyttäjäagentteja, mukaan lukien avustavilla teknologioilla.

Tämä osa-alue käsittää tasolla AA (Digipalvelulaki) seuraavat kriteerit:

• 4.1 Yhteensopiva

4.1 Yhteensopiva

Maksimoi yhteensopivuus nykyisten ja tulevien käyttäjäagenttien, mukaan lukien avustavien teknologioiden, kanssa.

Kriteeri 4.1.1 Jäsentäminen (Taso A)

Kun sisältö on toteutettu merkkauskieliä käyttämällä, elementeillä on täydelliset alku- ja lopputagit, elementit on järjestetty sisäkkäin spesifikaation mukaisesti, samaa attribuuttia ei ole annettu elementeille moneen kertaan ja kaikki ID-tunnisteet ovat yksilöllisiä, paitsi tilanteissa, joissa määritykset sallivat tämänkaltaiset ominaisuudet.

Alku- ja lopputagit, joiden muotoilusta puuttuu jokin kriittinen merkki, kuten päättävä ”suurempi kuin” -merkki tai sopiva lainausmerkki attribuutin arvosta, eivät ole täydellisiä.

Kriteeri täyttyy automaattisesti, jos käytetään HTML/XHTML-määrityksen mukaista koodia. Näin ei kuitenkaan ole pakko tehdä. Ainakin alla lueteltujen ehtojen tulee täyttyä:

• Elementtien aloitus- ja lopetustagit on merkitty oikein
• Elementit on järjestetty sisäkkäin oikein (”nesting”)
• ID-tunnisteet ovat yksilöllisiä
• Sivulla ei ole muita merkittäviä HTML/XHTML-virheitä

Sivuston voi tarkistaa virheiden varalta esimerkiksi W3C:n validaattorilla (englanniksi).

Kriteeri 4.1.2 Nimi, rooli, arvo (Taso A)

Kaikkien käyttöliittymäkomponenttien

• Nimi ja rooli voidaan selvittää ohjelmallisesti
• Tilat, ominaisuudet ja arvot, jotka käyttäjä voi asettaa, voidaan myös asettaa ohjelmallisesti
• Tieto edellisten muutoksista on käyttäjäagenttien, mukaan lukien avustavien teknologioiden, saatavissa

Käyttöliittymäkomponentteja ovat mm. lomake-elementit, linkit ja skriptien luomat komponentit. Käytännössä esimerkiksi:

• Fokuksen tila tai sen muutos ilmoitetaan
• Lomakkeen valintaruudun tai ¬napin tilan muutos ilmoitetaan
• Kaikilla käyttöliittymäkomponenteilla on ohjelmallisesti määritettävä nimi

Tämä kriteeri on suunnattu ensisijaisesti web-kehittäjille, jotka toteuttavat tai koodaavat itse käyttöliittymäkomponentteja. Esimerkiksi standardinmukaiset HTML-elementit täyttävät tämän onnistumiskriteerin, kun niitä käytetään spesifikaation mukaisesti.

Ohjelmallisesti luoduissa/muokatuissa käyttöliittymäkomponenteissa on usein tarvetta WAI-ARIAlle, esimerkiksi aria-label-attribuutin käytölle. Lisätietoa WAI-ARIAsta löytyy W3C:n sivuilta (englanniksi).

Kriteeri 4.1.3 Tilasta kertovat viestit (Taso AA)

Sisällössä, joka on toteutettu käyttäen merkkauskieliä, tilasta kertovat viestit voidaan selvittää ohjelmallisesti sellaisen roolin tai ominaisuuksien avulla, jotka mahdollistavat viestin esittämisen käyttäjälle avustavan teknologian avulla ilman kohdistuksen siirtämistä.

Esimerkkejä tärkeistä viesteistä:

• Toiminnon tulos tai onnistuminen
• Virhe
• Toiminto on käynnissä ja valmistumista odotellaan
• Toiminnon edistyminen

Viestin voi toteutettaa esimerkiksi käyttämällä ARIA-live-ominaisuutta tai ARIA-roolia ”alert”.

Lopuksi

Lisää suomenkielisiä käytännön vinkkejä löytyy Kehitysvammaliiton Papunet-sivuston WCAG-ohjeista sekä englanniksi kriteerien takana olevan W3C:n sivuilta. Hyödyllinen on myös Papunetin WCAG 2.1 -tarkistuslista, joka sisältää olennaiset asiat tiiviissä muodossa – samoin AVI:n ohjeet suunnittelun tueksi.

Mikäli on tarpeen syventää ymmärrystä tässä oppaassa mainituista asioista, suosittelen uppoutumaan W3C:n sivuille, joilta löytyy virallinen, suomenkielinen käännös kriteereistä. Alkuperäiset materiaalit löytyvät englanniksi täältä. Kummaltakin kriteerisivulta on linkkejä lisämateriaaleihin. Kannattaa kuitenkin varautua siihen, että WCAG-kriteereihin liittyvä teksti on hyvin lakitekstimäistä ja paikoitellen vaikeaselkoista.

Lisää luettavaa saavutettavuudesta:

Saavutettavuusdirektiivi vie kohti parempaa maailmaa – asiaa esteettömyydestä ja digitaalisten palvelujen saavutettavuudesta
Saavutettavuusstandardi WCAG ja digitaalisten palveluiden uusi aamunkoitto
Karhun kokemuksia saavutettavien sivustojen rakentamisesta
Saavutettavuus ja hakukoneoptimointi – 6 helppoa vinkkiä
Kaikki saavutettavuusaiheiset blogikirjoituksemme