Vielä 2000-luvun alussa oli aika tavallista, että internetiä käytettiin julkisilta yhteiskäyttöisiltä koneilta oppilaitoksissa, kirjastoissa, työvoimatoimistoissa jne. Tuolloin oli ihan vakava riski se, että koneissa oli ”javascript disabloituna” (tietoturvasyistä tai ylläpidon helpottamiseksi), tai konekanta oli niin vanhaa, että selainversiot eivät tukeneet selaimessa suoritettavia skriptejä. Esteettömyyden kannalta oli siis tärkeää ajatella, mitä tapahtuu niille tavallisille käyttäjille, joiden selaimet eivät tue skriptejä.
North Patrol on suunnitteluun erikoistunut konsulttitoimisto. Suunnittelemme, autamme teknologiavalinnoissa, kilpailutamme. Emme myy toteutusprojekteja, emmekä lisenssejä, olemme aidosti asiakkaan puolella.
1.3.2017
Sittemmin kuitenkin selaimessa suoritettavat ”javaskriptit” ovat käyneet miltei pääsääntöiseksi tavaksi toteuttaa käyttöliittymän dynaamiset toiminnallisuudet (”puhtaan” HTML-koodin sijaan), ja tästä syystä nykyisin kaikki selaimet joutuvat tukemaan javaskriptiä. Saavutettavuuden kannalta ei siis keskeinen ongelma enää ole ne vähäiset käyttäjät, joilla ei ole skriptitukea, vaan se, millaista javascriptiä verkkopalveluun tuotetaan esim. näkövammaisten ruudunlukuohjelmien tai muiden ’avustavien teknologioiden’ ymmärrettäväksi.
Takavuosilta on kuitenkin jäänyt monen verkkopalvelukehittäjän mieleen sellainen saavutettavuuden laatukriteeri, että verkkopalvelun pitäisi toimia täysin yhtäläisesti myös niille graafisten selainten käyttäjille, joilla on javaskriptit pois päältä. Tämä käsitys on kuitenkin aika lailla vanhentunut.
Kenellä ei ole javaskriptiä?
Kun kaikki selaimet nykyisin pystyvät tukemaan javaskriptiä, on se käytännössä poissa päältä vain sellaisilta käyttäjiltä, jotka ovat valinneet ottaa sen pois päältä. Nämä käyttäjät ovat tyypillisesti jonkin puhdasoppisuuden tai paranoian ajamia tehokäyttäjiä, jotka kaihtavat mainoksia, kansainvälisten korporaatioiden seurantamekanismeja, jäljen jättämistä seurantaan tai liiallisen grafiikan/animaatioiden tuottamaa latausaikojen hidastumista. Joka tapauksessa tämä rajaus on heiltä tietoinen valinta, ja he ovat ottaneet aktiivisesti riskin siitä, että verkkopalvelujen kaikki toiminnallisuus ei ole heidän käytössään.
Jos haluat saada statistiikkaa siitä, paljonko omaa verkkopalveluasi käytetään ilman javaskriptiä, pitää muistaa asettaa sivuille javaskriptatun seurantaelementin rinnalle myös tapa seurata ”noscript”-käyttäjiä. Blockmetry-palvelun (aiemmin Adblock Analytics) mittausten mukaan loppuvuodesta 2016 oli maailmanlaajuisesti vain 0,2 prosenttia kaikista sivulatauksista ”javascript disabled” -käyttäjien tekemiä.
Tuossa Blockmetryn mittauksessa oli muuten jännittävä huomio: Suomessa on tavanomaista enemmän työpöytäkäyttäjiä (1,3 %) ”javaskriptit-pois-päältä” -tilassa. Kiinassa, Taiwanissa ja Etelä-Koreassa tuntuu järkeenkäyvältä, etteivät käyttäjät halua jättää itsestään tunnistettavia jälkiä seurantaan, mutta miksi Suomessa? Näkyykö tässä meidän tarpeemme ”yksityiseen tilaan”? Vai allergisuus mainonnalle?
Skriptatut sisältöosuudet ovat arkipäivää
Suurin osa navigaatiovalikoista ja kätevistä laskeutumissivuista, joihin verkkopalveluissa törmäät, on nykyisin toteutettu Javaskripteillä. Skriptattujen nykyratkaisujen joukossa ovat mm. ”sisältöhaitarit”, ”tooltipit” ja ”välilehdet”, joilla jokin verkkosivun sisältöosuus on ”näkymättömissä”, kunnes käyttäjä aktiivisessa klikkauksella avaa sisällön näkyviin. Käyttöliittymäratkaisun ideana on helpottaa sivun silmäilyä ja sisältöjen hahmottamista, kun kaikki tekstit ja kuvat eivät ole suoraan näkyvissä, vaan käyttäjän hallitsemalla tavalla avattavissa. Käyttökokemuksen kannalta on olennaista, että käyttäjä ei siirry toiselle sivulle tai tee uutta sivulatausta, vaan tarkentava sisältö aukeaa näkyvästi juuri siihen kontekstiin, joka on käsillä.
Jos tällaista tyypillisesti skriptattua ”sisältöhaitaria” lähestyy käyttäjä, jolla on Javascript pois päältä, hän ei saa avattua haitaria ollenkaan. Jos pidetään kiinni siitä vanhasta periaatteesta, että myös näitä käyttäjiä palvellaan, on yleisin tekninen ratkaisu hätäinen fiksi, josta kärsivät kaikki muut käyttäjät. Hätäratkaisuna käytetään sitä, että sivulla olevat haitarit näkyvätkin oletusarvoisesti auki, ja skriptillä suljetaan ne sivulatauksessa välittömästi niiltä, joilla Javascriptit ovat käytössä. Graafisessa, skriptejä tukevassa selaimessa tämä näkyy käyttäjälle siten, että sivu ikään kuin ”räpsyy” tai ”heijaa” tekstien asettelun osalta.
Kun ”javaskriptittömien” käyttäjien ongelma on ”itseaiheutettu”, tuntuu väärältä laittaa muita käyttäjiä kärsimään sen vuoksi. Itse en pitäisi ongelmana sitä, että ratkaisu toteutetaan suuremman käyttäjäryhmän ehdoilla eli räpsymättä, haitarit oletuksena valmiiksi kiinni. Käyttäjien tasapuolisen kohtelun periaate toteutuu kyllä: palveluntarjoajan hyötytiedot ovat käyttäjän saatavilla, kunhan vain laittaa skriptit päälle.
Vaihtoehtoisen sisällön tarjoaminen
Jos javaskriptittömiä käyttäjiä halutaan tukea, on toinen tekninen ratkaisu suureellisempi: sivun sisällöstä luodaan ”vaihtoehtoinen” versio, joka on luotu skriptittömiä päätelaitteita varten. Vähän samaan tapaan kuin kuvista tai animaatioista voidaan antaa vaihtoehtoinen tekstiselite, luodaan javaskriptatusta sivusta rinnakkaisversio, jossa skriptiä ei käytetä. Tässä ratkaisussa esimerkiksi sisältöhaitarisivua lataava käyttäjä tunnistetaan skriptittömäksi ja hänelle näytetään vaihtoehtosivu, jonka sisällöt ovat suoraan esillä, ilman haitaria.
”Skriptitön vastine” on tyypillisesti jokin palvelinpäässä muodostettu peilikuva sivusta, jolloin molempien sivujen tuottamisen ja ylläpitämisen tekniset ratkaisut ovat aika kaukana tyypillisistä julkaisujärjestelmän ominaisuuksista.
Näitä ratkaisuja käytetään tyypillisesti silloin, kun on kyse vakavasta, olennaisesta asiointipalvelusta (kuten tärkeästä asiointilomakkeesta), jolle on pakko pystyä esittämään toimiva skriptitön vaihtoehto, vaikka skriptitön sivu ei sitten olisi yhtä älykäs, näppärästi käyteltävä ja näyttävä. Ratkaisu ei siis oikein sovellu tavanomaisen sisällöntuotannon tarpeeseen, jossa skriptattuja elementtejä luodaan sisällöntuottajien toimesta säännöllisesti WYSIWYG-periaatteella sadoille sivulle.
Tässäkin asiassa – kuten kaikissa käytettävyyden ja saavutettavuuden kysymyksissä – on palveluntarjoajan tehtävä oma linjaus siitä, mille käyttäjäryhmille kumarretaan, ja kenelle pyllistetään.
Saavutettavat skriptit
Saavutettavuuden kannalta ollaan ihan toisenlaisessa ongelmakentässä, kun ryhdytään pohtimaan niitä käyttäjiä, jotka lähestyvät skriptattuja verkkopalveluja muutoin kuin graafisina, silmin katsottavina käyttöliittyminä, joita käytellään hiiren avulla klikkaillen. Kokeilepa vaikka itsetyytyväisyyden hetkellä, miltä tuntuu etsiä verkkosivustoltanne laskutustiedot pelkästään näppäimistöä käyttäen!
Saavutettavuusperiaatteiden mukaan on huolehdittava siitä, että kaikki käyttäjät – päätelaitteesta huolimatta – voivat käytellä palveluntarjoajan verkkopalvelua, saavat käyttöönsä saman informaation ja pystyvät suorittamaan samat toiminnot.
Javaskriptiä saa siis olla verkkopalvelussa mielin määrin, mutta sen täytyy toimia erilaisissa päätelaitteissa ja erilaisilla avustavilla teknologioilla (kuten ruudunlukuohjelmat, tekstiselaimet, pistenäytöt, näppäinkomennot jne.).
Javaskriptillä (tai Ajaxilla tai muilla dynaamisilla web-teknologioilla) toteutettujen sovellusten saavutettavuuden takaamiseksi suosituksia ja standardeja niin sovellussuunnittelijoille kuin selainteknologioiden kehittäjille luo W3C-konsortion WAI-toiminnan (Web Accessibility Initiative) työryhmä, jonka tuloksena on synnytetty WAI-ARIA-määrittelyt: Accessible Rich Internet Applications Suite.
Verkkopalvelujen saavutettavuudesta (tai esteellisyyksien purkamisesta) on viime aikoina puhuttu paljon, kun joulukuussa 2016 tuli voimaan julkishallinnollisia palveluja koskeva EU:n saavutettavuusdirektiivi. Verkkopalvelujen esteettömyyden tavoittelussa on kuitenkin paljon ajankohtaisempaa tarkastella ja soveltaa noita ARIA-määrittelyjä skriptauksille kuin HTML-koodin WCAG-standardia, joka on ollut sovelluskehittäjien työkaluna jo pitkään.
Mutta tästä olenkin ajatellut kirjoittaa kuluvan kevään aikana ihan erillisen jutun.
Muita käyttöliittymäsuunnittelun perusasioita:
- Mikä vika megamenussa?
- Javaskriptittömien tukeminen ja saavutettavuus
- Tekstikokoa suurennetaan selaimella, ei erillisillä nappuloilla
- Valtion lippu ei ole symboli kielivalinnalle
- Responsiivisen käyttöliittymän hyödylliset sivuvaikutukset: Web sites ARE getting better
