Mitä uutta WCAG 2.2:ssa? Yhdeksän uutta kriteeriä selitettynä

Näppäimistöä käyttävä asiakas siirtyy kassasi läpi sarkainnäppäimellä. Kohdistus osuu ”Maksa nyt” -painikkeeseen, mutta kiinteä evästeilmoitus on sen päällä, joten hän ei näe, missä on. WCAG 2.1:n mukaan sivu voi silti läpäistä arvioinnin. WCAG 2.2:n mukaan se ei läpäise.

Juuri tällaisia aukkoja 2.2-päivitys paikkaa. Alla jokainen uusi onnistumiskriteeri käydään läpi samalla kaavalla: mitä se sanoo, ketä se auttaa, nopea testi ja tavallinen korjaus. Neljä periaatetta ja tasot löydät yhdeltä sivulta WCAG 2.2 -koosteestamme.

Mikä on WCAG 2.2?

WCAG 2.2 on Web Content Accessibility Guidelines -ohjeiden nykyinen versio. Se on W3C:n standardi, johon useimmat saavutettavuuslait ja -sopimukset viittaavat. Siitä tuli W3C:n suositus 5.10.2023 (avautuu uuteen välilehteen), sitä päivitettiin 12.12.2024 (avautuu uuteen välilehteen), ja se hyväksyttiin standardiksi ISO/IEC 40500:2025 (avautuu uuteen välilehteen) lokakuussa 2025.

WCAG koostuu testattavista vaatimuksista, joita kutsutaan onnistumiskriteereiksi, ja jokaisella on taso: A (vähimmäistaso), AA (jota lait yleensä edellyttävät) tai AAA (tiukin). ”Tarvitsemme WCAG 2.2 AA:n” tarkoittaa kaikkia version 2.2 A- ja AA-tason kriteerejä. Määrittelyn mukaan 2.2 ”rakentuu WCAG 2.1:n päälle ja on sen kanssa taaksepäin yhteensopiva”, eli se täydentää 2.1:tä eikä korvaa sitä.

Mikä muuttui WCAG 2.1:stä 2.2:een?

WCAG 2.2 lisää yhdeksän onnistumiskriteeriä ja poistaa yhden. Uusista kuusi on tasoa A tai AA, joten ne lasketaan tavalliseen AA-tavoitteeseen: 2.4.11, 2.5.7, 2.5.8, 3.2.6, 3.3.7 ja 3.3.8. Loput kolme ovat AAA-tasoa. Poistettu kriteeri on 4.1.1 Jäsentäminen, jota W3C kuvaa nyt vanhentuneeksi.

Kriteeri 4.1.1 Jäsentäminen tarkisti merkintävirheitä, kuten päällekkäisiä tunnisteita (ID). WCAG 2:n usein kysytyissä kysymyksissä (avautuu uuteen välilehteen) kerrotaan, että nämä ongelmat kuuluvat nyt muiden kriteerien, kuten 4.1.2 Nimi, rooli, arvo, piiriin. Yksi varaus kuitenkin: jos sopimus edellyttää yhä WCAG 2.0:aa tai 2.1:tä, sinun ”voi olla tarpeen jatkaa kriteerin 4.1.1 testaamista ja raportointia”.

Kohdistin ei peity ja kohdistuksen ulkoasu: näkeekö näppäimistön käyttäjä, missä hän on?

Nämä kriteerit pitävät näppäimistökohdistuksen saaneen elementin näkyvissä. AA-tasolla (2.4.11) kohdistettu linkki tai painike ei saa jäädä kokonaan lisäämäsi sisällön, kuten kiinteän yläpalkin, evästeilmoituksen tai chat-kuplan, alle. AAA-tasolla mikään ei saa peittää siitä mitään osaa (2.4.12), ja kohdistuksen reunuksen on oltava suuri ja selvästi erottuva (2.4.13).

• Ketä se auttaa: näkeviä ihmisiä, jotka käyttävät hiiren sijaan näppäimistöä, usein motorisen vamman vuoksi. Jos he eivät näe kohdistusta, he joutuvat arvaamaan.
• Nopea testi: avaa pitkä sivu niin, että evästeilmoitus, kiinteä yläpalkki ja chat-widget ovat kaikki näkyvissä, ja paina sarkainta toistuvasti. Jos kohdistus katoaa kokonaan jonkin taakse, kriteeri 2.4.11 ei täyty.
• Tavallinen korjaus: lisää CSS:ään scroll-padding, joka vastaa kiinteän ylä- tai alapalkin korkeutta, jolloin selain vierittää kohdistetut elementit sen alta esiin. W3C mainitsee tämän riittävänä tekniikkana (avautuu uuteen välilehteen). Ilmoitus voi läpäistä myös, jos se on modaalinen ja se on suljettava ensin.

Näkyvän kohdistuksen ulkoasu (2.4.13) edellyttää ilmaisinta, joka on vähintään yhtä suuri kuin komponentin ympäri kulkeva 2 CSS-pikselin paksuinen reunus, ja kohdistetun ja kohdistamattoman tilan välistä kontrastieroa vähintään 3:1. Se on AAA-tasoa, mutta yhtenäinen 2 pikselin reunus voimakkaassa värissä riittää yleensä. Värikontrastia käsittelevä oppaamme kertoo, miten 3:1 mitataan.

Raahaaminen ja kohdealueen koko: voiko sivustoa käyttää ilman tarkkaa osoittamista?

Nämä kaksi AA-tason kriteeriä auttavat ihmisiä, joille osoittimen tarkka hallinta on vaikeaa. Kriteerin 2.5.7 mukaan kaiken, minkä voi tehdä raahaamalla, on toimittava myös yksittäisillä napsautuksilla tai napautuksilla. Kriteerin 2.5.8 mukaan kohteiden on oltava vähintään 24 × 24 CSS-pikseliä tai niin kaukana toisistaan, että kunkin kohteen keskelle piirretty 24 pikselin ympyrä ei kosketa toista kohdetta.

2.5.7 Raahaamista vaativat toiminnot

Ajattele verkkokaupan suodattimien hintahaarukan liukusäädintä tai toivelistaa, jonka järjestystä muutetaan raahaamalla. Jos kädet vapisevat tai käytössä on pääosoitin, paina–pidä–siirrä–päästä voi olla todella vaikeaa.

Nopea testi: tee jokainen raahausta vaativa tehtävä pelkillä napsautuksilla tai napautuksilla. Tavallinen korjaus: anna käyttäjän napsauttaa mihin tahansa kohtaan liukusäätimen uraa, lisää viereen ”min”- ja ”max”-kentät tai lisää lajiteltaviin listoihin ”Siirrä ylös”- ja ”Siirrä alas” -painikkeet. Pelkkä näppäimistötuki ei riitä: W3C:n Understanding-asiakirjan (avautuu uuteen välilehteen) mukaan näppäimistövastine ”ei automaattisesti täytä tätä onnistumiskriteeriä”.

2.5.8 Kohdealueen koko (minimi)

Tavallisimmat puutteet ovat ponnahdusikkunoiden pienet ”×”-painikkeet, tiiviisti pakatut sivunumerot, tähtiarviot ja somekuvakkeiden rivit. Väärään kohtaan osuminen ärsyttää ketä tahansa, ja ihmiselle, jonka käsien hienomotoriikka on rajoittunut, se on todellinen este.

• Poikkeukset: virkkeen sisällä olevat linkit, kohteet, joilla on muualla sivulla vastaava riittävän kokoinen säädin, selaimen mitoittamat säätimet, joiden tyyliä et ole muuttanut, sekä tilanteet, joissa tietty koko on välttämätön tai laissa vaadittu.
• Nopea testi: kokeile puhelimella jokaista pientä kuvaketta ja painiketta; jos haluat mitata jonkin niistä, tarkastele sitä selaimen kehittäjätyökaluilla.
• Tavallinen korjaus: lisää täytettä (padding). Napsautettava alue kasvaa, vaikka kuvake näyttää samalta. Pidä 24 pikseliä alarajana: vanhempi AAA-kriteeri 2.5.5 edellyttää 44 × 44.

Johdonmukainen apu ja tarpeeton toistaminen: joutuvatko ihmiset etsimään tai toistamaan itseään?

Molemmat ovat A-tasoa. Kriteeri 3.2.6 Johdonmukainen apu ja ohjeet edellyttää, että jos apua, kuten yhteystiedot, chat tai linkki usein kysyttyihin kysymyksiin, tarjotaan usealla sivulla, se on joka kerta samassa järjestyksessä suhteessa muuhun sivuun. Kriteerin 3.3.7 Tarpeeton toistaminen mukaan ihmisten ei pitäisi joutua kirjoittamaan uudelleen tietoja, jotka he ovat jo antaneet samassa prosessissa.

Johdonmukainen apu ei velvoita tarjoamaan apua lainkaan. Se sanoo vain, että jos puhelinnumero on tuotesivuilla yläpalkissa, se ei saa siirtyä kassalla alatunnisteeseen, jossa sitä tarvitaan eniten. Eniten hyötyvät ihmiset, joilla on muisti- tai keskittymisvaikeuksia. Korjaus on yleensä yhteinen sivupohja eikä avun sijoittelu sivu kerrallaan.

Tarpeeton toistaminen koskee monivaiheisia lomakkeita. Varauslomake, joka kysyy sähköpostiosoitetta vaiheessa 1 ja uudelleen vaiheessa 3, ei täytä kriteeriä, eikä myöskään kassa, joka pakottaa kirjoittamaan identtisen laskutusosoitteen uudelleen. Täytä kenttä automaattisesti tai anna käyttäjän valita tieto, esimerkiksi valintaruudulla ”Laskutusosoite on sama kuin toimitusosoite”. Poikkeukset: uudelleensyöttö on välttämätöntä, sitä tarvitaan tietoturvan vuoksi tai aiemmin annettu tieto ei ole enää voimassa.

Saavutettava todentaminen: pääseekö sisään ilman muistikoetta?

Onnistumiskriteerin 3.3.8 (AA) mukaan mikään kirjautumisen vaihe ei saa perustua kognitiiviseen toimintatestiin, kuten salasanan muistamiseen, vääristettyjen merkkien kirjoittamiseen tai pulman ratkaisemiseen, ellet tarjoa vaihtoehtoa tai jotain, joka auttaa. Käytännössä: anna salasanojen hallintaohjelmien täyttää kentät, salli liittäminen ja tarjoa tapa, joka ei nojaa muistiin.

WCAG määrittelee kognitiivisen toimintatestin ”tehtäväksi, joka edellyttää käyttäjältä tiedon muistamista, käsittelemistä tai jäljentämistä”. Nimen, sähköpostiosoitteen tai puhelinnumeron syöttäminen ei ole sellainen, koska ne ovat henkilökohtaisia ja samoja kaikkialla. Kirjautumisvaihe täyttää AA-tason, jos se tarjoaa vähintään yhden seuraavista:

• Vaihtoehtoinen tapa ilman kognitiivista testiä, esimerkiksi pääsyavain tai kirjautumislinkki sähköpostiin.
• Mekanismi, joka auttaa, esimerkiksi tuki salasanojen hallintaohjelmille tai kopiointi ja liittäminen, jottei kertakäyttökoodia tarvitse kirjoittaa uudelleen.
• Esineiden tunnistaminen, esimerkiksi ”valitse kuvat, joissa on polkupyörä”.
• Henkilökohtainen sisältö, kuten itse lataamasi kuvan tunnistaminen.

AAA-versio 3.3.9 poistaa kaksi viimeistä vaihtoehtoa, joten kuva-CAPTCHA voi läpäistä AA-tasolla mutta ei AAA-tasolla. Tyypillisiä puutteita: salasanakentät, jotka estävät liittämisen tai salasanojen hallintaohjelmat, kertakäyttökoodin kentät, jotka menevät rikki liitettäessä, ja teksti-CAPTCHA ilman vaihtoehtoa. Eniten hyötyvät ihmiset, joilla on lukihäiriö tai muistivaikeuksia, mutta jokainen, joka on joskus jäänyt pitkän päivän päätteeksi ulos tililtään, tunnistaa ongelman.

Vaatiiko laki WCAG 2.2:ta?

Se riippuu siitä, missä olet ja kuka olet. Laeissa mainitaan harvoin WCAG-versio suoraan, ja moni viittaa yhä WCAG 2.1:n AA-tasoon. Koska WCAG 2.2 on taaksepäin yhteensopiva, 2.2:n AA-tason täyttäminen täyttää myös 2.1:n AA-tason poistettua kriteeriä 4.1.1 lukuun ottamatta. Tähtäämällä 2.2:een katat molemmat. Jos sopimuksessa mainitaan versio, noudata sopimusta.

• Euroopan unioni: EU:n esteettömyysdirektiivin (EAA) mukaan vaatimustenmukaisuutta oletetaan, kun täytät yhdenmukaistetun standardin EN 301 549. AccessibleEU:n (avautuu uuteen välilehteen) mukaan syyskuussa 2026 julkaistu versio 4.1.1 ottaa käyttöön WCAG 2.2:n, mutta se ei ole vielä oikeudellinen viite; kunnes siihen viitataan EU:n virallisessa lehdessä, sovelletaan versiota v3.2.1 (perustuu WCAG 2.1:n AA-tasoon). Esteettömyysdirektiiviä käsittelevä artikkelimme kertoo, keitä direktiivi koskee.
• Iso-Britannia: hallituksen ohjeen (avautuu uuteen välilehteen) mukaan julkisen sektorin verkkosivustojen ja sovellusten on täytettävä WCAG 2.2:n AA-taso. Ohje koskee julkisia toimijoita, ei yksityisiä yrityksiä.
• Yhdysvallat: oikeusministeriön osavaltioita ja paikallishallintoa koskeva sääntö käyttää WCAG 2.1:n AA-tasoa, ja määräajat siirrettiin huhtikuussa 2026 (avautuu uuteen välilehteen) 26.4.2027 ja 26.4.2028. Yksityisten yritysten osalta ministeriön vuoden 2022 ohje (avautuu uuteen välilehteen) toteaa, että ADA koskee niiden verkkosivustoja, mutta ei aseta tiettyä teknistä standardia.

Entä WCAG 3?

WCAG 3 on luonnos, joten kukaan ei voi vielä täyttää sitä. W3C julkaisi päivitetyt luonnokset syyskuussa 2026 ja toteaa, ettei WCAG 3:n odoteta valmistuvan standardiksi ”vielä muutamaan vuoteen”. WCAG 2:ta ei poisteta käytöstä vielä useaan vuoteen sen jälkeenkään, joten nyt kannattaa tehdä työtä version 2.2 mukaan.

Miten uudet kriteerit tarkistetaan 15 minuutissa?

Useimmat kuuden A- ja AA-tason kriteerin puutteet löydät noin 15 minuutissa näppäimistön, puhelimen ja oman kirjautumissivusi avulla. Se ei korvaa täyttä auditointia tai testausta vammaisten käyttäjien kanssa, mutta se kertoo, mistä aloittaa, ja antaa kehittäjälle konkreettisen listan.

1. Käy etusivu, tuotesivu ja kassa läpi sarkainnäppäimellä niin, että kaikki ilmoitukset ovat näkyvissä. Näetkö kohdistuksen koko ajan? (2.4.11)
2. Tee jokainen liukusäätimellä tai vetämällä ja pudottamalla tehtävä toiminto pelkillä napsautuksilla tai napautuksilla. (2.5.7)
3. Kokeile puhelimella jokaista sulkupainiketta, sivunumeroa ja pientä kuvaketta. (2.5.8)
4. Vertaa, missä apu ja yhteystiedot näkyvät kolmella eri sivutyypillä. (3.2.6)
5. Käy läpi osto tai varaus ja kirjaa jokainen kysymys, johon vastaat kahdesti. (3.3.7)
6. Kirjaudu sisään salasanojen hallintaohjelmalla ja liitä sitten salasana ja kertakäyttökoodi. Onko jokaiselle CAPTCHA:lle vaihtoehto? (3.3.8)

Muun WCAG:n osalta oppaamme verkkosivuston saavutettavuuden testaamisesta käy läpi ilmaiset työkalut ja manuaaliset tarkistukset, ja verkkosivuston saavutettavuuden tarkistuslista muuttaa yleiset puutteet tehtävälistaksi. Kaikki, mitä et vielä pysty korjaamaan, kuuluu saavutettavuusselosteeseesi.

Huomio widgeteistä, myös omastamme: yhtäkään näistä kriteereistä ei voi täyttää kävijän käyttämällä paneelilla. Suuri osoitin helpottaa pienten kohteiden osumista, mutta ei tee niistä 24 pikselin levyisiä, eikä kohdistuksen korostus siirrä kiinteää ilmoitusta pois tieltä. Jokainen uusi kriteeri koskee sitä, miten sivusi on rakennettu, joten korjaus tehdään sivupohjiin ja koodiin.