Miten esteettömyyttä testataan?

Sisällysluettelo

Tiivistelmä

Esteettömyyttä kannattaa testata ainakin yksinkertaisilla tavoilla, kuten katsomalla sivua tekstiselaimella ja kokeilemalla tavallisen selaimen erilaisten toiminta-asetusten vaikutusta. Eniten tietoa saadaan, jos sivu käydään huolellisesti läpi tarkistuslistan avulla ja lisäksi käytetään muutamia erilaisia testaajia. Käytännössä näin kattavaan testaamiseen on edellytyksiä vain harvoin. Joidenkin sivujen hyvä testaaminen kuitenkin antaa testaajalle käytännön tuntuman esteettömyyden eri puoliin. Tällöin testaaja osaa myöhemmin varoa ratkaisuja, jotka on havainnut ongelmallisiksi.

Testaamiseen käytettävien ohjelmien avulla voi automatisoida joidenkin asioiden tarkistamisen. Niistä voi olla hyötyä etenkin silloin, kun halutaan tehdä testaus, joka on välimuoto pinnallisen ja perusteellisen testauksen välillä. Vaikka testauksen käynnistäminen on yksinkertaista, niiden antamien tulosten hyödyntäminen vaatii opettelua. Lähinnä kannattaa harkita seuraavia: A-Prompt ja Cynthia Says.

[Kuva, jossa eräs sivu näkyy vain kokoelmana Image-sanoja]
Ruutukaappaus: Erään sivuston pääsivu katsottuna Opera-selaimella ilman kuvia.

Tässä esitellään monia erilaisia testaamisen menetelmiä ja välineitä. Vaihtoehtojen moninaisuus voi hämmentää, mutta kyse on paljolti samantapaisista välineistä eri muodoissa. Tavoitteena on tutustuttaa eri vaihtoehtoihin niin, että lukija voi valita tilanteeseensa sopivimman tai sopivimmat.

Miksi ja missä vaiheessa testataan

Testaus on väline, ei tarkoitus

Testaaminen ei saisi olla itsetarkoitus, olipa kyse esteettömyyden tai jonkin muun asian testaamisesta. Yleensä kannattaa testata vain sellaisessa tilanteessa ja vaiheessa, jonka jälkeen vielä voi korjata havaittuja virheitä ja puutteita.

Tiedon saaminen siitä, että sivu on ainakin joiden perusteiden mukaan arvioiden esteetön, ei paranna sivun laatua. Sivu oli ihan yhtä esteetön ennen arviointiakin. Myöskään tieto siitä, miten sivu ei ole esteetön, ei itsessään muuta mitään. Siitä on hyötyä vain osana prosessia, jossa tietoa käytetään sivun korjaamiseen tai päätökseen sivun tekemisestä uudestaan.

Esteettömyyttä testaamalla oppii

Toisaalta testaaja itse saattaa testaustyössä oppia asioita, joita hän voi myöhemmin soveltaa muissa tehtävissä. Siinä voi oppia sekä käytännöllisiä menettelytapoja, sillä testausohjeisiin usein liittyy korjausohjeita tai testaaja voi itse oivaltaa, miten asiat kannattaa tehdä. Lisäksi siinä saadaan näkemystä siitä, millaisista ongelmista on käytännössä kyse ja miten haitallisia ne voivat olla. Tällaisen oppimisen kannalta on paljon hyödyllisempää arvioida muutamia sivujen perusteellisesti kuin monia sivuja pinnallisesti. Voidaan jopa sanoa, että kun on arvioinut sivuja yksityiskohtaisesti esteettömyyden kannalta, on samalla oppinut näkemään jopa ensi silmäykseltä monia ongelmia ja pystyy siksi tehokkaasti myös pikatestaukseen.

Testauksen opettavaisuus on yksi syy siihen, miksi organisaation kannattaisi pyrkiä tekemään pääosa testauksesta itse eikä ulkoistamaan sitä. Ulkopuolinen apu on kyllä usein hyödyksi, jopa välttämätöntä, varsinkin isoissa hankkeissa. Esimerkiksi vammaisjärjestöissä on asiantuntemusta vammaisuuden eri muotojen ja vammaisten erilaisten apuvälineiden huomioon ottamisesta.

Korjaustarpeen ja -työn arviointi

Testausta voidaan käyttää myös korjaustarpeen ja -mahdollisuuksien arviointiin. Jos harkitaan päätöstä siitä, ryhdytäänkö sivustoa korjaamaan esteettömämmäksi, tarvitaan jonkinlainen arvio siitä, paljonko työtä siihen menee.

Valitettavasti testaus itsessään on työlästä ja tuottaa ensisijaisesti paljon yksityiskohtatietoa. Jos esimerkiksi testattaisiin sivuston kaikki sivut edes yksinkertaisella automaattitestillä, havaittaisiin lähes varmasti, että noin 100 % sivuista ei vastaa edes WAI-suosituksen 1. prioriteettitasoa. Tämä ei välttämättä vielä kerro virheiden vakavuudesta eikä korjaamisen työläydestä.

Korjaustarpeen arviointiinkin sopii usein se periaate, että on parempi testata hyvin muutamia sivuja kuin pinnallisesti suuri määrä sivuja. Usein sivuston sivut on tehty samojen mallien mukaan, jolloin riittää ehkä ottaa testattaviksi pienehkö edustava näyte eli muutamia tyypillisiä sivuja.

Yhden sivunkin testauksen tuloksissa on se ongelma, että kyseessä on yleensä suuri määrä yksityiskohtia. Mitä merkitsee, että sivulla on 80 virhettä tai ongelmaa jonkin tarkistusohjelman mukaan? Osa raportin kohdista on usein jopa virheellisiä, osa täysin epäolennaisia ja loput painoarvoltaan hyvin erilaisia. WAI-suosituksen prioriteettitasot auttavat virheiden merkityksen punnitsemisessa, mutta eivät kovin paljoa, sillä tosiasiallinen merkitys riippuu siitä, miten tärkeässä kohdassa virhe on, mitä se todellisuudessa vaikuttaa eri käyttötilanteissa jne.

Sivujen testauksen yhteydessä tai jälkeen tarvitaan siis ihmisen tekemä huolellinen arviointi, jossa harkitaan ongelmien merkitystä. Vasta tämän jälkeen voidaan esittää perusteltu arvio korjaustarpeesta ja -työstä. Korjaustyön määrä luonnollisestikin riippuu myös mm. sivujen tekemisen tekniikasta.

Mieluummin tulevia kuin vanhoja

Vanhojen sivujen korjaaminen on osoittautunut varsin työlääksi. Usein on nopeampaa suunnitella sivut kokonaan uudestaan kuin korjailla vanhaa. Kovin vanhojen sivujen esteettömyyden testaaminen on usein melko hyödytöntä, paitsi ehkä opiskelumielessä. Vanhoilla sivuilla on usein sisällössäkin paljon korjattavaa ja ulkoasukin ehkä haluttaisiin uusia. Niitä ei kannata ruveta paikkailemaan esimerkiksi esteettömyyden parantamiseksi, jos ne kuitenkin pitää kohta kokonaan uusia.

Toisaalta upouusiakaan sivujakaan ei yleensä kannata testata. Niiden tekijät tuskin haluavat ruveta heti muuttamaan niitä. Usein sivut on tehty projektina, jonka tekijät ovat jo muissa tehtävissä. Organisaatio, joka on juuri teettänyt sivut ehkä hyvinkin kalliilla, ei ole kovin vastaanottavainen tiedolle siitä, että niissä on paljon korjattavaa.

Näin ollen on parasta testata tulevia sivuja! Tämä tarkoittaa, että testataan rakenteilla olevan sivuston koesivuja tai alustavia hahmotelmia, prototyyppejä. Tällöin testauksen tulokset voivat vaikuttaa ehkä hyvinkin paljon itse sivuihin - eikä vain testattuihin vaan koko sivuston suunnittelu- ja toteutustapoihin.

Tulevat sivut voivat olla myös uusittavan sivuston sivuja. Valitettavasti sivuston uusiminen usein merkitsee huononnuksia tai ainakin huonontaa joitakin asioita samalla kuin parantaa joitakin muita. Sivuston uudistusta suunniteltaessa kannattaa ehkä ensin testata nykyistä sivustoa, jos on olemassa jonkinlainen hahmotelma siitä, miten erilainen uusi tulisi olemaan. Sivuston uusimisella voidaan tarkoittaa monenlaisia asioita, ja usein kyse on sivuston yleisen rakenteen ja ulkoasun uusimisesta, kun taas varsinaiset sisältösivut säilyvät suunnilleen samanlaisina. Testauksessa voi siis löytyä piirteitä, jotka on uudistuksessa tarkoitus jättää ennalleen mutta jotka aiheuttavat esteellisyyksiä.

Testaus osana prosessia

Testaus lähinnä osoittaa, missä on ongelmia, ei niinkään sitä, miten ne korjataan. Siksi on varauduttava siihen, että kuluu aikaa ratkaisujen etsimiseen, joka voi vaatia joskus paljonkin miettimistä ja kokeiluja. Korjaus saattaa viedä paljon aikaa myös siksi, että vika on sivuston perusratkaisuissa eikä yksityiskohdissa. Jos ongelmana on esimerkiksi se, että pääsivulla on liikaa aineistoa, tarvitaan isohko remontti, jossa aineistoa siirretään alasivuille.

Mieluiten testaus pitäisi tehdä niin, että virheiden havaitsemisen ja korjaamisen jälkeen tehdään uusi testaus. Ei ole harvinaista, että virheen korjaaminen aiheuttaa uusia ongelmia, joita korjaaja ei ole osannut ennakoida. Esimerkiksi kehysten (frames) käytön poistaminen vähentää kyllä joitakin ongelmia, mutta hyvin usein se tehdään niin, että tulos on alkuperäistä esteellisempi.

Seuraava kaavio pyrkii havainnollistamaan sitä ajatusta, että testaamisessa tavoiteltava tulos ei ole testausraportti vaan parempi sivu:

Testauksesta syntyy raportti, jota arvioidaan. Jos se on hyväksyttävä, sivu julkaistaan. Jos ei, sivua korjataan ja se testataan uudestaan.

Niinpä mitä aiemmin testataan, sen parempi.

Yksinkertainen selaimella testaaminen

Vaikka esteettömyyden testaamiseen on käytettävissä monia erilaisia välineitä, se voidaan aloittaa hyvin yksinkertaisilla tavoilla.

Voit pyrkiä kuvittelemaan itsesi katsomassa sivua erilaisissa tilanteissa ja erilaisten käyttäjien asemassa. Kuvittele, että olisit hiukan hitaampi lukemaan tai näkösi olisi hiukan heikompi tai keskittymiskykysi olisi hiukan huonompi tai väsyisit nopeammin, kun luet hiukankin vaikeaa tekstiä. Mielikuvituksen rajat tulevat helposti vastaan, joskin niitä voi ehkä ylittää ulkonaisilla järjestelyillä kuten se, että toimitaan meluisassa huoneessa tai oikeasti väsyneenä.

Monia hyödyllisiä testejä voidaan kuitenkin tehdä hyvin yksinkertaisesti. Voit esimerkiksi avata sivun millä tahansa selaimella ja kysyä seuraavanlaisia kysymyksiä:

Seuraavassa on ehdotuksia siitä, miten sivua voi testata hiukan teknisemmin mutta silti tavallisen selaimen tavallisia toimintoja käyttäen:

Käsiteltävä esimerkkisivusto, Internetix

Tässä esityksessä havainnollistetaan testauksen periaatteita ja menetelmiä siten, että niitä sovelletaan Internetix-sivustoon http://www.internetix.fi. Esimerkki on valittu paljolti siksi, että Internetix on luonteeltaan sentapaista aineistoa, jonka esteettömyyden kehittämiseen Essi on ensisijaisesti suunnattu, nimittäin verkossa olevaa opiskelu- ja opetusaineistoa. Internetixissä on myös monenlaisia ja aika tyypillisiä ongelmia esteettömyyden kannalta mutta kuitenkin suhteellisen lieviä ja vähäinen määrä, jolloin ongelmia voi järkevästi tarkastella erikseen. Toisaalta käytännön syistä tarkastelu rajoittuu lähinnä Internetixin pääsivuun, joka on sikäli hyvä esimerkki, että siinä on monenlaisia aineksia mutta kuitenkin melko kohtuullinen määrä.

Jotta olisi selvää, millaista sivustoa arvioidaan, on mukaan otettu kopio Internetixin etusivusta ja siihen liittyvistä kuvista sellaisena, kuin aineisto oli 6.10.2003. Tässä vaiheessa on ehkä hyvä avata Internetix-sivun kopio erilliseen ikkunaan, jotta sivua voi verrata tässä esitettäviin testeihin ja tuloksiin.

Parhaan oppimistuloksen saamiseksi kannattaa ensin itse tehdä tässä esitettävät tarkistukset ja sitten verrata omaa arviota "malliratkaisuun". Näin lukija saa tuntuman, jonka pohjalta on helppo itse tehdä omaa harjoittelua tai vaikka omien sivujen järjestelmällistä testausta.

Tehtävä: Arvioi lyhyesti esimerkkisivua sen pohjalta, mitä nyt tiedät esteettömyydestä. Kirjoita esimerkiksi viisi ranskalaista, jotka lyhyesti kuvaavat käsityksiäsi siitä, mitkä sivun piirteet voisivat olla ongelmia. Käytä tähän esimerkiksi kymmenen minuuttia. Kun olet käynyt tämän osuuden läpi, voit arvioida sivua uudestaan ja verrata tulosta nyt tekemääsi. Tähän tehtävään ei tietenkään ole oikeaa vastausta, vain eri ihmisten erilaisia vastauksia, mutta tehtävän tehtyäsi voit verrata sitä esimerkkiarvioon.

Esteettömyyden arvioinnin ohjelmat

Voiko esteettömyyttä arvioida ohjelmalla?

Esteettömyydessä on kyse on ihmisistä, erilaisten ihmisten mahdollisuuksista käyttää verkkosisältöjä ja muista toimintamahdollisuuksista. Millään tietokoneohjelmilla ei voi arvioida tästä moninaisuudesta kuin joitakin puolia ja niitäkin karkeasti. Toisaalta ohjelmien käyttö tarjoaa mahdollisuuksia arvioida sellaisia asioita, jotka muuten jäisivät arvailun varaan. Lisäksi testausohjelmat avaavat uusia näkökulmia, koska ne yleensä testaavat sellaisia ongelmia, joita sivuntekijä ei muuten tulisi edes ajatelleeksi.

Tärkeintä on, että ohjelmat ymmärretään välineiksi. Varsinainen tavoitehan on esteettömyys eli se, että erilaiset ihmiset voivat käyttää sivuja erilaisissa tilanteissa. Esteettömyysohjeet ovat vain välineitä tämän saavuttamiseksi, ja ne ovat väistämättä epätäydellisiä, joskus osittain vanhentuneitakin välineitä. Tarkistusohjelmat puolestaan ovat välineen välineitä eli niillä tarkistetaan esteettömyysohjeiden joidenkin kohtien täyttyminen. Tarkistusohjelmat perustuvat tekijöidensä tulkintaan ja käsityksiin, eivätkä ne voi parhaimmillaankaan kattaa kuin osan esteettömyysohjeista.

Valitettavasti esiintyy jopa sellaista, että sivua muutetaan esimerkiksi "jotta se menisi läpi Bobbysta" silloinkin, kun muutos tosiasiassa heikentää esteettömyyttä. Joskus sivuntekijä joutuu pakkotilanteeseen, jos työnantajan tai tilaajan asettamiin vaatimuksiin sisältyy, että jonkin tarkistusohjelman (tyypillisimmin ehkä juuri Bobbyn) pitää hyväksyä sivut.

Arvioinnin ohjelmien jaottelua

Esteettömyyden arviointiin käytetyt ohjelmat voidaan jakaa kolmeen ryhmään, jotka menevät osittain päällekkäin:

Käytännössä voidaan tarkistusohjelmina pitää sellaisia, jotka tuottavat jonkinlaisen sanallisen esteettömyysarvion, tyypillisesti siitä, missä määrin sivu noudattaa WAI-suosituksen jotakin tasoa. Analysointiohjelmat sen sijaan esittävät raportin sivun eri piirteistä, usein graafisessa muodossa, ja jättävät lukijan tehtäväksi päätellä, mitä tämä merkitsee esteettömyyden kannalta. Käytännössä tarkistusohjelmissa on useimmiten myös analysointipiirteitä ja kääntäen.

Tarkistusohjelmaan saattaa liittyä myös toimintoja, jotka avustavat sivun korjaamisessa. Tällöin ohjelma esimerkiksi ilmoitettuaan jonkin määritteen puuttumisesta pyytää käyttäjää antamaan sille arvon.

Laaja luettelo tarkistusohjelmista on W3C:n sivulla Evaluation, Repair, and Transformation Tools for Web Content Accessibility.

Tekstiselaimet

Tekstiselaimella tarkoitetaan selainta, joka esittää sivun ainakin ensisijaisesti pelkkänä tekstinä. Yleensä tekstiselain käyttää yhtä kiinteää fonttia (kirjasinlajia). Yksinkertaisimmillaan esitysasu vastaa ulkomuodoltaan vanhanaikaista kirjoituskonetekstiä.

Tekstiselainta voi käyttää sivun nopeaan yleisarviointiin. Siinä ilmenee nopeasti mm.

Tekstiselaimen käyttö antaa hyödyllistä tietoa myös siitä, miten sivu suurin piirtein toimii puheselaimella. Kyse on tietysti eri asioista, mutta hyvin karkeasti ottaen puheselaimen käyttö vastaa sitä, että sivua käytetään Lynxillä niin, että puhesyntetisaattori lukee Lynxin esittämän tekstin ääneen. Itse asiassa tällaista menettelyäkin käytetään jossain määrin.

Tavallisin tekstiselain on Lynx, joka on vapaasti saatavissa mm. Windows- ja Unix-ympäristöön. Aiheesta kertovat mm. sivut Lynx-tekstiselain ja Lynx-ohjeita.

Seuraava on näyte esimerkkisivumme alusta Lynxin erään version esittämänä.

                                Internetix
                                 [INLINE]


                        Tekstiversio Oppimateriaali
                         Rekisteröidy
                         Lukio
                         Ammatillinen

Vaikka Lynxiin tutustuminen (ja tarvittaessa sen hankkiminen) on monella tavoin hyödyllistä, sitä ei kuitenkaan tässä yhteydessä vaadita. Lynxin asemesta voidaan nimittäin käyttää Lynx-simulaattoria, Lynx Viewer. Sen käyttö on hyvin helppoa: mennään simulaattorin Web-osoitteeseen ja kirjoitetaan halutun sivun osoite (URL) siellä olevaan kenttään. Simulaattori sitten esittää sivun suunnilleen sellaisena kuin Lynx sen esittäisi.

Tehtävä: Tarkastele esimerkkisivua joko Lynx-ohjelmalla tai Lynx-simulaattorilla. Jos tässä on ylivoimaisia vaikeuksia, voit katsoa erillistä dokumenttia, joka esittää esimerkkidokumentin Lynx-simulaattorilla katsottuna. Arvioi esteettömyyttä erityisesti seuraavilta kannoilta: Jos sivu luetaan alusta loppuun, miten hyvin se toimii? Onko kaikissa kohdissa pelkän tekstin perusteella selvää, missä ollaan? Onko sivulla joitakin kummallisuuksia? Tehtävän tehtyäsi voit verrata sitä Lynx-testauksen esimerkkiarvioon.

Selaimen erilainen käyttö

Tavallistakin selainta, kuten IE:tä, voi monin tavoin käyttää esteettömyyden testaamiseen. Toiminta-asetuksia tai käyttötapaa muuttelemalla voi testata sivun toimivuutta erilaisissa tilanteissa.

Leveys

Niinkin yksinkertainen asia kuin selainikkunan koon muuttaminen paljastaa usein monia ongelmia. Jos sivu ei mahdu vaakasuunnassa puoleen tavallisen tietokonenäytön leveydestä, käyttö hankaloituu, koska käyttäjä ei voi kätevästi pitää sen rinnalla toista ikkunaa, jossa hän esimerkiksi hakee selityksiä vaikeille sanoille. Lisäksi sivu ei silloin toimi pieninäyttöisillä laitteilla kovin hyvin.

Fonttikoko

Jos selaimen käyttämää fonttikokoa muutetaan eikä fonttikoko muutukaan jollakin sivulla, niin sivun lukeminen on hankalaa lievästi heikkonäköisille. (Jos heikkonäköisyys on huomattavaa, niin käyttäjä on luultavasti joka tapauksessa joutunut opettelemaan tavan, jolla ohitetaan kaikki sivulla olevat fonttikokoasetukset.)

Jos taas fonttikoko muuttuu, kannattaa katsoa, mitä sivulle muutoin tapahtuu. Jos sivulla on esimerkiksi tekstiä taulukon solussa, jolle on asetettu kiinteä koko, niin sivun taitto voi mennä sekaisin tavalla tai toisella.

Fonttikokoa muutetaan eri selaimissa eri periaatteilla ja keinoilla. IE:ssä voi valita Näytä-valikon kohdasta "Tekstin koko" jonkin viidestä koosta. Fonttikokojen kokeilua IE:llä helpottaa hiukan, jos kyseistä toimintaa varten asettaa työkaluriville oman painikkeen (Koko). Työkalurivin muokkaus on muutenkin hyvä osata: napsauta hiirellä työkalurivin oikealla puolella olevaa harmaata aluetta, valitse avautuvasta valikosta kohta "Mukauta...", jolloin avautuu ikkuna, jossa voi helposti lisätä tai poistaa työkalurivin painikkeita.

[Kuva sivusta, jolla on normaalia tekstiä isolla fontilla ja sitä ennen pieni taulukko, jonka tekstirivit menevät osittain päällekkäin niin, että luettavuus kärsii.]

Oheinen kuva havainnollistaa, miten tavallisen tekstin esitys mukautuu valittuun fonttikokoon ja selainikkunan leveyteen, ellei mukautumista jotenkin estetä. Esimerkissä on myös pieni taulukko, jolle on käynyt hullusti, kun fonttikokoa on suurennettu. (Syynä on, että taulukossa olevalle tekstille on asetettu pikselimääräinen rivinkorkeus, line-height: 11px. Tällainen on onneksi harvinaista, mutta sitä esiintyy.)

Nykyisin ehkä tavallisin syy taiton sekoamiseen fonttikokoa muutettaessa on CSS-asemointi (positioning). Jos elementtejä asemoidaan alueisiin, joiden sijainti ja koko ilmaistaan pikseleinä, niin niiden tekstisisältö ei mahdu alueeseen, kun fonttikokoa suurennetaan huomattavasti. Tällöin tekstit menevät usein pahastikin päällekkäin. CSS:n poistaminen kokonaan käytöstä voi auttaa, mutta se ei ole esimerkiksi IE:ssä mahdollista millään yksinkertaisella tavalla.

Hiiretön käyttö

Tehtävä: Siirrä tietokoneesi hiiri syrjään niin, että et vahingossakaan ota sitä käteesi. Mene esimerkkisivulle ja käy läpi sen sisältö niin, että seuraat ainakin pari linkkiä ja teet jonkin haun sivun lopussa olevaa lomaketta käyttäen. Tämä voi vaatia muutaman uuden asian opettelemista selaimesta, mutta kyseiset asiat on hyvä opetella muistakin syistä.

Seuraavassa on perustietoja IE:n hiirettömästä käytöstä eli pelkän näppäimistön avulla toimimisesta. Muissa selaimissa perustoiminnot ovat melko samantapaiset.

Valitse ikkuna Alt Tab
Tuo näyttöön IE:n ohje tai valintaikkunassa kohteen pikaohje F1
Siirry koko näytön ja selaimen normaalin näkymien välillä F11
Siirry eteenpäin Web-sivun osissa, osoiterivillä ja linkkirivillä Tab
Siirry taaksepäin Web-sivun osissa, osoiterivillä ja linkkirivillä Shift Tab
Siirry selaimen aloitussivulle Alt Home
Siirry seuraavalle sivulle sivuhistoriassa Alt oikea nuoli
Siirry edelliselle sivulle sivuhistoriassaBackspace
Näytä linkin pikavalikko Shift F10
Siirry seuraavaan kehykseen F6
Siirry edelliseen kehykseen Shift Ctrl Tab
Vieritä sivun alkuun päin ylänuolinäppäin
Vieritä sivun loppuun päin alanuolinäppäin
Vieritä sivun alkuun päin yksi näyttö kerrallaan Page Up
Vieritä sivun loppuun päin yksi näyttö kerrallaan Page Down
Siirry sivun alkuun Home
Siirry sivun loppuun End
Vieritä sivua vaakasuunnassa nuoli oikealle ja vasemmalle
Etsi tältä sivulta Ctrl F
Päivitä nykyinen sivu F5 tai Ctrl R
Päivitä nykyinen sivu, vaikka välimuistissa oleva kopio on tuore Ctrl F5
Lopeta sivun lataaminen ESC
Avaa uusi sivu tai kansio Ctrl O
Avaa uusi ikkuna Ctrl N
Sulje nykyinen ikkuna Ctrl W
Tallenna nykyinen sivu Ctrl S
Tulosta nykyinen sivu tai aktiivinen kehys Ctrl P
Avaa valittu linkki Enter
Avaa valittu linkki uuteen ikkunaan Shift Enter
Avaa etsintäpalkki Ctrl E
Avaa suosikkipalkki Ctrl I
Avaa sivuhistoriapalkki Ctrl H
Sarkain- eli tab-näppäimessä on tyypillisesti oikealle osoittava nuoli ja sen yläpuolella vasemmalle osoittava nuoli.

Sarkain- eli tab-näppäin on siis keskeisessä asemassa. Sitä painamalla siirrytään seuraavaan linkkiin tai lomakkeen kenttään (tai sivun lopusta takaisin osoiteriville). Yhdistämällä se muiden näppäinten käyttöön saadaan aikaan muita toimintoja.

Selaimen asetusten muuttaminen

Selaimissa on suuria eroja sen suhteen, miten helppoa on muuttaa niiden asetuksia. Esimerkiksi IE:ssä voi valita (Näytä-valikon kohdasta "Tekstin koko") viisi erilaista fonttikokovaihtoehtoa. Niilläkin testaaminen on hyödyllistä, mutta muita keinoja tarvitaan, jos halutaan selvittää, miten sivu toimii, kun fonttikoko on hyvin iso (esimerkiksi 36 pistettä).

[Ruutukaappaus IE:n asetuksista]

Eri selainten asetusten muuttaminen on opeteltava erikseen, mutta tässä käydään lyhyesti läpi IE:n eräitä perusasetuksia. Keskeisiä esteettömyyden kannalta ovat ne asetukset, joihin päästään seuraavasti:

  1. Valitaan Työkalut-valikosta
  2. kohta "Internet-asetukset..."
  3. ja välilehti "Yleiset"
  4. ja painike "Muotoiluasetukset" (englanninkielisessä versiossa "Accessibility")

Kyseisistä asetuksista voidaan asettaa selain olemaan noudattamatta sivulla asetettuja värejä, fonttilajeja ja fonttikoon asetuksia. Erikseen on asetettavissa (Internet-asetusten kohdista "Värit" ja "Fontit"), mitä värejä ja fonttilajia selain tällöin käyttää. Fonttikoon asettamisesta mainittiin jo edellä.

Vihje: Tätä asetusten muuttamista nopeuttaa, jos opettelee käyttämään vastaavia näppäinkomentoja. Esimerkiksi Työkalut-valikko avataan Alt K:llä jne., joten vaikkapa värien ohittaminen sujuu näin: painetaan Alt-näppäin alas, sitä alhaalla pitäen näppäillään kimv, päästetään Alt-näppäin ylös ja painetaan kahdesti Enter-näppäintä.

Tarkemmin voi käyttäjä säätää IE:n toimintaa valitsemalla asetuksista kohdan "Käytä asiakirjojen muotoilussa omaa tyylisivua" ja valitsemalla halutun CSS-tiedoston. Tämä tietysti vaatii oman osaamisensa, mutta sen avulla voidaan hyvinkin monipuolisesti tutkia sivun toimivuutta erilaisissa tilanteissa. Aiheesta kertoo sivu Käyttäjän tyylisäännöstö Internet Explorerissa.

Esteettömien sivujen tekemisen kannalta ei ole niinkään tärkeää se, paljonko käyttäjät muuttavat esimerkiksi IE:n asetuksia. Tärkeää on, että asetuksia muuttamalla voi sivuntekijä tutkia sivun toimivuutta monenlaisissa tilanteissa, ikään kuin muuttaen IE:n "erilaiseksi selaimeksi". Lisäksi esimerkiksi sivulla asetettujen värien ohittaminen mahdollistaa sen, että tutkitaan, riippuuko sivun toimivuus ratkaisevasti värien näkemisestä - ilman, että itse sivuun tarvitsee koskea.

[Kuva, jossa tekstejä on mennyt päällekkäin]
Kuva: Ote eräästä sivusta, jonka ulkoasu sekoaa, kun fonttikoko asetetaan isoksi.

Erityisen olennainen kohta tässä käsitellyissä asetuksissa on kohta "Ohita Web-sivuilla määritetyt fonttikoot". Tämä johtuu siitä, että hyvin monille ihmisille on olennaista, että he voivat lukea sivua käyttäen itse valitsemaansa fonttikokoa. Jos sivun taitto on suunniteltu olettaen, että sivun tekijän haluama fonttikoko on käytössä, voi sivu muuttua lukukelvottomaksi siksi, että tekstit eivät mahdu niille varattuihin tiloihin.

Tehtävä: Valitse jokin portaalityyppinen sivu, esimerkiksi MTV3:n sivu. (Internet-esimerkkisivummekin on mahdollinen valinta, mutta siltä ei tässä tehtävässä tutkimuksessa löydy kovin isoja ongelmia.) Tutki, millaiseksi se muuttuu, kun edellä kuvatulla tavalla ohitetaan sivulla asetetut värit, fonttityylit ja koot, mieluiten ensin kukin erikseen ja sitten vielä yhdessä.

JavaScriptin poisto käytöstä

Joskus sivun toiminnallisuus perustuu olennaisesti JavaScript-koodiin. Tätä asiaa voi testata estämällä Javascript-koodin suorituksen selaimessa. IE:ssä tämä voidaan tehdä seuraavasti: Työkalut → Internet-asetukset… → Suojaus, sitten valitaan "Internet" ja napsautetaan painiketta "Mukautettu taso…", ja kohdassa "Komentosarjat", alakohdassa "Salli aktiiviset komentosarjat" valitaan vaihtoehto "Poista käytöstä".

Tyypillisiä (ja haitallisimpia) ongelmia, joita JavaScript-riippuvuudesta voi aiheutua, on se, että jotkin linkit lakkaavat toimimasta tai lomakkeen lähettäminen on mahdotonta.

Erikoisselaimet

"Erikoisselain" on epämääräinen käsite, jolla tarkoitetaan tässä väljästi sellaisia selaimia, jotka joissakin olennaisissa suhteissa poikkeavat tavallisimmin käytetyistä selaimista kuten Internet Explorer ja Netscape. Esimerkiksi Lynxiä voidaan pitää erikoisselaimena.

Seuraavassa kuvataan lyhyesti eräitä erikoisselaimia. Tietoja muista löytyy esimerkiksi sivun "Brand-X" Browsers kautta.

Opera

Opera on graafinen selain, joka on tarkoitettu ensi sijassa normaaliin selailuun. Erikoisselaimeksi se voidaan lukea ennen muuta siksi, että sen toiminta-asetuksia voi muuttaa helposti, enimmäkseen myös "lennosta", käytön aikana. Lisäksi toiminta-asetuksia voi muuttaa varsin monipuolisesti.

Operan saa osoitteesta http://www.opera.com, ja siitä on myös suomenkielinen versio. Sen käytössä on apua Opera-VUKK:sta.

Operan sisällä saa control-B:llä esille ikkunan Näppäinoikotiet Operassa. Siinä kuvatut menetelmät helpottavat niin esteettömyyden testausta kuin muutakin selailua.

Operalla voi ensinnäkin tehdä varsin kätevästi ne testit, jotka edellä kuvattiin. Esimerkiksi Javascriptin kytkeminen pois käytöstä tai käyttöön sujuu (suomenkielisessä Operassa) painamalla ensin F12-toimintonäppäintä ja sitten s-näppäintä. Mutta lisäksi Operalla voi tehdä testejä, joita ei kuvattu edellä, koska niiden tekeminen muilla selaimilla on usein varsin hankalaa tai mahdotontakin:

Puheselaimet

Puheselaimet ovat tärkeitä paitsi siksi, että ne ovat monille lähes ainoa tapa käyttää Web-sivuja, myös siksi, että tekstiä kuunneltaessa huomaa paljon tekstin ja rakenteen ongelmia. Kun ihminen lukee ruudulta omaa tekstiään, hän on usein sokea omille virheilleen, esimerkiksi raskaille lauserakenteille. Kuunneltaessa havaitaan myös kirjoitusvirheitä. Mutta sivuntekijälle puheselain antaa ennen muuta ahaa-elämyksiä siitä, millaista sivujen käyttö voi olla ja miten tämä kannattaa ottaa huomioon.

Puheselaimia on monia erilaisia. Näkövammaisten yleisesti käyttämät välineet ovat usein maksullisia ja kalliitakin, koska ne ovat varsin monipuolisia. Mutta yksinkertaisillakin puheselaimilla saa tuntuman asiaan ja voi myös käyttää sivuja uudella tavalla.

Puheselain sanan suppeassa merkityksessä tarkoittaa selainta, johon on erikseen toteutettu ääniesitys. Toisentyyppinen lähestymistapa, joka usein sopii näkövammaisille paremmin, on ns. ruudunlukuohjelma, joka pystyy lukemaan ääneen tekstejä, joita eri ohjelmat tulostavat kuvaruudulle. Täten sitä voi käyttää selaimen, tekstinkäsittelyohjelman, käyttöjärjestelmän ym. yhteydessä.

Suomessa käytetään tällä hetkellä lähinnä kahta ruudunlukuohjelmaa. JAWS on Freedom Scientific -yhtiön Yhdysvalloissa kehittämä tuote, jota käyttävät pääasiassa sellaiset näkövammaiset, joilla on Windows-kone työssään tai opiskelussaan. HAL (ja siihen liittyvä Supernova) on brittiläisen Dolphin-yhtiön tuote, joka on lähinnä kotikäytössä.

