Tee verkkosivustostasi WCAG 2.2 -yhteensopiva

Verkkosivustosi tekeminen WCAG 2.2 -yhteensopivaksi on prosessi, ei kertaluonteinen korjaus. Yhteensopivuus on toistettavan työnkulun tulos: ymmärrä standardi, mittaa nykytilasi, korjaa oikeat asiat oikeassa järjestyksessä, validoi todellisella avustavalla teknologialla ja oikeilla käyttäjillä, dokumentoi tulos ja estä sen taantuminen. Tämä opas muuttaa kyseisen työnkulun konkreettiseksi, vaihe vaiheelta eteneväksi etenemissuunnitelmaksi, jonka tiimisi voi ottaa käyttöön jo tänään — turvautumatta saavutettavuus-”overlay”-ratkaisuihin, jotka peittävät ongelmat DOM:ssa korjaamatta niitä ja jotka on toistuvasti mainittu oikeudenkäynneissä.

Vaihe 1: Ymmärrä, mitä WCAG 2.2 todella vaatii

Ennen kuin auditoit mitään, selvitä tavoite. Web Content Accessibility Guidelines -ohjeistus rakentuu neljän periaatteen ympärille, jotka tiivistyvät lyhenteeseen POUR:

Havaittava (Perceivable) — käyttäjien on voitava havaita sisältö. Tähän kuuluvat kuvien tekstivastineet, median tekstitykset ja litteroinnit sekä riittävä värikontrasti.
Hallittava (Operable) — jokaisen toiminnon on toimittava ilman hiirtä. Täysi näppäimistöhallinta, näkyvät kohdistusilmaisimet ja näppäimistöloukkujen puuttuminen ovat keskeisiä vaatimuksia.
Ymmärrettävä (Understandable) — sisällön ja toiminnan on oltava ennustettavaa. Selkeät otsikot, johdonmukainen navigointi, hyödylliset virheilmoitukset ja luettava kieli kuuluvat tähän.
Toimintavarma (Robust) — merkkauksen on oltava nykyisen ja tulevan avustavan teknologian jäsennettävissä, mikä käytännössä tarkoittaa kelvollista HTML:ää sekä ARIA-nimien, -roolien ja -arvojen oikeaa käyttöä.

Jokainen periaate jakautuu testattaviin onnistumiskriteereihin, ja jokaiselle kriteerille on määritetty vaatimustenmukaisuustaso: A (välttämätön), AA (oikeudellinen ja käytännön perustaso, johon useimmat organisaatiot pyrkivät) ja AAA (laajennettu). Kun ihmiset puhuvat “WCAG 2.2 AA:sta”, he tarkoittavat jokaisen tason A ja tason AA onnistumiskriteerin täyttämistä. WCAG 2.2 lisää yhdeksän uutta kriteeriä versioon 2.1 verrattuna — mukaan lukien Focus Not Obscured, Dragging Movements, Target Size (Minimum) ja Accessible Authentication — joista useimmat parantavat näppäimistöä käyttävien, heikkonäköisten ja motorisesti rajoittuneiden käyttäjien kokemusta.

On hyödyllistä tietää, miksi tämä on tavoite. AA-vaatimustenmukaisuuteen viittaavat lait ja säädökset, jotka todennäköisimmin koskevat sinua: tutustu WCAG-yhteensopivuuteen teknisenä standardina ja katso sitten, miten se liittyy Euroopan esteettömyysdirektiiviin, ADA -lakiin yksityisten ja julkisten yhdysvaltalaisten toimijoiden osalta sekä Section 508 -säädökseen Yhdysvaltain liittovaltion virastojen ja niiden toimittajien osalta. Jos terminologia tuottaa matkan varrella vaikeuksia, pidä saavutettavuussanasto auki välilehdellä.

