Saavutettavuutta testaavat automaattiset työkalut ovat lisääntyneet viime vuosina. Niistä on suuri apu tiettyjen saavutettavuusongelmien varhaisessa havaitsemisessa. Automaatiotyökalut eivät kuitenkaan ole mikään pomminvarma ratkaisu saavutettavuuden testaamiseen, sillä monet ongelmat jäävät niiltä havaitsematta. Tässä blogissa syvennytään siihen, miten nämä ongelmat voidaan havaita ja miten järjestelmistä voidaan tehdä entistä saavutettavampia.
Automaattinen saavutettavuustestaus
Verkkosisällön saavutettavuustestaus perustuu yleensä W3 Web Content Accessibility Guidelines (WCAG) -ohjeisiin ja sen onnistumiskriteereihin. Osa vaatimuksista voidaan testata automaattisesti. Automaattisesti testaamalla voidaan tarkistaa mm. onko tekstissä riittävä värikontrasti, kuvissa tekstivastine ja lomakekentissä seloste. Testaustyökalut helpottavat huomattavasti tiettyjen saavutettavuusongelmien varhaista havaitsemista.
Automaattiset testaustyökalut voivat kuitenkin antaa myös väärän vaikutelman verkkosivun saavutettavuudesta, mikäli työkalu ei löydä ongelmia. Käytännössä automaattiset testaustyökalut pystyvät havaitsemaan vain noin 30 prosenttia saavutettavuusongelmista tällä hetkellä käytettävissä olevalla tekniikalla. Toisin sanoen asiantuntijan työtä tarvitaan edelleen aina manuaalisten saavutettavuusarviointien suorittamiseen.
Manuaalinen saavutettavuustestaus
Useimmat ihmiset käyttävät verkon selailuun osoitinlaitetta, kuten hiirtä, trackballia tai kosketusnäyttöä. Niin tekevät myös ohjelmistokehityksen ammattilaiset. Tästä syystä manuaalinen testauskin suoritetaan yleisimmin osoitinlaitteella. On kuitenkin olemassa laaja vähemmistö ihmisiä, jotka fyysisistä rajoitteista riippumatta käyttävät verkkoa pelkän näppäimistön ja avustavien teknologioiden, kuten ruudunlukijoiden, pistekirjoitusnäyttöjen ja kytkinohjainten, avulla. Tästä syystä on välttämätöntä, että manuaalinen testaus suoritetaan myös näppäimistöllä ja ruudunlukijoilla eikä pelkästään osoitinlaitteilla.
Näppäimistöön liittyvät saavutettavuussuositukset on melko helppo oppia ja ottaa osaksi testausrutiineja. Ruudunlukuohjelman saavutettavuuden ymmärtäminen vaatii jonkin verran alkuponnisteluja, kuten tutustumista tekniikkaan ja tapaan, jolla ohjelmia käytetään netin selaamiseen. Onneksi avuksi on saatavana erinomaisia ohjeita, kuten Sara Soueidanin opas ruudunlukijoiden testausympäristön asettamiseen ja DWP Accessibility Manualin eri ruudunlukijoiden testauskohteita ja -tapoja kuvailevat mallit.
Usein huomaamatta jäävät helppokäyttöisyysongelmat
Työskentelen vanhempana käyttäjäkokemus- ja saavutettavuusasiantuntijana ja teen säännöllisesti sekä saavutettavuustestauksia kehitteillä oleville järjestelmille että saavutettavuusauditointeja tuotannossa oleville järjestelmille. Vaikka myös mobiilisovelluksia testataan, tässä tekstissä huomio on selainpohjaisissa responsiivisissa verkkopalveluissa. Testauksista saadut tulokset sisältävät sekä automaattisten työkalujen havaitsemia että havaitsematta jääneitä ongelmia. Automaattisten työkalujen havaitsemat yleiset ongelmat on dokumentoitu hyvin esimerkiksi WebAIM Millionissa. Siksi keskityn tässä yleisiin ongelmiin, joita automaattiset työkalut eivät havaitse. Ongelmat on luokiteltu tyypeittäin, ja ne liittyvät pääasiassa toisiinsa. Ei ole yllättävää, että ongelmat liittyvät myös näppäimistöön ja avustaviin teknologioihin.
Ohituslinkki
Ohituslinkki mahdollistaa toistuvan navigointiosion ohittamisen ja siirtymisen suoraan pääsisältöön helposti. Henkilöt, jotka käyttävät vain näppäimistöä tai avustavia teknologioita, kuten kytkinohjainta tai suutikkua, käytännössä selaavat läpi kaikki kohdistettavat elementit järjestyksessä. Pääsisältöön pääseminen edellyttää, että käyttäjä käy läpi kaikki navigointilinkit toistuvasti jokaisella sivulla, mikä on erittäin työlästä erityisesti liikehäiriöistä kärsiville.
Valitettavasti tämä linkki yleensä puuttuu. Linkin toimintaa voi testata aloittamalla sivulla siirtymisen näppäimistön avulla. Ohituslinkin tulisi näkyä sivulla ensimmäisenä, ja linkin valitsemisen pitäisi siirtää käyttäjä pääsisältöön – hyvin yksinkertaista ja hyödyllistä. Linkin lisäksi tehokas näppäimistön ja avustavien teknologioiden käyttö vaatii myös loogisen kohdistusjärjestyksen.
Kohdistusjärjestyksen hallinta
Kohdistusjärjestys perustuu oletusarvoisesti elementtien järjestykseen Document Object Model (DOM) -mallissa. Tämän takia sen tulisi vastata elementtien visuaalista järjestystä. Pääasiassa linkkejä käsittävässä sisällössä kohdistusjärjestys on hyvin suoraviivainen. Dynaamiseen sisällössä on kuitenkin toimintoja, kuten sisällön lataaminen, modaalisen valintaikkunan avaaminen ja lomakkeen lähettäminen. Dynaamiset toiminnot edellyttävät kohdistusjärjestyksen hallintaa, eli kohdistuksen ohjelmallista asettamista loogisesti kunkin toiminnon jälkeen. Näin voidaan varmistaa, että näppäimistön ja avustavien teknologioiden käyttäjäkokemus etenee peräkkäisessä järjestyksessä ja intuitiivisesti.
Alla on tyypillisiä tapauksia, jotka edellyttävät kohdistusjärjestyksen hallintaa:
- Dynaamisesti luotu sisältö. Esimerkiksi ”Lataa lisää” -painikkeen aktivoinnin jälkeen kohdistus tulisi asettaa juuri ladattuista ensimmäiseen kohdistettavaan elementtiin.
- Dynaamisesti poistettu sisältö. Kun esimerkiksi luettelokohde poistetaan, kohdistus voidaan asettaa luettelon seuraavaan elementtiin (tai edelliseen elementtiin, jos poistettu kohde oli viimeinen).
- Modaaliset valintaikkunat. Kun modaali avataan, kohdistuksen tulisi asettua modaaliin eikä modaalin takana olevaan sisältöön pitäisi päästä käsiksi näppäimistöllä. Kun modaali suljetaan, kohdistus palaa tyypillisesti modaalin avanneeseen elementtiin (modaalissa toteutetusta toiminnosta riippuen).
- Virheilmoitukset. Kun lomakkeessa on virheilmoituksia, saavutettavuus varmistetaan usein esittämällä luettelo virheistä ja asettamalla kohdistus luetteloon.
Dynaamisissa toiminnoissa kohdistus kuitenkin usein katoaa, palautuu sivun yläreunaan tai pysyy muuttumattomana. Tämä johtaa usein heikkoon käytettävyyteen, esimerkiksi kun käyttäjä joutuu uudelleen navigoimaan sivua. Helpoin tapa testata kohdistusjärjestystä on selata sivua näppäimistön avulla ja esimerkiksi aktivoida toimintoja kohdistuksen tarkistamiseksi. Jos kohdistusta ei näy lainkaan, ongelma saattaa olla siinä, että kohdistuksen ilmaiseminen (focus indicator) on asetettu väärin.
Kohdistuksen ilmaisin (focus indicator)
Vain näppäimistöä käyttävillä kohdistuksen ilmaisin vastaa hiiren käyttäjien kohdistinta. Ilmaisin näyttää, missä kohtaa verkkosivua käyttäjä on. Ilman selkeää visuaalisen kohdistuksen ilmaisinta, tai kohdistinta, verkkosivustolla siirtyminen ja sivuston käyttö on mahdotonta. Selaimissa on oletustoteutuksena kohdistuksen ilmaisin niiden omille kohdistettaville elementeille, kuten painikkeille, linkeille ja lomakkeiden ohjausobjekteille. Tämä toteutus on WCAG-yhteensopiva ja pääosin riittävän selkeä.
Kohdistetuissa elementeissä havaitaan ongelmia useimmiten silloin, kun oletusarvoinen kohdistuksen ilmaisin korvataan tai poistetaan kokonaan. Räätälöidyissä käyttöliittymäkomponenteissa kohdistuksen ilmaisin ei usein ole oikein toteutettu. Testaus voidaan suorittaa yksinkertaisesti selaamalla sivua näppäimistön avulla. Kaikkien hiirellä käytettävien elementtien tulee olla käytettävissä myös näppäimistöllä, ja niissä tulee olla riittävän selkeä kohdistuksen ilmaisin. Varmista, että testaat myös dynaamisen sisällön kohdistuksen ilmaisimen edellisessä osiossa kuvatulla tavalla.
Semanttinen HTML
Näppäimistöä ja ruudunlukijaa hyödyntävät selaamisessa ja sisällön rakenteen ymmärtämisessä semanttista HTML:ää. Semanttiset HTML-elementit ovat oletusarvoisesti saavutettavia. Ongelmat liittyvät yleensä puuttuvaan tai virheelliseen semantiikkaan. Ongelmia aiheuttavat esimerkiksi:
- Painikkeet, jotka toteutetaan käyttämällä geneeristä elementtiä semanttisen painikkeen sijaan. Tällaiset painikkeet toimivat vain osoitinlaitetta käyttäville henkilöille. Ongelma on niin yleinen, että sitä varten on jopa T-paita.
- Virheelliset tai puuttuvat otsikko-, luettelo- ja taulukkoelementit. Ilman oikeaa elementtiä ruudunlukuohjelmia käyttävät henkilöt eivät pysty ymmärtämään sisällön rakennetta.
- Maamerkkialueiden merkinnät puuttuvat. Alueita tarvitaan, jotta verkkosivustolla on mahdollista siirtyä tehokkaasti ruudunlukuohjelmien avulla.
Semanttinen HTML testataan sekä manuaalisella näppäimistönavigoinnilla, jolla tarkistetaan kohdistettavien elementtien odotetun kaltainen toiminta, että ruudunlukuohjelmalla, jolla tarkistetaan rakenteellistenelementtien oikea toteutus. DOM:n tarkastelu käyttöliittymää vasten voi myös paljastaa useimmat semanttisen HTML:n ongelmat.
Räätälöidyt komponentit
Kaikille käyttöliittymäkonventioille ei ole (vielä) olemassa natiivia tai sisäänrakennettua HTML-elementtiä, kuten esimerkiksi välilehdille, ponnahdusikkunoille tai haitarivalikoille. Tällaiset konventiot toteutetaan räätälöityinä komponentteina useita elementtejä hyödyntämällä. Valitettavasti räätälöidyt komponentit toimivat usein vain hiiren tai kosketusnäytön kanssa. Yleisiä saavutettavuusongelmia ovat esimerkiksi seuraavat:
- Näppäimistötoiminnot puuttuvat tai ne on toteutettu väärin.
- Kohdistuksen ilmaisin puuttuu.
- ARIA (Accessible Rich Internet Applications)-roolit, -tilat ja -ominaisuudet puuttuvat tai ovat virheellisiä. Ruudunlukuohjelmia käyttävät henkilöt ymmärtävät räätälöityjen komponenttien toiminnan ARIA-merkintöjen avulla eivätkä näin ollen voi pahimmillaan käyttää väärin toteutettuja komponentteja.
Räätälöityjen komponenttien testaaminen edellyttää ymmärrystä siitä, miten komponenttien odotetaan toimivan näppäimistön ja ruudunlukuohjelman avulla. W3 ARIA Authoring Practices Guide sisältää hyviä yleisimpiä räätälöityjä komponentteja koskevia ohjeita. Myös Smashing Magazine on koonnut laajan oppaan saavutettavista komponenteista. Näitä lähteitä kannattaa mieluusti hyödyntää räätälöityjen komponenttien toteuttamisessa. Näin säästyt paljolta turhalta testaustyöltä.
Dynaamiset päivitykset
Jotkin käyttöliittymätoiminnot vaativat dynaamisia sisältöpäivityksiä, kuten hakusanaa kirjoitettaessa näkyviin tulevia hakutuloksia, toimintoa seuraavia onnistumis- ja virheilmoituksia tai tuotteen lisäämisen ostoskoriin. Näiden päivitysten yleinen ongelma on, että ne ovat havaittavissa vain visuaalisesti, eivät ohjelmallisesti, eivätkä ne näin ollen ole ruudunlukuohjelmien käytettävissä. Päivitysten saavutettavuus edellyttää päivitetyn sisällön toteuttamista ARIA-live-alueilla ja testaamista ruudunlukuohjelmilla.
Kieliasetukset
Kieli on ruudunlukuohjelmien kriittinen elementti erityisesti henkilöille, jotka puhuvat useita kieliä ja käyttävät monikielisiä verkkosivustoja. Ruudunlukuohjelmat käyttävät verkkosivujen kieliasetuksia oikean ääntämisen määrittämiseen.
Automaattiset työkalut pystyvät toistaiseksi havaitsemaan vain sivun kieliasetusten olemassaolon, mutta eivät sitä, onko asetus oikea tai onko osa sivun sisällöstä kirjoitettu muulla kuin sivulle määritetyllä kielellä. Esimerkiksi Suomessa virallisia kieliä ovat suomi ja ruotsi ja monet sivustot ovat monikielisiä. Jos molempia kieliä käytetään samalla sivulla ilman oikeaa kielimerkintää, ruudunlukuohjelmien ilmoitukset alkavat kuulostaa esimerkiksi Muppetien ruotsalaiselta kokilta – mikä on toki hupaisaa mutta ei järin hyödyllistä.
Kieliasetukset testataan ruudunlukuohjelmilla kuuntelemalla sisältö läpi tai tarkistamalla sisältö sen taustalla olevia merkintöjä vasten.
Kirjoituksen tärkein anti: panosta manuaaliseen saavutettavuustestaukseen
Automaattisten työkalujen käyttö tarjoaa kustannustehokkaan ratkaisun monien saavutettavuusongelmien varhaiseen havaitsemiseen. Se ei kuitenkaan yksinään riitä, kuten tämä kirjoitus todistaa. Siksi kannattaakin panostaa hieman lisää saavutettavuuteen ja suorittaa manuaalinen testaus näppäimistöllä ja ruudunlukuohjelmilla. Kunhan tästä muodostuu tapa, opit myös välttämään ongelmat ennen niiden muodostumista. Lopulta tämä ”ylimääräinen vaiva” ei enää rasita ja palveluistasi tulee paljon saavutettavampia.
Tarvitsetko apua saavutettavuusasioissa? Laita meille viestiä.
