Saavutettavuus on yksi devauksen osa-alue, josta ammattilaisen tulee tänä päivänä tietää ja osata riittävällä tasolla. Ihan siinä missä vaikkapa koodin selkeydestä ja suorituskykyasioistakin. Saavutettavuutta ei vain ripotella mausteeksi kaiken päälle projektin lopussa, vaan se pitää huomioida alusta asti. Yllättävää on, että monelle tämä kaikki tulee, no, yllätyksenä.
North Patrol on suunnitteluun erikoistunut konsulttitoimisto. Suunnittelemme, autamme teknologiavalinnoissa, kilpailutamme. Emme myy toteutusprojekteja, emmekä lisenssejä, olemme aidosti asiakkaan puolella.
Essential for some, useful for all.
– W3C
Miksi saavutettavuus on tärkeää?
Maailman terveysjärjestön, WHO:n, mukaan 16 prosentilla maailman ihmisistä on jonkinlainen vamma tai tila, joka saattaa rajoittaa heidän jokapäiväistä tekemistään – ja aina se ei näy päällepäin. Pelkästään Suomen asukaslukuun suhteutettuna tuo prosenttiluku tarkoittaa yli 800 000 henkilöä! Itse asiassa Suomessa saavutettavuusasiosta vastaava taho, Aluehallintovirasto, mainitsee sivuillaan, että jopa yli miljoona suomalaista hyötyisi saavutettavammista digipalveluista. Käytännössä saavutettavuudesta hyötyy jokaikinen ihminen, koska todennäköisesti meistä jokaisella on jossain elämän vaiheessa ainakin tilapäisesti alentunut toimintakyky joko henkilökohtaisista syistä tai olosuhteista johtuen. On stressiä töissä tai kiire löytää joku tärkeä tieto netistä. Ehkäpä käsi on murtunut ja paketissa, tai sitten jossain korvessa on surkeat nettiyhteydet. Listaa voisi jatkaa loputtomiin.
W3C:n Perspective videos -sarjassa esiintyy yksi lempilausahduksistani saavutettavuuden saralta: ”Essential for some, useful for all” eli oleellista joillekin, hyödyllistä kaikille. Suosittelen tsekkaamaan videot.
WCAG:n haasteet
Digipalvelulain vaatimuksissa viitataan Web Content Accessibility Guidelinesien eli WCAG 2.1 -version AA-tasoon. Kollegani Virpi Blom toi taannoin ansiokkaasti esiin WCAG:n ongelmia lähinnä sisällöntuottajien näkökulmasta, eikä se devaajienkaan kannalta ole mikään hopealuoti, joka ratkaisee kaiken. Eihän sitä alunperinkään ole tehty lainsäädännön perustaksi, mutta sellaisena sitä nyt kuitenkin tulkitaan.
Jos tuijottaa pelkkiä WCAG -kriteereitä ja luottaa vain automatisoituihin testeihin, jää iso osa saavutettavuusongelmista ratkomatta – yleensä ne käyttäjän kannalta hankalimmat tapaukset. WebAIM -organisaation suorittama miljoonan suosituimman verkkosivuston vuosittainen saavutettavuusanalyysi, The WebAIM Million, on karua luettavaa. Vuonna 2022 tutkituista sivustoista 96,8 prosentissa havaittiin WCAG 2 -virheitä. Ja kuinka paljon siihen päälle onkaan vielä sitten niitä saavutettavuusongelmia, joita ei saada millään automatisoidulla WCAG -testauksella kiinni? Melkoisen masentavaa ajateltavaa.
Toki pitää muistaa, että pääseminen nollaan WCAG -herjaan ei pitäisi olla päätavoite vaan se, että sivustolla ei ole käyttäjän toimintaa hankaloittavia tai estäviä virheitä. Se, että normaalikokoisen leipätekstin värikontrasti on 4,48:1 sen sijaan että se olisi kriteeristön mukainen 4,5:1 on mielestäni aivan turhaa hiusten halkomista. Jos se on sivuston ainoa saavutettavuusongelma, on ansainnut taputuksen olkapäälle.
Pikkutärpit
Aloitetaan pikkutärpeillä, sellaisilla ”no tottakai nämä pitää olla paikoillaan” -jutuilla, jotka toivottavasti eivät enää tässä vaiheessa tule yllätyksenä kenellekään. Eli alt -teksteillä, focus -tyyleillä ja suhteellisten yksiköiden käytöllä fonttien koon asettamisessa.
Tärppi 1: Kuvien alt -attribuutti on pakollinen tieto
Alt -tekstien puuttuminen oli kontrastiongelmien jälkeen toiseksi yleisin havaittu ongelma WebAIMin miljoonaprojektissa. Kuvalla on oltava alt -attribuutti, jätetään se sitten tyhjäksi tai ei. Jos alt -attribuuttia ei ole ollenkaan, ruudunlukija lukee yleensä kuvan tiedostonimen – ei mitenkään ideaalia. Jos taasen alt -attribuutti on, mutta se jätetään tyhjäksi, ruudunlukija tulkitsee kuvan koristeelliseksi eikä reagoi siihen mitenkään. Ja se on ihan ookoo. Mutta jos kuvassa on jotain sisällön kannalta oleellista, on sille kirjoitettava kunnollinen alt -teksti.
Alt -tekstin kirjoittaminen onkin sitten oma taiteenlajinsa eli miten kuvassa näkyvää asiaa pitää kuvailla ja kuinka runsassanaisesti. Sitä voi kukin tykönään miettiä, mitä haluaisi itselleen kuvasta kerrottavan, jos ei sitä jostain syystä pystyisi näkemään. Huomioitavaa on myös, että jos kuva ei jostain syystä lataannu, kuvan alt -teksti on se, joka näkyy siinä tapauksessa myös näkevälle käyttäjälle. Tokihan alt -tekstien runoilu on useimmiten sisällöntuottajan vastuulla. Mutta devaajan vastuulla on se, että nettiin ei pääse kuvia, joilla ei ole alt -attribuuttia, ja että oletuksena alt -attribuutti jätetään tyhjäksi eikä laiteta siihen mitään tiedostonnimeä ihan vain varmuudeksi.
Tärppi 2: Interaktiivisilla elementeillä on focus -tyyli oletuksena ihan syystä, älä ota sitä pois
Kaikilla interaktiivisilla elementeillä (nappulat, linkit, lomakekentät, …) on oletuksena focus -tyyli, koska sillä on tärkeä merkitys sijainnin hahmoittamisessa sivulla vaikkapa näppäimistön käyttäjälle. Toki oletustyyliä on täysin sallittua muokata, jos se vaikka ei erotu tarpeeksi sivuston taustaväristä. Mutta kokonaan pois focus -tyyliä ei saa missään tapauksessa ottaa!
Tärppi 3: Aseta fonttikoko suhteellisilla yksiköillä, jotta tekstiä voi helpommin suurentaa
Yksi WCAG:n saavutettavuusvaatimuksista on, että sivustoa, ja etenkin sen tekstiä, pitää pystyä zoomaamaan vähintään 200 % siten, että sisältö on vielä hyvin luettavaa. Siksipä fonttikoko on syytä asettaa suhteellisilla yksiköillä (esim. rem, em), koska pikselit eivät skaalaudu. Pikseleille on webissä kyllä paikkansa, mutta ei fonteissa.
Sivun rakenne
Jos sivuston perusrakenne on kunnossa, on paljon helpompaa lähteä tekemään siitä saavutettavaa. Rakenteesta olisi sanottavaa useammankin blogipostauksen edestä, mutta nostan tähän nyt muutaman (omasta mielestäni) tärkeimmän.
Tärppi 4: Käytä semanttisia HTML-elementtejä
Harmillisen usein törmää edelleen sivustoihin, joiden dokumenttirakenne koostuu pelkästä div -mössöstä vaikka fiksumpiakin tapoja olisi. HTML5, jonka myötä HTML:ään tuli lukuisia uusia semanttisia elementtejä, on julkaistu alunperin jo vuonna 2008. Joten pelkkien divien käyttöä ei voi kukaan tämän päivän ammatikseen webbikehitystä tekevä devaaja perustella enää mitenkään. Toki divien käyttö ei ole kielletty, mutta jos hommaan löytyy semanttinen elementti – niin kuin hyvin todennäköisesti löytyykin – käytä mieluummin sitä! HTMHell -blogissa on divien ylenpalttisesta käytöstä hyvä esimerkki. (Muutoinkin kyseinen sivusto on oikea aarreaitta, kannattaa kahlata läpi, hyvää settiä.)
Avustavat teknologiat perustavat toimintansa hyvin pitkälle semanttisten elementtien käyttöön, joten käyttämällä pelkkiä divejä, karkoitat potentiaalisia asiakkaita, koska he eivät todennäköisesti löydä sivulta tarvitsemiaan tietoja. Ja jos rahapuoli kiinnostaa, niin myös hakukoneet hyötyvät semanttisista elementeistä – ja sehän merkitsee lisää liikennettä (ja rahaa) sivustolle.
Tärppi 5: Käytä maamerkkejä
Moni ruudunlukijakäyttäjä navigoi sivulla maamerkkien (landmarks) avulla, esimerkiksi otsikkoelementit (h1–h6), <main>, <nav> ja <footer> toimivat sellaisina. Myös <section> -elementti on maamerkki, mutta sille on muistettava antaa lapsielementtinä otsikko (h1–h6). Ruudunlukija tulkitsee sectionin ilman otsikkoa aivan tavalliseksi diviksi eikä sitä näin ollen löydy ruudunlukijan maamerkki -valikosta. Maamerkkejä kannattaa käyttää rakenteen määrittelyssä, koska ne tuovat vielä yhden käyttäjää helpottavan tavan lisää sivulla suunnistamiseen.
Tärppi 6: Käytä otsikoita loogisesti
Otsikkoelementtejä (h1–h6) tulisi käyttää loogisessa järjestyksessä ilman, että hypitään tasojen yli (esimerkiksi h2 -elementistä seuraava elementti ei voi olla h4). Tässä voi olla sisällöntuotannollisia haasteita, jos vaikka johonkin komponenttiin on kovakoodattu otsikkokentäksi h2 -elementti, mutta komponenttia käytetäänkin jossain syvemmällä sivun rakenteessa. Tällöin on mietittävä, pystyykö sivun otsikot muodostamaan dynaamisesti, jotta oikea semanttinen järjestys voitaisiin säilyttää.
Tyylit ja semantiikka on pidettävä toisistaan erillään. Jos semanttisesti komponentissa kuuluu olla h2 -elementti, mutta sen halutaan näyttävän h4 -elementiltä, tulee itse elementin pysyä h2:na ja tyyleillä muotoilla se halutun näköiseksi. Ei siis vaihdeta otsikkotasoa h4:ksi vain sen ulkoasun takia!
Jos näkevälle käyttäjälle jonkin sisältöalueen sisällön luonne on ilmeinen, vaikkapa ”Tuoreimmat uutiset”, voidaan otsikko piilottaa näkyviltä, mutta jättää se ruudunlukijoiden löydettäväksi. Tosin miksi piilottaa mahdollisesti selventävää tietoa näkeviltäkään?
Tärppi 7: Lisää sivulle ”hyppää sisältöön” -linkki
Monesti sivustoilla on sivun yläosassa massiivinen päänavigaatiokokonaisuus, joka sisältää lukuisia linkkejä ja painikkeita. Niiden läpikliksutteleminen ennen varsinaiseen sisältöön pääsemistä voi olla avustavaa teknologiaa käyttävälle henkilölle todella turhauttavaa. Sivun alkuun onkin hyvä lisätä ”Hyppää sisältöön” -linkki (skip to content), jonka avulla käyttäjä pääsee suoraan pääsisältöön.
Tärppi 8: Ole tarkkana ARIAn kanssa!
No ARIA is better than bad ARIA.
– Toinen saavutettavuuteen liittyvä lempilausahdukseni W3C:ltä
ARIA -attribuutteja voi käyttää elementeissä tuomaan avustavalle teknologialle lisäohjeistusta tilanteissa, joissa elementti ei sitä oletuksena tarjoa. Esimerkiksi ”aria-label”:n käyttö on monissa tilanteissa hyvin suotavaa. Mutta ARIA:n kanssa on oltava tarkkana, koska sen liiallisella käytöllä voi nopeasti joutua ojasta allikkoon. Jopa W3C on itse todennut ”no ARIA is better than bad ARIA”.
Jos elementillä on jo implisiittisesti eli oletuksena jokin rooli (esim. button -elementillä on oletuksena role=”button”), ei sitä pidä enää erikseen lisätä elementille. Tai ei tehdä painiketta divistä lisäämällä sille role=”button” – käytä, hyvä ihminen, rehellistä <button> -elementtiä!
Eikä sitten myöskään käytetä aivan tavallisessa sivuston päänavigaatiossa ARIA -rooleja role=”menu” tai role=”menuitem”, koska niitä ei ole tarkoitettu siihen käyttöön. Ruudunlukijakäyttäjä hämmentyy helposti, koska hän ei odota törmäävänsä tavallisessa webbisivun navigaatiossa täysverisen web-sovelluksen valikkorakenteeseen ja sen erilaisiin näppäinkomentoihin. Käyttöliittymäkonventioita on hyvä noudattaa, jotta ei turhaan sekoiteta käyttäjiä.
Internet on täynnä ohjeita, miten tehdä saavutettavia komponentteja ilman, että ängetään turhia ja jopa haitallisia ARIA -attribuutteja jokaiseen elementtiin. Smashing Magazinella on hyvä kokoelma saavutettavista komponenteista ja Heydon Pickeringin Inclusive Components on myös tutustumisen arvoinen lähde. Niistä on hyvä aloittaa.
Tärppi 9: Kunnioita käyttäjän asetuksia
Käyttäjä voi asettaa tiettyjä saavutettavuusasetuksia päälle käyttöjärjestelmätasolla, joita on fiksua kunnioittaa webissäkin.
Esimerkiksi prefers-reduced-motion -asetuksen päälläolon voi helposti tarkistaa CSS:ssä media queryllä. Kyseinen parametri kertoo, että käyttäjä haluaa nähdä vähemmän liikettä netissä surffaillessaan. Se ei tietenkään tarkoita sitä, että kaikki animaatiot on otettava kokonaan pois, vaan sitä, että pyritään välttämään sellaisia laajoja liikkeitä, jotka voivat laukaista matkapahoinvointiin verrattavaa huonovointisuutta tai huimausta (vestibular motion disorder). Esimerkiksi parallax scrolling ja jopa scroll-behavior: smooth voi aiheuttaa joissakin ihmisissä tällaisia oireita. WCAG:ssa on tälle oma AAA-tasoinen kriteerinsä. Olen itse hyvinkin tietoinen tästä käyttöjärjestelmäasetuksesta, koska kärsin edellä mainituista oireista – onneksi melko lievänä.
Muita vastaavanlaisia käyttöjärjestelmätason asetuksia ovat prefers-color-scheme, prefers-contrast, ja tulevaisuudessa myös prefers-reduced-data.
Tärppi 10: Älä unohda testata saavutettavuuttakaan
Kuten muussakin softakehityksessä, myös saavutettavuudessa testaaminen on tärkeää. Automaattisia työkaluja kannattaa hyödyntää: Vaikkapa Chromen Lighthousea, selaimiin asennettavia lisäosia (WAVE:a, Accessibility Insightsia tai axe DevToolsia) tai Polypane -selainta. Näiden ongelmana on vain se, kuten aiemmin mainitsin jo WebAIM:n miljoonaprojektin yhteydessä, että ne saavat kiinni vain pienen osan saavutettavuusongelmista. Paljon jää testattavaa vielä niiden ulkopuolellekin.
Se, missä oikea ihminen tulee mukaan kuvioon, on sivuston testaaminen näppäimistöllä ja ruudunlukijalla. Esimerkiksi näppäimistökäytön on oltava loogista ja ruudunlukijoilta ei saa piilottaa oleellisia asioita. Me kaikki koodarit osaamme kyllä testata sivuston käyttöä näppiksellä (huom, ilman hiirtä!) – tabin, enterin, välilyönnin ja nuolinäppäinten käytön luulisi käyvän kaikilta kuin tanssi. Ruudunlukijoiden käytössä on oma oppimiskynnyksensä, mutta muutamalla peruskomennolla pääsee jo pitkälle, ja ne kannattaa opetella omalla käyttöjärjestelmä+ruudunlukija -yhdistelmällä.
On muistettava, että avustaviin teknologioihin kuuluu paljon muunkinlaisia laitteita kuin vain ruudunlukijoita, ja niillä on aivan yhtälaiset haasteet nettisivujen käytön suhteen. Käyttämällä semanttista HTML:ää ja tekemällä hyvin mietittyjä koodausratkaisuja, laajennetaan potentiaalista käyttäjä- ja asiakaskuntaa huomattavasti.
Ideaalitilanteessa jokainen kehittäjä osaisi tehdä sivustolle täydellisen saavutettavuusauditoinnin, mutta se ei ole realistista. Keskitytään siis mieluummin löytämään ja korjaamaan ne olennaisimmat ongelmat mahdollisimman helposti ja nopeasti siten, että jokainen devaaja tietää saavutettavuustestauksesta vähintäänkin perusasiat.
Loppusanat
Saavutettavuus ei ole rakettitiedettä, se on empatiaa. Henkilökohtainen mielipiteeni on, että jos loppukäyttäjän hyvinvointi ei kiinnostaa webbidevaajaa pätkääkään, suosittelen vaihtamaan alaa. Lopulta meidän tuotoksia kuitenkin käyttävät ihan oikeat ihmiset kaikkine haasteineen ja tunteineen, ja niiden huomioon ottaminen kuuluu meidän ammattitaitoomme.
PS. Sinua voisi kiinnostaa tulossa oleva ilmainen webinaarimme: Digitaaliset asiointipalvelut – Erilaiset konseptit ja toteutuksen eri vaihtoehdot (11.12.2024 klo 10:00). Ilmoittaudu webinaariin
