WCAG 2.2 on nyt EU:n toimiva AA-tavoite eurooppalaisen esteettömyysdirektiivin ja harmonisoidun standardin EN 301 549 kautta, ja se on tosiasiallinen vertailukohta, jota yhdysvaltalaiset tuomioistuimet käyttävät ADA:n kattamien verkkosivustojen arviointiin, vaikka säädökset nimeäisivät yhä 2.1:n. Standardi on hyvin dokumentoitu; polku “tiedämme, että meidän on noudatettava” -tilasta “meillä on puolustettava asema” -tilaan ei ole. Tämä opas on se polku, kuudessa vaiheessa siinä järjestyksessä, jossa tiimin kannattaa todella edetä.

WCAG 2.2 on nykyinen versio Verkkosisällön saavutettavuusohjeista (WCAG), jonka W3C julkaisi suosituksena lokakuussa 2023. Se määrittelee 86 onnistumiskriteeriä neljän periaatteen mukaan organisoituina — sisältö on oltava havaittava, hallittava, ymmärrettävä ja luja. Kullekin kriteerille on määritelty vaatimustenmukaisuustaso. Taso A on minimiraja; taso AA on käytännön vertailukohta, johon jokainen suuri sääntelyviranomainen viittaa; taso AAA on tavoitteellinen eikä se ole sääntelyllinen lattia missään.

Kun sääntelyviranomainen tai sopimus sanoo “WCAG 2.2 AA -vaatimustenmukainen”, se tarkoittaa enemmän kuin yhden sivun läpäisemistä. W3C:n vaatimustenmukaisuusmääritelmä edellyttää, että koko vaatimustenmukaisuusyksikkö — sivu tai prosessin muodostava sivujoukko — täyttää jokaisen tason A ja AA kriteerin, että kaikki prosessit ovat saavutettavia alusta loppuun ja että avustavaa teknologiaa ei tarvitse sammuttaa sisällön toimimiseksi. Sivusto, joka täyttää useimmat kriteerit useimmilla sivuilla, ei ole vaatimustenmukainen; lista on täydellinen kattavuus.

WCAG 2.2 lisää yhdeksän uutta kriteeriä 2.1:een verrattuna — kohdistuksen ulkoasu, kohteen koko, raahaaminen, redundantti syöte, saavutettava todennus, johdonmukainen ohje ja muutama muu. Sivustot, jotka olivat 2.1 AA -vaatimustenmukaisia, eivät automaattisesti ole 2.2 AA -vaatimustenmukaisia; uudet kriteerit ovat se, mistä aukko näkyy. Kriteerikohtainen totuuden lähde löytyy täydellisestä WCAG 2.2 -onnistumiskriteerien viitteestämme.

Vaatimustenmukaisuus on asema, ei tila — sivusto, joka täyttää kriteerit maanantaina, voi julkaista regression tiistaina. Sen käsitteleminen kertaluonteisena projektina on alan yleisin ja kallein virhe.

Et voi korjata sitä, mitä et ole mitannut, eikä yksikään työkalu mittaa sitä hyvin. Lähtökohtaauditointi suoritetaan kolmessa tilassa suunnilleen samoilla sivuilla.

Tila 1 — Automaattinen skannaus. Skanneri raportoi koneellisesti tarkistettavissa olevat virheet — puuttuvat vaihtoehtoistekstit, puuttuvat lomaketunnisteet, matala värikontrasti, virheellinen ARIA, otsikkorakenneongelmat. Se löytää tiheät, toistuvat ongelmat, joita insinööri muuten joutuisi metsästämään manuaalisesti, mutta ei pysty arvioimaan, onko vaihtoehtoinen teksti merkityksellinen, tuntuuko mukautettu widget ruudunlukijalla oikealta tai onko kohdistusjärjestys kognitiivisesti järkevä. Käsittele skannaus volyymiperustan saamiseksi, ei tuomiona. Aloita ajamalla ilmainen WCAG 2.2 -skanneri kymmenellä tärkeimmällä sivullasi — etusivu, kirjautuminen, kassavirta, kaksi tuotesivua, hallintapaneeli, tilin asetukset, saavutettavuusseloste jos se on olemassa sekä kaksi eniten liikennöityä laskeutumissivua. Skannaus kertoo, onko sinulla sata vai kymmenentuhatta ongelmaa, mikä on ensimmäinen tieto, jota korjausvastaava tarvitsee.

