WCAG 2.2 AA -tarkistuslista SaaS-tuotteille ja verkkosovelluksille

WCAG 2.2 AA -tarkistuslista SaaS-tuotteille: kirjautuminen, lomakkeet, valintaikkunat, SPA-navigointi, taulukot, kaaviot, vetäminen, aikakatkaisut ja ACR.

FixReportsin toimitusPäivitetty 26. lokakuuta 2026Lukuaika 7 min

SaaS-tuotteella on kaksi pintaa, joiden on oltava saavutettavia: markkinointisivusto, joka myy tuotetta, ja sovellus, jota ihmiset käyttävät päivittäin. Markkinointisivusto epäonnistuu samoilla tavoilla kuin mikä tahansa verkkosivusto: heikko kontrasti, puuttuvat alt-tekstit ja nimiöttömät lomakkeet. Sovellus tuo omat ongelmansa: kirjautumisprosessit, jotka estävät salasanojen hallintaohjelmat, valintaikkunat, joihin näppäimistön fokus jää loukkuun, yksisivuisten sovellusten navigointi, jota ruudunlukijat eivät huomaa, datataulukot ja kaaviot ilman tekstiä, vetäminen ja pudottaminen ilman vaihtoehtoa sekä istunnot, jotka vanhenevat varoittamatta. Tämä tarkistuslista käy WCAG 2.2:n AA-tason läpi tyypillisen SaaS-tuotteen osa kerrallaan.

Tärkeimmät kohdat

WCAG 2.2:sta tuli W3C:n suositus lokakuussa 2023, ja se lisäsi yhdeksän onnistumiskriteeriä, joista kuusi on A- tai AA-tasolla (W3C (avautuu uuteen välilehteen)).
Accessible Authentication (3.3.8, AA) tarkoittaa, että kirjautuminen ei saa edellyttää salasanan muistamista tai jäljentämistä, ellei käyttäjä voi liittää sitä tai käyttää salasanojen hallintaohjelmaa (W3C (avautuu uuteen välilehteen)).
Vuorovaikutteisten kohteiden on oltava vähintään 24 × 24 CSS-pikseliä, tai niiden ympärillä on oltava riittävästi tilaa (2.5.8, AA) (W3C (avautuu uuteen välilehteen)).
Viestien, kuten ”Tallennettu” tai ”3 tulosta”, on välityttävä ruudunlukijoille ilman, että fokus siirtyy (4.1.3, AA) (W3C (avautuu uuteen välilehteen)).
Yritys- ja julkisen sektorin ostajat pyytävät usein saavutettavuuden vaatimustenmukaisuusraporttia (Accessibility Conformance Report, ACR), joka laaditaan yleensä Information Technology Industry Councilin VPAT-pohjalle (ITI (avautuu uuteen välilehteen)).

Miksi saavutettavuus on SaaS-tuotteelle tärkeämpää kuin esittelysivustolle?

Ihmiset käyttävät SaaS-tuotetta tuntikausia, usein siksi, että heidän työnantajansa on valinnut sen. Este markkinointisivulla maksaa yhden kävijän; este tuotteessa voi estää jotakuta tekemästä työtään. Siksi suuret asiakkaat, yliopistot ja julkiset organisaatiot kysyvät yhä useammin saavutettavuudesta ennen ostopäätöstä, ja siksi vastauksen on katettava sovellus eikä pelkkää verkkosivustoa.

Asia on tärkeä myös siksi, että automaattiset testit havaitsevat vain osan ongelmista. Työkalut, kuten axe-core, löytävät virheitä merkintäkoodista, esimerkiksi puuttuvia nimiöitä ja heikkoa kontrastia. Ne eivät pysty kertomaan, palauttaako valintaikkuna fokuksen oikeaan paikkaan, onko kaavion data saatavilla tekstinä tai voiko työnkulun suorittaa näppäimistöllä. Sovellus tarvitsee sekä automaattisia tarkistuksia että manuaalista testausta.

Miten teet rekisteröitymisestä ja kirjautumisesta saavutettavia?

Tunnistautumiseen WCAG 2.2 lisäsi SaaS-tuotteiden kannalta tärkeimmän uuden vaatimuksen.