Kaksi muuta käsitettä muovaavat jokaista rehellistä vaatimustenmukaisuusväitettä. Ensimmäinen on vaatimustenmukaisuuden laajuus: WCAG-vaatimustenmukaisuus koskee kokonaisia sivuja, ei yksittäisiä komponentteja, ja täydellisiä prosesseja (esim. koko kassavirtaa) — et voi väittää sivun olevan vaatimustenmukainen, jos yksi vaihe monivaiheisessa tehtävässä epäonnistuu. Toinen on saavutettavuutta tukeva teknologia: voit luottaa vain sellaisiin ominaisuuden käyttötapoihin, joita käyttäjiesi avustava teknologia todella tukee. Käytännössä tämä tarkoittaa testaamista nykyisillä ruudunlukijoilla ja selaimilla sen sijaan, että olettaisi pelkän kelvollisen merkkauksen takaavan käytettävän tuloksen. Pidä molemmat mielessä rajatessasi työtäsi alla olevissa vaiheissa; ne määrittävät, mitä voit puolustettavasti sanoa saavuttaneesi.

Vaihe 2: Suorita automaattinen lähtötasoskannaus

Et voi korjata sitä, mitä et voi mitata, joten määritä lähtötaso. Automaattinen testaus on nopeaa, toistettavaa ja erinomaista havaitsemaan suurivolyymiset, mekaaniset virheet, jotka vaivaavat useimpia sivustoja: puuttuvat tekstivastineet, alhainen värikontrasti, tyhjät linkit ja painikkeet, nimeämättömät lomakekentät, puuttuva dokumentin kieli ja kahdentuneet ID:t.

Avoimen lähdekoodin axe-core -moottoriin perustuvat työkalut — mukaan lukien QualiBoothin saavutettavuuden skannausohjelmisto — tuottavat priorisoidun ongelmaluettelon minuuteissa. Jos haluat vain nopean kuvan nykytilanteestasi, aloita muutaman keskeisen sivun ilmaisella saavutettavuusskannauksella.

Muutama sääntö pitää lähtötasosi rehellisenä:

Skannaa edustavat mallipohjat, ei koko sivustoasi. Testaa etusivu, sisältö-/artikkelimallipohja, tuote- tai kategoriasivu, lomake (rekisteröityminen, kassa, yhteydenotto) ja mahdollinen kirjautumista vaativa hallintapaneeli. Yhden mallipohjan korjaaminen korjaa yleensä satoja sivuja.
Testaa todellisia tiloja, ei vain alkulatausta. Avaa valikoita, laajenna haitareita, käynnistä modaaleja ja lähetä lomakkeita virheineen. Monet rikkomukset ilmenevät vain vuorovaikutteisissa tiloissa.
Kirjaa luvut. Tallenna ongelmamäärät vakavuuden ja onnistumiskriteerin mukaan. Tämä on ennen/jälkeen-vertailukohtasi ja korjaustyölistasi perusta.

Ole rehellinen rajoitusten suhteen: automaattiset työkalut havaitsevat luotettavasti vain 30–40 % WCAG-ongelmista. Puhdas automaattinen skannaus on välttämätön, mutta se ei koskaan riitä todelliseen vaatimustenmukaisuusväitteeseen.

Vaihe 3: Täydennä automaatiota manuaalisella auditoinnilla

Loput 60–70 % WCAG-kriteereistä vaatii inhimillistä harkintaa. Välittääkö tämä tekstivastine todella kuvan merkityksen vai kuvaako se vain pikseleitä? Onko luku- ja kohdistusjärjestys looginen? Kertovatko virheilmoitukset käyttäjälle, kuinka toipua? Ilmoitetaanko mukautettu pudotusvalikko oikein, ja voitko saavuttaa ja käyttää sitä pelkällä näppäimistöllä? Mikään moottori ei voi vastata näihin luotettavasti.

Jäsennelty manuaalinen auditointi kattaa tyypillisesti:

Pelkkä näppäimistökäyttö — selaa jokaisen vuorovaikutteisen elementin läpi sarkaimella; varmista näkyvä kohdistusilmaisin, looginen järjestys, loukkujen puuttuminen ja se, että kaiken minkä voit tehdä hiirellä, voit tehdä myös ilman sitä.
Semanttinen rakenne — otsikot merkityksellisessä hierarkiassa, maamerkit, listat merkitty listoiksi ja taulukot oikeilla otsikoilla.
Lomakkeet — ohjelmalliset nimet, ryhmitellyt kentät, selkeä pakollisten kenttien merkintä ja virheilmoitukset, jotka on kytketty niihin syöttökenttiin, joita ne kuvaavat.
Dynaaminen sisältö — modaalit, jotka loukkuun ja palauttavat kohdistuksen oikein, live-alueet, jotka ilmoittavat päivityksistä, ja ARIA, jota käytetään vain siellä, missä natiivi HTML ei pysty tekemään työtä.
Sisällön laatu — merkityksellinen linkkiteksti, riittävä kontrasti todellisissa konteksteissa ja sisältö, joka ei nojaa pelkkään väriin tai muotoon.

Manuaalisten saavutettavuusauditointien oppaamme käy läpi koko menetelmän, ja vältettävät yleiset saavutettavuusongelmat on nopea tarkistuslista virheistä, joita auditoijat löytävät useimmiten. Jos haluat sen mieluummin tehtynä puolestasi, QualiBoothin saavutettavuuskonsultoinnin tiimi suorittaa asiantuntevat manuaaliset auditoinnit WCAG 2.2 AA -kriteerejä vasten.

Vaihe 4: Priorisoi ja korjaa

Pitkä rikkomuslista on ylivoimainen, kunnes järjestät sen. Lajittele yhdistämällä käyttäjävaikutus ja kattavuus:

Estävät ensin. Kaikki, mikä tekee tehtävästä mahdottoman jollekin käyttäjäryhmälle — näppäimistöloukut, saavuttamaton kassa, nimeämätön kirjautumislomake — menee kärkeen riippumatta siitä, kuinka monta esiintymää on olemassa.
Sitten korkeataajuiset, sivustonlaajuiset ongelmat. Kontrasti- tai kohdistusongelma ylätunnisteessasi, alatunnisteessasi tai suunnittelujärjestelmän komponentissa kertaantuu jokaisella sivulla. Sen korjaaminen kerran tuottaa suurimman tuoton.
Sitten sivukohtaiset ja sisältöongelmat. Yksittäinen puuttuva tekstivastine, yksi väärin nimetty ohjain tai kertaluonteinen otsikkopuute.

Kun korjaat, korjaa lähde, ei oire. Suosi natiiveja HTML-elementtejä ARIA-paikattujen <div>-elementtien sijaan; korjaa suunnittelujärjestelmän komponentti sen sijaan, että korjaisit jokaisen sitä käyttävän sivun; ja puutu juurisyihin mallipohjissa ja jaetuissa komponenteissa, jotta korjaus skaalautuu. Skannaa uudelleen jokaisen erän jälkeen, jotta näet lukujen putoavan ja vältät taantumien aiheuttamisen. Tämä on myös oikea hetki sisällyttää saavutettavuus suunnittelutokeneihisi — määritä kontrastiturvalliset värit, vähintään 24×24 px:n kohdekoko ja näkyvät kohdistustyylit oletuksiksi, jotta uusi työ alkaa vaatimustenmukaisena.

Muutama korjausmalli toistuu riittävän usein nostettavaksi nimenomaisesti esiin:

Käytä alustaa. Natiivi <button>, <a href>, <input>, <select> ja <dialog> tulevat näppäimistökäyttäytymisen, kohdistuksen hallinnan ja oikean saavutettavan nimen kanssa ilmaiseksi. Turvaudu ARIAan vain täyttääksesi todelliset aukot — ja muista ARIAn ensimmäinen sääntö: älä käytä ARIAa, jos natiivi elementti riittää.
Nimeä asiat ohjelmallisesti. Jokainen ohjain tarvitsee saavutettavan nimen <label>-elementistä, aria-label-määreestä tai aria-labelledby-määreestä — ei vain läheisestä visuaalisesta tekstistä. Pelkät kuvakepainikkeet ovat yleisin rikkoja.
Hallitse kohdistusta tarkoituksellisesti. Kun modaali avautuu, siirrä kohdistus siihen, loukkaa se auki ollessaan ja palauta se laukaisimeen sulkemisen yhteydessä. Kun sisältö päivittyy ilman navigointia, käytä live-aluetta, jotta ruudunlukijan käyttäjät kuulevat, mikä muuttui.
Älä koodaa merkitystä pelkkään väriin tai muotoon. Yhdistä väri tekstiin, kuvakkeisiin tai kuvioihin, jotta tieto säilyy värisokeille ja heikkonäköisille käyttäjille.

