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.
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.
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.
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.
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.
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 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:
Niinpä mitä aiemmin testataan, sen parempi.
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:
title
-elementin sisällön)? Kertooko se, mitä
sivu käsittelee, vaikka et näkisi itse sivua? (Joissakin käyttömuodoissa
"ulkoinen otsikko" on ensimmäinen asia, jonka käyttäjä
kuulee tai näkee sivusta.)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ö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.
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.
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.
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.
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.
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.
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.
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 sivuhistoriassa | Backspace |
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ä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.
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ä).
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:
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.
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ä.
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.
"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 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 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.
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.
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 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:
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:
frame
-elementeissä
tulee olla longdesc
-määrite.)
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 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.
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ä.
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:
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.
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.
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.
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".
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=""
.
Tässä käsitellyt tekniikat ovat luonteeltaan lähinnä teoreettisia. Valitse kohta "The image is not complex enough to require a 'longdesc'".
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.
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.).
Tässä kohdassa A-Prompt käytännössä vain muistuttaa asioista, joita se ei tarkista ja joita sillä ei voi korjata.
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!
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.
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.
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.
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.
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):
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.
- 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 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:
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)".
pre
-elementeistä,
sillä pre
-elementti on tavallisin tapa esittää
Ascii-grafiikkaa).
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.
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:
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ä:
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 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:
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 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 Rate Download 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 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 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.
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 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.
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:
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-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 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ö.
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:
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:
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ä.
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ä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ä?
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.
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).
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 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.
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 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.
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.
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: