WCAG 2.2 -omaksumisaste: missä suositus on ja ei ole siirtynyt lakiin, hankintaan ja auditointikäytäntöihin — vuoden 2026 kartoitus
W3C julkaisi WCAG 2.2:n suosituksena 5. lokakuuta 2023. Kaksi ja puoli vuotta myöhemmin se on versio, jota vastaan jokainen arvostettu auditoija arvioi ja jonka jokainen merkittävä suunnittelujärjestelmä on vähintään osittain omaksunut — mutta ei vielä se versio, johon useimmat maailman saavutettavuuslait tosiasiassa viittaavat. Viive näkyy yhdeksässä tietyssä kohdassa: yhdeksässä uudessa onnistumiskriteerissä. Tämä kenttäopas luettelee ne kaikki.
Tämän sarjan aiemmissa osissa kartoitettiin oikeusviittausten kokonaiskuvaa ylhäältä alaspäin — lainkäyttöalue kerrallaan, säädös kerrallaan. Tämä näkökulma on hyödyllinen vaatimustenmukaisuuspäälliköille ja hankintavastaville. Se on vähemmän hyödyllinen kehittäjälle, suunnittelijalle tai tuotepäällikölle, jonka on toteutettava varsinainen korjaustyö. Tämä opas ottaa päinvastaisen näkökulman: se lähtee liikkeelle onnistumiskriteeristä ulospäin.
Jokainen alla oleva kohde on yksi yhdeksästä uudesta WCAG 2.2 -onnistumiskriteeristä — tarkat muutokset, jotka työryhmä teki edelliseen suositukseen. Jokaisesta kuvataan selkokielellä, mitä kriteeri vaatii, kuinka usein ala tosiasiassa havaitsee puutteen vuoden 2026 auditoinneissa, tuotantosivuston mekanismi, joka laukaisee rikkomuksen, sekä tekninen korjaus. Jokaisella kohteella on sama rakenne, samassa järjestyksessä, joten luetteloa voi lukea ylhäältä alas tai hypätä suoraan haluamaansa kohtaan.
9 uutta onnistumiskriteeriä · järjestetty auditointiepäonnistumistiheyden mukaan 2026
| ID | Malli (SC + otsikko) | Taso | Auditointiepäonnistumisaste |
|---|---|---|---|
| E·01 | 2.4.13 Kohdistuksen ulkoasu | AAA | >70% |
| E·02 | 2.5.8 Kohteen koko (minimi) | AA | Yleisin AA-epäonnistuminen |
| E·03 | 3.3.8 Saavutettava tunnistautuminen (min.) | AA | Suurin vaikutus AA-tasolla |
| E·04 | 2.4.11 Kohdistus ei peity (min.) | AA | Top 5 AA |
| E·05 | 2.5.7 Raahausliikkeet | AA | Kapea pintaala |
| E·06 | 3.3.7 Toistuva syöttö | A | Palvelinpuolen korjaus |
| E·07 | 3.2.6 Yhdenmukainen ohje | A | Toimituksellinen |
| E·08 | 2.4.12 Kohdistus ei peity (parann.) | AAA | E·04:n tiukempi versio |
| E·09 | 3.3.9 Saavutettava tunnistautuminen (parann.) | AAA | E·03:n tiukempi versio |
Epäonnistumisastekuvaukset on koottu itsenäisistä auditoijien raporteista, jotka on julkaistu Q1 2026:een mennessä; menetelmät vaihtelevat yritysten välillä, joten luvut ovat suuntaa antavia eivätkä tarkkoja. Viisi yhdeksästä kriteeristä on AA-tasolla — sääntelyllisesti sitovalla tasolla — ja ne ovat rivejä, joihin hankintaehtojen on ensimmäisenä puututtava.
Missä viive todella näkyy
WCAG:n oikeudellinen sisällyttäminen tapahtuu versioviittauksen kautta. Asetus ei sano “nykyinen WCAG”; se sanoo WCAG 2.0 tai WCAG 2.1, tasoineen ja päivämäärineen. Viittauksen päivittäminen on laki- tai asetusmuutos. Vuoden 2026 puolivälissä maailman tärkeimmät saavutettavuussäädökset jakautuvat edelleen kolmeen versioon: Yhdysvaltain Section 508 viittaa 2.0:aan; EU:n EN 301 549 V3.2.1 viittaa 2.1:een; Yhdistyneen kuningaskunnan PSBAR viittaa 2.1:een (helmikuun 2026 suljettu konsultaatio odottaa tuloksia). Käytännön vuosikymmenen puolivälin kompromissista — “WCAG 2.1 AA minimissään, VPAT 2.5 -raportoinnilla 2.2:ta vastaan toimittajan vasteen salliessa” — on tullut vakiintunutta hankintakieltä.
Hankinta etenee lakia nopeammin. ITI:n VPAT 2.5 / ACR -malli, julkaistu tammikuussa 2025, lisäsi raportointisarakkeet jokaiselle yhdeksälle uudelle kriteerille; jokainen sen jälkeen WCAG-versiota vasten laadittu VPAT raportoi 2.2:ta vastaan. Suurten teknologiayritysten suunnittelujärjestelmien omaksuminen on edennyt kaikkein nopeimmin — Microsoft, Apple HIG, Material 3, Adobe Spectrum ja Meta ovat kaikki yhdenmukaistaneet 2.2:n kanssa vuosina 2024–25. Seuraava luettelo on tekninen vastine: yhdeksän tarkkaa muutosta, jotka työryhmä teki, ja mitä ne todella havaitsevat tuotannossa.
Viisi yhdeksästä uudesta onnistumiskriteeristä on AA-tasolla — nämä ovat sääntelyllisesti sitovia, rivejä joita vuoden 2026 hankintaehto ei voi sivuuttaa.
Kohdistusindikaattorit olivat työryhmän ensisijainen huolenaihe 2.2-työssä. Kaksi kriteeriä käsittelee sitä, peittyykö kohdistusrengas koskaan tekijän sisällön alle; kolmas määrittelee itse indikaattorin. Yhdessä ne havaitsevat jokaisen näppäimistömatkan eniten laiminlyödyn alueen.
Kohdistuksen ulkoasu — 2.4.13 AAA
Kun käyttöliittymäkomponentti saa näppäimistökohdistuksen, kohdistusindikaattorin on täytettävä vähintään 3:1 kontrastisuhde viereiseen väriin nähden ja katettava vähintään kohdistetun elementin ympärillä olevan 2 CSS-pikselin yhtenäisen ääriviivan kehä tai vastaava indikaattorialue. Kriteeri on yksi harvoista WCAG-lisäyksistä, joka määrittelee mitattavan geometrian eikä pelkää käyttäytymistä.
Oletusselainten kohdistusrenkaat, joita suunnittelijat ovat ylikirjoittaneet viisitoista vuotta esteettisistä syistä, eivät läpäise tätä mittausta suurimmalla osalla auditoiduista tuotantosivustoista. Mukautetut kohdistustyylit käyttävät yleensä 1 px:n ääriviivoja tai heikkokontrastisia aksenttivärejä, jotka näyttävät oikeilta suunnittelutyökaluissa, mutta saavat alle 3:1 pisteet todellisen kohdistetun elementin taustaa vasten.
Luku on merkittävä, vaikka kriteeri on AAA-tasolla: se osoittaa, mitä tapahtuisi, jos tuleva sääntelijä kiinnittäisi version WCAG 2.2 tasoon AAA tai jos hankintasopimus nostaisi juuri tämän kriteerin tärkeämmäksi.
Aseta 2 CSS-pikselin ääriviiva värillä, joka saa vähintään 3:1 pisteet elementin taustaa vasten; tarkista kontrastianalysaattorilla eikä silmämääräisesti. Kun suunnittelujärjestelmä ylikirjoittaa selaimen kohdistuksen, luo kohdistustyyli-token, jota suunnittelijat eivät voi vahingossa pudottaa kontrastikynnyksen alle.
Kohteen koko (minimi) — 2.5.8 AA
Jokaisen osoitinsyötteen osumakohteen on oltava vähintään 24 kertaa 24 CSS-pikseliä, ellei kohde ole osa lausetta, käyttäjäagentti aseta sen kokoa, vastaava kohde on saatavilla, tai kohteen toiminto on välttämätön. Kriteeri mittaa osumakohteen, ei näkyvää kuvaketta.
Kriteeri havaitsee tietyn käyttöliittymämallin: tiheät kuvakepalkit, erityisesti editoreissa, hallintapaneeleissa ja datataulukon otsikoissa. Useimmat kuvakepainike-kirjastot käyttävät oletuksena 16×16 tai 20×20 pikselin visuaalisia kuvakekokoja hieman suuremman osumakohteen sisällä. Kun osumakohde on myös alle 24×24 pikselin, kriteeri epäonnistuu — ja palkin suunnittelijat tiivistävät toistuvasti välejä mahduttaakseen enemmän kuvakkeita rajalliseen vaakatilaan.
Aseta suunnittelujärjestelmään vähintään 24 kertaa 24 CSS-pikselin osumakohde-token, toteutettuna täytteellä eikä kuvakkeen omilla mitoilla. Kun palkit eivät pysty noudattamaan lattiaa, lisää riittävästi tilaa niin, etteivät vierekkäiset kohteet ole kriteerin päällekkäisyyspoikkeuksen sisällä. Tarjoa asetustason vaihtoehto (suurempi valikko) todellisesti ahtaille pinnoille.
Saavutettava tunnistautuminen (minimi) — 3.3.8 AA
Verkkosivuston tai sovelluksen tunnistautumisvaihe ei voi perustua kognitiiviseen funktiotestaukseen — palapelin ratkaiseminen, vääristyneen kuvan transkriptio, objektien tunnistaminen ruudukosta — ellei vaihtoehtoista tunnistautumismenetelmää ole tarjolla, apumekanismi ole käytettävissä tai objektintunnistuspoikkeus sovellu. Salasanan muistaminen katsotaan kognitiiviseksi funktiotestaukseksi, minkä vuoksi salasananhallintaohjelmat on nimenomaisesti otettu huomioon.
Useimmat kuvaan perustuvat CAPTCHA-ratkaisut epäonnistuvat tässä suoraan. Samoin “klikkaa liikennevalokuutiot” -haasteet, vääristyneen tekstin transkriptiotestit sekä kaikki työnkulut, joissa kertakäyttöinen koodi liitetään kenttään, mutta liittämistoiminto on poistettu käytöstä. Malli on keskittynyt kirjautumis-, salasanan palautus- ja tilin luomisvirtoihin — juuri niihin korkean panoksen pisteisiin, joissa lukittumisella on suurin hinta.
Tunnistautumisvirrat ovat myös alue, jossa kriteerin pureva vaikutus on terävimmillään, koska epäonnistuminen ei heikennä kokemusta — se lopettaa sen.
Korvaa kognitiiviset CAPTCHA-ratkaisut ei-kognitiivisella vaihtoehdolla — laitepohjainen varmennus, maaginen linkki, passkeys tai näkymätön riskipisteet. Salli salasananhallintaohjelman täyttö automaattisesti. Varmista, että kopiointi ja liittäminen toimii kertakäyttöisissä koodikentissä. Jos CAPTCHA on säilytettävä, tarjoa äänivaihtoehto, joka itsessään ei vaadi vääristyneen puheen transkriptiota.
AA-taso on jännitteinen kohta
Viisi yhdeksästä uudesta kriteeristä on AA-tasolla: 2.4.11 Kohdistus ei peity (min.), 2.5.7 Raahausliikkeet, 2.5.8 Kohteen koko (min.), 3.3.8 Saavutettava tunnistautuminen (min.) ja (paranneltu AAA-versio 3.3.9). Nämä ovat kriteereitä, joita hankintaehto ei voi sivuuttaa, ja rivejä, joissa ero WCAG 2.1 AA -vaatimustenmukaisuuden ja WCAG 2.2 AA -vaatimustenmukaisuuden välillä on mitattavissa. Kaksi A-tason lisäystä (3.2.6 Yhdenmukainen ohje, 3.3.7 Toistuva syöttö) ovat helpompia voittoja. Kaksi AAA-lisäystä (2.4.12 ja 3.3.9) ovat AA-parien tavoitteellisempia tiukennuksia.
Kohdistus ei peity (minimi) — 2.4.11 AA
Kun käyttöliittymäkomponentti saa näppäimistökohdistuksen, kohdistettu elementti ei saa olla kokonaan piilossa tekijän luoman sisällön alle. Osittainen peittyminen on sallittua tällä tasolla (kiinteä otsikko, joka peittää kohdistetun kentän yläpuolen, on sallittu); täydellinen peittyminen ei ole.
Yleisin törmäys on kiinteä otsikko — joskus evästebanneri tai kelluva chat-widget — joka peittää kohdistetun lomakekentän, kun näppäimistön käyttäjä siirtyy siihen tab-näppäimellä. Tuotantosivustot, jotka lisäsivät kiinteän otsikon olemassa olevaan lomakkeeseen vuosien 2020–22 uudelleensuunnitteluvaiheessa, jättivät toistuvasti huomaamatta kohdistus- ja vieritystoiminnan, koska alkuperäinen lomake oli kirjoitettu ennen kiinteiden elementtien olemassaoloa.
Aseta scroll-margin-top (tai scroll-padding-top vierityskontaineriin) vastaamaan kiinteän päällysteen korkeutta. Testaa, että pitkän lomakkeen tab-siirtyminen vierittää kohdistetun elementin kokonaan näkyviin otsikoiden alapuolelle. Yhdistä tämä kohdistuksen näkymistä parantaviin tyyleihin, jotta käyttäjä näkee, mihin kohdistus todellisuudessa siirtyi.
Motorisen saavutettavuuden ohjelma WCAG 2.2:ssa tiivistyi kahteen kriteeriin, molemmat AA-tasolla. Toinen havaitsee listajärjestystoiminnot, jotka vaativat jatkuvaa raahaamista; toinen (E·02 yllä) havaitsee tiheät kuvakepalkit. Niillä on yhteinen syy — suunnittelujärjestelmät, jotka olettavat tarkan osoittimen.
Raahausliikkeet — 2.5.7 AA
Toiminnallisuuden, joka käyttää raahausliikettä, on myös oltava käytettävissä yksiosoitintoiminnolla — napautuksella, klikkauksella tai vastaavalla, joka ei vaadi jatkuvaa osoitinliikettä. Raahaa ja pudota -vuorovaikutuksia ei kielletä; ne eivät vain voi olla ainoa käytettävissä oleva polku toimintoon.
Listan järjestämis- ja kanban-tyyppiset käyttöliittymät toimitetaan usein pelkällä raahauksella toteutetulla järjestelyllä. Sama koskee liukusäätimiä, jotka on toteutettu raahauksella toimivina peukaloina ilman vastaavaa numeerista syötettä, sekä kuvanrajauskäyttöliittymiä, jotka vaativat raahauksen rajojen asettamiseen. Kriteeri havaitsee nämä joka kerta.
Tarjoa jokaiselle raahaustoiminnolle vastaava napautus- tai klikkausvaihtoehto — “siirrä ylös”- ja “siirrä alas”-painikkeet raahaettavien listakohteiden viereen, numeerinen syöte liukusäätimen viereen, klikkaamalla-aseta-rajat-tila rajaajassa. Kun vaihtoehto on piilotettu kontekstuaaliseen valikkoon, varmista, että se on saavutettavissa näppäimistöllä.
Neljä jäljelle jäävää kriteeriä jakautuu kahteen pariin: kaksi A-tason toimituksellista lisäystä (Toistuva syöttö ja Yhdenmukainen ohje) sekä kaksi AAA-tiukennusta (Kohdistus ei peity paranneltu, Saavutettava tunnistautuminen paranneltu). Yhdessä ne täydentävät WCAG 2.2:n ohjelman kognitiivisen kuorman saavutettavuudesta.
Toistuva syöttö — 3.3.7 A
Saman todennetun prosessin aikana käyttäjää ei saa pyytää syöttämään samaa tietoa kahdesti — ellei uudelleensyöttö ole välttämätöntä, aiempi syöte ei enää päde tai tieto koskee turvallisuutta (salasanan uudelleenkirjoittaminen tilin luomisen yhteydessä on kanoninen poikkeus). Aiemmin syötettyjen arvojen automaattinen täyttö tai valitseminen täyttää kriteerin molemmat.
Monivaiheinen kassavirta, monisivuiset hakulomakkeet ja viisumi- tai lupahakemukset pyytävät toistuvasti samaa osoitetta, nimeä tai yhteystietoa kahdessa erillisessä vaiheessa, koska vaiheet on rakennettu eri tiimeissä eikä niitä ole koskaan yhdenmukaistettu. Käyttäjän aiemmin syöttämiä arvoja ei säilytetä vaiheiden välillä jaetussa istunnossa.
Säilytä käyttäjän syöttämät arvot prosessin vaiheiden yli; esitäytä vastaavat kentät myöhemmissä vaiheissa; tai tarjoa yhdellä klikkauksella toimiva “käytä samaa osoitetta” -ohjain. Malli tulee yleensä esiin prosessien kartoituksessa eikä käyttöliittymän auditoinnissa, joten poikkitiiminen virtauskatselmus on käytännön korjausaskel.
Yhdenmukainen ohje — 3.2.6 A
Jos ohjeistusmekanismi on tarjolla — yhteystietolinkki, ohjesivu, chat-widget, tukipuhelinnumero, itsepalvelulinkki — sen on esiinnyttävä samassa suhteellisessa sijainnissa sivuilla, joilla se on tarjolla. Kriteeri ei vaadi ohjeistuksen olemassaoloa; ainoastaan sen, että se on tarjolla johdonmukaisesti sijoitettuna.
Kriteeri on periaatteessa suoraviivainen ja havaitsee kapean joukon sivustoja, joilla on “Ota yhteyttä” -linkki otsikossa joillain sivuilla, alatunnisteessa toisilla ja kelluvan chat-widgetin sisällä kolmannella ryhmällä sivustoja — usein tuloksena useista sivuston osioista, joita omistavat eri tiimit erillisillä mallipohjilla.
Auditoi ohjeistusmekanismien sijoittuminen eri mallipohjilla; päätä yhdestä kanonisesta sijainnista (otsikko, kiinteä alatunniste tai kelluva widget) ja yhdenmukaista poikkeukset. Korjaus on harvoin tekninen; se on sisällön ja mallipohjan hallintavaihe.
Kohdistus ei peity (paranneltu) — 2.4.12 AAA
2.4.11:n AAA-versio: kun käyttöliittymäkomponentti saa näppäimistökohdistuksen, kohdistettu elementti ei saa olla lainkaan tekijän luoman sisällön peittämä. Osittainen peittyminen on kiellettyä tällä tasolla — kiinteä otsikko, joka peittää minkä tahansa osan kohdistetusta kentästä, ei täytä vaatimusta.
Samat kiinteän päällysteen törmäykset, jotka aiheuttavat 2.4.11-epäonnistumisia, jatkuvat 2.4.12:ssa. Sivustot, jotka ottivat käyttöön scroll-margin-top täyttääkseen minimikriteerin, jättävät yleensä muutamia CSS-pikseleitä päällekkäisyyteen reunatapauksissa eri näkymäkorkeuksilla. AAA-tasolla tämä päällekkäisyys on epäonnistuminen.
Säädä scroll-margin-top ylittämään mukavasti jokaisen tekijän luoman päällysteen korkeus, mukaan lukien dynaamiset (evästebanneri, joka näkyy ensimmäisellä käyntikerralla, chat-widget, joka laajenee hoverilla). Lisää eksplisiittiset regressiotestit tab-into-form-käyttäytymiselle yleisillä näkymäkoilla.
Saavutettava tunnistautuminen (paranneltu) — 3.3.9 AAA
3.3.8:n AAA-versio: tunnistautuminen ei voi nojautua kognitiiviseen funktiotestaukseen, piste. AA-tasolla soveltuvat poikkeukset objektintunnistukseen ja henkilökohtaiseen sisältöön eivät päde tässä. Muistitestit, transkriptiotestit ja kuvatunnistushaasteet epäonnistuvat kaikki tällä tasolla.
Jopa sivustot, jotka korvasivat perinteiset CAPTCHA-ratkaisut objektintunnistushaasteilla (AA-poikkeus), epäonnistuvat 3.3.9:ssä. Kriteeri on työryhmän signaali siitä, minne tunnistautuminen tulisi suunnata: pois kognitiivisista haasteista kokonaan, kohti laitevarmennusta tai biometristä tunnistamista.
Ota passkeys (WebAuthn) käyttöön ensisijaisena tunnistautumismekanismina; pidä salasana-plus-passkeys-yhdistelmä siirtymätilana eikä määränpäänä. Kun kuvantunnistusta on säilytetty riskipisteytykseen, suorita se palvelinpuolella käyttäytymissignaalien pohjalta eikä käyttäjälle näytettävänä haasteena.
WCAG 2.2 -lisäykset eivät ole se paikka, jossa saavutettavuuden vaikein työ sijaitsee. Ne ovat se paikka, jossa yleisimmät, mitattavimmat tuotantoepäonnistumiset sijaitsevat — mikä on täsmälleen se syy, miksi ne valittiin.
Mitä yhdeksällä on yhteistä
Luettelona luettuna yhdeksällä uudella kriteerillä on yhteinen toimituksellinen asenne. Ne eivät ole uusia epäonnistumistapoja, joita työryhmä keksi; ne ovat epäonnistumistapoja, jotka ovat esiintyneet johdonmukaisimmin WCAG 2.1:n julkaisemisen jälkeisillä vuosilla. Työryhmä käsitteli niitä aukkoina, jotka on suljettava: tiheät palkit (2.5.8), kiinteät päällykset (2.4.11 / 2.4.12), CAPTCHA-tyylinen tunnistautuminen (3.3.8 / 3.3.9), oletuskohdistusrenkaat (2.4.13), toista-osoite-kassa-mallit (3.3.7), vain raahauksella toimivat listajärjestelyt (2.5.7) ja ohjelinkin sijoittelun epäjohdonmukaisuus, joka turhauttaa kognitiivisten vammojen asianajajia (3.2.6).
Oikeusviittauksen kuva jää jälkeen, koska versioviittausmekanismi on hidas. EN 301 549 V4 — suurin yksittäinen tuleva tapahtuma — kaskadoisi WCAG 2.2:n EU:n saavutettavuusdirektiivin, eurooppalaisen esteettömyysdirektiivin (EAA) vaatimustenmukaisuusviittauksen ja jokaisen kansallisen verkkosaavutettavuuslain yli, joka viittaa harmonisoituun eurooppalaiseen standardiin. Vuoden 2026 julkaisu on ETSI JTC HF:n sisäinen oletus; vuoden 2027 viivästyminen on varovaisempi arvio. Yhdistyneen kuningaskunnan PSBAR-muutos, helmikuun 2026 suljetun konsultaation jälkeen, odotetaan ennen vuoden loppua. Yhdysvaltain Section 508 -päivitys pysyy hitaimmin liikkuvana suurena palana — jopa 2.1-päivitys on edelleen vireillä 2026:ssa; 2.2-päivitys on realistisesti 2020-luvun lopun instrumentti.
Vuoden 2026 suunnittelutarkoituksiin WCAG 2.2 on standardi, johon laissa ja hankinnassa viitataan vuosikymmenen loppuun asti. WCAG 3 (Silver) on edelleen Working Draft -tilassa eikä ole lähellä Recommendation-julkaisua; vuoden 2025 viimeisimmässä julkisessa luonnoksessa kävi selväksi, ettei Recommendation-tason julkaisua odoteta ennen vuotta 2028. Versioviittauskäytäntö säädöksissä tarkoittaa, että 2.2 säilyy viitattuna vuosia 3.0:n julkaisemisen jälkeen. Käytännön hankintaehto — vaadi WCAG 2.2 tasolla AA vaatimustenmukaisuuden kohteeksi, vaadi viimeisen 12 kuukauden aikana päivätty VPAT 2.5 ACR, vaadi toimittajaa yksilöimään yhdeksästä uudesta kriteeristä ne, joissa vaatimustenmukaisuutta ei vielä saavuteta — toimii missä tahansa lainkäyttöalueessa, jonka taustalla oleva laki viittaa edelleen 2.0:aan tai 2.1:een, koska mikään näissä laeissa ei estä ostajaa sopimasta enemmästä.
WCAG 2.2 -valmiustarkistuslista
Hankintakieli (tee tämä nyt)
- Vaadi WCAG 2.2 tasolla AA vaatimustenmukaisuuden kohteeksi uusissa sopimuksissa
- Vaadi jokaiselta toimittajalta viimeisen 12 kuukauden sisällä päivätty VPAT 2.5 ACR
- Vaadi toimittajia yksilöimään yhdeksästä uudesta kriteeristä ne, joissa vaatimustenmukaisuutta ei vielä saavuteta, sekä dokumentoitu korjaussuunnitelma
- Pidä “WCAG 2.1 AA minimissään, raportoinnilla 2.2:ta vastaan toimittajan vasteen salliessa” lattiana — ei kattona
Tekniset regressiotestit (havaitse AA-viisi ennen kuin auditoija tekee sen)
- Tab-into-form-käyttäytyminen yleisillä näkymäkoilla, kaikki päällykset auki (2.4.11)
- Osumakohteen mitat kuvakepalkissa, hallintapaneeleissa ja datataulukon otsikoissa (2.5.8)
- Yksiosoitin-vaihtoehdot jokaiselle raahaustoiminnolle — listajärjestys, liukusäätimet, rajaajat (2.5.7)
- Kirjautumis-, rekisteröinti- ja salasanan palautusvirrat ilman kognitiivisia funktiotesteistä; liittäminen käytössä OTP-kentissä (3.3.8)
- Vaiheiden välinen pysyvyys: mitään kenttää ei kysytä kahdesti saman todennetun prosessin aikana (3.3.7)
Toimituksellinen / IA-katselmus (kaksi A-tason lisäystä)
- Yksi kanoninen sijainti ohjeistusmekanismeille eri mallipohjilla (3.2.6)
- Poikkitiiminen virtauskatselmus kaikille monivaiheisille prosesseille, joita omistaa useampi kuin yksi tiimi (3.3.7)
Vuoden 2026 seurantakohteet
- EN 301 549 V4 -julkaisu — käynnistää WCAG 2.2:n koko EU:n verkkosaavutettavuuslainsäädännössä
- Yhdistyneen kuningaskunnan PSBAR-muutos — ensimmäinen merkittävä englanninkielinen lainkäyttöalue, joka kiinnittää version 2.2
- Yhdysvaltain Section 508 ICT -päivitys — 2.1 edelleen vireillä; 2.2 on 2020-luvun lopun instrumentti
- VPAT 2.5 -sykli — jokaisen vuonna 2025 tai sen jälkeen päivätyn ACR:n tulisi raportoida 2.2:ta vastaan
WCAG 2.2 -siirtymä on rakenteellisesti kaksi siirtymää, jotka kulkevat eri kellojen mukaan. Lain siirtymä on hidas, riippuvainen pienestä joukosta standardointielimiä — ennen kaikkea ETSI JTC HF:stä — ja jatkuu läpi vuosien 2026–27. Ammatinharjoittajan siirtymä on suurelta osin jo tehty: auditoijat pisteyttävät 2.2:ta vastaan, suunnittelujärjestelmät yhdenmukaistuvat sen kanssa, toimittajat toimittavat VPAT 2.5 ACR -raportteja sitä vastaan ja yhdeksästä uudesta kriteeristä on tullut vakiintunut saavutettavuusauditointien sanasto. Mielenkiintoinen analyyttinen kysymys ei enää ole se, onko WCAG 2.2 käytännön standardi — se on — vaan se, saavuttavatko sääntelyviittaukset sen ennen kuin WCAG 3 alkaa vetää huomiota eteenpäin.
MenetelmäEpäonnistumisastekuvaukset on koottu itsenäisistä auditoijien raporteista, jotka on julkaistu Q1 2026:een mennessä SaaS-, verkkokauppa- ja julkisen sektorin auditointisykleissä. Laadullisia kuvauksia käytetään, kun yritykset julkaisevat ordinaalisia eikä tarkkoja asteita.
LaajuusVain yhdeksän uutta WCAG 2.2 -onnistumiskriteeriä. SC 4.1.1 Parsing, poistettu WCAG 2.2:ssa, on rajattu ulkopuolelle. WCAG 2.1:stä siirretyt kriteerit on rajattu ulkopuolelle.
LähteetW3C, Web Content Accessibility Guidelines (WCAG) 2.2, Recommendation 5 October 2023 — w3.org/TR/WCAG22; W3C AG WG, What’s New in WCAG 2.2 — w3.org/WAI/standards-guidelines/wcag/new-in-22; ETSI, EN 301 549 V3.2.1 (2021) and JTC HF V4 drafts; US Access Board ICT Standards (Section 508 Refresh, 2017); US DOJ, Final Rule — Title II web accessibility, 28 C.F.R. Part 35 (April 2024); UK Cabinet Office, PSBAR 2018 and 2025–26 consultation; ITI, VPAT 2.5 / ACR, January 2025 — itic.org/policy/accessibility/vpat; EU Directives 2016/2102 and 2019/882; W3C, WCAG 3.0 Working Draft — w3.org/TR/wcag-3.0. Lue lisää kansallisista saavutettavuussäädöksistä, ammatinharjoittajan Toolkitista, täydellisestä WCAG 2.2 -onnistumiskriteerien viitteestä, vaatimustenmukaisuus-, vaatimustenmukaisuus- ja saavutettavuusselityksestä, seurannan ostajan oppaasta, ilmaisesta WCAG 2.2 -perustasoskannauksesta ja laajemmasta vuoden 2026 raporttitietueesta.