Tila 2 — Manuaalinen arviointi koulutetun saavutettavuusasiantuntijan toimesta. Koulutettu arvioija, joka käy läpi samat sivut, löytää sen, mitä automaatio ei pysty arvioimaan. Onko vaihtoehtoinen teksti tarkka? Onko otsikkorakenne looginen, ei vain syntaktisesti pätevä? Paljastavatko mukautetut widgetit oikean nimen, roolin ja tilan? Asiantuntija kattaa noin viisitoista-kaksikymmentä sivua päivässä; tuloksena on kirjallinen raportti, jossa toistettavat vaiheet on yhdistetty tiettyihin onnistumiskriteereihin.

Tila 3 — Käytettävyysauditointi avustavaa teknologiaa käyttävien henkilöiden kanssa. Ruudunlukijankäyttäjä suorittaa kassan; pelkkää näppäimistöä käyttävä henkilö navigoi hallintapaneelissa; heikkonäköinen käyttäjä täyttää yhteydenottolomakkeen 200 prosentin zoomilla. Tulokset ovat laadullisia — “julkaisuilmoitus tapahtuu ennen kuin kohdistus siirtyy, joten jätin sen huomaamatta” — ja se on kerros, joka erottaa vaatimustenmukaisuuden saavutettavuudesta. Tämä tila on se, jonka organisaatiot useimmiten ohittavat; ohita se ja läpäiset skannaukset ja selosteet samalla kun käyttäjäsi eivät edelleenkään pysty suorittamaan tehtäviään loppuun.

Kolme tilaa täydentävät toisiaan: automaatio löytää volyymin, asiantuntija-arviointi löytää rakenteelliset ja semanttiset ongelmat, käyttäjätestaus löytää kokemusvirheet. Kaikkien kolmen kattava lähtökohtaauditointi vie kaksi-neljä viikkoa keskikokoiselle sivustolle.

Lähtökohtaauditointi tyypillisellä sivustolla tuo esiin satoja tai tuhansia ongelmia. Aloittaminen litteän listan ylhäältä on tapa käyttää kolme kuukautta ilman edistystä. Triage toimii kahdella akselilla — vakavuus ja kattavuus.

Vakavuus on se, kuinka pahasti ongelma rikkoo käyttökokemuksen. Estäjät estävät tehtävän suorittamisen: kassapainike, jota ruudunlukijat eivät pysty aktivoimaan, lomakekenttä ilman ohjelmallista tunnistetta, modaali, joka loukkaa kohdistuksen. Merkittävät ongelmat aiheuttavat huomattavaa kitkaa eivätkä estä: epäselvä linkkiteksti, puuttuva kohdistustyyli, virheviestit, jotka näkyvät mutta eivät ilmoitu. Vähäiset ongelmat ovat kosmeettisia tai koskevat vain kapeita avustavan teknologian konfiguraatioita: kontrasti juuri alle 4,5:1, koristeellinen vaihtoehtoinen teksti, jossa on perässä välilyönti, ohitettu otsikkotaso alaviitesivulla.

Kattavuus on se, kuinka moni käyttäjä kohtaa ongelman. Epäselvä linkki globaalissa navigoinnissa tavoittaa jokaisen kävijän jokaisella sivulla. Saavuttamaton päivämäärälomake kassavirrassa tavoittaa jokaisen ostajan. Saavuttamaton komponentti lehdistömateriaalilla tavoittaa lähes ketään. Kattavuus määritetään analytiikan perusteella, ei ongelman sisäisen kiinnostavuuden perusteella.