Esimerkiksi Windows-ympäristöön ovat maksutta saatavilla ääniselaimet Simply Web, Sensus ja Web Talkster. Nämä puhuvat englantia melko hyvin mutta eivät osaa suomea lukevat kaiken ikäänkuin se olisi englantia.

IBM:n Home Page Reader osaa suomeakin, samoin eräitä muita kieliä, mutta se on maksullinen. Toisaalta siinä on maksuton 30 päivän kokeilukausi, jonka aikana voi saada jo aika hyvän tuntuman siihen, millaista puhesyntetisaattorin käyttö on. Samalla voi testata ja korjailla Web-sivujen keskeisimpiä osia.

Puheselainten puhenopeus on yleensä säädettävissä. Käyttäjä tottuu suhteellisen nopeasti kuuntelemaan paljon nopeampaa puhetta kuin normaalipuhe. Oletusnopeus on melko pieni, mutta sitä kannattaa siis ruveta nostamaan asteittain.

Simulointiohjelmat

Ihmisten aistien ja havainnointitilanteiden erilaisuuden vaihtelua voi jossain määrin jäljitellä ohjelmilla. Esimerkiksi värisokeuden vaikutusta voi testata Vischeck-ohjelmalla. Yksinkertaisimmassa käyttötavassa sitä käytetään verkon kautta siten, että sille annetaan sivun osoite ja se esittää sivun sellaisena, kuin esimerkiksi punavihervärisokea saattaisi sen nähdä. Ohjelma on valitettavasti vielä osittain keskeneräinen.

Erikoisselainten kokeilu

Tehtävä: Valitse edellä olevien kuvausten perusteella jokin mainituista erikoisselaimista ja testaa esimerkkisivu sillä. Tämä edellyttää yleensä mahdollisuutta asentaa omaan koneeseen erikoisselain, joten tehtävän voi joutua jättämään suorittamatta. Tehtävään ei ole malliratkaisuja, mutta voit verrata tuloksia muissa testaustehtävissä saavuttamiisi. Tuliko esille joitakin sellaisia asioita, joita muut testit eivät paljastaneet?

Cynthia says

Cynthia says on verkossa oleva palvelu, jolle annetaan tarkastettavan sivun sisältö ja joka sitten laatii ja esittää raportin sivusta. Oletusasetuksena on, että tarkistus tapahtuu Section 508 -sääntöjen mukaan, ja tämän tilalle on hyvä vaihtaa WAI-ohjeen jokin taso. Seuraavassa on tämän mukainen yksinkertaistettu käyttöliittymä:

Käyttöliittymä on siis aika helppo, mutta raportin lukeminen ja tulkitseminen on hankalampaa. Raportti sisältää (WAI-ohjeen mukaista tarkistusta käytettäessä) taulukon, jonka kukin rivi vastaa WAI-ohjeen yhtä alakohtaa (checkpoint). Mukana ei ole kaikkia alakohtia, eivätkä alakohdat ole WAI-ohjeen mukaisessa järjestyksessä Seuraavassa on erään raportin alkua:

[Ote Cynthian raportista]

Raportin ensimmäisessä sarakkeessa on itse alakohdan kuvaus ja joukko sääntöjä (rule), jotka ovat ohjelman tekijöiden tulkintoja siitä, miten alakohdan noudattamista voi testata. Joskus tulkinnat ovat erikoisia. (Esimerkistä näkyy ensimmäinen omituisuus: säännön 1.1.1 mukaan pitää olla alt- tai longdesc-määrite, vaikka jo HTML:n määrittely asettaa alt-määritteen käytön ehdottomaksi vaatimukseksi.) Tässä solussa on myös tietoja testauksesta, kuten säännön 1.1.2 kohdalla tieto siitä, ettei sivulta löytynyt lomake-elementtejä. Tällainen monisanaisuus on melko tyypillistä tarkistusohjelmille, ja siksi olennaisten kohtien tunnistaminen niiden raporteista vaatii pientä harjaantumista. Mukana voi myös olla varoituksia, kuten tässä säännön 1.1.1 alla varoitus alt-määritteestä, jonka arvo on tyhjä merkkijono. Varoitus on usein aiheellinen, mutta se voi joskus jopa johtaa harhaan.

Raportissa on kolme muuta saraketta yhteisen otsikon "Passed" alla. Vaihtoehdot ovat:

Raportin lukeminen vaatii siis kriittisyyttä. Jos tehdään kaikkien prioriteettitasojen testaus, niin raportti sisältää Warning-ilmoituksen (siis väitteen virheestä) mm. jokaisesta linkistä, jossa ei ole sekä tabindex- että accesskey-määritettä. WAI-suositus ei vaadi sellaista, eikä kyseisten määritteiden lisäämisestä useimmiten ole mitään hyötyä, sen sijaan mahdollisesti haittaa.

A-Prompt

A-Prompt on perusidealtaan erinomainen ohjelma: se auttaa sekä havaitsemaan että korjaamaan ongelmia. Valitettavasti sen kehittäminen lienee lopetettu. Se on kuitenkin vakavimmin otettavia tarkistusohjelmia.

Toisin kuin monia muita tarkistusohjelmia, A-Promptia ei voi käyttää verkon kautta, vaan se on kopioitava omaan koneeseen. Sen ilmoitetaan toimivan seuraavissa ympäristöissä: Windows 95/98/NT/2000.

Mitä A-Prompt tekee

A-Prompt tekee suuren joukon testejä, jotka vastaavat WAI-ohjeen eri alakohtia. Testauksen laajuutta voi jossain määrin säädellä.

Kuitenkaan A-Prompt ei, kuten ei mikään muukaan testausohjelma, tarkista likikään kaikkia alakohtia eikä myöskään testaa useimpia alakohtia kattavasti. Se on siis virheiden etsinnän väline, ei väline, jolla voitaisiin todistaa sivu WAI-ohjeen mukaiseksi.

A-Prompt on myös väline sivun korjaamiseen. Ilmoitettuaan virheestä se myös yleensä tarjoaa mahdollisuuden korjata se. Käyttäjän tekemien valintojen ja hänen antamiensa tietojen mukaisesti A-Prompt muuttaa itse sivua, sen HTML-merkkausta ja sisältöä. Muutettu sivu voidaan tallentaa samalla nimellä kuin alkuperäinen tai uudella nimellä.

Miten A-Promptia käytetään

A-Prompt on maksuton ohjelma, jonka saa osoitteen http://aprompt.snow.utoronto.ca kautta. Kyseisellä sivulla on linkki "Download", joka vie sivulle, jolla on lataus- ja asennusohjeet. Ladattavan tiedoston koko on noin 3,4 megatavua. Tiedosto on zipatussa muodossa, joten ohjelman asentamiseen tarvitaan sopiva zippausohjelma, esim. WinZip.

Kun A-Prompt on asennettu, sitä käytetään seuraavasti:

  1. Varmista, että sinulla on kohtalaisesti aikaa, esimerkiksi puoli tuntia, sillä tiedoston tarkistusta A-Promptilla ei kannata jättää kesken. (Jos jätät sen kesken, voit kyllä tallentaa tiedoston korjatussa muodossa, mutta jatkaessasi tarkistusta myöhemmin joudut tekemään uudestaan asioita, jotka olet jo tehnyt.)
  2. Jos tutkittavat tiedostot eivät ole oman koneesi kovalevyllä, kopioi ne sinne (esimerkiksi IE:n Tiedosto-valikon kohdan Tallenna nimellä -vaihtoehdon kautta).
  3. Avaa tutkittava tiedosto johonkin selaimeen. Tämä auttaa hahmottamaan tilannetta, sillä A-Prompt esittää sivusta vain yksityiskohtia, ja monissa korjauksissa on tarpeen nähdä kokonaisuus.
  4. Valitse A-Prompt Windowsin Käynnistä-valikosta.
  5. Kun ohjelma käynnistyy, se aluksi esittää tiedostonvalintaikkunan. Valitse tutkittava tiedosto.
  6. Jos tiedostossa on taulukoita, A-Prompt kysyy jokaisesta, onko se datataulukko vai taittotaulukko. Valitettavasti tämä toistuu aina, kun tarkistat tiedostoa, eli A-Prompt ei tallenna antamaasi tietoa muuten kuin tarkistuksen ajaksi.
  7. A-Prompt esittää nyt listan havaitsemistaan ongelmista. Esimerkki:
    [A-Promptin raportti]
  8. Ensimmäisellä kerralla käyttäessäsi A-Promptia napsauta Settings-painiketta ja tarkista, että
    • Conformance Level -välilehdellä on valittuna AAA-taso (ellet halua tehdä suppeampaa tarkistusta)
    • Automatic Repairs -välilehdellä on kaikissa kohdissa OFF (sillä kyseiset automaattiset korjaukset aiheuttaisivat yleensä enemmän hämminkiä kuin hyötyä)
    • Saving Files -välilehdellä on valittuna "Allow user to select a name for the repaired file" (jonka haluat ehkä myöhemmin vaihtaa toisenlaiseksi asetukseksi, kun olet saanut kokemusta A-Promptin käytöstä)
  9. Napsauta oikealla olevassa listassa olevaa ongelman lyhyttä kuvausta (esim. "Color contrast low"), jolloin A-Prompt avaa ikkunan, jossa voit korjata ongelman. Korjaamisen tapa riippuu ongelmasta, mutta lopuksi napsautetaan painiketta "Repair". Ongelmat voit käydä läpi haluamassasi järjestyksessä, mutta selvintä on yleensä edetä listan alusta loppuun. Jäljempänä on vinkkejä erityyppisten ongelmien korjaamisesta.
  10. Kun olet tarkistanut kaikki kohdat, napsauta Done-painiketta. A-Prompt kysyy, mille nimelle haluat tallentaa muutetun tiedoston. Nimeä se siten, että osaat mielessäsi helposti yhdistää sen alkuperäiseen tiedostoon.
  11. Tulet nyt takaisin A-Promptin tiedostonvalintavalikkoon. Voit valita seuraavan tiedoston tai lopettaa napsauttamalla Quit-painiketta.
  12. Käytä tarvittaessa jotakin sivunteko-ohjelmaa korjataksesi ne havaitut virheet, joita A-Promptissa ei voinut korjata (esimerkiksi taulukoiden rakenteen muuttaminen).
  13. Tarkista, miltä korjattu sivu näyttää selaimessa.
  14. Nyt voit esimerkiksi siirtää korjatun sivun vanhan tilalle Web-palvelimeen. Yleensä kannattaa ottaa talteen kopio vanhasta joksikin aikaa.

Vinkkejä A-Promptin käyttöön

Jos jonkin ongelman korjaaminen A-Promptilla ei näytä selvältä, napsauta Help-painiketta. Tällöin pääset A-Promptin laajaan dokumentaatioon, joka kertoo ongelman luonteesta ja sen korjaamisesta.

Seuraavassa on neuvoja joidenkin ongelmien korjaamisesta. Otsikot viittaavat A-Promptin antamiin ilmoituksiin.

Color contrast low

A-Prompt tarjoaa mahdollisuuden korjata liian pieni värikontrasti. Tässä asetetaan taustan, tekstin ja eri tiloissa olevien linkkien värit. On syytä katsoa, että värit muodostavat järkevän kokonaisuuden ja sopivat sivun luonteeseen, joten itse sivun katseleminen rinnalla on tarpeellista.

