Miten WCAG-kriteereitä tulisi tulkita?

Kannettavan tietokoneen näytöllä teksti miten WCAG kriteereitä tulisi tulkita.

Kirjoita lyhyesti ehdotuksesi artikkelin aiheeksi.

Saavutettavuustestauksissa olen törmännyt tilanteeseen, jossa on ollut tarpeen tuoda esiin saavutettavuuden ideaa. Sitä miksi sisällön on oltava saavutettavaa ja miten sitä tulisi tarkastella.

WCAG-ohjeisto (Web Content Accessibility Guidelines) on verkkosisältöjen saavutettavuuden kansainvälinen standardi. Käytännössä saavutettavuustyössä törmää kuitenkin usein tilanteeseen, jossa yksittäinen WCAG-kriteeri näyttää täyttyvän, mutta käyttäjän näkökulmasta verkkosivu ei silti ole saavutettava.

Tämä johtuu siitä, että WCAG:n tarkoituksena ei ole muodostaa pelkkää teknistä tarkistuslistaa. Kriteerit ovat työkalu, jonka avulla pyritään toteuttamaan saavutettavuuden neljä perusperiaatetta:

  • Havaittava (Perceivable)
  • Hallittava (Operable)
  • Ymmärrettävä (Understandable)
  • Toimintavarma (Robust)

Saavutettavuudella tarkoitetaan näiden periaatteiden toteutumista – ei yksittäisten ohjekriteerien.

Kun arvioit verkkosivuston saavutettavuutta, tärkein kysymys ei ole “täyttyykö tämä yksittäinen kriteeri”, vaan:

Toteutuuko saavutettavuuden periaate käyttäjän näkökulmasta?

WCAG ei ole pelkkä tarkistuslista

Saavutettavuustestauksessa on helppoa ajautua tilanteeseen, jossa huomio kiinnittyy yksittäisiin numeroihin, mittauksiin ja teknisiin yksityiskohtiin. Saavutettavuus on kuitenkin ratkaistava tapauskohtaisesti eikä aina ole yhtä oikeaa vastausta. Vain osa kriteereistä on selkeästi mitattavissa olevia objektiivisia vaatimuksia.

Esimerkiksi:

  • Kuvalla on alt-teksti.
  • Linkillä on nimi.
  • Kontrastisuhde on 4.5:1.
  • Lomakekentällä on label-elementti.

Teknisesti kaikki näyttää olevan kunnossa.

Todellinen kysymys on kuitenkin – Pystyykö käyttäjä käyttämään sisältöä tarkoituksenmukaisesti?

WCAG-kriteerit ovat keino arvioida saavutettavuutta, eivät saavutettavuuden lopullinen tavoite.

Esimerkki: kontrasti voi olla oikein mutta teksti silti huonosti luettavaa

Yksi hyvä esimerkki löytyy värikontrasteista.

WCAG määrittelee normaalikokoiselle tekstille vähimmäiskontrastiksi 4.5:1. Moni automaattinen tarkistustyökalu ilmoittaa tällaisen tekstin olevan hyväksyttävä.

Tarkastellaan kuitenkin seuraavaa esimerkkiä:

p {
    color: #767676;
    background: #ffffff;
    font-family: "Roboto", sans-serif;
    font-weight: 100;
}

Yllä oleva CSS tyyli on itse asiassa eräältä sivustolta lähes sellaisenaan kopioitu esimerkki. Väriyhdistelmä jossa tekstin väri on ilmaistu hexakoodina #767676; ja tausta täysin valkoinen #ffffff; tuottaa tekstille kontrastisuhteen 4.54:1 eli värin kontrasti täyttää WCAG kriteerin vaatimukset. Mutta onko teksti aidosti havaittavaa? Alla kuvassa keskimmäinen tekstikappale käyttää yllä olevaa tyyliä ja väriä.

OK, voi olla, että näet lukea tekstin mutta kyse ei olekaan yksin siitä näetkö sinä, vaan onko teksti aidosti myös muiden luettavissa.

Kontrastisuhde voi olla täysin vaatimusten mukainen. Silti käyttäjä saattaa kokea tekstin erittäin vaikeasti luettavaksi, koska:

  • kirjasin on erittäin ohut
  • kirjainten viivat ovat kapeita
  • näytön laatu vaikuttaa luettavuuteen
  • käyttäjällä voi olla heikentynyt näkö
  • tekstin hahmottaminen vaatii tavallista enemmän keskittymistä

Tällaisessa tilanteessa WCAG-kriteeri täyttyy teknisesti, mutta havaittavuuden periaate ei toteudu käytännössä.

Jos arviointi perustuu pelkkään kontrastimittariin, todellinen käytettävyysongelma jää huomaamatta. Ja erityisesti tässä kohden haluaisin huomauttaa, että kaikki selainten automaattiset (ohjelmalliset) saavutettavuuden tarkistustyökalut hyväksyvät kyseisen tekstin muotoilun kyseenalaistamatta sitä millään tavoin. Miksi – koska väri täyttää yksittäisen WCAG kriteerin mutta ohjelmallinen tarkistus ei tutki tosisasiallista havaittavuutta.

Saavutettavuuden arviointi vaatii kokonaisuuden tarkastelua

Sama ilmiö näkyy monissa muissakin tilanteissa. Ei yksin väreissä.

Linkit

Linkillä voi olla ohjelmallisesti oikea nimi, mutta käyttäjä ei välttämättä ymmärrä sen tarkoitusta.

Esimerkiksi: ”Lue lisää”

Teknisesti linkki voi olla täysin WCAG:n mukainen, jos ohjelmallinen nimi muodostuu esimerkiksi ARIA-attribuuteista. Käyttäjän näkökulmasta linkki voi silti olla epäselvä. Näköaistiin perustuvassa tarkastelussa linkin sijainti voi määrittää kontekstin ja linkin merkitys on selvä mutta ilman näköhavaintoa ei.

Lomakkeet

Lomakekentillä voi olla asianmukaiset label-elementit ja siten vaikuttaa teknisesti saavutettavalta. Jos virheilmoitukset ovat epäselviä tai ohjeistus puutteellinen, käyttäjä ei silti välttämättä pysty täyttämään lomaketta onnistuneesti.

Näppäimistökäyttö

Kaikki sivun elementit voivat olla saavutettavissa Tab-näppäimellä. Mutta, jos fokusjärjestys on sekava tai epälooginen, sivun käyttäminen voi olla käytännössä mahdotonta.

Näissä kaikissa tapauksissa yksittäiset tekniset vaatimukset voivat täyttyä, mutta saavutettavuuden periaatteet eivät toteudu käyttäjän kokemuksen tasolla. Eli sillä tasolla jolla saavutettavuutta tulisi tosiasiallisesti tarkastella.

Miksi automaattinen testaus ei riitä?

Markkinoilla on runsaasti erilaisia saavutettavuuden tarkistustyökaluja. Ne ovat hyödyllisiä ja säästävät aikaa, mutta niiden kyky arvioida saavutettavuutta on rajallinen. Käytä niitä esimerkiksi oman työn osana mutta älä korvaa omaa testausta sovelluksilla.

Automaattiset työkalut ovat hyviä havaitsemaan esimerkiksi:

  • puuttuvia alt-tekstejä
  • puuttuvia label:itä lomakkeen ”nimilappuja”
  • kontrastiongelmia
  • otsikkorakenteen virheitä
  • puuttuvia ohjelmallisia nimiä

Ne eivät kuitenkaan pysty luotettavasti arvioimaan:

  • onko alt-teksti tarpeen tai tarkoituksenmukainen
  • onko linkkiteksti ymmärrettävä
  • onko ohjeistus riittävä
  • onko sisältö helposti hahmotettavaa
  • onko käyttöliittymä looginen
  • ymmärtääkö käyttäjä mitä hänen pitäisi tehdä

Tästä syystä saavutettavuusasiantuntijoiden keskuudessa arvioidaan yleisesti, että automaattisilla työkaluilla voidaan todentaa vain osa WCAG-vaatimuksista. Yleinen käsitys mitattavien kriteerien osuudesta kaikista on vain noin 30%. Kuitenkin vain alle kolmannes.

Merkittävä osa arvioinnista edellyttää ihmisen tekemää tarkastelua.

Kriteerien sijasta kannattaa ajatella käyttäjää

WCAG-kriteerien tarkoituksena on tukea saavutettavuuden toteutumista, ei korvata käyttäjän näkökulmaa.

Kun arvioit verkkosivua, voit esittää itsellesi seuraavia kysymyksiä:

Havaittavuus

  • Onko sisältö helposti nähtävissä?
  • Onko teksti aidosti luettavaa?
  • Erottuvatko tärkeät elementit riittävästi?

Hallittavuus

  • Voiko sivustoa käyttää näppäimistöllä?
  • Onko navigointi loogista?
  • Pääseekö käyttäjä helposti haluamaansa toimintoon?

Ymmärrettävyys

  • Ymmärtääkö käyttäjä mitä sivulla tapahtuu?
  • Ovatko ohjeet selkeitä?
  • Ovatko virheilmoitukset ymmärrettäviä?

Toimintavarmuus

  • Toimiiko sivu erilaisilla selaimilla ja avustavilla teknologioilla?
  • Tulkitaanko sisältö ohjelmallisesti oikein?

Kun näihin kysymyksiin löytyy myönteinen vastaus, myös WCAG-kriteerien toteutuminen on yleensä hyvällä tasolla. Mutta huomaa, tarkastelu ei ala yksittäisten kriteerien mittaamisesta vaan kokonaisuudesta ja periaatteiden toteutumisesta. Vasta sieltä tarkastelua tarkennetaan yksittäisten kriteerien asettamiin vaatimuksiin.

Yhteenveto

WCAG-kriteerit ovat erittäin tärkeä työkalu saavutettavuuden arvioinnissa, mutta niitä ei kannata tulkita irrallisina teknisinä vaatimuksina.

Yksittäinen kriteeri voi täyttyä täydellisesti samalla, kun käyttäjä kohtaa todellisen saavutettavuusongelman. Siksi arvioinnin lähtökohtana tulisi aina olla saavutettavuuden neljä perusperiaatetta ja niiden toteutuminen käytännössä.

Saavutettavuuden tavoitteena ei ole kerätä mahdollisimman monta hyväksyttyä tarkistusta raporttiin. Tavoitteena on varmistaa, että mahdollisimman moni käyttäjä pystyy havaitsemaan, ymmärtämään ja käyttämään verkkopalvelua riippumatta omista ominaisuuksistaan tai käyttämistään apuvälineistä.

Vasta silloin saavutettavuus toteutuu aidosti – eikä vain teknisessä tarkistuslistassa.

Suorittamissani saavutettavuustestauksissa lähtökohta on aina todellisessa käyttäjän näkökulmasta suoritetussa tarkastelussa ja saavutettavuuden periaatteiden toteutumisessa.