Yksinkertainen kaksi-kertaa-kaksi -matriisi riittää. Tarkoitus ei ole tarkkuus — vaan pakottaa se keskustelu, että “ruudunlukijan estäminen kassan loppuun saattamisesta” ei ole sama ongelma kuin “vaihtoehtoinen teksti, jossa on perässä välilyönti, lehdistösivulla.”

Triage tuottaa priorisoidun backlogin. Backlog — ei auditointiraportti — on se, minkä perusteella kehitystiimi työskentelee.

Korjaustyö jakautuu samoihin kaavoihin lähes jokaisella sivustolla. Jokainen kategoria vastaa yhtä tai useampaa WCAG-onnistumiskriteeriä; täydellinen WCAG 2.2 -onnistumiskriteerien viite on totuuden lähde.

Semanttinen HTML-rakenne. Eniten vaikutusta tuottava korjaus on oikean elementin käyttäminen. button ei ole div napsautuskäsittelijällä; otsikko ei ole lihavoitu teksti; lista ei ole rivinvaihdoilla erotellut kappaleet. Natiivi HTML kantaa nimen, roolin ja näppäimistökäyttäytymisen ilmaiseksi; sen uudelleentoteuttaminen ARIA:lla yleisellä elementillä on tapa, jolla useimmat saavutettavuusvirheet syntyvät. Vastaa onnistumiskriteereihin SC 1.3.1 ja SC 4.1.2.

Kuvien vaihtoehtoistekstit. Jokaisella merkityksellisellä kuvalla on oltava kuvaileva vaihtoehtoinen teksti. Koristeelliset kuvat saavat alt="", ei puuttuvaa attribuuttia. Toiminnalliset kuvat — kuvakkeet painikkeissa, kuvanapit — saavat vaihtoehtoisen tekstin, joka kuvaa toiminnon, ei kuvaa. Vastaa onnistumiskriteeriin SC 1.1.1.

Näppäimistön käytettävyys. Jokaisen interaktiivisen elementin on oltava saavutettavissa ja käytettävissä pelkällä näppäimistöllä — tabuloi siihen, aktivoi Enterillä tai Välilyönnillä, poistu Escapella. Mukautetut widgetit (pudotusvalikot, modaalit, välilehdet, karusellit, päivämäärävalitsimet) ovat tyypillisimmät rikkojat. Testaa irrottamalla hiiri. Vastaa onnistumiskriteereihin SC 2.1.1 ja SC 2.1.2.

Kohdistuksen hallinta. Kun kohdistus saapuu elementille, sen on oltava näkyvä, ja kun jokin muuttaa sivua, kohdistuksen on siirryttävä järkevään paikkaan. Modaali, joka avautuu, pitäisi siirtää kohdistuksen siihen; sen sulkeminen pitäisi palauttaa kohdistuksen laukaisijaan. WCAG 2.2 lisäsi SC 2.4.11 Kohdistus ei peity ja tiukensi SC 2.4.7 Kohdistus näkyy; kohdistusrengas ei ole enää valinnainen viimeistely.

Värikontrasti. Tekstin taustaa vasten on saavutettava 4,5:1 normaalille ja 3:1 suurelle SC 1.4.3:n nojalla; interaktiivisten käyttöliittymäkomponenttien ja grafiikoiden on saavutettava 3:1 SC 1.4.11:n nojalla. Useimmat rikkomukset ovat markkinointipinnoilla — brändivärein, jotka näyttävät hyvältä suunnittelijan kalibroidulla näytöllä ja epäonnistuvat oikealla kannettavalla. Kontrastin tarkistustyökalu suunnittelutyökaluissa estää useimmat regressiot.

Lomake-etiketit ja virheilmoitukset. Jokaisella kentällä on oltava ohjelmallinen tunniste, ei paikkamerkki. Virheet on ilmoitettava avustavalle teknologialle, liitettävä niitä tuottavaan kenttään ja kuvattava toiminnanohjauksellisesti. “Virheellinen syöte” ei ole tunniste; “Puhelinnumero täytyy sisältää maakoodi” on.