Joissakin tilanteissa joudutaan käymään läpi suuri joukko elementtejä, joita ongelma koskee, ja tekemään niille samantapaisia toimintoja. Kannattaa opetella näppäinkomentojen käyttö eli Alt-näppäimen ja kirjainnäppäinten käyttö hiiren käytön vaihtoehtona, koska näppäintekniikalla nämä rutiinitehtävät sujuvat nopeammin. Yleensä Alt-näppäin yhdessä kirjainnäppäimen kanssa vastaa sitä vaihtoehtoa, jonka nimessä kyseinen kirjain on alleviivattuna, eli jos ruudulla näkyy esim. "The image is not complex enough to require a 'longdesc'" (T alleviivattuna), niin Alt+t valitsee kyseisen vaihtoehdon. Vastaavasti Alt+r vastaa Repair-painikkeen napsauttamista.

DOCTYPE missing

Yleensä kannattaa valita Transitional-vaihtoehto. (Frameset-vaihtoehto valitaan vain, jos kyseessä on kehyksiä käyttävän sivuston pääsivu, kehikko- eli frameset-sivu, valitaan.)

Doctype-määrittelyn lisääminen voi vaikuttaa siihen, miten selaimet näyttävät sivun. Periaatteessa muutos merkitsee sitä, että selain toimii standardinmukaisemmin, mutta se voi aiheuttaa yllätyksiä sivun ulkoasussa. Aihetta kuvaa dokumentti Doctype switching and standards compliance.

Flicker should be avoided

Käy eri objektit (kuvat) läpi ja tarkista silmämääräisesti, että mikään ei ole välkkyvä, ja valitse kohta "This object does NOT flicker".

Image missing alt text

Nämä on tietysti kaikki korjattava. Mutta A-Promptin ohjeet siitä, millaiset alt-tekstit ovat sopivia, ovat osittain aivan harhaanjohtavia, joten tekstien sopivuus on syytä harkita itse muita ohjeita käyttäen. A-Promptissa alt-teksti kirjoitetaan sellaisenaan, ilman lainausmerkkejä.

A-Prompt ei anna asettaa alt-tekstiä tyhjäksi, vaikka sellainen on usein oikea (ja A-Promptin ohjeessakin) mainittu vaihtoehto. Käytännössä pelkkä välilyönti on usein suunnilleen yhtä hyvä vaihtoehto, ja sen A-Prompt hyväksyy. Tarvittaessa voi erikseen sivunteko-ohjelmalla korjata määritteet alt=" " määritteiksi alt="".

Image missing descriptive text

Tässä käsitellyt tekniikat ovat luonteeltaan lähinnä teoreettisia. Valitse kohta "The image is not complex enough to require a 'longdesc'".

Language not identified

Tämä tarkoittaa, että html-elementistä puuttuu lang-määrite, joka ilmoittaa sivulla olevan tekstin (pääasiallisen) kielen. A-Prompt tarjoaa kyllä kätevän valikon, josta voi valita kielen, mutta sen tuottama HTML-merkkaus sisältää vääränlaisen kielikoodin, nimittäin kolmimerkkisen koodin (esim. fin = suomi), vaikka HTML:n määrittelyn mukaan tulee käyttää kaksimerkkistä koodia (esim. fi = suomi), jos sellainen on. Asia ei ole käytännössä kovin tärkeä, mutta se on hyvä korjata muokkaamalla sivua jälkeenpäin (tai etukäteen) sivunteko-ohjelmalla.

Link text may not be meaningful

Tässä A-Prompt on arvioinut linkkitekstejä. Se esittää sivun linkkien listan, ja siitä on hyvä tarkistaa, että linkkitekstit ovat järkeviä. Erityisesti A-Prompt merkitsee linkkitekstin eteen punaisen rastin ×, jos se pitää tekstiä erityisen epäilyttävänä. Nämä linkit on ainakin syytä tarkistaa. Erityisesti ei sivulla pitäisi olla kahta linkkiä, joissa on sama linkkiteksti mutta eri kohde. (Tämä sisältyy WAI-ohjeen alakohtaa 13.1 tarkentavaan tekniseen ohjeeseen Link text.) Valitettavasti A-Promptissa voi korjata vain linkkitekstin, ei kohdetta. (Useinkin ongelmana on se, että kohteet ovat perimmältään samat, URLit vain on kirjoitettu eri tavoin.).

Manual checks

Tässä kohdassa A-Prompt käytännössä vain muistuttaa asioista, joita se ei tarkista ja joita sillä ei voi korjata.

Sound file missing text transcript

Tämä ilmoitus johtuu usein A-Promptin tekemästä väärästä arvauksesta. Se esimerkiksi päättelee, että jos linkki viittaa osoitteeseen, joka on .php-loppuinen, niin kyseessä on äänitiedosto!

TABLE (layout) may not linearize properly

Tässä kohdassa voi arvioida, miten hyvin taittotaulukoiksi ilmoitetut taulukot linearisoituvat: taulukkoa voi katsoa solu solulta. Tämä vastaa sitä, miten taulukko toimii puhe-esityksessä tai monissa tekstiselaimissa.

Tässä toiminnossa ei voi tehdä korjauksia, vaan havaitut ongelmat on erikseen korjattava jollakin sivunteko-ohjelmalla.

TABLE missing summary

Tämän A-Prompt esittää myös taittotaulukoista. Monien asiantuntijoiden mielestä taittotaulukoille ei pidä kirjoittaa summary-määritettä. Lisäksi kyseisellä määritteellä on muutenkin melko vähäinen merkitys.

Bobby

Mitä Bobby testaa

Myös Bobby tekee joukon esteettömyystarkistuksia, jotka vastaavat osittain WAI-ohjeen tai Section 508:n sääntöjä. Yksityiskohdissa on eroja eri tarkistusohjelmien (A-Prompt, Bobby ym.) välillä. Erot perustuvat mm. ohjeiden erilaiseen tulkintaan ja erilaisiin tapoihin muuntaa yleisiä ohjeita teknisiksi säännöiksi.

Bobby antaa tietoja päätelmien tekemistä varten, ei valmista analyysia. Vaikka sen raportti sisältää lausuman hyväksymisestä tai hylkäämisestä, raportti osoittautuu tarkemmin luettaessa hyvinkin ehdolliseksi: Bobby "hyväksyy" sivun, jos käyttäjä on tarkistanut kaikki Bobbyn ilmoittamat ns. user checks -kohdat eli käytännössä ne esteettömyysohjeisiin kuuluvat säännöt, joiden noudattamista Bobby ei ole mitenkään tarkistanut.

Lisäksi Bobby saattaa antaa aivan harhaanjohtavia ilmoituksia. Jos sivulla esimerkiksi ei käytetä <head>-tägiä, Bobby antaa virheilmoituksen title-elementin puuttumisesta. Kuitenkaan <head>-tägi ei ole esimerkiksi HTML 4:ssä pakollinen, eikä sen puuttuminen vaikuta mitään title-elementin toimivuuteen.

Miten Bobbya käytetään

Bobby on käytettävissä maksutta verkon kautta sivulla http://bobby.watchfire.com/bobby/. Sivun lähettäminen tarkistettavaksi on helppoa: kirjoitetaan lomakkeen kohtaan sivun osoite ja napsautetaan Lähetä-painiketta. Vastauksen tulkitseminen on hankalampaa.

Tarkistusten lajiksi on valittavissa jokin WAI-tasoista (AAA, AA tai A) tai Section 508 -säännöt. Oletuksena on WAI-taso AAA, joka on yleensä sopiva, koska raportissa on ilmoitukset ryhmitelty prioriteettitasojen mukaan. On kätevämpää saada kerralla kaikki ilmoitukset ja sitten haluttaessa käsitellä niistä vain osa, ainakin aluksi.

Bobbyn maksuttoman version käyttöä on rajoitettu siten, että käyttäjä saa tehdä vain yhden tarkistuksen minuutissa.

Miten Bobbyn raporttia luetaan

Bobbyn raporttisivun ulkoinen otsikko (title-elementin sisältö) on hiukan hämmentävästi testatun sivun ulkoinen otsikko sellaisenaan. Täten selaimen yläpalkissa näkyy esimerkiksi "Internetix Campus" eikä esimerkiksi "Bobby report on Internetix Campus".

Bobbyn raportti (ks. esim. Bobbyn raporttia esimerkkisivustamme) koostuu seuraavista osista (joista osat 1 - 4 joissakin tilanteissa puuttuvat):

  1. Bobbyn tunnus ja logo.
  2. Linkki "Skip to report", joka viittaa varsinaisen raportin alkuun.
  3. Tieto testatun sivun osoitteesta, testaushetkestä, Bobbyn versiosta ja testausasetuksista (WAI-ohjeen jokin taso tai Section 508).
  4. Huomautus, joka hiukan epäselvästi kertoo, että Bobby on poistanut kaikki tyyliohjeet ja skriptit. Tämä tarkoittaa, että kun Bobby seuraavaksi esittää testatun sivun varustettuna Bobbyn merkinnöillä, sivu näkyy ilman sivulla mahdollisesti olevien tyyliohjeiden ja skriptien vaikutusta. Tästä seuraa, että jos sivun ulkoasun muotoiluun on käytettu CSS:ää, sivu näkyy toisenlaisena kuin on tarkoitus, mutta jos on käytetty HTML:n ulkoasupiirteitä, niin niitä Bobby ei ole poistanut. Tämähän merkitsee, että jos sivu näkyy ulkoasultaan halutunlaisena (eikä haluttu asu satu vastaamaan selaimen oletusarvoja), niin ulkoasuasetuksia ei ole tehty WAI-ohjeissa suositellulla tavalla!
  5. Testattu sivu, esitettynä edellä sanotun mukaisesti. Kysymysmerkit, joita on usein paljon, osoittavat kohtia, joista Bobbylla on jotain huomauttamista. Kukin kysymysmerkki on linkki itse huomautukseen. (Tämä muuten rikkoo WAI-ohjeen alakohtaa 13.1 vastaan.)
  6. Otsikko "About this report" ja sen alla olevan tiedon siitä, onko Bobby hyväksynyt sivun. Tässä käytetään sellaisia ilmaisuja kuin "Bobby AAA Approved". Usein sen tulkitaan tarkoittavan samaa kuin WAI-suosituksen mukaisuus AAA-tasolla, mutta näin ei ole eikä sitä tarkkaan ottaen edes väitetä. Toki tavoitteena on ollut vastaavuus, mutta Bobby ei tarkista kaikkia WAI-suosituksen alakohtia eikä ole suinkaan selvää, että Bobbyn tulkinta kaikista kohdista on oikea.
  7. Yksityiskohtaiset huomautukset, jaoteltuina prioriteettitasoittain. Erittäin olennainen on huomautusten jako kolmeen osaan kullakin prioriteettitasolla:
    • Virheilmoitukset, joita edeltää teksti "This page does not meet the requirements - -". Nämä ovat Bobbyn arvioita siitä, että sivulla oleva kohta rikkoo suosituksia (jonkin tason WAI-suositusta tai Section 508 -sääntöjä, sen mukaan, millainen tarkistus on valittu).
    • Otsikon User checks alla on huomautuksia asioista, joita Bobby ei ole tarkistanut mutta jotka pitäisi tarkistaa. Näitä on raportissa aina mukana, ja ne jakautuvat kahteen osaan:
      • huomautukset, jotka Bobby esittää vain, jos sivulla on jotain, joka "laukaisee" ilmoituksen, esimerkiksi värien käyttöä, joka saa Bobbyn huomauttamaan värien käyttöä koskevista säännöistä
      • yleiset huomautukset, jotka Bobby esittää aina.

Viimeksi mainitun tyyppisiä, jokaisessa raportissa toistuvia huomautuksia monet pitävät hyödyttömänä nalkutuksena. Myös toisen ryhmän huomautukset ovat usein asiallisesti samantapaisia, jos niihin ei liity mitään rivinumerotietoa siitä, mikä ne on "laukaissut".

