WCAG 2.2 -saavutettavuusvaatimukset koskettavat käytännössä jokaista suomalaista yritystä, jolla on verkkosivut tai verkkokauppa – ja vaatimukset ovat tiukentuneet edellisestä versiosta. Tässä artikkelissa käydään läpi, mitä WCAG 2.2 konkreettisesti tarkoittaa kotisivujen suunnittelussa ja toteutuksessa, ja miten vaatimuksiin päästään kiinni ilman koko sivuston uudelleenrakentamista.
Mikä WCAG 2.2 on ja kenelle se koskee
WCAG (Web Content Accessibility Guidelines) on kansainvälinen ohjeistus, joka määrittelee, miten verkkosisällöstä tehdään saavutettavaa kaikille käyttäjille – myös niille, jotka käyttävät ruudunlukijaa, näppäimistöä ilman hiirtä tai suurennettua tekstikokoa. Versio 2.2 julkaistiin lokakuussa 2023, ja se täydentää aiempaa 2.1-versiota yhdeksällä uudella kriteerillä.
Suomessa saavutettavuusvaatimukset perustuvat lakiin digitaalisten palvelujen tarjoamisesta, ja ne koskevat suoraan julkishallintoa. Yksityisille yrityksille vaatimus tulee usein epäsuorasti – esimerkiksi silloin, kun verkkokauppa myy tuotteita tai palveluita kuluttajille EU:n alueella, jolloin Euroopan esteettömyysdirektiivi (European Accessibility Act) astuu kuvaan kesäkuusta 2025 alkaen.
Moni pienyrittäjä ajattelee, ettei asia koske heitä, koska yritys ei ole julkinen toimija. Tämä on yksi yleisimmistä väärinkäsityksistä: jos sivustolla on esimerkiksi verkkokauppa, ajanvaraus tai muu digitaalinen palvelu, saavutettavuusvaatimukset voivat koskea myös pientä yritystä. Kannattaa siis tarkistaa oma tilanne ajoissa, ei vasta kun asiakas tai valvova viranomainen ottaa yhteyttä.
Mitä uutta WCAG 2.2 toi verrattuna aiempiin versioihin
WCAG 2.2 ei kumoa vanhoja kriteerejä vaan lisää niihin. Käytännön kannalta tärkeimmät uudet vaatimukset liittyvät kohdistuksen näkyvyyteen, kosketuskohteiden kokoon ja lomakkeiden täyttämisen helpottamiseen.
Focus Not Obscured -kriteeri edellyttää, että kun käyttäjä siirtyy sivulla näppäimistöllä elementistä toiseen, aktiivinen kohde ei saa jäädä esimerkiksi kiinteän yläpalkin tai evästebannerin alle piiloon. Tämä on yllättävän yleinen ongelma monilla sivustoilla, joissa on sticky-navigaatio.
Target Size -kriteeri määrittää, että klikattavien elementtien, kuten nappien ja linkkien, tulee olla vähintään 24×24 pikseliä, jotta niitä on helppo käyttää myös kosketusnäytöllä tai motorisen rajoitteen kanssa. Tämä vaikuttaa suoraan mobiilinavigaation ja lomakkeiden suunnitteluun.
Consistent Help -kriteeri vaatii, että jos sivustolla on esimerkiksi chat-tuki tai yhteystiedot, ne löytyvät samasta paikasta jokaiselta sivulta. Redundant Entry puolestaan kieltää pyytämästä käyttäjää syöttämästä samaa tietoa uudelleen saman prosessin aikana, mikä koskee erityisesti verkkokaupan kassaprosesseja ja monivaiheisia lomakkeita.
Käytännön esimerkki: verkkokaupan kassaprosessi
Ajatellaan pientä käsityöyritystä, joka myy tuotteita verkkokaupassa. Kassaprosessissa on kolme vaihetta: toimitustiedot, maksutapa ja tilauksen vahvistus. Ennen WCAG 2.2 -tarkistusta asiakkaan piti syöttää sähköpostiosoite sekä toimitustietojen että laskutustietojen kohdalla erikseen, vaikka ne olivat samat.
Tämä rikkoo Redundant Entry -kriteeriä. Korjaus on teknisesti yksinkertainen: lisätään valintaruutu ”käytä samoja tietoja laskutukseen”, joka esitäyttää kentät automaattisesti. Samalla kannattaa tarkistaa, että jokainen lomakekenttä antaa selkeän virheilmoituksen, jos täyttö epäonnistuu – tästä löytyy lisää ohjeita mikrotekstien ja virheilmoitusten suunnittelusta.
Samalla sivustolla havaittiin, että mobiilinavigaation ”lisää ostoskoriin” -napit olivat vain 18×18 pikseliä – selvästi alle uuden 24 pikselin vähimmäiskoon. Napin koon kasvattaminen ja riittävän marginaalin lisääminen viereisiin elementteihin ratkaisi ongelman ilman, että ulkoasua tarvitsi muuttaa merkittävästi.
Miten WCAG 2.2 -vaatimukset tarkistetaan käytännössä
Saavutettavuuden arviointi kannattaa aloittaa automaattisilla työkaluilla, mutta niihin ei pidä luottaa sokeasti – ne löytävät tyypillisesti vain 30–40 prosenttia ongelmista. Loput vaativat manuaalista testausta.
1. Automaattinen skannaus. Työkalut kuten WAVE tai Lighthouse antavat nopean yleiskuvan puuttuvista alt-teksteistä, kontrastiongelmista ja HTML-rakenteen virheistä.
2. Näppäimistötestaus. Käy koko sivusto läpi ilman hiirtä, pelkällä Tab-näppäimellä. Jos et pääse johonkin toimintoon käsiksi tai kohdistus katoaa näkyvistä, kyseessä on todennäköinen rikkomus.
3. Ruudunlukijatesti. Testaa sivusto esimerkiksi NVDA:lla (ilmainen Windowsille) tai VoiceOverilla (Mac/iOS). Tämä paljastaa nopeasti, ovatko lomakkeiden kentät ja napit nimetty järkevästi.
4. Oikeiden käyttäjien testaus. Jos resursseja on, pienikin käytettävyystesti saavutettavuuden näkökulmasta tuo esiin ongelmia, joita kukaan sisäinen tarkistus ei löydä. Aiheesta enemmän artikkelissa käytettävyystestauksesta pienellä budjetilla.
Näiden tarkistusten kannattaa olla osa julkaisuprosessia, ei vain kertaluonteinen projekti. Kun sivustolle tehdään muutoksia, on hyvä käydä tarkistuslista läpi ennen julkaisua – tästä on hyötyä myös yleisemmin sivuston laadunvarmistuksessa, ks. sivuston julkaisun tarkistuslista.
Yleisiä virheitä ja niiden välttäminen
Yksi yleisimmistä virheistä on ajatella, että saavutettavuus tarkoittaa pelkästään ruudunlukijatukea. Todellisuudessa suuri osa käyttäjistä hyötyy saavutettavuusparannuksista muutenkin – esimerkiksi selkeät kontrastit auttavat kaikkia kirkkaassa auringonvalossa, ja hyvin suunniteltu näppäimistönavigointi nopeuttaa myös tehokäyttäjien työtä.
Toinen tyypillinen virhe on alt-tekstien täyttäminen mekaanisesti tiedostonimillä tai avainsanoilla ilman todellista kuvausta. Tämä ei ainoastaan riko saavutettavuusvaatimuksia, vaan heikentää myös hakukoneoptimointia, koska Google käyttää alt-tekstejä kuvahaun indeksoinnissa.
Kolmas virhe on kontrastiin liittyvä: monet trendikkäät, vaaleanharmaat tekstit vaaleaa taustaa vasten näyttävät tyylikkäiltä, mutta eivät täytä WCAG:n vähimmäiskontrastisuhdetta (4.5:1 normaalikokoiselle tekstille). Kannattaa tarkistaa värit kontrastityökalulla jo suunnitteluvaiheessa, ei vasta julkaisun jälkeen.
Neljäs sudenkuoppa liittyy fonttivalintoihin – liian ohuet tai koristeelliset fontit heikentävät luettavuutta erityisesti näkövammaisille käyttäjille. Aiheesta lisää artikkelissa web-fontit vs. järjestelmäfontit.
UKK
Koskeeko WCAG 2.2 myös pientä yritystä ilman verkkokauppaa?
Suoraan lakisääteinen velvoite koskee pääasiassa julkishallintoa, mutta jos sivustolla on lomakkeita, ajanvarausta tai muuta interaktiivista sisältöä, saavutettavuus kannattaa huomioida joka tapauksessa. Se parantaa käyttökokemusta kaikille kävijöille ja voi vaikuttaa myös hakukonenäkyvyyteen.
Paljonko WCAG 2.2 -vaatimusten täyttäminen maksaa olemassa olevalle sivustolle?
Kustannus riippuu sivuston koosta ja nykyisestä toteutuksesta. Pienet korjaukset, kuten kontrastien ja alt-tekstien parantaminen, voi usein tehdä muutamassa päivässä, kun taas laajempi rakenteellinen uudistus vaatii enemmän aikaa ja resursseja.
Riittääkö automaattinen saavutettavuustestaus vai tarvitaanko manuaalista tarkistusta?
Automaattiset työkalut löytävät vain osan ongelmista, tyypillisesti alle puolet. Kattava tarkistus vaatii aina myös manuaalista näppäimistö- ja ruudunlukijatestausta.
WCAG 2.2:n käytännön toteutus ei vaadi koko sivuston uudelleensuunnittelua – useimmiten kyse on kohdennetuista korjauksista kohdistuksen näkyvyyteen, kosketuskohteiden kokoon ja lomakkeiden logiikkaan. Kun tarkistukset tehdään säännölliseksi osaksi julkaisuprosessia, saavutettavuudesta tulee luonteva osa sivuston laatua eikä erillinen lisätyö.