ARIA — hillittyyttä, ei innostuneisuutta. Käytä ARIA:a vain silloin, kun natiivi HTML ei pysty ilmaisemaan mitä komponentti tekee. nav on parempi kuin role="navigation"; button on parempi kuin role="button". Virheellinen ARIA on pahempi kuin ei ARIA:a lainkaan, koska se aktiivisesti antaa avustavalle teknologialle väärää tietoa.

Dynaamisen sisällön ilmoitukset. Kun sisältö muuttuu ilman sivun uudelleenlataamista — ilmoituspalkit, vahvistusviestit, hakutulokset, jotka päivittyvät paikallaan — ruudunlukijat eivät huomaa sitä, ellei niille kerrota. Käytä aria-live="polite" ei-kiireellisille päivityksille ja aria-live="assertive" vain todellisiin keskeytyksiä vaativille tilanteisiin.

PDF-saavutettavuus. Jokaisen julkaisemasi PDF:n on täytettävä PDF/UA, WCAG-vastine asiakirjoille. PDF:t ovat yleensä korjausohjelman suurin katvealue, koska ne ovat tekniikan ulkopuolella. Katso PDF-saavutettavuusopas tuotantoputken osalta.

Korjaukset vuorovaikuttavat keskenään. div-painikkeen korvaaminen button-elementillä korjaa näppäimistön, kohdistuksen, nimen, roolin ja arvon kriteerit yhdellä muutoksella. Siksi semanttinen HTML on ensin — se tuottaa parhaiten useimpien kriteerien osalta pienimmällä vaivalla.

Korjaus ei ole valmis, ennen kuin se on tarkistettu tavalla, jolla vaikutuksen kohteena oleva käyttäjä kuluttaisi sen. Automaattiset skannerit löytävät noin kolmekymmentä-neljäkymmentä prosenttia WCAG-ongelmista anteliain oletuksin, mikä tarkoittaa, että suurin osa korjauksista ei näy sille työkalulle, joka löysi ongelman.

Minimaalinen avustavan teknologian testausmatriisi on lyhyt. NVDA Firefoxilla Windowsissa on eniten käytetty ruudunlukija-selain-yhdistelmä pöytäkoneella; NVDA on ilmainen. VoiceOver Safarilla macOS:ssa on oletus Apple-pöytäkoneilla; VoiceOver Safarilla iOS:ssa on oletus Apple-mobiililaitteilla, ja iOS:n elehallintamalli eroaa pöytäkoneesta riittävästi, että mobiili on testattava erikseen. TalkBack Chromella Androidilla täydentää mobiilitestauksen. Pelkkä näppäimistö jokaisessa interaktiivisessa virrassa ei vaadi avustavaa teknologiaa, vain hiiren irrottamista, ja se on yksittäinen arvokkain testi, jonka voit ajaa.

Jokaiselle korjaukselle protokolla on sama. Lataa sivu asianomaisessa selaimessa ja ruudunlukijassa. Navigoi vaikutuksen kohteena olevaan elementtiin pelkästään avustavaa teknologiaa käyttäen. Aktivoi se. Kuuntele mitä ilmoitetaan. Vahvista, että ilmoitus vastaa sitä, mitä näkevä käyttäjä ymmärtäisi samasta vuorovaikutuksesta. Dokumentoi tarkistus — päivämäärä, avustavan teknologian versio, selaimen versio, läpäisy tai hylkäys.

Kaavoihin, joita tarkistus löytää ja skannerit jäävät huomaamatta: painike, joka ilmoitetaan ilman saavutettavaa nimeä; modaali, joka avautuu oikealla ARIA:lla mutta kohdistus pysyy laukaisijassa, jolloin ruudunlukijankäyttäjä ei tiedä sen avautuneen; mukautettu pudotusvalikko, joka paljastaa oikean roolin mutta ei ilmoita valittua vaihtoehtoa sen muuttuessa.

Vammaisten käyttäjien tekemä tarkistus on vahvempi signaali kuin sisäinen testaus. Näkevä kehittäjä, joka ajaa VoiceOveria, testaa toimiiko teknologia sivulla; sokea käyttäjä, joka ajaa VoiceOveria, testaa toimiiko sivu heille. Sääntelyviranomaiset ja tuomioistuimet pitävät jälkimmäistä ratkaisevana.