Salli liittäminen ja salasanojen hallintaohjelmat (3.3.8, AA). Älä estä liittämistä salasana- tai koodikenttiin, ja käytä määreitä autocomplete="username", autocomplete="current-password" ja autocomplete="one-time-code", jotta selaimet ja salasanojen hallintaohjelmat voivat täyttää ne.
Vältä tehtäviä ainoana sisäänpääsykeinona. CAPTCHA, joka pyytää jäljentämään vääristettyä tekstiä tai ratkaisemaan tehtävän, on kognitiivisen toiminnon testi. Tarjoa vaihtoehto ja suosi tarkistuksia, jotka eivät vaadi käyttäjältä toimia (W3C (avautuu uuteen välilehteen)).
Anna jokaiselle kentälle nimiö (1.3.1 ja 3.3.2, A). Käytä näkyvää <label>-elementtiä, joka on yhdistetty kenttäänsä; paikkamerkkiteksti katoaa, kun käyttäjä kirjoittaa, eikä se ole nimiö.
Kerro virheet tekstinä (3.3.1, A) ja ehdota korjauksia (3.3.3, AA). ”Salasanassa on oltava vähintään 12 merkkiä” auttaa; pelkkä punainen reunus ei auta.
Älä kysy kahdesti (3.3.7, A). Jos monivaiheinen rekisteröityminen on jo kysynyt yrityksen nimeä tai osoitetta, täytä se valmiiksi tai anna käyttäjän valita se uudelleen kirjoittamisen sijaan.
Pidä ohjeet samassa paikassa (3.2.6, A). Jos tarjoat chatin, ohjelinkin tai yhteystiedot, sijoita ne samaan suhteelliseen paikkaan prosessin jokaisella sivulla.

Mitkä lomake- ja virhemallit aiheuttavat eniten virheitä?

Lomakkeissa on suurin osa sovellusten virheistä. WebAIMin vuoden 2026 selvitys miljoonasta etusivusta löysi puuttuvia lomakkeiden nimiöitä 51 prosentilta niistä (WebAIM (avautuu uuteen välilehteen)), ja sovelluksissa on paljon enemmän lomakkeita kuin etusivuilla.

Anna jokaiselle syöttökentälle ohjelmallisesti määritetty nimi ja ryhmittele toisiinsa liittyvät säätimet, kuten valintanapit, elementeillä <fieldset> ja <legend>.
Kerro virheistä siellä, missä käyttäjä huomaa ne: siirrä fokus lomakkeen yläosan virheyhteenvetoon tai ensimmäiseen virheelliseen kenttään ja linkitä yhteenvedon jokainen kohta omaan kenttäänsä.
Merkitse pakolliset kentät tekstillä, ei pelkällä värillä (1.4.1, A).
Älä lähetä lomaketta tai muuta kontekstia pelkästään siksi, että käyttäjä valitsee vaihtoehdon (3.2.2, A); odota erillistä toimintoa.

Miten valintaikkunoiden, valikoiden ja ponnahdusikkunoiden pitäisi toimia?

Itse rakennetuissa komponenteissa näppäimistön ja ruudunlukijan tuki pettää useimmin. WAI-ARIA Authoring Practices Guide kuvaa kunkin mallin odotetun toiminnan (W3C (avautuu uuteen välilehteen)).

Valintaikkunat: siirrä fokus valintaikkunaan, kun se avautuu, pidä Tab-näppäin sen sisällä sen ollessa auki, sulje se Esc-näppäimellä ja palauta fokus säätimeen, joka avasi sen. Käytä natiivia <dialog>-elementtiä tai määrettä role="dialog" yhdessä määreen aria-modal="true" ja nimen kanssa.
Ei näppäimistöansoja (2.1.2, A): jokaisesta komponentista on päästävä pois näppäimistöllä.
Näkyvä fokus (2.4.7, AA), jota kiinteät ylätunnisteet, evästebannerit tai chat-widgetit eivät peitä (2.4.11, AA, uusi versiossa 2.2).
Työkaluvihjeet ja ponnahdusikkunat (1.4.13, AA), jotka voi sulkea Esc-näppäimellä, joiden päälle voi viedä osoittimen niiden katoamatta ja jotka pysyvät näkyvissä, kunnes ne suljetaan.
Yhden näppäimen pikanäppäimet (2.1.4, A): jos kirjainnäppäimen painallus käynnistää toiminnon, anna käyttäjien poistaa pikanäppäimet käytöstä tai määrittää ne uudelleen, tai tee niistä aktiivisia vain, kun kyseinen komponentti on fokuksessa.

Miten navigointi hoidetaan yksisivuisessa sovelluksessa?

Yksisivuisessa sovelluksessa (single-page app) URL-osoite vaihtuu ilman sivun latautumista, joten ruudunlukijat eivät välttämättä ilmoita, että mitään tapahtui.