Joissakin tilanteissa toisen ryhmän huomautukset ovat hyödyllisiä, koska niiden avulla voi tutkia, missä sivun kohdissa esiintyy rakenne, jota jokin tarkasteltava ohje koskee. Tosin sivunumerot eivät aina ole järjestyksessä ja joskus niitä on kovin paljon. Esimerkiksi seuraavanlainen ilmoitus on sikäli harhaanjohtava, että Bobby siinä viittaa kaikkiin riveihin, joilla esiintyy <table>-tägi. Google ei siis ole analysoinut, onko kyseessä sellainen taulukko, jota ohjeessa tarkoitetaan.

  1. If a table has two or more rows or columns that serve as headers, use structural markup to identify their hierarchy and relationship. (15 instances)
    Lines 57, 97, 117, 162, 178, 158, 228, 151, 269, 288, 317, 347, 44, 35, 28

Linkit tällaisissa ilmoituksissa viittaavat Bobbyn dokumentaatiossa oleviin selitys- ja ohjesivuihin. Nämä sivut sisältävät usein hyvää, käytännönläheistä neuvoa kyseessä olevan ongelman tarkastelusta ja korjaamisesta. Kunkin tällaisen sivun lopussa on myös linkki siihen WAI-ohjeen alakohtaan, jota Bobbyn mielestä on rikottu. Tämä osittain korjaa sitä puutetta, että Bobbyn varsinainen raportti ei yksilöi sitä, mihin WAI-sääntöön mikin ilmoitus liittyy.

Tehtävä: Testaa esimerkkisivu Bobbylla. Käytä oletusasetusta eli tarkistusta WAI-ohjeen AAA-tason mukaan. Mitkä sen ilmoituksista ovat virheilmoituksia ja miten arvioit niiden aiheellisuutta? Missä määrin ilmoitukset auttavat paikantamaan ja korjaamaan virheet? Tässä on siis kyse vain niistä ilmoituksista, jotka Bobby esittää virheilmoituksina. Tehtyäsi tehtävän vertaa omaa arviotasi malliratkaisuun Bobbyn raportin arvioinnista.

Tarkistusohjelmien käytön ongelmia

Tarkistusohjelmien käytön perusongelma on se, että niiden luullaan tekevän enemmän kuin ne tekevät. Lisäksi niiden antamia ilmoituksia saatetaan soveltaa tarkistamatta, ovatko ne perusteltuja tai edes oikeita.

Tähän ei riitä ratkaisuksi todeta, että tarkistusohjelmissa on rajoituksia. Kuten edellä esitetystä ilmenee, ei voida edes sanoa, että ne testaavat suurimman osan esteettömyysasioista ja käyttäjälle pieni täydentävä osa. Itse asiassa ne testaavat vain osan esimerkiksi WAI-ohjeista ja enimmäkseen vain joiltakin kannoilta.

Realistinen asenne onkin, että tarkistusohjelmat ovat parhaimmillaankin vain apuvälineitä, joilla automatisoidaan osa tarkistuksia. Asian luonteesta johtuu, että nämä piirteet ovat suhteellisen teknisiä. Tarkistusohjelmat eivät tee mitään sellaista, mitä ihminen ei voisi tehdä - ne vain saattavat tehdä joitakin asioita hiukan tehokkaammin ja tarkemmin.

Artikkelissa Notes on some tools for checking and improving Web page accessibility on luokiteltu esteettömyysohjeet periaatteellisen automaattisen tarkistettavuuden kannalta neljään ryhmään:

  1. Täysin tarkistettavissa. Tällaisia kohtia on vähän, ja ne ovat luonteeltaan teknisiä, kuten ohje, jonka mukaan tulee käyttää määrättyä HTML:n versiota.
  2. Osittain tarkistettavissa. Automaattinen analyysi voi (luotettavasti) antaa tuloksen, jonka mukaan sivu ei noudata jotakin ohjeen kohtaa, mutta se voi antaa tulosta, jonka mukaan sivu noudattaa ohjeen kohtaa. Tällainen on esimerkiksi vaatimus kuvien tekstivastineista. Jos img-elementillä ei ole lainkaan alt-määritettä, ohjetta on rikottu. Mutta määritteen olemassaolo ei tietenkään takaa, että se on todella ohjeen mukainen sisällöltään oikea vaihtoehto kuvalle eikä jotain täysin hyödytöntä kuten "djgf.jpg (3769 bytes)".
  3. Tarkistettavissa varoituksia varten. Tällöin automaattisella analyysilla ei voida päätyä sen enempää siihen, että sivu noudattaa ohjeen kohtaa, kuin siihenkään, että se ei noudata ohjeta, mutta voidaan silti antaa hyödyllinen varoitus. Esimerkki: Yksi ohjeista sanoo, että tulisi olla tapa hypätä Ascii-grafiikan yli. Automaattinen analyysi ei voi varmasti todeta, että sivulla on Ascii-grafiikkaa, mutta käyttäjää voidaan varoittaa mahdollisista ongelmista (alkeellisimmillaan esimerkiksi kaikista pre-elementeistä, sillä pre-elementti on tavallisin tapa esittää Ascii-grafiikkaa).
  4. Ei tarkistettavissa. Usein esteettömyysohjeen kohta on sellainen, että automaattisella analyysilla ei voida sanoa oikeastaan mitään hyödyllistä siitä, noudattaako sivu ohjetta vai ei. Tämä tosin riippuu osittain myös tekniikan tasosta. Esimerkiksi vaatimus mahdollisimman yksinkertaisesta kielestä on hyvin hankala testata, mutta tekstin ulkonaisiin piirteisiin (virkkeiden ja sanojen pituus yms.) perustuva analyysi voisi tuottaa hyödyllisiä suuntaa-antavia tuloksia.

Toisin kuin usein luullaan, ensimmäiseen ryhmään (automaattisesti täysin tarkistettavissa olevat asiat) kuuluu vain pieni osa esteettömyysohjeista. Ohjeiden useimpien kohtien osalta ei voida tietokoneohjelmalla saada muuta kuin avustavaa tietoa, jonka perusteella ohjeen merkityksen ymmärtävä ihminen voi ratkaista, miten hyvin kohdan vaatimukset toteutuvat. Tämän lisäksi tarkistusvälineet tekevät vain pienen osan sellaisesta analyysista, joka olisi periaatteessa mahdollista.

Muita tarkistus- ja analysointiohjelmia

WebXACT

WebXACT on Watchfire-yhtiön tarjoama uudehko palvelu. Se on verkossa oleva maksuton palvelu, joka arvioi sivun useilta eri kannoilta, minkä lisäksi se viittaa saman yhtiön maksullisiin tarkistuspalveluihin. Käyttöliittymältään se on nykyaikainen ja selkeä, ja sen raporttien muodon on luonnehdittu olevan varsinkin aloittelijalle sopivampi kuin Bobbyn. Se on toisaalta hiukan hidas, eikä sen tekemä esteettömyystarkistus ilmeisestikään poikkea sisällöltään olennaisesti Bobbyn tekemästä. Seuraavassa on ote sen antaman raportin alusta, kun raportista on valittu Accessibility-osa:

[Ruutukaappaus: XebXACT-tarkistimen raportti. Pääosina General, Quality, Accessibility, Privacy, Traffic, User Feedback. Taulukossa on tiivistelmä eri prioriteettitasojen virheistä ja huomautuksista.]

Site Valet

Site Valet on kokoelma erilaisia verkkosivujen tarkistamisen ja arvioinnin välineitä. Yksi välineistä on Accessibility Valet, jolla voi tuottaa monenmuotoisia raportteja. Siihen sisältyy verkon kautta käytettävä Accessibility Valet Demonstrator, jolle annetaan tarkistettavan sivun osoite, valitaan haluttu testaustaso (oletuksena WAI:n AAA-taso) ja raportin muoto.

Oletusmuoto on sellainen, jossa on sivun HTML-merkkaus määrätavalla muotoiltuna ja siinä symboleita "A", "AA" ja "AAA" osoittamassa kohtia, joista Accessibility Valet huomauttaa jotakin. Kun vie kursorin sellaisen symbolin päälle, tulee näkyviin selitysteksti. Selkeämpänä voinee pitää raporttia, joka saadaan, kun kohdasta "Report Format" valitaan. "Verbose" saatavaa raporttia. Siinä selitystekstit ovat suoraan näkyvissä:

[Accessibility Valet -raportin alkua]

Tällainenkin raportti on varsin hankala lukea, jos dokumentissa on paljon mutkikasta merkkausta, esimerkiksi paljon taulukkotaittoa. Toisaalta niille, jotka osaavat hyvin työskennellä HTML:n parissa, raportointitapa on usein täsmällinen ja käyttökelpoinen, jos dokumentin rakenne on riittävän selkeä.

Wave

Wave on palvelu, joka esittää annetun Web-sivun graafisessa muodossa siten, että mukana on Wave-ohjelman lisäämiä kuvakkeita. Kyseessä on siis lähinnä analysointiohjelma, mutta mukana on virheilmoituksen luonteista raportointia.

Käyttöliittymä on sikäli helppo, että palvelulle vain annetaan analysoitavan sivun osoite ja analyysi saadaan saman tien. Ongelmia tuottaa sen sijaan värikkään analyysin lukeminen, sillä se sisältää monia erilaisia kuvakkeita, joiden merkitys ei ole lainkaan ilmeinen. Seuraavassa on pieni otos esimerkkisivumme Wave-analyysista:

[Ruutukaappaus: Ote Internetix-sivun Wave-analyysista]
Kuva: Wave-analyysi sisältää mm. tiedon sivun elementtien linearisoidusta järjestyksestä (numerot sinisellä pohjalla).

Vaikka kuvassa on vain pienehkö ote Wave-analyysista, siitä ilmenee, että sivun elementtien linearisoitu järjestys poikkeaa aika lailla niiden järjestyksestä graafisessa esityksessä. Tämä voi merkitä joskus isojakin ongelmia. Analyysista ilmenee myös sivun jakautuminen elementteihin (reunaviivat). Wave lisää esitykseen myös kuvasymboleita, jotka esittävät erilaisia varoituksia esimerkiksi. Kun kursori viedään symbolin päälle, tulee näkyviin selitysteksti, kuten kuvassa näkyvä "FORMATTING ELEMENT: Layout table", joka kertoo, että Wave on arvioinut, että kyseessä on taulukkotaitto.

Web Page Analyzer

Web Page Analyzer tekee teknisen analyysin, joka arvioi sivun kokonaiskoon ja latausajan. Tämä on hyödyllistä mm. sen kannalta, miten hyvin sivu toimii hitailla yhteyksillä. Seuraavassa on ote esimerkkisivuamme koskevasta raportista:

Connection RateDownload Time
56K 12.95 seconds
ISDN 128K 7.02 seconds
T1 1.44Mbps 4.63 seconds

Tässä tapauksessa latausaika on siis varsin nopeallakin yhteydellä useita sekunteja. Raportti sisältää myös ehdotuksia siitä, miten latausaikaa voisi pienentää.

Doctor HTML

Doctor HTML on ohjelma, joka tekee sekalaisen joukon tarkistuksia. Siitä on sekä maksuton versio että monipuolisempi maksullinen versio. Tarkistukset eivät suoranaisesti koske esteettömyyttä. Se mainitaankin tässä vain siksi, että sitä on usein suositeltu. Raportit ovat osittain harhaanjohtavia, jopa virheellisiä.

CSE HTML Validator

CSE HTML Validator on myös sekalaisia tarkistuksia tekevä ohjelma, jossa kuitenkin on myös esteettömyyteen liittyviä piirteitä. Nimestään huolimatta se ei tee validointia. Se on maksullinen ohjelma, josta kuitenkin saa maksuttoman kokeiluversion, ja lisäksi siitä on täysin maksuton kevytversio. Verkossa oleva demo antaa lähinnä kummallista tietoa, koska se mm. väittää täysin virheettömiäkin sivuja virheellisiksi mutta kertoo vain "virheiden" lukumäärän.