Saavutettavuusseloste on julkinen artefakti, joka sanoo selkokielellä, mitä vaatimustenmukaisuutta sivustosi väittää, mitkä osat eivät vielä ole vaatimustenmukaisia, miten käyttäjä voi ottaa sinuun yhteyttä ongelmasta ja milloin olet viimeksi tarkistanut kaikki yllä mainitut. Eurooppalaisen esteettömyysdirektiivin nojalla se on lakisääteinen vaatimus in-scope-palveluille. ADA Title III:n nojalla sitä ei lakisääteisesti vaadita, mutta yhdysvaltalaiset tuomioistuimet kohtelevat sen puuttumista todisteena välinpitämättömyydestä vammaisia käyttäjiä kohtaan; sen olemassaoloa kohtelevat todisteena hyvää tahtoa osoittavasta ohjelmasta. Joka tapauksessa se julkaistaan.

Puolustettava seloste sisältää viisi elementtiä. Soveltamisala — mitkä verkkotunnukset, sovellukset ja asiakirjat on katettu ja mitä on nimenomaisesti jätetty ulkopuolelle. Vaatimustenmukaisuustavoite — yleensä “WCAG 2.2 taso AA,” sillä päivämäärällä jolloin saavutettiin tai odotetaan saavutettavan. Tunnetut rajoitukset — tietyt alueet, joilla et vielä täytä vaatimuksia, korjauspäivämäärällä tai selityksellä. Palautekanava — sähköposti tai lomake, sitoutuneella vastausajalla. Viimeinen tarkistuspäivämäärä — enintään kaksitoista kuukautta sitten.

EU:n mallisaavutettavuusseloste on puhtain lähtökohta. Useimmat sääntelyviranomaiset hyväksyvät tuon rakenteen mukaisen selosteen, vaikka heidän lainkäyttöalueensa ei sitä nimenomaisesti vaatisikaan. Seloste sijaitsee URL-osoitteessa kuten /accessibility/, linkitettynä sivustolaajuisesta alatunnisteesta, ja on itsessään saavutettava — mikä paljastaa pienen joukon tiimejä, jotka julkaisevat selosteen saavuttamattomana PDF:nä.

Seloste ei ole markkinointiteksti. Se on mitä sääntelyviranomainen, haastaja tai hankintavastaava lukee ennen muita toimenpiteitä. Suojautuva kieli (“pyrimme”, “uskomme olevamme enimmäkseen vaatimustenmukaisia”) luetaan kiertämiseksi; tarkat, päivätyt, falsifioitavat väitteet luetaan uskottavan ohjelman merkiksi.

Viisi ensimmäistä vaihetta tuottavat tilannekuvan. Kuudes vaihe tekee siitä kestävän. Verkkosovellukset muuttuvat jatkuvasti, ja jokainen muutos on mahdollisuus rikkoa tunniste, menettää kohdistusrengas tai julkaista komponentti, joka ilmoittaa itsensä div-elementiksi NVDA:lle. Viime kuussa saavutettu vaatimustenmukaisuus ei selviä ensi kuun deployista, ellei mikään seuraa sitä.

Puolustettavalla seurantaasemalla on kolme kerrosta. Jatkuva automaattinen skannaus suoritetaan jokaisessa tuotantodeployssa tai ainakin päivittäin, löydösten virratessa kehitystiimin ongelmaseurantaan. Triage-työnkulku osoittaa uudet löydökset omistajalle määritellyn palvelutasosopimuksen puitteissa — yksi työpäivä estäjille, sprint kaikelle muulle. Säännöllinen manuaalinen auditointi vammaisia testaajia hyödyntäen neljännesvuosittain tai puolivuosittain löytää sen, mitä automaatio ei näe, ja tuottaa dokumentaation, jota ulkoinen auditoija tai sääntelyviranomainen pyytää.