Päivitä asiakirjan otsikko jokaisella reitin vaihdoksella, jotta jokaisella näkymällä on kuvaava otsikko (2.4.2, A).
Siirrä fokus uuden näkymän pääotsikkoon tai ilmoita muutoksesta kohteliaalla (polite) live-alueella; esimerkiksi Next.js-sovelluskehyksessä on tätä varten reitti-ilmoittaja (route announcer).
Säilytä looginen fokusjärjestys (2.4.3, A): kun kohde on poistettu, fokuksen pitäisi siirtyä järkevään viereiseen kohteeseen eikä takaisin sivun alkuun.
Tarjoa keino ohittaa toistuva navigointi (2.4.1, A), esimerkiksi ohituslinkki tai maamerkit.

Miten teet koontinäkymistä, datataulukoista ja kaavioista saavutettavia?

Taulukot: käytä aitoa <table>-merkintää, otsikoissa <th>-elementtejä ja scope-määrettä sekä taulukon otsikkoa (caption) (1.3.1, A). <div>-elementeistä rakennetut ruudukot tarvitsevat koko ARIA-ruudukkomallin (grid), joka on paljon vaikeampi toteuttaa oikein.
Kaaviot: anna jokaiselle kaaviolle tekstivastine, joka kertoo pääasian, ja tarjoa data taulukkona (1.1.1, A). Älä erottele datasarjoja pelkällä värillä (1.4.1, A); lisää nimiöitä tai kuvioita.
Kontrasti: teksti tarvitsee suhteen 4.5:1 (1.4.3, AA), ja kaavioiden viivat, kuvakkeet ja syöttökenttien reunat tarvitsevat suhteen 3:1 taustaansa vasten (1.4.11, AA). Tarkista tumma tila erikseen. Värikontrastin tarkistuksemme testaa minkä tahansa väriparin.
Tilaviestit (4.1.3, AA): ”Tallennettu”, ”Lataus valmis” ja tulosmäärät pitäisi välittää role="status"-määreellä tai live-alueella, jotta ruudunlukijoiden käyttäjät kuulevat ne kohdastaan siirtymättä.

Mitä WCAG 2.2:n uudet kriteerit muuttavat verkkosovelluksissa?

Kriteeri	Taso	Mitä se tarkoittaa sovelluksessa
2.4.11 Focus Not Obscured (Minimum)	AA	Kiinteät työkalupalkit, bannerit ja chat-widgetit eivät saa peittää fokuksessa olevaa elementtiä kokonaan
2.5.7 Dragging Movements	AA	Kaikelle vetämällä tehtävälle, kuten kanban-taulun järjestyksen muuttamiselle, tarvitaan yhden osoittimen vaihtoehto, esimerkiksi valikko tai ylös- ja alas-painikkeet
2.5.8 Target Size (Minimum)	AA	Painikkeet ja linkit ovat vähintään 24 × 24 CSS-pikseliä, tai niiden välissä on niin paljon tilaa, ettei kunkin ympärille piirretty 24 pikselin ympyrä mene toisen päälle
3.2.6 Consistent Help	A	Ohjelinkit, chat ja yhteystiedot samassa suhteellisessa paikassa jokaisella sivulla
3.3.7 Redundant Entry	A	Samassa prosessissa jo syötetyt tiedot täytetään valmiiksi tai ne voi valita
3.3.8 Accessible Authentication (Minimum)	AA	Kirjautuminen ilman ulkoa muistamista tai jäljentämistä, ellei liittäminen, salasanojen hallintaohjelmat tai jokin muu keino ole sallittu

WCAG 2.2 poisti myös kriteerin 4.1.1 Parsing, jolla ei enää ole käytännön vaikutusta saavutettavuuteen (W3C (avautuu uuteen välilehteen)).

Entä aikakatkaisut, asettelu ja zoomaus?

Istuntojen aikakatkaisut (2.2.1, A): varoita käyttäjiä ennen istunnon vanhenemista ja anna heidän jatkaa sitä yksinkertaisella toiminnolla, ellei aikaraja ole välttämätön tai yli 20 tuntia. Keskeneräisen työn tallentaminen estää pahimman lopputuloksen.
Uudelleenjuoksutus (Reflow, 1.4.10, AA): sisällön on toimittava 320 CSS-pikselin levyisenä (vastaa 400 %:n zoomausta 1280 pikselin näytöllä) ilman vierittämistä kahteen suuntaan; datataulukot ja vastaava sisältö on vapautettu.
Tekstin välistys (1.4.12, AA): rivinkorkeuden ja merkkivälin kasvattaminen ei saa leikata tekstiä, mitä kiinteäkorkuiset säiliöt usein tekevät.
Suunta (1.3.4, AA): älä lukitse sovellusta pysty- tai vaakasuuntaan, ellei se ole välttämätöntä.

Mikä on ACR, ja tarvitsetko sellaisen?