Ohjelman etuna on kuitenkin monipuolisuus: se tekee jonkinlaisen HTML-syntaksin tarkistuksen, erilaisia esteettömyystarkistuksia, monia heuristisia testejä ym. Toisaalta voidaan myös valita suoritettavaksi vain osa testeistä, esim. pelkät esteettömyystarkistukset. Asiantuntevan ja tottuneen käyttäjän käsissä CSE HTML Validator voi olla tehokas työväline, mutta aloittelijaa se todennäköisesti hämmentää ja jopa johtaa harhaan.

Liitteenä on kuva CSE HTML Validatorin käytöstä. Ohjelman ikkuna jakautuu useisiin osaikkunoihin, joissa yhdessä näkyy tutkittavan tiedoston HTML-koodi, jota voidaan myös muokata.

Esimerkki ohjelmien käytöstä

Tehtävä: Tarkista esimerkkisivu ainakin yhdellä edellä kuvatuista tai mainituista tarkistusohjelmista. Ensijaisesti tehtävä kannattaa tehdä A-Promptilla, jolloin voidaan harjoitella myös virheiden korjaamista.

Koska tarkistusohjelmat tuottavat tietoa hyvin erilaisissa muodoissa ja osittain suuria määriä, ei tässä esitetä ohjelmakohtaisia malliratkaisuja. Saatuja tuloksia kannattaa arvioida ennen muuta sen mukaan, ovatko ohjelmat auttaneet testaajaa paitsi havaitsemaan mahdollisia ongelmia myös ymmärtämään ongelmien luonnetta ja löytämään ratkaisuja.

Sen sijaan on liitteenä kooste esimerkkisivun ongelmista. Mukaan on otettu sekä tarkistusohjelmilla että muutoin havaittuja ongelmia. Kullakin tarkistusohjelmalla saavutettuja tuloksia voidaan verrata tähän koosteeseen.

Tarkistuslistat

Tarkistuslistojen merkitys

Tarkistuslistat ovat yleensä tiiviitä luetteloita tarkistettavista asioista. Niissä ei useinkaan ole ohjetta siitä, miten jokin asia tarkistetaan, saati perustelua sille, miksi asia on syytä tarkistaa. Niistä on kuitenkin hyötyä

Kun tarkistuslistan mukaisesti käydään läpi jotakin sivua, huomataan yleensä, että suuri osa kohdista ei lainkaan koske tarkasteltavaa sivua. Esimerkiksi kohdat, joissa puhutaan taulukoista, eivät yleensä koske sivua, jolla ei ole mitään taulukoita. Aluksi tarkistuslistan käyttö vie aikaa, mutta melko nopeasti oppii ohittamaan epäolennaiset kohdat ainakin, jos listan kohdat on ryhmitelty sopivasti.

Tarkistuslistat saattavat hämmentää laajuudellaan, ennen kuin opitaan tunnistamaan nopeasti, mitkä listan kohdat ovat kussakin tilanteessa olennaisia. Toisaalta laajimmatkin tarkistuslistat kattavat vain osan esteettömyysongelmista. Tarkistuslistoja tulisikin pitää apuvälineinä, ei kaavoina, joita on noudatettava.

WAI-suositus tarkistuksen välineenä

Itse WAI-suositus on jaoteltu pääkohtiin ja alakohtiin, joista alkuteksti käyttää nimitystä checkpoint. Mutta vaikka ise WAI-suositusta voi käyttää tarkistuslistana, se on varsin laaja ja osittain epäkonkreettinen. Sehän pyrkii olemaan kattava ja siksi esittämään myös asioita, joita ei voi tai ei ole vielä osattu tyhjentävästi konkretisoida käytännöllisiksi menettelytapaohjeiksi. Lisäksi menettelytapojen on vaihdeltava tekniikan kehityksen ja sivun luonteen ja toteutuksen mukaan.

WAI-suosituksen liitteenä A on eräänlainen tarkistuslista, joka tosin on vain kymmenen kohdan lista tarkistusmenetelmistä. Vielä tiivistetympänä se on seuraava:

  1. Käytä automaattista arviointityökalua sekä arvioivaa selainta.
  2. Arvioi [validaattorilla] syntaksi (esim. HTML, XML jne.).
  3. Arvioi [tarkistusohjelmalla] tyylitiedostot (esim. CSS).
  4. Kokeile merkkipohjaista selainta tai sen emulaattoria.
  5. Kokeile useita graafisia selaimia eri asetuksin,
  6. Kokeile useita eri-ikäisiä selaimia.
  7. Kokeile puhuvaa selainta, ruudunlukuohjelmaa, suurennusohjelmia, pientä näyttöä jne.
  8. Käytä kieliopin ja oikeinkirjoituksen tarkistusohjelmia.
  9. Tarkasta dokumentin selkeys ja yksinkertaisuus.
  10. Pyydä vammaisia käyttäjiä arvioimaan sivuja.

Yhdeksännessä kohdassa mainitaan myös: "Esimerkiksi joidenkin tekstinkäsittelyohjelmien luomat luettavuustilastot voivat olla hyödyksi." Tämä pätee englanninkielisiin teksteihin. Suomen kielelle on kehitetty eräitä luettavuuden mittareita, mutta niiden mukaisia toimintoja ei ole toteutettu tekstinkäsittelyohjelmiin.

WAI-suositukseen liittyvä tarkistuslista

WAI-suosituksen oheisaineistona on tarkistuslista Checklist of Checkpoints, johon on koottu kaikki alakohdat taulukon muotoon.

Alakohdat on jaoteltu ensin prioriteettitasojen mukaan ja sitten kunkin tason sisällä ryhmiin. Ryhmillä on sentapaisia otsikoita kuin "And if you use tables", ja tämän ansiosta on helppo ohittaa sellaisia kohtia, joista testaaja tietää, että ne eivät koske testattavaa sivua.

W3C:n Suomen toimisto on laatinut tarkistuslistasta osittaisen suomennoksen, johon on otettu 1 prioriteettitason alakohdat. Se sisältyy sivuun Web-saavutettavuuden 1-2-3. Tämä lista on varsin kätevä silloin, kun halutaan aloittaa sivujen tarkistaminen niistä kohdista, jotka WAI-suosituksessa on luokiteltu tärkeimmiksi.

Näkövammaistahojen testausohjeet

Näkövammaistahojen testausohjeet verkkosivuille ja -palveluille sopivat luonteeltaan hyvin tarkistuslistaksi. Suurin osa kohdista voidaan tarkistaa sivun ulkoasun ja käytännöllisen kokeilun perusteella, perehtymättä esimerkiksi sivun HTML-merkkaukseen (poikkeuksina lähinnä kohdat 11 ja 12). Esimerkiksi ensimmäinen kohta, "Onko sivun title-elementti kuvaava?", voidaan yleensä tarkistaa katsomalla tavallisen selaimen yläpalkkia, jossa käytännössä näkyy title-elementin sisältö.

TIEKEn tarkistuslista

TIEKE Tietoyhteiskunnan kehittämiskeskus on julkaissut oppaan Verkkosivut jokaiselle sopiviksi, jossa on laajahko esteettömyyden tarkistuslista testausohjeineen. Se soveltuu erityisesti perusteelliseen esteettömyyden analyysiin, mutta siihen sisältyy myös yksinkertaista testausta, joka ei vaadi mitään erityistä teknistä osaamista. Tarkemmin sanoen siinä on testaustavat jaettu käytännöllisin perustein ryhmiin sen mukaan, mitä ne testaajalta vaativat:

Esimerkiksi "silmäilytestit" on tiivistetty seuraaviksi kohdiksi, joita oppaassa selitetään tarkemmin:

  1. Onko sivu kohtuullisen mittainen?
  2. Onko ulkoinen otsikko kuvaava?
  3. Selviääkö olennaisin otsikoista?
  4. Onko nopeasti hahmotettavissa, mitä sivulla on?
  5. Saako sisältösivusta sen olennaisimman sisällön, jos otsikoiden lisäksi lukee kunkin kappaleen ensimmäisen virkkeen?
  6. Onko kielenkäyttö yhtenäistä (esim. ei tarpeettomasti eri kieliä sekaisin)?
  7. Jos sivulla on animaatio tai muuta liikkuvaa, onko sen mukanaolo perusteltua?

Muita tarkistuslistoja

Tarkistuslistoja on monia muitakin. Erityisesti mainittakoon Web Matters - Website Checklist, joka on monipuolinen mutta lyhyehkö ja selkeä yleinen tarkistuslista, joka testaa verkkosivua monelta eri kannalta:

  1. validointi ja vastaavat (validation)
  2. joustavuus (flexibility)
  3. nopeus (speed)
  4. esteettömyys (accessibility)
  5. selainriippumattomuus (browser independence)
  6. muut tarkistukset (other checks), mm. "orvot" sivut (sivut, joissa ei ole mitään asiayhteyden kertovaa linkkiä).

Eri organisaatioilla saattaa olla omia tarkistuslistoja. Ainakin sellaiset olisivat usein tarpeen, sillä sivujen luonne, paikalliset ohjeet, käytetyt sivuntekotyökalut ja sivuntekijöiden tausta vaikuttavat erittäin paljon siihen, mitkä ongelmat ovat tärkeimpiä.

Esimerkki tarkistuslistojen käytöstä

Tehtävä: Arvioi esimerkkisivua yhden tai useamman tarkistuslistan mukaan. Malliratkaisuna on esimerkkisivun arviointi WAI-tarkistuslistan mukaan. Jos käytät muuta tarkistuslistaa, on hyödyllistä verrata tulosta tähän malliratkaisuun, koska yleensä muilla tarkistuslistoilla havaitaan pienempi määrä ongelmia, mutta osittain erilainen ja toisella tavalla painottunut.

Testihenkilöiden käyttö

Testihenkilöiden käytön hyödyt

Testihenkilöiden käyttämisellä tarkoitetaan tässä yhteydessä sitä, että yhtä tai useampaa ihmistä käytetään koehenkilöinä sivujen testaamisessa. Testaaminen voi tällöin tarkoittaa sivun tavanomaista käyttöä, usein kuitenkin oloissa, joissa suoriutumista erityisesti seurataan. Jos testihenkilöllä on jokin vamma tai ongelma, joka voi vaikeuttaa sivujen käyttöä, voimme saada käytännöllistä ensi käden tietoa.

Voimme esimerkiksi testata sivun esteettömyyttä sokeille monin eri menetelmin, joita edellä on kuvattu. Kyse on tällöin kuitenkin vain arvioinnista tai jäljittelystä, joka voi joskus paljonkin poiketa siitä, miten sokea käyttää verkkosivuja. Sama koskee heikkonäköisyyden eri muotojen vaikutusta.

Vielä selvempää on, että on vaikeaa arvioida esteettömyyttä esimerkiksi suomea huonosti osaaville tai kehitysvammaisille tai keskittymiskyvyn häiriöistä kärsiville. Aistien alueella voimme ainakin kuvitella, mitä jonkin aistin puuttuminen tai sen häiriö voi vaikuttaa, vaikka kuvittelu onkin rajallista ja voi johtaa harhaan. Mutta miten voisimme kuvitella tai jäljitellä esimerkiksi tilannetta, jossa sivua yrittää käyttää ihminen, jonka on lukihäiriön takia vaikea lukea tavallista tekstiä?

Miten testaus voidaan järjestää?

