Kaikki artikkelit

Tein oman sivustoni WCAG 2.2 AA -auditin. Tässä, mitä löytyi

Auditoin oman uuden sivustoni saavutettavuuden. Löytyi kontrastivirheitä, vaakavieritys 320 pikselin leveydellä ja animaatio, jota ei voinut pysäyttää.

  • Saavutettavuus
  • WCAG

Teen saavutettavuusauditteja asiakkaille, joten oman sivuston pitää olla kunnossa. Ajoin uudelle sivustolleni WCAG 2.2 AA -tason auditin heti julkaisun jälkeen. Automaattinen tarkistus löysi kaksi ongelmaa, mutta suurin osa löydöksistä tuli vasta käsin tehdyissä tarkistuksissa. Kaikki korjattiin samana päivänä. Tässä on lista löydöksistä, koska ne ovat juuri niitä virheitä, joita löydän asiakkaidenkin sivustoilta.

Miten auditti tehtiin?

Auditissa oli kaksi osaa:

  1. Automaattinen tarkistus. Ajoin axe-core -työkalun jokaiselle sivulle sekä työpöytä- että mobiilileveydellä. Se löytää muun muassa kontrastivirheet, puuttuvat kenttänimet ja virheelliset rakenteet.
  2. Käsin tehdyt tarkistukset. Kävin sivuston läpi pelkällä näppäimistöllä, kapeimmalla 320 pikselin leveydellä ja suurennetuilla tekstiväleillä. Lisäksi tarkistin kosketuskohteiden koot ja liikkuvan sisällön.

Automaattinen tarkistus löytää tyypillisesti vain osan ongelmista. Tässä se löysi yhden kontrastivirheen ja rakennevirheen, jossa sivupalkkialueita (aside) oli sisäkkäin. Kaikki muu alla oleva löytyi käsin.

Kontrasti: punainen teksti ei riittänyt

Sivuston aksenttiväri on punainen. Kahdessa kohdassa sitä oli käytetty tekstinä, eikä kontrasti riittänyt:

  • Etusivun animaatiossa punainen teksti tummalla taustalla: kontrasti 3,4:1, kun vaatimus on 4,5:1.
  • Lomakkeen virheilmoitus vaalealla taustalla: 4,0:1.

Jälkimmäistä automaattinen tarkistus ei löytänyt, koska virheilmoitus ei ollut näkyvissä testin aikana. Löysin sen laskemalla kontrastit kaikille väriyhdistelmille. Korjaus oli yksinkertainen: tummalle taustalle vaaleampi punainen, vaalealle tummempi. Nyt sivuston ohjeissa on sääntö, että punaista käytetään tekstinä vain näillä kahdella sävyllä.

Vaakavieritys 320 pikselin leveydellä

WCAG 1.4.10 edellyttää, että sivua voi lukea 320 pikselin leveydellä ilman vaakavieritystä. Tämä vastaa tilannetta, jossa käyttäjä suurentaa sivun 400 prosenttiin. Minun sivustollani oli kaksi ongelmaa:

  • Yläpalkin valikko ei mahtunut logon viereen.
  • Pitkät suomen sanat eivät mahtuneet otsikoihin. "Verkkosivustoja," ja "saavutettavuusauditit" ovat isolla fontilla leveämpiä kuin kapea näyttö.

Suomi on tässä hankala kieli, koska yhdyssanat ovat pitkiä. Korjasin valikon rivittymään ja otin otsikoissa käyttöön tavutuksen, jolloin selain katkaisee pitkät sanat oikeasta kohdasta tavuviivalla.

Animaatio, jota ei voinut pysäyttää

Etusivulla on animaatio, jossa auditin löydöksiä korjataan yksi kerrallaan. Se pyöri loputtomiin, eikä sitä voinut pysäyttää. WCAG 2.2.2 edellyttää, että yli viiden sekunnin ajan jatkuvan liikkeen voi pysäyttää. Liike voi häiritä keskittymistä ja lukemista erityisesti silloin, kun käyttäjällä on tarkkaavaisuuden vaikeuksia.

