WCAG 2.2 on julki, oletko jo huomioinut muutokset?

WCAG 2.2 julkaistiin virallisesti 5. lokakuuta. W3C (the World Wide Web Consortium) suosittelee jo kriteeristön huomioimista, mutta lain vaatimuksissa uusi versio ei aivan vielä ole. Tarkkaa tietoa aikataulusta ei tällä hetkellä ole tiedossa, mutta joitakin melko varovaisia arvioita vuodelle 2025 on esitetty. 

Uusi kriteeristön versio toi tullessaan A- ja AA-tasoille kuusi uutta kriteeriä, joista jokainen on erinomainen parannus käyttökokemukseen. Suosittelemme lämpimästi kriteeristön huomioimisen aloittamista jo nyt. Tällöin tarvittavat muutokset olisi jo tehtynä versiopäivityksen astuessa lain piiriin.

WCAG 2.2 huomioimisen voi myös ottaa huomioon jo saavutettavuusselosteessa, tällöin myös kävijät näkevät, että saavutettavuuteen panostetaan enemmän kuin mitä laissa tällä hetkellä vaaditaan.

Mikä ihmeen WCAG?

WCAG tulee sanoista Web Content Accessibility Guidelines ja tämä ohjeistus pitää sisällään onnistumiskriteerejä, joiden avulla mitataan sivuston saavutettavuutta. On hyvä muistaa, että tämä ohjeisto on vain minimivaatimus saavutettavuudelle, eli saavutettavuuteen voi (ja kannattaakin) panostaa myös enemmän. Tätä kriteeristöä käytetään saavutettavuusauditoinneissa saavutettavuuden mittarina.

Ohjeisto on käännetty virallisesti myös suomeksi W3C:n sivustolla: Verkkosisällön saavutettavuusohjeet (WCAG) 2.1. 

Millaisia muutostarpeita uudet kriteerit tuovat tullessaan?

Yksinkertainen vastaus kysymykseen on, että jos saavutettavuus on huomioitu todella hyvin jo aikaisemmin, ei välttämättä mitään. Ja tapauksissa, joissa nämä uudet vaatimukset eivät ole vielä ihan kunnossa, tarvittavat muutokset eivät välttämättä ole kovinkaan suuria.

Uusia kriteerejä ei ole vielä käännetty suomeksi, joten viittaan kriteereiden nimiin vielä englanniksi. Käyn läpi tällä kertaa ainoastaan A- ja AA-tason kriteerit, koska AAA-tasoa ei laissa vaadita. Uusien kriteerien osalta AAA-tasolla on erinomaisia ja käyttäjien käyttökokemuksia huomattavasti parantavia vaatimuksia, joihin kannattaa kyllä mahdollisuuksien mukaan panostaa.

Focus not obscured – taso AA (kriteeri 2.4.11)

Näkevä näppäimistökäyttäjä tietää sijaintinsa sivulla kohdistustyylien (focus) avulla. Jos nämä tyylit ovat puutteelliset, on käyttäjän todella haastavaa tai jopa mahdotonta tietää missä kohtaa sivulla ollaan menossa.

Tämä kriteeri pyrkii varmistamaan, ettei sivulla aukeavat elementit, kuten modaalit tai pop up -ikkunat peitä kokonaan alleen kohdistettua elementtiä.

Dragging movements – taso AA (kriteeri 2.5.7)

Kaikki käyttäjät eivät voi käyttää hiirtä asioiden raahaamiseen. Yleinen esimerkki raahausta hyödyntävästä toiminnallisuudesta on asioiden järjestely.

Tämä kriteeri vaatii, että tällaisella toiminnolla on aina yhden osoittimen vastine. Toiminnon ei välttämättä tarvitse olla täysin identtinen, vaan se voi olla tätä varten erikseen toteutettu vastine. Ainoa vaatimus on, että sama toiminnallisuus pitää voida suorittaa.

Koska WCAG 2.1 vaatii, että kaikkien elementtien pitää olla käytettävissä myös pelkällä näppäimistöllä, on tämän kriteerin vaatimus monessa tapauksessa täytetty jo näppäimistötuella.

Target size (minimum) – taso AA (kriteeri 2.5.8)

Kohteiden, kuten linkkien ja nappien pitää olla riittävän suuret, jotta niitä voi käyttää. Kokovaatimuksia on jo WCAG 2.1 -kriteeristössä AAA-tasolla, mutta nyt vaatimuksia tuodaan myös AA-tasolle.

Vähimmäisvaatimus kohteiden koolle on 24×24 CSS-pikseliä. Tämä ei automaattisesti tarkoita sitä, että esimerkiksi ikonin pitää olla tässä koossa, vaan sen ympärillä on mahdollista hyödyntää myös tilaa käyttämällä CSS-tyyleissä paddingia.

Tutustu tarkemmin tähän kriteeriin englanniksi W3C:n Understanding-sivuston kriteeriesittelyssä. Sivulta löytyy kattavampi selitys vaatimuksista sekä monia havainnollistavia esimerkkejä erilaisista käyttötilanteista.