Käytännössä joudutaan usein tyytymään aivan vapaamuotoiseen testaukseen. Ääritapauksena on se, että pyydetään yleisesti jollakin foorumilla ihmisiä testaamaan sivuja ja toivotaan, että näin saadaan palautetta myös esteettömyydestä. Foorumina voi olla esimerkiksi yrityksen sisäinen postituslista tai tiedotuslehti taikka jokin julkinen keskustelufoorumi (esimerkiksi news-järjestelmän ryhmä sfnet.viestinta.www.palaute).

Testauspyynnöissä ja yleensä testausta suunniteltaessa kannattaa kiinnittää huomiota sellaisiin asioihin, joita erityisesti epäillään ongelmallisiksi. Tätä varten kannattaa yleensä ensin käyttää tarkistuslistoja, tarkistusohjelmia ja muita itse käytettäviä välineitä. Tällöin saadaan alustava käsitys ongelmista, voidaan korjata niistä osa ja tiedetään myös esimerkiksi se, mitä tarkistuslistan kohtia ei voitu sillä tavoin selvittää.

Vapaamuotoisella testauksella ei tietenkään saada yhteismitallista eikä kattavaa tietoa, eikä tieto aina ole kovin luotettavaakaan. Varsinainen järjestetty testaus vaatii selkeän listan siitä, mitä on tarkoitus tutkia ja miten. Koehenkilöille laaditaan ohje siitä, mitä heidän pitäisi tehdä, ja yleensä itse testaus järjestetään oloissa, joissa koehenkilön suoritusta koko ajan seurataan. Valitettavasti tämä muuttaa koehenkilöiden käyttäytymistä, varsinkin jos heillä muutenkin on keskittymisvaikeuksia.

Yksinkertaisimmassa tapauksessa koehenkilölle annetaan joitakin selviä, tavanomaisia tehtäviä, kuten "etsi tästä sivustosta NN:n puhelinnumero", "tilaa sivustosta itsellesi yrityksen tuoteluettelo" tai "vastaa seuraavaan kysymykseen tästä sivustosta löytyvän tiedon perusteella: - -". Suoriutumista seurataan ja verrataan "normaalin" koehenkilön suoriutumiseen. Erityistä ohjeiden antamista pitäisi välttää, koska tarkoitus on muun muassa testata juuri sivuston omien ohjeiden riittävyyttä käyttäjälle, jota kukaan ei ole opastamassa. Jos kuitenkin tilanne täysin jumittuu, voidaan pyrkiä opastamaan eteenpäin niin, että mahdollisimman suuri osa suunnitelluista toiminnoista voidaan testata.

Käytännössä esteettömyystestaus koehenkilöillä voidaan tehdä samantapaisilla järjestelyillä kuin käytettävyystestaus. Tällaisten testien käytännöllinen yhdistäminen yhdeksi testiksi on kuitenkin ongelmallista, koska käytettävyystestit ovat usein koehenkilöille vaativia.

Testauksen ongelmia

Testihenkilöiden käytön keskeinen etu on se, että siinä selvitetään esteettömyyttä todellisissa tilanteissa. Tämä on samalla myös haitta, koska tilanteet ovat yksilöllisiä. Yhden testihenkilön kokemus voi tuoda esiin ongelman, joka kohtaisi miljoonia muitakin ihmisiä, tai sitten hyvin harvinaisen ongelman.

Lisäksi havaitut ongelmat voivat johtua aivan muista seikoista kuin sivulla olevista esteellisyyksistä. Jos heikkonäköinen käyttäjä ei tiedä, miten selaimen fonttikokoa suurennetaan, se on hyvin todellinen ongelma mutta pitää ratkaista häntä opastamalla.

Koska testihenkilöitä on väistämättä pieni tai pienehkö määrä, esille tulee vain osa esteettömyysongelmista. Lisäksi ne painottuvat sen mukaan, mitä vaikeuksia testihenkilöillä on.

Tulosten yleistettävyys onkin aivan toisenlainen kuin käytettävyystutkimuksissa. Käytettävyydessä riittää muutama koehenkilö, kun tutkimus tehdään oikein, ja jos sitä ei tehdä oikein, ei koehenkilöiden määrän lisääminen auta. Sen sijaan esteettömyyden testaamisessa voitaisiin tuloksia oikeastaan aina parantaa, jos voidaan ottaa mukaan erilaisia koehenkilöitä. Käytännössä joudutaan yleensä tyytymään pieneen määrään testaajia, mutta silloin olisi olennaista, että tällöin selvitettäisiin ainakin muutamien tavallisimpien ongelmien vaikutusta (kuten sokeus, heikkonäköisyys, kuurous, käden motoriikan häiriöt, kielelliset vaikeudet, hahmotusvaikeudet ja huonomuistisuus).

Yleisten tarkistusten merkitys

Tässä kohdassa käsitellään sellaisia tarkistuksia, jotka eivät suoraan testaa esteettömyyttä mutta saattavat olla hyödyllisiä myös esteettömyyden kannalta.

HTML-merkkauksen tarkistus

HTML-merkkauksen muodollisen oikeellisuuden tarkistus voidaan tehdä validaattorilla. Käytännössä tämä merkitsee yleensä sitä, että validaattori vertaa merkkausta yksityiskohtaisesti niihin muotosääntöihin, jotka HTML:n määrittelyssä eli "standardissa" on asetettu. Tällöin havaitaan muun muassa seuraavanlaiset virheet:

Käytännössä suuri osa tällaisista virheistä ei vaikuta kovin paljoa esteettömyyteen. Pahat kokonaisrakenteen virheet kuten elementtien väärä sisäkkäisyys kyllä aiheuttavat isoja ongelmia, mutta ne ilmenevät usein jo yleisenä toimimattomuutena. Standardiin kuulumattomat elementit saattavat olla oire siitä, että sivulla käytetään olennaisella tavalla jotain piirrettä, joka ei toimi kuin joissakin selaimissa. Standardiin kuulumattomat määritteet sen sijaan vaikuttavat yleensä vain ulkoasun yksityiskohtiin. Puuttuvista pakollisista määritteistä olennaisin esteettömyyden kannalta on alt-määrite.

Toisaalta on useinkin muita syitä tehdä sivuille ensin validointi. Sillä voidaan havaita vahingossa tehtyjä merkkauksen virheitä, joista on joskus yllättäviä seuraamuksia. Validoinnin merkitys kuitenkin usein yliarvioidaan. Validoinnissa on kyse muototarkistuksista. Asiaa kuvaa tarkemmin kirjoitus HTML-validaattori - mikä se on.

Validointimenettely on sinänsä helppo, mutta validaattorien virheilmoitusten tulkinta on usein ongelmallista. Kenties helppokäyttöisin validaattori tässä mielessä on WDG:n validaattori. Sen käyttöliittymä koostuu olennaisesti vain lomakkeesta, johon kirjoitetaan tarkistettavan sivun osoite. Tarkistettava HTML-dokumentti voidaan antaa myös muussa muodossa.

Tällä lomakkeella voit käyttää edellä mainittua validaattoria. Valitse esimerkkisivu (Internetixin pääsivun kopio) siitä hakemistosta, jossa se on sinulla tallennettuna.

Jos validaattori antaa virheilmoituksia, ei niinkään kannata tutkia ilmoitusten yksityiskohtia kuin verrata käytettyä HTML-merkkausta HTML:n määrittelyyn. Käytännöllinen HTML:n kuvaus tällaista varten on esimerkiksi WDG HTML 4.0 Reference..

Tehtävä: Tarkista esimerkkisivu WDG:n validaattorilla. (Halutessasi voit vaihtoehtoisesti käyttää W3C:n validaattoria tai suomenkielistä Lehtori-validaattoria, mutta malliratkaisu on WDG:n validaattorin ilmoituksia vastaava. Toisaalta eri validaattorien ilmoituksissa ei ole kovin suuria eroja.) Pyri selvittämään ainakin muutaman virheilmoituksen syy ja arvioimaan niiden merkitystä esteettömyyden kannalta. Kaikkien virheilmoitusten käsittely tällä tavoin vaatii hyvää HTML:n osaamista ja vie aikaa, mutta jo muutaman tarkastelu antaa hyödyllisen tuntuman validointiin. Tehtyäsi tehtävän vertaa omaa selvitystäsi validoinnin malliratkaisuun.

CSS-koodin tarkistus

CSS-koodin tarkistamiseen sopii CSSCheck, jos koodissa käytetään lähinnä vain CSS 1:n piirteitä, muutoin CSS Validator.

CSS-koodin tarkistus on hyvin hyödyllistä, koska kokeneetkin CSS:n käyttäjät tekevät usein pieniä mutta haitallisia kirjoitusvirheitä, eivätkä virheet useinkaan paljastu yksinkertaisessa selaimella tehtävässä testauksessa. Toisaalta suhteellisen pieni osa CSS-koodin virheistä vaikuttaa suoranaisesti esteettömyyteen. Pikemminkin virheet aiheuttavat sen, että sivun ulkoasu ei ole haluttu tai se on tarpeettomasti erilainen eri selaimilla.

Tehtävä: Tarkista esimerkkisivun CSS-koodi CSSCheckillä. Arvioi mahdollisia ilmoituksia ja niiden merkitystä esteettömuuden kannalta. Vihje: tässä tapauksessa CSS-koodia on vain HTML-dokumentin sisällä olevassa style-elementissä, joten voit esimerkiksi vain leikata ja liimata sen. Tehtyäsi tehtävän vertaa omaa selvitystäsi CSS-tarkistuksen malliratkaisuun.

Linkkien tarkistus

On hyvin hyödyllistä tarkistaa, että kaikki sivulla olevat linkit toimivat ainakin teknisesti. Tämä ei kuitenkaan juurikaan liity erityisesti esteettömyyteen. Tosin toimimattomat linkit hämmentävät erityisesti niitä, joilla on hahmottamisvaikeuksia tai jotka herkästi hämmentyvät ja jopa hermostuvat tietokoneiden antamista virheilmoituksista tai muista poikkeuksellista tilanteista.

Sivun linkit voi tarkistaa esimerkiksi W3C:n Checklink-tarkistimella. Tässä vaiheessa on hyvä tutustua siihen. Erillistä harjoitustehtävää ei kuitenkaan ole, vaan toteamme vain, että 6.10.2003 tehdyssä tarkistuksessa esimerkkisivumme kaikki linkit toimivat paitsi IRC (yhteyttä ei saa aikarajan puitteissa). Tämä toimimattomuus on erityisen ikävä siksi, että linkkiin ei liity mitään selitystä eli käyttäjä ei voi tietää, mihin se johtaisi (ainakaan ellei tunne lyhennettä "IRC").

Mainittu Checklink on kyllä helppokäyttöinen, mutta melko hidas, joten se sopii melko huonosti ison sivuston tarkistamiseen.

Windows-ympäristöön on saatavissa maksutta erillinen linkkientarkistusohjelma Xenu's Link Sleuth, joka on varsin nopea.

Esimerkkisivun korjaus

Tehtävä: Laadi oma ehdotuksesi esimerkkisivun korjatuksi versioksi, käyttäen hyväksesi tehtyjä testejä ja tarvittaessa testaamalla lisää. Tehtävä on huomattavan työläs, jos halutaan korjata kaikki esteettömyysongelmat, mutta harjoituksessa voidaan keskittyä harjoituksen tekijän tärkeinä pitämiin ongelmiin. Tehtävä voidaan tehdä monella tavalla, mutta malliratkaisu on tehty seuraavien "reunaehtojen" puitteissa:

Jukka K. Korpela (jkorpela@cs.tut.fi)
Muita artikkeleita aiheesta:
Seuraa polkua:
Edellinen: Esteettmyytt koskevat suositukset, standardit ja lait
Seuraava: Huomioonottava verkkosivusto on helppokyttinen ja esteetn