Seuraa korjauksia normaalissa tehtävienseurannassasi, merkittynä onnistumiskriteerin mukaan, jotta saavutettavuustyö on näkyvissä kaiken muun rinnalla sen sijaan, että se eläisi erillisessä laskentataulukossa, joka vanhentuu.

Vaihe 5: Testaa avustavalla teknologialla ja vammaisten ihmisten kanssa

Vaatimustenmukaisuudessa on lopulta kyse siitä, voivatko oikeat ihmiset käyttää sivustoasi. Tässä on merkitystä kahdella validointikerroksella, eivätkä ne ole keskenään vaihdettavissa.

Ruudunlukijatestaus. Varmista korjauksesi sitä avustavaa teknologiaa vasten, jota ihmiset todella käyttävät: NVDA tai JAWS Chromen/Firefoxin kanssa Windowsilla ja VoiceOver Safarin kanssa macOS:llä ja iOS:llä. Kuuntele tarkkoja nimiä, oikeita rooleja, ilmoitettuja tilamuutoksia ja järkevää lukujärjestystä. Ruudunlukija-arviointi antaa sinulle ammattimaisen läpikäynnin tärkeimmistä yhdistelmistä, jos tiimiltäsi puuttuu kokemusta.

Käytettävyystestaus vammaisten käyttäjien kanssa. Jokaisen onnistumiskriteerin läpäiseminen on lattia, ei katto — sivusto voi olla teknisesti vaatimustenmukainen ja silti turhauttava käyttää. Luotettavin signaali tulee vammaisten ihmisten tekemistä auditoinneista, jotka testaavat omalla avustavalla teknologiallaan ja tottumuksillaan ja paljastavat esteitä, joita tarkistuslistat eivät huomaa. Tämä on ero standardin kirjaimen täyttämisen ja todellisen digitaalisen saavutettavuuden tarjoamisen välillä.

Vaihe 6: Dokumentoi vaatimustenmukaisuus (lausunto ja VPAT/ACR)

Kun olet korjannut ja validoinut, tallenna tulos. Dokumentaatio on se, mikä muuttaa “yritimme”-tilan puolustettavaksi ja viestittäväksi väitteeksi.

Saavutettavuuslausunto. Julkinen sivu, joka ilmoittaa vaatimustenmukaisuustavoitteesi (esim. WCAG 2.2 AA), kuvaa mitä olet tehnyt, listaa mahdolliset tunnetut rajoitukset ja antaa käyttäjille tavan ilmoittaa ongelmista. Monet säädökset, mukaan lukien EAA, odottavat sellaista.
VPAT / saavutettavuuden vaatimustenmukaisuusraportti. Täytetty Voluntary Product Accessibility Template muuttuu ACR:ksi — vakioasiakirjaksi, jota hankintatiimit ja yritysostajat pyytävät todisteeksi. Mikä on VPAT/ACR -oppaamme selittää asiakirjan, ja VPAT-raportit -palvelu tuottaa tarkan, auditointiin perustuvan raportin, jonka voit luovuttaa asiakkaille ja oikeudellisille tiimeille.

Kirjoita nämä todellisten auditointitulostesi todisteita vasten, ei toiveidesi pohjalta. VPAT, joka liioittelee vaatimustenmukaisuutta, on vastuu, ei voimavara.

Vaihe 7: Ylläpidä vaatimustenmukaisuutta ajan myötä

Saavutettavuus taantuu sillä hetkellä, kun sivusto muuttuu — uusi komponentti, uudelleensuunniteltu lomake, kolmannen osapuolen widget tai sisältömuokkaus voi hiljaa palauttaa esteitä. Vaatimustenmukaisuus on tila, jota ylläpidät, ei virstanpylväs, jonka ohitat kerran.

Rakenna saavutettavuus ohjelmistosi elinkaareen:

Siirrä vasemmalle. Lisää automaattisia tarkistuksia putkistoosi CI/CD-saavutettavuusintegraatiolla, jotta rikkomukset havaitaan vetopyynnöissä ennen julkaisua — halvimmassa mahdollisessa paikassa korjata ne.
Seuraa tuotantoa. Aikatauluta toistuvat saavutettavuusauditoinnit havaitaksesi taantumat ja sisällön ajautumisen, joita julkaisua edeltävät tarkistukset eivät näe.
Voimaannuta tiimisi. Varusta suunnittelijat, kehittäjät ja sisällöntuottajat saavutettavuustyökalupakilla ja yhteisillä standardeilla, jotta saavutettavuus on jokaisen oletus, ei asiantuntijan jälkikäteinen ajatus.
Hallinnoi laajassa mittakaavassa. Suurille tai monisivustoisille organisaatioille Agora -alustan kaltainen ratkaisu keskittää seurannan, raportoinnin ja korjauksen tiimien välillä.

Virheet, jotka kaatavat vaatimustenmukaisuuspyrkimykset

Tiimit, jotka pysähtyvät, tekevät niin yleensä ennustettavista syistä. Varo näitä:

Pelkkään automaatioon luottaminen. Vihreä automaattinen raportti kattaa vain kolmanneksen kriteereistä. Sen pitäminen todisteena vaatimustenmukaisuudesta on yksittäinen yleisin — ja oikeudellisesti riskialttein — virhe.
Overlayn ostaminen. Overlayt ja “saavutettavuuswidgetit” lupaavat välitöntä vaatimustenmukaisuutta ruiskuttamalla JavaScriptiä, joka ohittaa sivun. Ne eivät korjaa taustalla olevaa koodia, häiritsevät usein käyttäjien omaa avustavaa teknologiaa ja on mainittu kasvavassa määrässä valituksia. Ne ovat oikotie riskiin, eivät vaatimustenmukaisuuteen.
Sivujen korjaaminen järjestelmien sijaan. Yksittäisten sivujen korjaaminen suunnittelujärjestelmän jäädessä rikkinäiseksi tarkoittaa, että jokainen uusi sivu palauttaa samat viat. Korjaa jaetut komponentit ja mallipohjat ensin.
Sen kohteleminen kertaluonteisena projektina. Ilman CI/CD-tarkistuksia ja toistuvia auditointeja vaatimustenmukainen sivusto ajautuu pois vaatimustenmukaisuudesta muutaman julkaisusyklin sisällä.
Todellisten käyttäjien ohittaminen. Tekninen vaatimustenmukaisuus ilman käytettävyystestausta voi silti jättää vammaiset käyttäjät kykenemättömiksi suorittamaan keskeisiä tehtäviä.

Näiden välttäminen estää investointiasi vuotamasta sillä hetkellä, kun projekti “julkaistaan”.

Kaiken kokoaminen yhteen

Realistinen polku WCAG 2.2 AA -tasolle näyttää tältä: opi POUR-periaatteet ja AA-tavoite, suorita automaattinen lähtötaso, lisää manuaalinen auditointi, korjaa vaikutuksen ja kattavuuden mukaan, validoi ruudunlukijoilla ja vammaisten käyttäjien kanssa, dokumentoi vaatimustenmukaisuutesi lausunnossa ja VPAT:ssa ja pidä se sitten terveenä CI/CD-tarkistuksilla ja toistuvilla auditoinneilla. Jokainen vaihe kasaantuu edellisen päälle — eikä mikään siitä riipu overlaysta, joka peittää todellisen koodin.

Aloita pienestä ja rakenna vauhtia: skannaa kourallinen mallipohjia tällä viikolla, korjaa suunnittelujärjestelmäsi kontrasti- ja kohdistustyylit ja laita yksi automaattinen tarkistus putkistoosi. Sieltä yllä oleva etenemissuunnitelma vie sinut loppumatkan. Kun olet valmis kiihdyttämään, tutustu hinnoitteluumme, pyydä demo tai keskustele asiantuntijan kanssa pinoosi räätälöidystä korjaussuunnitelmasta.