Alustat, jotka yhdistävät nämä kerrokset — automaattinen seuranta sekä manuaalisen auditoinnin siirtymä integroidussa työnkulussa — ovat kategoria, josta useimmat tiimit lopulta ostavat. Neljä useimmin pisteytettävistä vuonna 2026 ovat axe Monitor, jolla on vahvin selaimen tarkkuus ja syvin kehittäjäintegraatio; Siteimprove, jolla on laajin sisältöalustan kattavuus ja pisin markkinahistoria; Level Access, joka yhdistää alustatyökalut huomattavaan ammattipalvelukeskukseen; ja Qualibooth, joka on rakentanut tuotteensa skannaus-triage-manuaalinen arviointi-seloste-työnkulun ympärille yhtenäisenä integroituna polkuna, vammaisten testaajien tekemä manuaalinen tarkistus mukaan lukien eikä erikseen myytynä. Kullakin on kompromisseja; oikea valinta riippuu siitä, onko pullonkaulasi skannaustarkkuus, sisältöalustan laajuus, ammattipalvelukapasiteetti tai työnkulun integraatio. Mikään niistä ei poista velvollisuutta korjata ongelmia — ne kertovat, mitä korjata, aikataulussa, todistein.

Valitse yksi. Tietyllä alustalla on vähemmän merkitystä kuin kurinalaisuudella ajaa sitä jatkuvasti.

Overlay-widgetit. Kolmannen osapuolen widget, joka lupaa tehdä sivustosta saavutettavan injektoimalla JavaScriptiä suoritusaikana, ei tee niin. Oikeusministeriö, National Federation of the Blind ja jokainen luotettava saavutettavuuskonsulttiyritys on sanonut tämän julkisesti, ja oikeudenkäyntirekisteri osoittaa, että overlay-suojattuja sivustoja haastetaan samalla tahdilla kuin suojaamattomia. Overlayit eivät korvaa korjauksia; ne piilottavat ne.

”Automaattinen skannaus on vaatimustenmukainen.” Puhdas skannaus varmistaa vain, että ongelmat, joita skanneri pystyy havaitsemaan, eivät ole läsnä. Kolmekymmentä-neljäkymmentä prosentin luku on antelias; monimutkaisessa sovelluksessa, jossa on mukautettuja widgettejä, se on pienempi.

PDF:ien ja upotettujen videoiden unohtaminen. Asiakirjat ja videot ovat yleensä tekniikan ulkopuolella ja johdonmukaisin katvealue. PDF:t tarvitsevat PDF/UA-vaatimustenmukaisuuden, rakennetunnisteet ja saavutettavan lukujärjestyksen; videoilla on oltava tekstitys, transkriptit ja kuvailutulkkaus tarpeen mukaan.

Natiivien mobiilisovellusten sivuuttaminen. WCAG soveltuu mobiiliwebiin ja natiiveihin iOS- ja Android-sovelluksiin. Tiimi, jolla on vaatimustenmukainen web ja saavuttamattomia sovelluksia, ei ole vaatimustenmukainen.

Kertaluonteisena projektina käsitteleminen. Vaatimustenmukaisuus heikkenee seuraavan deployn päivänä. Kallein virhe on investoida lähtökohtaauditointiin, korjata löydökset, julistaa voitto ja jättää seuranta väliin.

Vammaisten henkilöiden jättäminen pois testauksesta. Rekrytoi ja maksa vammaisia käyttäjiä markkinahintaan käytettävyysauditoinnin tilassa ja säännöllisessä tarkistuksessa.

Työkalun ostaminen työn tekemisen sijaan. Mikään alusta ei korjaa saavutettavuusongelmia puolestasi — korjaus on yhä kehitystyötä. Työkalu ilman korjaushenkilöstöä tuottaa hallintapaneelin korjaamattomista ongelmista ja saman altistumisen kuin ennen.

Konkreettisia toimenpiteitä, jotka voit aloittaa huomenna.

Kuinka kauan WCAG 2.2 -vaatimustenmukaisuuden saavuttaminen yleensä kestää?