Sivustolla oli jo huomioitu käyttöjärjestelmän asetus, jolla liikettä voi vähentää. Se ei kuitenkaan riitä, koska kaikki eivät tiedä asetuksesta. Animaatioon tuli pysäytyspainike. Sama korjaus tehtiin myös logoriville, joka liukuu jatkuvasti.

Muut löydökset

  • Evästeilmoitus peitti kohdistuksen. Mobiilissa ruudun alalaidassa oleva evästeilmoitus saattoi peittää elementin, johon näppäimistön kohdistus siirtyi (WCAG 2.4.11, uusi kriteeri versiossa 2.2). Lisäksi ilmoitus oli sivun lopussa, joten näppäimistön käyttäjä pääsi siihen vasta koko sivun jälkeen. Nyt ilmoitus on heti alussa, sen voi sulkea Esc-näppäimellä ja sivu jättää sille tilaa.
  • Pienet kosketuskohteet. Muutama erillinen linkki ja painike oli 22–23 pikseliä korkea. Uusi kriteeri 2.5.8 edellyttää vähintään 24 pikseliä tai riittävää tyhjää tilaa ympärillä. Väli olisi riittänyt, mutta nostin koot silti.
  • Englanninkielinen teksti. Footerissa on nimike "Freelance Web Developer". Ilman kielimerkintää ruudunlukija lukee sen suomen ääntämyksellä.
  • Ristiriitainen painikkeen tila. Pysäytyspainikkeessa sekä teksti että ruudunlukijalle kerrottu tila vaihtuivat, mikä tuotti sekavan ilmoituksen.
  • Pakolliset kentät. Lomakkeessa ei kerrottu, että kaikki kentät ovat pakollisia.
  • Uuteen välilehteen avautuvat linkit. Referenssien linkit avautuvat uuteen välilehteen. Siitä kerrotaan nyt ruudunlukijalle.

Mitä tästä voi oppia?

Ensinnäkin automaattinen tarkistus ei riitä. Tässä se löysi vain kaksi ongelmaa ja kaikki muut löytyivät käsin. Toiseksi WCAG 2.2:n uudet kriteerit, kuten kohdistuksen peittyminen ja kosketuskohteiden koko, jäävät helposti huomaamatta, koska vanhat tarkistuslistat eivät sisällä niitä. Kolmanneksi suomenkielinen sivusto tarvitsee tavutuksen, jos otsikot ovat isoja.

Yksi asia jäi vielä tekemättä: sivustoa ei ole testattu oikealla ruudunlukijalla. Teen sen seuraavaksi, koska rakenne voi olla teknisesti oikein, vaikka lukukokemus ontuu.

Jos haluat saman läpikäynnin omalle sivustollesi, se kuuluu SEO-, GEO- ja saavutettavuusauditteihin.

Usein kysyttyä

Riittääkö automaattinen saavutettavuustarkistus?

Ei. Automaattinen työkalu löytää osan virheistä, kuten kontrastit ja puuttuvat nimet, mutta ei esimerkiksi sitä, peittyykö kohdistus tai voiko animaation pysäyttää. Tässä auditissa suurin osa löydöksistä löytyi vasta käsin.

Mitä uutta WCAG 2.2 toi?

Muun muassa kriteerit kohdistuksen näkyvyydestä, kosketuskohteiden vähimmäiskoosta, raahaamisen vaihtoehdoista ja siitä, ettei käyttäjää pakoteta syöttämään samoja tietoja uudelleen. W3C:n sivulla What's New in WCAG 2.2 on koko lista.

Kuinka kauan korjaukset kestivät?

Tällä pienellä sivustolla kaikki löydökset korjattiin samana päivänä. Isommalla sivustolla korjausten määrä ja laajuus riippuvat siitä, toistuuko sama virhe sivupohjassa vai onko se jokaisessa sisällössä erikseen.

Tarvitsetko apua?

Kerro, mitä tarvitset, niin mietitään yhdessä, miten asia kannattaa hoitaa.

Kerro projektistasi