Tämän kriteerin kohdalla on mielenkiintoista se, että AAA-tasolla minimikoko on 44×44 CSS-pikseliä. Mutta tällä hetkellä jotkin automaattiset työkalut, kuten esimerkiksi Siteimprove kehottavat asettamaan mobiililaitteille 48×48 CSS-pikseliä kokoisia kohteita. Eli tämä on suurempi kuin mitä WCAG vaatii 2.1 tai 2.2 versioissaan. Suosittelemme mahdollisuuksien mukaan käyttämään tätä 48×48 pikselin kokoa mobiililaitteilla, koska se helpottaa monia käyttäjiä. Mutta WCAG-kriteeristö itsessään ei tätä vaadi.

Consistent help – taso A (kriteeri 3.2.6)

Tämä kriteeri pyrkii siihen, että sivustolla olevat aputoiminnot löytyvät helposti ja loogisesti samasta paikasta. Jos aputoiminto löytyy vain yhdeltä sivulta, tämä kriteeri ei aseta sille vaatimuksia.

On hyvä huomioida, että tämä kriteeri ei myöskään vaadi, että sivustolla on aputoimintoja. Eli kriteeri ottaa kantaa vain siihen, että aputoimintojen löytyessä ne on toteutettu loogisesti.

Mitä loogisuus tässä sitten tarkoittaa? Sitä, että jos esimerkiksi sivun alatunnisteessa on yhteystiedot, ne ovat siellä aina eivätkä jollakin tietyllä sisällön tyypillä vaihda paikkaa. Jos sivustolla on chat-toiminto, se löytyy aina sivusta riippumatta samasta kohdasta. Jos chat-toiminto olisikin yhdellä sivulla oikeassa alareunassa ja toisella vasemmassa yläreunassa, olisi tämä epäloogista ja käyttäjää hämmentävää. Käytännössä jos sivuston käyttöliittymäsuunnittelu ja sisällöntuotanto on toteutettu laadukkaasti, tämän kriteerin pitäisi täyttyä suoraan.

Redundant entry – taso A (kriteeri 3.3.7)

Tämä kriteeri pyrkii varmistamaan, että samaa tietoa ei tarvitse syöttää moneen kertaan saman prosessin aikana. Osalla käyttäjistä voi olla haasteita muistaa mitä tietoja ovat syöttäneet aikaisemmin. Ja jos ihan rehellisiä ollaan, eihän se ole millään tavalla käyttäjäkokemusta parantavaa toimintaa, jos samat tiedot joutuu esimerkiksi samalla lomakkeella syöttämään uudelleen ja uudelleen.

Tapoja, joilla tämän kriteerin saa lomakkeiden osalta melko vaivattomasti täytettyä on esimerkiksi tarjota käyttäjälle mahdollisuus valita aikaisemmin lisättyä tietoa. Toinen, varsinkin verkkokaupoissa jo nyt varsin yleisesti nähty tapa on sallia käyttäjän vahvistaa, että laskutusosoite on sama kuin toimitusosoite.

Lisäksi todella erinomainen tapa mahdollistaa käyttäjän tietojen valitseminen on käyttää käyttäjätietoa keräävissä kentissä automaattista täydentämistä eli ns. Autocomplete-toimintoa. Tällöin käyttäjä voi valita itseään koskevat tiedot, jos ne vain selaimelta jo löytyy tallennettuna.

Accessible authentication (minimum) – taso AA (kriteeri 3.3.8)

Viimeinen, mutta ei suinkaan vähäisin uusi onnistumiskriteeri pyrkii varmistamaan, että kaikki käyttäjät voivat kirjautua sisään järjestelmään. Käyttäjätunnuksen ja salasanan muistaminen on osalle käyttäjistä jopa mahdotonta. Ja tunnusten oikein kirjoittaminenkin voi monelle olla hankalaa.

Tämä kriteeri on varsin helppo saada täyttymään niinkin yksinkertaisilla toiminnoilla kuin, että ei estetä käyttäjää liittämästä kirjautumiskenttiin tekstiä. Tai sallitaan käyttäjän käyttää kolmannen osapuolen tunnustenhallintajärjestelmää. Kirjautumiseen voidaan tarjota myös kolmannen osapuolen kirjautuminen hyödyntämällä vaikkapa käyttäjältä jo löytyvää Google- tai Facebook-tunnusta.

Myös tämän kriteerin kohdalla ensimmäisenä ajatuksena herää käyttäjäkokemus. Näiden ratkaisujen avulla käyttökokemuksesta saadaan miellyttävämpi vähentämällä käyttäjän todennäköisyyttä ja mahdollisuuksia tehdä virheitä. Tässä kriteerissä kuitenkin on määritetty, että jos näitä ominaisuuksia ei voida sallia tietoturvasyistä, silloin tästä kriteeristä saa poiketa.

Miten lähteä valmistautumaan tuleviin vaatimuksiin?

Hyvä tapa lähteä liikkeelle on saavutettavuusauditointi. Auditoinnissa kannattaa tarkastaa uusien kriteerien lisäksi myös sivuston tila WCAG 2.1 -vaatimusten osalta, erityisesti jos edellisestä auditoinnista on vierähtänyt jo tovi. Auditoinnin tulokset kertovat kattavasti sivuston mahdollisten puutteiden tilasta ja tulosten avulla on helppo päivittää sivuston saavutettavuusseloste taas ajan tasalle.

Kaipaatko apua saavutettavuusauditoinnissa?

Ota meihin yhteyttä ja sovitaan tarpeisiisi sopiva auditointi!

Ajatuksiaan jakoi