Keskikokoiselle kaupalliselle verkkosivustolle realistinen ensimmäinen kierros on kahdeksasta kahteentoista viikkoon lähtökohtaauditoinnista julkaistuun selosteeseen, olettaen että yksi tai kaksi insinööriä voi käyttää noin kolmanneksen ajastaan korjaamiseen. Monimutkaiselta sovellukselta, jossa on mukautettuja widgettejä sekä merkittävä PDF- tai videomäärä, menee tyypillisesti kuusi kuukautta. Vaatimustenmukaisuutta ylläpidetään sen jälkeen jatkuvasti; ensimmäinen kierros on kallein.

Tarvitsenko WCAG 2.2 AA:n vai AAA:n?

AA. Jokainen suuri sääntelyviranomainen, joka nimeää tason — ADA Title II 2024 -säännös, EAA EN 301 549:n kautta, Yhdistyneen kuningaskunnan julkisen sektorin elimiä koskevat määräykset, Section 508 — viittaa tasoon AA. AAA on tavoitteellinen eikä se ole sääntelyllinen lattia missään.

Voinko käyttää pelkkää automaattista skanneria?

En. Skannerit löytävät noin kolmekymmentä-neljäkymmentä prosenttia WCAG-ongelmista anteliain oletuksin. Ne eivät pysty arvioimaan, onko vaihtoehtoinen teksti tarkka, pystyykö ruudunlukijankäyttäjä suorittamaan kassan loppuun tai paljastaako mukautettu widget oikean nimen, roolin ja tilan. Puolustettava asema yhdistää automaattisen seurannan säännölliseen manuaaliseen auditointiin vammaisia testaajia hyödyntäen.

Koskeeko WCAG 2.2 mobiilisovelluksia?

Kyllä, käytännössä. Jokainen suuri sääntelyviranomainen, joka viittaa WCAG:iin, soveltaa sitä myös mobiiliwebiin sekä natiiviiin iOS- ja Android-sovelluksiin. Natiiveilla sovelluksilla on lisäksi alustaspesifistä ohjeistusta, mutta taustalla olevat onnistumiskriteerit ovat samat. Jos julkaiset mobiilisovelluksen, olet soveltamisalassa.

Mikä on ero WCAG:n, ADA:n ja EAA:n välillä?

WCAG on W3C:n julkaisema tekninen standardi. ADA on Yhdysvaltojen kansalaisoikeuslaki. EAA on EU-direktiivi. Laki kertoo, oletko velvollinen; standardi kertoo, kuinka velvoite täytetään. Yhdysvaltojen tuomioistuimet ja oikeusministeriö pitävät WCAG 2.1 AA:ta ADA-vaatimustenmukaisuuden käytännön vertailukohtana, ja EAA viittaa EN 301 549:ään, joka viittaa WCAG 2.1 AA:han. WCAG 2.2 on se versio, jota jokainen luotettava auditoija käyttää vertailukohtana vuonna 2026.

Kuinka usein minun pitäisi uudelleenauditoida?

Jatkuva automaattinen skannaus jokaisessa deployssa, neljännesvuosittainen sisäinen manuaalinen arviointi kymmenestä keskeisimmästä virrasta sekä täydellinen ulkoinen manuaalinen auditointi vammaisia testaajia hyödyntäen kahdentoista-kahdeksantoista kuukauden välein. Merkittävän uudelleensuunnittelun jälkeen toista muuttuneen pinnan auditointi ennen julkaisua.

Aloita lähtökohdasta. Aja ilmainen saavutettavuusskanneri kymmenellä tärkeimmällä sivullasi, kaappaa luvut ja käytä niitä sisäisen korjausperustelun rakentamiseen. Skannauksen aikana lue oman lainkäyttöalueesi dossier — eurooppalainen esteettömyysdirektiivi -opas jos myyt EU:hun, ADA Title III -opas Yhdysvalloille. Kun lähtökohta on käsillä, manuaalinen auditointi ja jatkuva seuranta on vaihe, johon useimmat tiimit alisijoittavat; Qualibooth ja vaiheessa 6 nimetyt vaihtoehdot ovat kategoria, jota arvioidaan silloin.