Saavutettavuuden vaatimustenmukaisuusraportti (Accessibility Conformance Report, ACR) dokumentoi, miten tuote täyttää kunkin saavutettavuuskriteerin: tukee, tukee osittain tai ei tue, huomautuksineen. Useimmat laaditaan Information Technology Industry Councilin julkaisemalle VPAT-pohjalle, josta on versiot WCAG:lle, Yhdysvaltain Section 508 -standardeille ja eurooppalaiselle standardille EN 301 549 (ITI (avautuu uuteen välilehteen)).

Yhdysvaltain liittovaltion virastojen on hankittava saavutettavaa teknologiaa Section 508:n mukaisesti (Section508.gov (avautuu uuteen välilehteen)), ja EU:n julkiset elimet viittaavat standardiin EN 301 549, joten näille asiakkaille myyviltä B2B-tuotteilta pyydetään usein ACR:ää hankinnan yhteydessä. Rehellinen ACR, jossa tunnetut puutteet on lueteltu, on ostajille hyödyllisempi kuin raportti, joka väittää täyttä tukea. Sen pitäisi perustua tuotteen testaamiseen, myös manuaaliseen testaukseen; automaattinen skannaus ei yksinään riitä sen laatimiseen.

Jos myyt EU:n kuluttajille, EU:n esteettömyysdirektiivi (European Accessibility Act) voi koskea myös sitä, miten myyt verkossa; esteettömyysdirektiiviä käsittelevä oppaamme selittää sen soveltamisalan. Tämä ei ole oikeudellista neuvontaa.

Miten SaaS-tiimin pitäisi testata saavutettavuutta?

Automatisoi perusasiat. Aja axe-core tai vastaava moottori end-to-end-testeissäsi ja markkinointisivustolla, ja anna koontiversion epäonnistua uusien rikkomusten vuoksi. Ilmainen saavutettavuustestimme ajaa saman moottorin millä tahansa julkisella sivulla.
Testaa näppäimistöllä. Suorita keskeiset työnkulkusi, kuten rekisteröityminen, tietueen luominen ja asetusten muuttaminen, käyttäen vain näppäimiä Tab, Shift+Tab, Enter, välilyönti, Esc ja nuolinäppäimet.
Testaa ruudunlukijalla. NVDA Windowsissa ja VoiceOver macOS:ssä ja iOS:ssä ovat ilmaisia. Tarkista, että nimet, roolit, tilat ja viestit ilmoitetaan.
Zoomaa ja muuta kokoa. Tarkista 200 %:n tekstin zoomaus ja 320 pikselin levyinen ikkuna.
Korjaa design-järjestelmässä. Useimmat virheet tulevat jaetuista komponenteista; kun korjaat painikkeen tai valintaikkunan kerran, se korjaantuu kaikkialla.

Usein kysytyt kysymykset

Koskeeko WCAG verkkosovelluksen kirjautumisen takana olevia osia?

WCAG koskee kaikkea verkkosisältöä, myös kirjautumisen takana olevia sivuja. Se, vaatiiko jokin laki tiettyä tuotetta täyttämään sen, riippuu lainkäyttöalueesta ja asiakkaasta, mutta saavutettavuudesta kysyvät ostajat tarkoittavat yleensä koko tuotetta.

Voiko overlay-työkalu tehdä SaaS-tuotteesta saavutettavan?

Ei. Overlay-työkalut eivät muuta itse rakennettujen komponenttien taustalla olevaa koodia, ja juuri siellä sovellusten virheet ovat. Overlay-työkaluja käsittelevä oppaamme kertoo FTC:n toimista johtavaa overlay-toimittajaa vastaan.

Kuinka suuren osan WCAG:stä automaattiset työkalut voivat tarkistaa?

Vain osan. Automaattiset säännöt löytävät luotettavasti puuttuvat nimet, nimiöt ja kontrastivirheet, mutta monet kriteerit, kuten mielekäs fokusjärjestys, hyödyllinen alt-teksti ja ymmärrettävät virheilmoitukset, vaativat ihmisen arviota.

Mihin WCAG-versioon meidän pitäisi tähdätä?

WCAG 2.2:n AA-taso on nykyinen versio. Monet lait ja hankintasäännöt viittaavat yhä WCAG 2.1 AA -tasoon; 2.2 AA -tason täyttäminen täyttää myös 2.1 AA -tason poistettua Parsing-kriteeriä lukuun ottamatta.

Pitääkö meidän täyttää AAA-taso?

W3C ei suosittele AAA-tason vaatimista kokonaisilta tuotteilta, koska osa sisällöstä ei voi täyttää kaikkia AAA-kriteereitä. AA-taso on tavallinen tavoite.