Esteettömyyttä koskevat suositukset, standardit ja lait

Tiivistelmä

Esteettömyyttä koskevat suositukset perustuvat suurelta osin Web-konsortion (W3C) WAI-ohjeisiin. Siksi seuraavassa kommentoidaan laajasti sekä varsinaisia WAI-ohjeita että niitä täydentäviä teknisempiä ohjeita. Kokonaisuutena ne muodostavat suhteellisen kattavan ja perustellun ohjeiston, mutta niihin sisältyy myös vanhentuneita tai muuten ongelmallisia kohtia.

Euroopan unionin asiakirjoissa on voimakkaasti korostettu esteettömyyttä ja erityisesti WAI-ohjeiden merkitystä. Suomessa on verkkosivuja koskeva julkisen hallinnon suositus, JHS 129. Se asettaa esteettömyyden keskeiseksi tavoitteeksi ja viittaa erityisesti WAI-ohjeisiin. Sen sijaan ei maassamme toistaiseksi ole esteettömyyttä koskevia varsinaisia standardeja eikä lainsäädäntöä. Epäsuoraa vaikutusta on Yhdysvaltain ja muiden maiden lainsäädännöllä.

Sisällysluettelo

Yhteiskunnallista taustaa

Vammaisten oikeuksien tunnustaminen

Ihmisten suhtautuminen vammaisuuteen on suuresti vaihdellut historian aikana. Kärjistäen voidaan asenteet ja toimintatavat jakaa seuraavasti:

Näistä kaksi viimeksi mainittua ovat paljolti rinnakkaisia, toisiaan täydentäviä periaatteita. Käytännössä esimerkiksi vammaisen osallistuminen normaaliin kouluopetukseen vaatii usein tuekseen erityisjärjestelyjä. Sama koskee verkkosisältöjen esteetöntä käyttöä.

Vaikka yleinen yhteiskunnallinen asenneilmasto kehittyneissä maissa on muuttunut vähintäänkin vammaisia sietäväksi etenkin 2. maailmansodan jälkeen, yhteiskunnallinen tilanne ei aina heijastu yksilöiden tunteisiin ja asenteisiin. Onkin ilmeistä, että julkisuudessa näkyvät asenteet kuvastavat pikemminkin sitä, mitä julkisesti pidetään oikeana, kuin todellisia asenteita. Tämä on esteettömyystyön yksi ongelma: vastarintaa on vaikea kohdata, koska sitä ei ilmaista sanoilla ja selvillä kannanotoilla.

Usein mainittu ilmentymä asenteiden muuttumisesta on Yhdistyneet kansakunnat -järjestön yleiskokouksen vuonna 1975 antama Vammaisten oikeuksien julistus. Toisaalta vaikka se sisältää vahvan ajatuksen tasa-arvosta ja myös vammaisten erityistarpeisiin vastaamisesta, se on luonteeltaan suhteellisen vanhakantainen. Se keskittyy paljolti kaikkein perustavimpiin oikeuksiin kuten ihmisarvoon, toimeentuloon, oikeuteen elää yhdessä perheen kanssa, terveydenhuoltoon jne., koska nämäkin hyvin usein puuttuivat - ja puuttuvat yhä - vammaisilta monissa maissa. Erityisesti julistuksesta puuttuu myöhemmin tärkeäksi nostettu ajatus valtavirtaistamisesta (mainstreaming) eli siitä, että tuotteet, palvelut ym. suunnitellaan kaikille sopiviksi eli että vammaisten tarpeet otetaan huomioon kaikessa suunnittelussa sen sijaan, että suunniteltaisiin vain enemmistölle ja sitten tehtäisiin vammaisille erityisratkaisuja.

Huomattavasti nykyaikaisempaa lähestymistapaa edustaa YK:n yleiskokouksen vuonna 1993 hyväksymä päätöslauselma The Standard Rules on the Equalization of Opportunities for Persons with Disabilities. Vaikka se siis on laadittu jo ennen Internetin kehittymistä nykyisenkaltaiseksi ilmiöksi, se painottaa vahvasti tietotekniikan kautta tarjottavien mahdollisuuksien esteettömyyttä. Sen sääntö 5, Accessibility, käsittelee sekä fyysisen ympäristön että informaation ja viestinnän esteettömyyttä. Se esittää jälkimmäisestä seuraavan, jossa ensimmäinen kohta korostaa vammaisten oikeutta heille erityisen olennaiseen tietoon mutta muut painottavat laaja-alaisesti sitä, mitä nykyisin voi kutsua tietoyhteiskunnan esteettömyydeksi yleensä:

Rakennusten esteettömyydestä tietotekniikan esteettömyyteen

Digitaalinen esteettömyys on suhteellisen nuori ajatus. Sen sijaan rakennusten esteettömyyteen on kiinnitetty huomiota jo pitkään. Siinä on kyse esteistä myös hyvin konkreettisessa mielessä, kuten portaista, kynnyksistä ja liian kapeista ovista. Sana "esteettömyys" johtuukin paljolti tästä.

Esteettömyyteen laajassa mielessä kuuluu myös liikenteen kuten liikennevälineiden ja terminaalien esteettömyys. Suomessa on liikenne- ja viestintäministeriö julkaissut elokuussa 2003 esteettömyysstrategian Kohti esteetöntä liikkumista.

Rakennetun ympäristön esteettömyys liittyy suoranaisesti myös digitaaliseen esteettömyyteen sikäli, että julkisten tilojen tietokoneiden tulisi olla kaikkien saavutettavissa. Monille esimerkiksi yleisten kirjastojen verkkopäätteet ovat ainoa tai ainakin tärkeä tapa päästä käyttämään verkkoa. Silloin on olennaista, että päätteen luokse pääsee helposti. Suomessa on tällaisia asioita selvitelty melko paljon, ja on laadittu muun muassa Ohjeita julkisten päätteiden saavutettavuuden ja käytettävyyden parantamiseksi.

Uusien rakennusten esteettömyys perustuu nykyisin pääosin osin siihen, että lainsäädännöllä on asetettu vähimmäisvaatimuksia. Tällöin rakennuttajat ja rakentajat joutuvat kaikki noudattamaan niitä, jolloin ei synny kiusausta parantaa omaa kilpailuasemaa sillä, että tingitään esimerkiksi luiskien rakentamisesta. Paljon on keskusteltu siitä, pitäisikö vastaavista syistä asettaa lailla velvoitteita myös digitaalisten sisältöjen ja toimintaympäristöjen rakentajille.

On myös huomattu, että kun lainsäädäntö on pakottanut ottamaan vammaiset huomioon, on päädytty ratkaisuihin, joista on hyötyä kaikille. Esimerkiksi vaikka luiskat on tehty ensi sijassa pyörätuolilla liikkuvien käyttöön, niiden käyttäjistä suurin osa on rattaiden tai vaunujen työntäjiä, tavaroiden kuljettajia ym. Tämä on ollut omiaan luomaan yleistä ilmapiiriä, jossa esteettömyyden vaatimia asioita ei pidetä vain vammaisten asioina vaan luonnollisena osana suunnittelua.

Normien tilanne

Tässä käytetään sanaa normi yhteisnimityksenä virallisille suosituksille, standardeille ja laeille. Yhteistä niille on, että jokin julkinen elin tai yhteistoimintaelin on esittänyt kannanoton, joka on tarkoitetty toimintaa ohjaavaksi.

Normien tasoja

Seuraava taulukko luokittelee eräitä jäljempänä kuvattavia esteettömyysnormeja niiden tason mukaan.

Taulukko: Esteettömyysnormien tasoja
Taso Esimerkkejä
maailmanlaajuinen YK:n suositukset (yleisiä periaatteita), W3C:n WAI-ohjeet (verkkosivujen esteettömyys)
Euroopan unioni Komission kannanotto julkisen sektorin verkkosivujen saavutettavuudesta
Suomi Julkisen hallinnon suositus JHS 129
yritykset, laitokset yrityksen viestintästrategia

Normien merkitys esteettömyydelle

Miksi normeja on pidetty tärkeinä esteettömyydelle? Tähän on ainakin viisi syytä, joita voidaan painottaa eri tavoin:

  1. Normi määrittelee tavoitteet ja antaa siten selkeän perustan käytännön työlle. Esteettömyys on niin laaja aihe, että tarvitaan sen jäsentämistä osa-alueiksi, kohdiksi ja alakohdiksi, jotta se voidaan edes käsitteellisesti hallita.
  2. Normi antaa arviointiperusteita sekä itsearviointia että ulkopuolisen tekemää arviointia varten. Normin täyttäminen tai täyttämättä jättäminen antaa siis palautetta siitä, miten esteettömyydessä on onnistuttu. Tämä voi auttaa korjaamaan ne kohdat, joissa on vielä puutteita.
  3. Normin täyttämistä voidaan käyttää mainos- ja kilpailukeinona. Sikäli kuin esteettömyys yleisesti koetaan sosiaalisesti tärkeäksi tai jopa välttämättömäksi, esteettömyysnormien täyttämisestä kertominen parantaa yrityskuvaa. Tällöin ei yleensä ole mielekästä kertoa erityisten tavoitteiden saavuttamisesta, vaan on voitava viitata johonkin yleisesti tunnustettuun normistoon.
  4. Normi kehottaa tai painostaa ihmisiä ja organisaatioita ottamaan esteettömyyden huomioon. Vaikutus voi vaihdella normin aseman mukaan kannustavasta pakottavaan.
  5. Normi ilmaisee (poliittisen) tahdon. Poliittisessa toiminnassa tätä pidetään käytännössä usein saavutuksena sinänsä.

Lainsäädäntöä vai suosituksia?

Useissa maissa on esteettömyysvaatimuksia otettu myös lainsäädäntöön. Tunnetuin on Yhdysvalloissa voimassa oleva niin sanottu Section 508, joka koskee liittovaltion ja sen tukea nauttivien organisaatioiden verkkosivuja. Se perustuu enimmäkseen WAI-ohjeisiin mutta poikkeaa niistä ennen muuta siksi, että WAI-ohjeita ei pidetty luonteeltaan lainsäädäntöön soveltuvina. Lakeihin halutaan yleensä ottaa vain sellaisia vaatimuksia, joista voidaan suhteellisen yksiselitteisesti sanoa, onko ne täytetty vai ei. Esimerkiksi WAI-ohjeiden kohta, jonka mukaan tulee käyttää mahdollisimman yksinkertaista kieltä, on tuskin sellainen vaatimus.

Esteettömyyslainsäädäntöä on myös muun muassa Isossa-Britanniassa ja Australiassa. Yksi tunnetuimpia oikeustapauksia esteettömyyden alalta onkin se, että Sydneyn (vuoden 2000) olympialaisten verkkosivuista vastannut taho tuomittiin maksamaan korvauksia siitä, että sivusto ei täyttänyt Australian lain vaatimuksia esteettömyydestä.

Euroopan unionin piirissä on paljon keskusteltu siitä, tulisiko esteettömyysvaatimukset ottaa unionin lainsäädäntöön. Nykyisin esteettömyydestä on EU:ssa vahvoja suosituksia, joiden taakse ovat asettuneet sekä komissio että parlamentti. Mutta on epäilty suositusten olevan riittämätön keino.

Yleensä esteettömyysnormit koskevat ainakin ensisijaisesti julkisen sektorin verkkosivuja. Paljolti tämä johtuu siitä, ettei ole pidetty mahdollisena, että julkinen valta asettaisi vaatimuksia yritysten tai järjestöjen saati yksityisten ihmisten sivuille. Toisaalta elinkeinoelämää koskevat jo nyt eräät säädökset, jotka kieltävät joitakin syrjinnän muotoja.

On kiinnitetty huomiota myös siihen, että kilpailutilanne voi toimia esteettömyyttä vastaan. Vaikka esteettömyyden toteuttaminen maksaisi suhteellisen vähän, se vaikuttaisi kuitenkin kilpailukykyyn. Ne ihmisryhmät, jotka kaikkein eniten hyötyvät esteettömyydestä, eivät muodosta kovin suurta osaa markkinoista. Eri asia on, että esteettömyys voi parantaa sivujen yleistä laatua niin, että esteettömyys kannattaa liiketaloudellisesti.

Digitaalisen esteettömyyden ajatuksen esikuvana on paljolti ollut rakennetun ympäristön esteettömyys. Tässä yhteydessä on viitattu siihen, miten lainsäädännöllä on asetettu vaatimuksia sille, että tiloihin pääsee ja niissä voi liikkua esteettömästi. Tämä asettaa rakennusten suunnittelijat ja rakentajat samalle viivalle, koska kaikkien on otettava huomioon nämä vaatimukset ja niiden kustannukset. Toisaalta digitaalista esteettömyyttä on varsin vaikea pukea samanlaisiksi täsmällisiksi määräyksiksi kuin esimerkiksi vaatimukset luiskista ja ovien avautumissuunnista.

Tietoja esteettömyyttä koskevien normien tilanteesta eri maissa on Web-konsortion sivulla Policies Relating to Web Accessibility.

Normien ristiriitoja

Esteettömyyttä koskevat normit eivät yleensä ole ristiriidassa keskenään, ainakaan periaatteessa. Käytännössä painotuserot ovat joskus niin suuret, että normit vetävät eri suuntiin. Tähän johtaa jo se, että useimmissa tilanteissa ei ole mahdollista noudattaa kaikkia jonkin suosituksen kohtia, ainakaan nopeasti. Se, mitä suositus erityisesti painottaa, ohjaa voimavarojen käyttöä, ja silloin muita asioita jää tekemättä.

Osa normeista sisältää kohtia, jotka ovat ehdottomuudessaan epärealistisia. Jos niitä noudattaisiin kirjaimellisesti, resurssit kuluisivat tavalla, joka jättäisi monia aivan olennaisia esteettömyysasioita hoitamatta. Tyypillinen esimerkki on vaatimus, jonka mukaan kaikelle sisällölle, myös esimerkiksi videoesitykselle, pitää olla tekstivastine. On selvää, että esimerkiksi uutislähetykseen sisältyville videonpätkille ei voida laatia tekstivastineita, jotka sisältäisivät saman informaation. Sen sijaan on tietysti kohtuullista ja oikein vaatia, että videoon sisältyvä puheselostus on saatavilla myös tekstinä (mm. kuuroja ja kuulovammaisia varten).

On myös tilanteita, joissa esteettömyysvaatimukset johtavat vakavaan ristiriitaan muiden, hyvin perusteltujen vaatimusten kanssa. Esimerkiksi videon tekstittämisen vaatimus, niin kohtuullinen kuin se sinänsä onkin, voi merkitä sitä, että uutistoiminta hidastuu niin paljon, ettei se enää ole uutistoimintaa. Voidaanko esteettömyysnormien tiukan tulkinnan mukaan sallia edes sitä, että tekstittämätön video on saatavilla ennen kuin tekstitys valmistuu? Sehän rikkoisi sitä periaatetta vastaan, että sisällön tulee olla yhtäläisesti saatavilla eri aistien avulla vastaanotettavaksi.

Esteettömyysnormeissa on jopa kohtia, jotka vaativat joskus periaatteellisesti mahdottomia asioita. Esimerkiksi vaatimus siitä, että kaiken kuvana tai äänenä esitetyn sisällön tulee olla saatavilla myös tekstinä, merkitsee joissakin tilanteissa hyvin suurta työmäärää, esimerkiksi laajan aineiston kaikkien kaaviokuvien selittämistä. Mutta lisäksi se voi olla periaatteellisestikin mahdotonta, esimerkiksi kun kyse on maalauksesta tai sinfoniasta. Joissakin normeissa jo tunnustetaankin tällaiset rajoitukset.

Yhdysvaltain lainsäädännön esteettömyysnormeissa on periaate, jonka mukaan jokin vaatimus voidaan jättää noudattamatta, jos sen toteuttaminen merkitsisi kohtuutonta taakkaa (undue burden). Tämä on sikäli ymmärrettävää, että lainsäädännön tasoisissa normeissa on pakko olla tämäntapainen takaportti. Väistämätöntä on, että se on tulkinnanvarainen ja että sitä voidaan yrittää käyttää porsaanreikänä.

Toisaalta vaatimustason alentaminen helposti johtaa esteettömyyden heikkenemiseen, toisaalta taas sen pitäminen korkeana johtaa lipsumiseen, jossa voidaan ajautua isoihinkin ongelmiin. Käytännössä usein tulkitaan esimerkiksi niin, että riittää, kunhan tekstivastineessa on pääkohdat informaatiosta. Tästä voidaan lähes huomaamattomasti päätyä siihen, että tekstinä tarjolla oleva "vaihtoehto" onkin B-luokan tietoa ilman, että tätä edes rehellisesti kerrotaan.

Normeja lukiessa onkin hyvä pitää mielessä, että niissä on kohtia, joita tuskin kukaan pitää kaikissa tilanteissa kohtuullisina vaatimuksina. Normit on usein haluttu kirjoittaa yksinkertaisiksi ja tiukoiksi, jotta niitä vakavasti yritettäisiin noudattaa ja jotta niistä vasta todellisen pakon edessä tingittäisiin.

WAI-suositus

Miksi WAI-suositus on keskeinen?

Ilmaisu "WAI-suositus" tai "WAI-ohje" (tai monikossa "WAI-ohjeet") tarkoittaa yleensä suositusta Web Content Accessibility Guidelines 1.0, joka on suomennettu nimellä Verkkosisällön saavutettavuusohjeet. Se on Web-konsortion (World Wide Web Consortium, W3C) laatima. Konsortio on laajapohjainen ja arvostettu yhteistyöelin, jolla on keskeinen asema Webin tekniikoiden kehittämisessä ja kehityksen ohjaamisessa. Luonteeltaan konsortio on ensi sijassa käytännöllis-tekninen yhteistyöelin, mutta esteettömyyden alalla se on siis ottanut myös toimintalinjoja vetävän roolin. Tämä rooli sille on myös tunnustettu mm. Euroopan unionin kannanotoissa. Konsortiosta on tietoja mm. W3C:n Suomen-toimiston sivuilla.

WAI-suositukseksi yleensä kutsuttu asiakirja on vain yksi konsortion WAI-toiminnan (Web Accessibility Initiative) tuotoksista, mutta selvästi tunnetuin. Se on suunnattu yleisesti sivujen tekijöille ja sivujen tekoa ohjaaville tahoille. WAI-toiminnan tuottamat muut suositukset on suunnattu mm. selainten ja sivunteko-ohjelmien tekijöille, kuten User Agent Accessibility Guidelines 1.0 ja Authoring Tool Accessibility Guidelines 1.0 (ks. myös Authoring Tool Accessibility Guidelines 2.0 Working Draft). Niillä voi olla huomattava epäsuora merkitys, mutta ne eivät suoranaisesti vastaa kysymyksiin siitä, miten tehdään esteettömiä Web-sivuja.

Lyhenne "WAI" luetaan suomen kielessä yleensä sanana, siis "vai".

WAI-suositus on valmisteltu laajapohjaisessa asiantuntijatyöryhmässä, ja se on vahvistettu konsortion päätöksentekomenettelyjen mukaan. Se on varsin laajasti tunnustettu esteettömyyttä koskevaksi ehdottomasti keskeisimmäksi suositukseksi.

WAI-suosituksen vahvuudet ja heikkoudet

WAI-suosituksen keskeiset vahvuudet ovat siinä, että se on yhteisesti hyväksytty pohja ja sisällöltään monipuolinen. Se ei rajoitu näkövammaisille olennaisiin kysymyksiin, kuten esteettömyyskeskustelu usein rajoittuu, vaan se pyrkii kattamaan esteettömyyden koko kentän.

Toisaalta WAI-suositus on hajanainen ja osittain vanhentunut (vuodelta 1999). Se sisältää joitakin teoreettisia periaatteita, joiden käytännöllinen merkitys on vähäinen tai kyseenalainen. Kun sitä tarkastellaan yhdessä siihen liittyvien teknisempien ohjeiden kanssa, se menee osittain liiaksikin tekniseen toteutukseen, osittain taas etääntyy liiaksi käytännön mahdollisuuksista ja tarpeista.

Suurin ongelma WAI-suosituksessa ei kuitenkaan ole suosituksessa itsessään vaan siinä, että siitä on tehty lähes pyhä kirjoitus. Pahimmillaan tämä on johtanut siihen, että toimivia sivuja muutetaan WAI-suosituksen täyttämiseksi, vaikka tämä todellisuudessa merkitsee esteettömyyden heikentymistä. Siksi on tärkeää WAI-suosituksia sovellettaessa arvioida niiden merkitystä ja esteettömyyden vaatimuksia kussakin tilanteessa.

WAI-suosituksen rakenne

Itse WAI-suositus on yhtenäinen dokumentti, jossa on 14 pääkohtaa, jotka jakautuvat alakohtiin. Pääkohdista se käyttää nimitystä "guideline", alakohdista taas nimitystä "checkpoint". Alakohdat eivät kuitenkaan ole varsinaisesti minkään tarkistuslistan kohtia vaan kunkin pääkohdan sisältöä tarkentavia ja täsmentäviä periaatteita. Lisäksi suosituksessa on kaksi liitettä: lyhyt tarkistuslista ja laajahko selittävä sanasto.

Suositukseen liittyy myös Errata, joka sisältää painovirheiden ja muiden virheiden korjauksia. W3C:n käytännön mukaisesti saattaa "Errata" sisältää myös asiamuutoksia. Tämän suosituksen osalta asiamuutokset ovat kuitenkin melko vähäisiä. Muutokset eivät ole mukana suomennoksessa. Tärkeimmät muutokset ovat seuraavat:

Suositukseen liittyy tiivistetty tekniikkaohje, Techniques for Web Content Accessibility Guidelines. Tekniikkaohje koostuu Guidelines-dokumentin lyhennelmästä, jossa eri kohtiin on liitetty linkkejä kolmessa eri dokumentissa oleviin toteutusohjeisiin:

Lisäksi on vielä tiivistetty, taulukkomuotoinen tarkistuslista, Checklist of Checkpoints.

Kokonaisuuden rakenne ei kuitenkaan ole niin sekava kuin tämän perusteella voisi luulla. Voidaan ruveta lukemaan varsinaista WAI-suositusta, ja sen eri alakohdissa olevia viittauksia toteutusohjeisiin voi käyttää muun muassa sen tarkistamiseen, onko ajatus ymmärretty oikein. Toteutusohjeisiin voi siis perehtyä varsinaisen suosituksen mukaisissa asiayhteyksissä. Tosin suomenkielisessä versiossa viittauksia ei ole tehty linkeiksi.

WAI-suosituksessa on monet kohdat esitetty ehdollisina, esimerkiksi "Kunnes selaimet antavat käyttäjän pysäyttää liikkuvan sisällön, vältä sivuilla tapahtuvaa liikettä." Ajatuksena on, että monet ongelmat pitäisi pystyä hoitamaan selaimissa, mutta kun tilanne nyt on (tai ainakin WAI-suositusta laadittaessa) oli sellainen, ettei voida, niin noudatetaan joitakin rajoituksia ja sovelletaan erityismenettelyjä sivujen tekemisessä. Valitettavasti monet tarkistusohjelmat toimivat ikään kuin ehtoa "Kunnes selaimet antavat mahdollisuuden - -" ei olisi. Ne saattavat ilmoittaa sivun rikkovan WAI-suositusta, vaikka kyse olisi tällaisesta ehdollisesta alakohdasta, jonka ehto ei ehkä enää toteudu. Ja vaikeaa onkin sanoa, milloin selainten tilanne on kehittynyt niin, että tällaisen kohdan voidaan sanoa vanhentuneen.

Prioriteetit ja luokat

Suosituksessa on eri alakohdat jaettu etusija- eli prioriteettitasoille, "priority". Tämä luokitus kuvastaa periaatteessa arvioita siitä, miten vakavaa alakohdassa esitetyn ohjeen rikkominen on. Tarkemmin sanoen luokituksen kuvaus WAI-ohjeessa voidaan ilmaista seuraavasti:

Käytännössä tilanne ei ole ollenkaan näin yksinkertainen. Paljon riippuu myös mm. siitä, miten tärkeä on se sivun osa tai piirre, jossa ohjetta rikotaan. Todellisuudessa tasoluokituksessa on otettu huomioon myös se, miten monia ihmisiä jokin ongelma koskee. Toisaalta luokitus ei juurikaan ota huomioon sitä, miten työlästä kunkin ongelman korjaaminen on. Lisäksi kunkin prioriteettitason ja kunkin alakohdankin sisällä on hyvin monentyyppisiä kysymyksiä. Jotkin kohdat on luokiteltu aika yllättävästi, osittain ehkä siksi, että niissä on kyse vaikeasti arvioitavista asioista.

Esimerkiksi ohjeen kohta 14.2, "Täydennä tekstiä graafisella tai äänimuotoisella esityksellä, jos ne voivat auttaa sivun ymmärtämistä", on monissa tilanteissa monille ihmisille ratkaisevan tärkeä. Monimutkainen tekstiselostus jostakin asiasta voi olla mahdoton ymmärtää jopa ihmisten enemmistölle, ellei sitä havainnollisteta kuvituksella. Kuitenkin kohta on vain 3. prioriteettitasolla.

Prioriteettitasoja vastaavat esteettömyysluokat A, AA ja AAA siten, että

Prioriteettitasojen ja luokkien numerointi ja tunnukset ovat aiheuttaneet hämmennystä. Erityisesti luokkien tunnukset perustuvat järjestelmään, jota monet eivät tunne, paitsi ehkä luottokelpoisuusluokituksesta. Luokka A ei siis tarkoita parasta vaan alinta luokkaa.

Tasoluokitus ei siis kaikilta osin ole kovin looginen eikä käytännöllinen. Vaikka luokituksella voi olla käytännön toimintaa ohjaavaa merkitystä, se on opiskelussa ja usein muutenkin hyvä enimmäkseen panna syrjään. Kannattaa tarkastella suosituksia aihepiireittäin, ei niinkään luokittain. Sikäli kuin luokitukseen kiinnitetään huomiota, voi ohjenuorana ottaa huomioon, että Euroopan unionin parlamentin kannanotossa on käytännössä asetettu tavoitteeksi AA-luokitus, siis 1. ja 2. prioriteettitason vaatimusten huomioon ottaminen.

WAI-suosituksen pääkohdat kommentoituina

Tässä esitetään suosituksen pääkohdat eli "guidelines" lyhyesti selitettyinä ja kommentoituina. Lisäksi arvioidaan, missä määrin eri kohtien noudattaminen on testattavissa ohjelmilla. Alaotsikkoina on käytetty suosituksen pääkohtien tekstejä sellaisina, kuin ne ovat suomennoksessa. Tämä teksti on tarkoitettu luettavaksi yhdessä itse WAI-suosituksen tai sen suomennoksen kanssa.

WAI-suosituksen ohjeiden toteuttamisesta on alakohdittain jaoteltuja esimerkkejä Web-konsortion aineistossa Examples: WAI Web Content Accessibility Curriculum. Se on jo melko vanha ja puutteellinenkin, mutta siitä voi olla apua, kun yritetään hahmottaa alakohtien varsinaista merkitystä.

1. Tarjoa vaihtoehto ääni- ja kuvasisällölle

Tunnetuin ja käytännössä tavallisin osa tätä on vaihtoehtotekstien ilmoittaminen alt-määritteillä kaikille kuville (ja ns. karttalinkkien, image maps, kaikille alueille). Varsin monilla testaustyökaluilla voidaan tarkistaa, että kaikilla kuvilla on alt-määritteet. Sen sijaan ei ole mahdollista automaattisesti tarkistaa, että alt-määritteen arvo on kuvan sisältöä vastaava. Jotkin testaustyökalut tarkistavat määritteen arvon pituuden merkkeinä ja pyrkivät eri tavoin arvioimaan sen mielekkyyttä. Nämä tarkistukset voivat joskus auttaa huomaamaan, että vaihtoehtoteksti on huono, mutta ne voivat olla myös täysin harhaanjohtavia.

Valitettavasti vaatimus vaihtoehtoteksteistä kovin usein ymmärretään vain muodolliseksi, ilman ajatusta siitä, miksi kuvalla pitää olla vaihtoehtoteksti. Pahimmillaan tästä seuraa "vaihtoehtotekstejä", jotka ovat vain haitaksi. Lisäksi unohtuu helposti, että ohje koskee kaikkea ääni- ja kuvasisältöä, siis myös esimerkiksi sivuston sisältöön kuuluvia kuvia, äänitteitä ja videoita, joihin viitataan linkeillä. Tekstivaihtoehtojen tekeminen niille on usein työlästä, jopa mahdotonta, mutta esteettömyyden arvioinnissa ohjetta on siis otettava huomioon muutakin kuin sivuille upotetut kuvat.

Suomennoksesta ei täysin ilmene alkutekstin ajatus: "Provide equivalent alternatives to auditory and visual content". Tekstivaihtoehdon siis tulee olla ääni- tai kuvasisältöä vastaava. Tämä ei merkitse, että sen tulisi kuvailla sisältöä, vaan sen tulisi esittää tekstillä se sanoma, jonka ääni tai kuva esittää silloin, kun se kuullaan tai nähdään ja ymmärretään. Tästä seuraa, että tyhjä merkkijono (alt="") on täysin asianmukainen vaihtoehtoteksti silloin, kun kuvalla ei ole mitään sisällöllistä viestiä vaan se on pelkkä koriste tai havainnollistaa kuvallisesti jotain, joka on jo sanottu tekstissä. Kuitenkin tällainen oikea vaihtoehtoteksti on usein tulkittu WAI-suosituksen vastaiseksi!

WAI-suositus esittää vaihtoehtotekstejä koskevat periaatteet jossain määrin epäselvästi. Suositukseen liittyvä tekninen ohjeisto esittää joitakin huomionarvoisia esimerkkejä ja periaatteita vaihtoehtotekstin kirjoittamisesta, mutta ne kattavat vain osan erilaisista tapauksista. Lisäksi ne suosittavat longdesc-määritteitä, joita selaimet eivät ole ruvenneet tukemaan mainittavassa määrin, ja niin sanottuja D-linkkejä (description link), joita ei nykyisin pidetä kovinkaan hyvinä ajatuksina ja joiden käyttö sitä paitsi itse asiassa rikkoo WAI-suosituksen alakohtaa 13.1 (sellaisena kuin sitä on selostettu siihen liittyvässä HTML-tekniikkaohjeessa). Tilanteet, joissa kuvalle tarvittava vaihtoehtoteksti olisi pitkä (käytännössä pitempi kuin noin 50 merkkiä), on siksi syytä ratkaista muilla keinoin, kuten tavallisella linkillä, joka viittaa sivulle, jossa on erillinen tekstiselostus.

Seuraavilla sivuilla on lisätietoja vaihtoehtoteksteistä ja myös kommentteja siitä, missä määrin suositukset niistä ovat tulkinnanvaraisia tai ristiriitaisia:

2. Älä turvaudu pelkästään väreihin

Tämän kohdan tarkoitus ei missään tapauksessa ole kieltää värien käyttöä. Päinvastoin väreillä voidaan tehokkaasti edistää viestin perillemenoa kuten korostaa tärkeitä asioita tai auttaa lukijaa hahmottamaan sivun rakenne.

Sen sijaan kohta sanoo, ettei pidä luottaa väreihin niin, että niitä käytetään ainoana tapana esittää jokin informaatio. Kärjistetty esimerkki: jos sivulla on kaksi painiketta, jotka tarkoittavat jonkin hyväksymistä tai hylkäämistä ja joiden ainoa ero on, että toinen on vihreä ja toinen punainen, tästä syntyy suuri ongelma monille ihmisille, kuten värisokeille. Jos taas painikkeissa on selvästi tekstit "Hyväksyn" ja "En hyväksy", on täysin hyväksyttävää säestää tätä väreillä.

Tavallaan pääkohdasta aika erillinen alakohta on se, että värien pitäisi muodostaa riittävä kontrasti. Tyypillinen virhe on käyttää tummaa tekstiä tummalla pohjalla taikka vaaleanharmaata tekstiä vaalealla pohjalla.

Jotkin tarkistusohjelmat antavat yleisen varoituksen tästä aiheesta, jos sivulla ylipäänsä käytetään värejä. Käytännössä tätä ei juurikaan voi tarkistaa täysin automaattisilla ohjelmilla. Sen sijaan voidaan tavallisilla selaimilla tai erityisillä testausohjelmilla tutkia, miten sivu toimii ilman värejä.

3. Käytä merkintäkieltä ja tyylitiedostoja ja käytä niitä oikein

Tämän kohdan perusviesti on se, että sivut tulisi tehdä käyttäen W3C:n suositusten mukaista HTML-merkkausta siten, että ulkoasuseikat hoidetaan tyylitiedostoilla eli CSS:llä. Tarkkaan ottaen tämä tarkoittaa, että HTML-merkkauksessa ei pitäisi lainkaan käyttää ulkoasua sääteleviä piirteitä, kuten font-elementtejä tai align-määritteitä.

Tavoitteen käytännöllisyyttä rajoittaa se, että kaikkia ulkoasuseikkoja ei toistaiseksi voi hoitaa CSS:llä toimivalla tavalla. Rajoitetusti ja hallitusti käytettyinä eivät esimerkiksi taulukoiden ulkoasuun vaikuttavat HTML:n piirteet mitenkään heikennä esteettömyyttä, pikemminkin päinvastoin.

Käytännössä erityisen tärkeä periaate tässä kohdassa on otsikoiden ja listojen esittäminen niitä varten tarkoitetulla HTML-merkkauksella. Kun otsikot esitetään h1-, h2- jne. elementeillä, sivu toimii paljon paremmin monilla puheselaimilla, siitä saa automaattisesti muodostettua sisällysluettelon eräissä selaimissa jne. Vastaavasti listarakenteiden (ul ja ol) käyttö auttaa monissa tilanteissa selaimia esittämään listan kohdat selvästi toisistaan erottuvina.

Toisaalta tässä pääkohdassa on eräitä ongelmallisia kohtia. Siihen sisältyy (alakohdassa 3.1) ohje "jos sopiva merkintäkieli on olemassa, käytä tiedon esittämiseen mieluummin sitä kuin kuvia" ja mainitsee esimerkkinä matemaattisten lausekkeiden esittämiseen käytettävän MathML-kielen. Ohje on kuitenkin epärealistinen, kuten esimerkki osoittaa: MathML on kyllä olemassa mutta ei kovinkaan käytännöllinen ratkaisu, eikä sille edelleenkään ole sellaista tukea selaimissa, että sen käyttö Web-sivuilla olisi yleisesti mielekästä. Teoriassa MathML mahdollistaisi lausekkeiden esteettömämmän esittämisen, mutta käytännössä useimmat selaimet eivät osaa esittää MathML:ää lainkaan. (Yksinkertaisimpia matemaattisia lausekkeita voi tyydyttävästi esittää HTML:n ja CSS:n tarjoamilla välineillä. Vaativampien kaavojen esittämiseen on kuvien käyttö usein ainoa käyttökelpoinen ratkaisu. Ks. sivua Math in HTML (and CSS).)

Toinen ongelma on alakohta 3.7, jonka mukaan lainaukset tulisi esittää q- ja blockquote-elementeillä. Näistä ensin mainittu, joka on tarkoitettu lyhyisiin, tekstin sisällä esitettäviin lainauksiin, on käytännössä lähes toteuttamatta selaimissa. Jos sitä käytetään, valtaosa käyttäjistä näkee (tai kuulee) lainatun tekstin normaalina tekstinä. Lisäksi q-elementti on kokonaan poistettu XHTML 2.0 -luonnoksesta. Täten lyhyet lainaukset on syytä esittää lainausmerkkejä käyttäen.

Esteettömyyden kannalta lainausten esittämisessä on käytännössä tärkeintä se, että itse tekstistä esimerkiksi ääneen luettuna ilmenee, milloin lainaus alkaa ja milloin se päättyy. Tämä voidaan toteuttaa esimerkiksi johdantolauseella ennen lainausta ja lähdeviittauksella lainauksen jälkeen. Tällöin on toissijaista, onko lainaus merkattu q- tai blockquote-elementillä tai onko lainatun tekstin ympärillä lainausmerkit tai onko se esitetty esimerkiksi kursiivilla. Esimerkki:

Suomessa ei ole erityistä lainsäädäntöä esteettömyydestä. Se on kuitenkin ilmaistu tavoitteeksi yleisellä tasolla, muun muassa seuraavasti:

Ketään ei saa ilman hyväksyttävää perustetta asettaa eri asemaan sukupuolen, iän, alkuperän, kielen, uskonnon, vakaumuksen, mielipiteen, terveydentilan, vammaisuuden tai muun henkilöön liittyvän syyn perusteella.

Lähde: Suomen perustuslaki, 6 §

Tarkistusohjelmilla voidaan selvittää merkkauksen ja CSS-tiedostojen muodollinen oikeellisuus, joka on sinänsä tärkeää, joskaan ei useinkaan varsinaisesti esteettömyyskysymys. Niillä voidaan myös useimmissa tapauksissa havaita sellaisten HTML-piirteiden käyttö, joita W3C ei suosittele.

Tarkistusohjelmat eivät kuitenkaan pysty juurikaan arvioimaan, onko HTML:n ja CSS:n käyttö sisällöllisesti oikeaa ja järkevää. Esimerkiksi blockquote-elementin käyttö pelkkään tekstin sisentämiseen, ilman että teksti olisi mistään lainattua, on WAI-suosituksessa kiellettyä, mutta ohjelmilla ei juurikaan voida tutkia sitä, onko teksti lainattua. Tarkistusohjelmat eivät myöskään havaitse esimerkiksi sellaista melko tavallista virhettä, että tekstissä käytetään kappalejaon (p-elementtien) asemesta pakotettuja rivinvaihtoja (br-elementtejä). Sellainen ei nimittäin riko mitään muotosääntöä vastaan eikä muutenkaan ole ohjelmalla tehtävässä analyysissa havaittavissa.

4. Varmista, että käytetty kieli käy selvästi ilmi tekstistä

Tämä kohta käsittelee otsikkonsa vastaisesti kielen teknistä ilmoittamista merkkauksessa, tarkemmin sanoen lähinnä kielimerkkausta eli sivun ja sen elementtien kielen ilmoittamista lang-määritteellä tai xml:lang-määritteellä. Periaatteessa nämä määritteet voivat auttaa, kuten suosituksessa sanotaan, esimerkiksi puheselaimia esittämään tekstin ymmärrettävästi. Käytännössä niiden vaikutus on erittäin vähäinen, koska vain harvat ohjelmat (lähinnä IBM Home Page Reader) käyttävät hyväksi kyseistä informaatiota. Lisäksi kielimerkkauksen yksityiskohtiin liittyy paljon ongelmia, joita kuvaa sivusto Kielimerkkaus: tekstin kielen ilmoittaminen merkkausjärjestelmissä.

Käytännössä voidaan pitää esteettömyyden kannalta riittävänä kielimerkkauksena seuraavanlaista lang-määritteiden käyttöä:

Periaatteessa tämä ei useinkaan riitä edes 1. prioriteettitason vaatimusten täyttämiseen, koska tekstissä on yksittäisiä vieraskielisiä sanoja, ainakin nimiä. Toisaalta vaatimuksia ei tältä osin täytä esimerkiksi WAI-suositus itsekään.

Suosituksen hengen mukaista on kyllä ymmärtää tämä kohta laajemmin niin, että käytetyn kielen tulisi ilmetä itse tekstistä. Jos esimerkiksi suomenkielisellä sivulla oleva linkki viittaa muunkieliseen sivuun, on hyvä ilmaista asia itse linkissä tai sen yhteydessä. Usein riittää, että linkkinä on viitatun sivun nimi sen kielellä.

Kielimerkkausta koskevien ohjeiden noudattaminen ei ole käytännössä tutkittavissa nykyisillä ohjelmilla, koska ne eivät pysty tunnistamaan sen tarpeellisuutta ja oikeellisuutta. Poikkeuksena on koko dokumenttia koskevan kielimääritteen käyttö.

Pääkohta sisältää myös alakohdan, jonka mukaan jokainen lyhenne (abbreviation) ja lyhennesana (acronym) tulisi "avata" ja selittää, kun se esiintyy tekstissä ensimmäistä kertaa. Tämäkin on vaatimus, joka itse asiassa merkitsee, että juuri mikään sivu (edes WAI-ohje itse) ei ole WAI-ohjeen mukainen. Käytännössä sitä on pakko tulkita niin, että ainakin kaikkein tavallisimmat lyhenteet jätetään selittämättä eikä varsinaisia lyhennesanoja eli akronyymejä lainkaan selitetä, ellei itse sivun sisältö tee mielekkääksi kertoa, mistä sanoista esimerkiksi nimi "abloy" tai englannin "radar" johtuu.

Vaikka tämä alakohta painottuu erityisen merkkauksen, nimittäin abbr- ja acronym-elementtien, käyttämiseen, niin tämä puoli asiasta on vähämerkityksisempi ja kiistanalaisempikin. Erityisesti huomattakoon, että acronym-elementin merkitystä ei ole koskaan kunnolla määritelty ja että XHTML 2.0 -luonnoksesta se on kokonaan poistettu. Lisäksi abbr-elementin käyttö saattaa aiheuttaa suoranaisia ongelmia, kuten hämmentävän pisteviivan tulostumisen lyhenteen alle myös paperitulosteisiin joissakin selaimissa. Onkin perusteltua ja suosituksen idean ja hengen mukaista keskittyä selittämään lyhenteet ja muut erikoisilmaisut itse tekstissä tai erillisessä dokumentissa, johon teksti viittaa. Aihetta käsittelee tarkemmin sivu Explaining abbreviations, acronyms and symbols on Web pages.

5. Luo taulukoista sujuvasti muuntuvia

Usein esiintyy epätietoisuutta siitä, mitä suositukset sanovat taulukkotaitosta. Taulukkotaitto on HTML:n taulukkorakenteen (eli table-elementin) käyttämistä pelkkään sivun taittamiseen, siis elementtien asemointiin kuvaruudulle, kun kyseiset elementit eivät loogisesti muodosta taulukkoa eli eivät ole (jossain mielessä) taulukoituja tietoja. Vastoin melko yleistä luuloa WAI-suositus ottaa melko lievän kannan: taulukkotaitosta johtuviin ongelmiin viitataan 3. pääkohdassa, ja tässä 5. pääkohdassa mainitaan ensin, että niitä tulisi välttää. Alakohta 5.3 on suomennoksessa jyrkempi, "Älä käytä taulukoita ulkoasun luomiseen", mutta siinä on käännösvirhe. Alkuperäisessä tekstissä virke jatkuu tavalla, joka voidaan suomentaa näin: "ellei taulukko ole mielekäs, kun se linearisoituu". Linearisoiminen tarkoittaa taulukon esittämistä tavalla, jossa solujen sisällöt ovat peräkkäin siinä järjestyksessä, jossa ne esiintyvät merkkauksessa.

Käytännössä on olennaista ottaa huomioon, että taulukkotaittoa on hyvin monenlaista ja että sen vaikutus esteettömyyteen vaihtelee huomattavasti. Esimerkiksi pelkkä tekstipalstan tai koko sivun leveyden rajoittaminen kirjoittamalla teksti määrälevyisen taulukon sisään ei juurikaan heikennä esteettömyyttä. Se luonnollisestikin täyttää linearisoituvuusvaatimuksen, koska taulukossa on tällöin tyypillisesti vain yksi solu. Sen sijaan jopa kymmenien elementtien sijoittelu taulukkotaitolla suunnilleen siihen tapaan, kuin sanomalehtiä taitetaan, aiheuttaa verkkosivulla monenlaisia ongelmia. Usein linearisointi tällöin johtaa sekasotkuun. Linearisoituvuuden voi testata käyttämällä sopivaa ohjelmaa ja katselemalla tai kuuntelemalla sen linearisoimaa esitystä, mutta automaattisempi analyysi ei ole mahdollinen.

Sivun leveyden rajoittaminen ja yleensä määrälevyiset taulukot ovat kyllä usein ongelmallisia käytettävyyden kannalta. Tämä koskee varsinkin tilannetta, jossa asetettu kiinteä leveys on suuri, jolloin sivu ei useinkaan mahdu edes koko kuvaruudun kokoiseen ikkunaan. Tämä on tavallisimpia ongelmia Web-sivuilla, ja se voi suuresti vaikeuttaa käyttöä pienillä laitteilla. Tämän pääkohdan nimessä sanat "sujuvasti muuntuvia" viittaa kuitenkin lähinnä linearisoitavuuteen, ei varsinaisesti sivun toimimiseen erilevyisissä ikkunoissa.

Tämä pääkohta käsittelee ennen muuta sellaista lisämerkkausta, jolla varsinaiset taulukot (taulukoidut tiedot) saadaan esteettömämmiksi. Periaatteessa tämä on erittäin tärkeää. Jos sivulla on esimerkiksi taulukko, jossa on kolmesataa riviä ja kymmenen saraketta, on puhesyntetisaattoria käytettäessä tavattoman hankalaa poimia esille haluttu tieto yhdestä solusta. Kehittyneet selaimet pystyvät auttamaan tässä, jos taulukkoon liittyy lisätietoa sen rakenteesta. Käytännössä ongelmaksi muodostuu, että tarvittavan merkkauksen lisääminen voi olla hyvin työlästä (ja se lisää sivun kokoa ja siten latausaikaa) ja saavutettava hyöty on usein kyseenalainen, koska mainitunlaiset kehittyneet selaimet ovat vielä suhteellisen harvinaisia.

Tämän pääkohdan alakohdat liittyvät enimmäkseen mainittuun lisämerkkaukseen. Ensinnäkin jos kyseessä on datataulukko eli taulukoitua tietoa, niin taulukon solut pitäisi jakaa tietosoluihin (datasoluihin), jotka merkataan td-elementeiksi (table data), ja otsikkosoluihin, jotka merkataan th-elementeiksi (table header). Tämä on yleensä helppoa ainakin siltä osin, että yleensä datataulukon alussa on (ja olisi syytä olla) rivi sarakkeiden otsikoita ja muut solut ovat enimmäkseen tietosoluja. Toinen periaate on, että loogisesti yhteenkuuluvat rivit tulisi ryhmitellä thead, tfoot- ja tbody-elementeillä. Lisäks pitäisi ilmaista sarakerakenne col-elementeillä ja tarvittaessa ryhmitellä sarakkeet loogisesti colgroup-elementeillä. Tämäkin on suhteellisen helposti tehtävissä ja auttaa esimerkiksi sivun myöhempää muokkaajaa hahmottamaan taulukon rakenteen. Mutta välitön käytännön vaikutus esteettömyyteen on yleensä melko pieni.

Lisäksi tulisi käyttää scope- tai headers-määritteitä ja mahdollisesti myös axis-määritteitä taulukossa esiintyvän tiedon suhteita, kuten sitä, onko otsikkosolu sarake- vai riviotsikko. Käytännössä scope- ja headers-määritteet ovat keskenään vaihtoehtoisia, ja niistä scope-määritteet vaativat paljon vähemmän työtä mutta eivät riitä mutkikkaimmissa tapauksissa, ja lisäksi jotkin vanhahkot selaimet tukevat vain headers-määritteitä. Tilanne on siis melko hankala. Kuvaavaa on, että WAI-suosituksessakaan ei suinkaan ole merkattu kaikkia taulukoita suosituksen mukaisella tavalla.

Suosituksen mukaan tulisi table-elementissä olla summary-määrite, joka sisältää tiivistelmän taulukon tarkoituksesta ja rakenteesta. Asiantuntijoidenkin käsitykset tämän hyödyllisyydestä ja tulkinnasta vaihtelevat paljon. Monet tarkistusohjelmat valittavat summary-määritteiden puuttumisesta, mutta epäselvää suosituksessa on, tulisiko myös taulukkotaittoon käytetyssä table-elementissä olla tämä määrite ja mitä siinä silloin pitäisi olla. Tämän määritteen olemassaolo on tietysti ohjelmilla tarkistettavissa, mutta ihmisen ratkaistava asia on, onko määrite on sisällöltään järkevä.

Lisämerkkausta ovat vielä otsikkosoluille abbr-määrittellä määriteltävät lyhenteet. Niitä kehotetaan käyttämään silloin, kun otsikkosolun teksti on pitkä. Ajatuksena on lähinnä se, että jos puheselain lukee taulukon sisältöä tyyliin "rivi ..., sarake ..., sisältö on ...", niin esitys voisi olla miellyttävämpi, jos se käyttäisi rivien ja sarakkeiden niminä jotain lyhyempää kuin otsikkosoluissa ehkä olevat pitkätkin tekstit.

Kaiken kaikkiaan siis taulukoiden merkkaaminen kaikki suosituksen kohdat täyttävällä tavalla voi olla työlästä ja muutenkin ongelmallista. Tärkeää on muistaa, että nämä ohjeet koskevat vain "oikeita" taulukoita, siis taulukkomuotoista tietoa. Sellaisia on vain pienehkö osa verkkosivujen table-elementeistä.

6. Varmista, että uutta teknologiaa hyödyntävät sivut muuntuvat sujuvasti myös vanhemmalla teknologialla käytettäviksi

Tämä pääkohta ilmaisee periaatteen, joka tunnetaan nimellä graceful degradation, joka voitaisiin vapaasti suomentaa ilmaisulla "siisti latistuminen". Tämä merkitsee parhaimmillaan sitä, että kehittynyttä tekniikkaa käyttävä sivu on esitettävissä myös (paljonkin) yksinkertaisemmalla tekniikalla niin, että esitystapa on niin hyvä, kuin yksinkertaisempi tekniikka sallii. Periaatetta voidaan kyllä tulkita lievempäänkin suuntaan niin, että riittää, että sisältö ylipäänsä on käytettävissä vanhemmillakin tekniikoilla.

Käytännössä tärkein kohta koskee tyylien eli CSS:n käyttöä. Vaikka useimmissa selaimissa on nykyisin jonkinlainen CSS-tuki, on useita mahdollisia syitä poistaa se käytöstä. Siistin latistumisen periaate sisältää yksinkertaisesti sen, että sivu on hyvin luettavissa myös ilman CSS:n käyttöä, vaikka tämä yleensä merkitseekin yksitoikkoisempaa ulkoasua. Tätä vastaan rikkoo esimerkiksi esimerkiksi sellainen tavallinen menettelytapa kuin otsikoiden merkkaaminen kappaleiksi ja muotoilu otsikon näköisiksi vain CSS:llä (esim. <p class="otsikko3">otsikkoteksti</p> eikä <h3>otsikkoteksti</p></h3>). Kun CSS ei ole käytössä, otsikot näyttävät (ja kuuluvat) tällöin vain tekstikappaleilta.

Muissa alakohdissa käsitellään erikoiskysymyksiä: dynaamisesti päivittyviä sivuja sekä skriptejä, sovelmia ja muita vastaavia. Käytännössä tavallisin ongelma on ehkä se, että linkkejä toteutetaan tavalla, joka tekee ne täysin toimimattomiksi, kun skriptit eivät ole käytössä. Alakohdassa 6.3 mainittu noscript-elementti saa esityksessä ehkä liian ison painon, sillä skriptejä käyttävien sivujen esteettömyys on lähes aina toteutettava muilla keinoin.

7. Varmista, että käyttäjä voi itse ohjata ajastettuja sisällön muutoksia

Yleinen periaate tässä on, että käyttäjän tulisi voida estää kaikenlainen liike sivulla ja kontrolloida, milloin liikettä on. Tämä on sitten jaoteltu alakohtiin tekniikoiden mukaan. Käytännössä selainten tarjoamat mahdollisuudet liikkeen kontrolloimiseen ovat edelleen vähäiset, joten suositus merkitsee, että vilkkumista, liikettä, automaattista sivun päivitystä ja uudelleenohjaamista toiselle sivulle pitäisi välttää.

Tässä tarkoitettu uudelleenohjaus (ns. meta refresh) on yleensä helposti vältettävissä käyttämällä näkymätöntä HTTP-uudelleenohjausta (HTTP redirect). Sen sijaan sivun automaattinen päivittäminen esimerkiksi viiden minuutin välein on joissakin sovelluksissa olennaista. Liikkuva sisältö, esimerkiksi video tai animaatio, voidaan toteuttaa joko viittaamalla siihen linkeillä tai upottamalla se osaksi Web-sivua. Jälkimmäisessä tapauksessa tämä kohta merkitsee sitä, että upotus tehdään tavalla, joka ei jätä pois niitä kontrollimahdollisuuksia, jotka selain tai selaimen lisäosa pystyisi toteuttamaan, esimerkiksi kuvan pysäytys ja pikakelaus. Esteettömyyden kannalta paras tulos saavutetaan, jos esimerkiksi animaatio ei käynnisty automaattisesti vaan sivulla on staattinen kuva, jota napsauttamalla animaatio käynnistyy, ja tästä on selkeät ohjeet.

8. Varmista upotettavien käyttöliittymien saavutettavuus

Vaikka esimerkiksi sivun osana olevan animaation esityksen kontrollit olisivat näkyvissä, jolloin käyttäjä voi esimerkiksi pysäyttää esityksen, nämä kontrollit eivät aina ole käytettävissä esteettömästi. Tyypillinen esimerkki on tilanne, jossa ne toimivat vain hiirellä napsauttamalla.

WAI-suositukseen liittyvissä tekniikkaohjeissa on tietoja siitä, miten sovelmien ja skriptien ohjaus voidaan tehdä esteettömäksi. Esimerkiksi lomakkeen kenttään on voitu liittää onclick-määrite, joka käynnistää jonkin toiminnon (esimerkiksi tarkistuksen), kun kenttää napsautetaan hiirellä. Suosituksen mukaan siihen pitäisi tällöin yleensä liittää myös onkeypress-määrite, jotta toiminnon voisi käynnistää myös vain näppäimistöä käyttäen. (Jos toiminto määritellään funktioksi, tämä ei vaadi paljoakaan lisätyötä: kumpaankin määritteeseen kirjoitetaan sama funktionkutsu.)

9. Suunnittele lopputulos laiteriippumattomaksi

WAI-suositus puhuu useassa yhteydessä laiteriippumattomuudesta, ja se tarkoittaa, että sivujen tulisi toimia hyvinkin erilaisilla laitteilla. Tässä pääkohdassa tarkoitetaan ennen muuta käyttäjän laitteen tarjoamia ja käyttäjälle mahdollisia vuorovaikutuksen välineitä. Käytännössä kyse on nykyisin paljolti siitä, että sivun tulee olla käytettävissä ilman hiirtä taikka tilanteissa, joissa hiiren tai muun kohdistimen tarkka käyttö on vaikeaa. Vaihtoehtona on tällöin lähinnä näppäimistö.

Laiteriippumattomuus on varsin laaja ongelmakenttä, ja tämän pääkohdan alakohdat käsittelevät vain muutamia erityisaiheita. Yleiskatsauksen aiheeseen esittää W3C:n Device Independence Activity -ryhmän tuottama muistio Device Independence Principles.

WAI-suositus mainitsee erityisesti tabindex- ja accesskey-määritteet. Monet asiantuntijat eivät kuitenkaan pidä näitä määritteitä hyvinä ratkaisuina. On kyllä tärkeää, että linkkien tai lomakkeen kenttien välillä voi liikkua sarkainnäppäimellä eli tab-näppäimellä, mutta ensisijaisesti tämä pitäisi hoitaa sillä, että ne ovat valmiiksi oikeassa järjestyksessä. Toisin sanoen niiden järjestyksen sivun merkkauksessa tulisi vastata luonnollista läpikäyntijärjestystä. Jos näin on, niin tabindex-määritettä ei tarvita, ja jos ei ole, niin tabindex on vain osittainen ratkaisu (mm. siksi, että kaikki selaimet eivät tue sitä).

Vielä paljon voimakkaammin on kyseenalaistettu accesskey-määritteiden merkitys. Niillä voidaan periaatteessa saada aikaan, että näppäinyhdistelmillä päästään eri kohtiin sivua. Käytännössä toteutukset ovat puutteellisia, ja lisäksi accesskey-määritteillä tehdyt asetukset (esim. Alt s vie johonkin sivun erityiseen kohtaan) voivat poistaa käytöstä sellaisia selainten tarjoamia käyttötapoja, joihin monet käyttäjät ovat tottuneet (esim. Alt s avaa Suosikit-kansion).

Monet sivujen tarkistamisen työkalut huomauttavat tabindex- ja accesskey-määritteistä, kenties jopa antavat virheilmoituksen jokaisesta linkistä, jossa niitä ei ole käytetty. WAI-suosituskin kuitenkin esittää tabindex-määritteet vain vaihtoehtona sivun loogiselle suunnittelulle, ja accesskey-määritteitä se suosittaa tärkeille linkeille ja kentille.

10. Käytä väliaikaisratkaisuja

Tämä pääkohta on oudosti muotoiltu. Sen on tarkoitus sanoa: käytä erilaisia tilapäisiä ratkaisuja silloin, kun ne ovat tarpeen esimerkiksi selaimissa olevien tunnettujen puutteiden takia. Tarkoitus ei suinkaan ole kannustaa väliaikaisiin ratkaisuihin missään muussa mielessä.

Eri alakohdissa käsiteltyjen asioiden tilanne on tätä kirjoitettaessa, syksyllä 2003, seuraavanlainen, eikä se todennäköisesti muutu kovinkaan pian:

  1. "Kunnes selaimet antavat käyttäjien estää automaattisesti avautuvat ikkunat, älä käytä itsestään avautuvia valikkoja tai muita ikkunoita äläkä vaihda aktiivista ikkunaa tiedottamatta asiasta käyttäjälle." Tämä kohta on edelleen hyvin aiheellinen. Vaikka selaimet tarjoavat aiempaa enemmän tässä tarkoitettuja kontrollimahdollisuuksia käyttäjälle, ne ovat osittain hankalia käyttää ja saattavat poistaa käytöstä sellaisiakin piirteitä, joista on käyttäjälle hyötyä.
  2. "Kunnes selaimet tukevat ohjetekstin ja lomakkeiden suoraa yhteyttä, varmista että ohjeteksti (label-elementti) on ennen täytettävää kenttää." Lisäksi on muita ohjeita kentän ja ohjetekstin välisestä suhteesta. Tähän on tullut aiemmin mainittu muutos eli ohjeteksti saa olla (ja sen on hyväkin olla) kentän jäljessä silloin, kun kenttänä on valintanappi (radio button) tai asetusnappi (checkbox). Mutta kohta on muutoin edelleen ajankohtainen, sillä selainten tuki label-elementille on edelleen puutteellinen.
  3. "Kunnes selaimet (sekä apuvälineet) tulkitsevat vierekkäiset tekstisarakkeet oikein, luo lineaarinen tekstivastine (samalle tai omalle sivulleen) kaikille taulukoille, jotka sisältävät tekstiä vierekkäisissä sarakkeissa ja sallivat tekstin jakamisen usealle riville." Tämän merkitys on vähentynyt, eikä sen mukaisesti ole juurikaan toimittu, koska se vaatisi huomattavaa lisätyötä. Selaimet ja apuvälineet ovat kehittyneet niin, että ne yleensä pystyvät esittämään ainakin yksinkertaiset taulukot niiden rakenteen mukaan. Huomattakoon, että yleensä taulukoissa teksti saattaa jakautua eri riveille (etenkin kapeassa ikkunassa), ja tämän estäminen aiheuttaa usein enemmän ongelmia kuin ratkaisee.
  4. "Kunnes selaimet käsittelevät tyhjiä lomake-elementtejä oikein, sisällytä syöttö- ja tekstikenttiin aina jokin oletustieto."
    "Oletustieto" tarkoittaa tässä kentälle asetettavaa alkuarvoa. Joskus on mahdollista asettaa mielekäs alkuarvo, esimerkiksi käyttäjän aiemmin antamien tietojen perusteella, mutta tämä alakohta käskee kirjoittamaan alkuarvon aina muulloinkin. Tätä on pidettävä täysin vanhentuneena (myös W3C:n taholta esitettyjen lausumien mukaan). Alun alkaenkin kyse oli vain muutamista ohjelmista, joiden osuus on vähentynyt. Lisäksi "oletustiedon" asettaminen vain tämän ohjeen noudattamiseksi aiheuttaa huomattavia ongelmia, muun muassa sen, että käyttäjä joutuu erikseen poistamaan "oletustiedon".
  5. "Kunnes selaimet (kuten apuvälineet) erottavat vierekkäiset linkit selkeästi toisistaan, lisää linkkien väliin välilyönti sekä linkittämättömiä, tulostettavia merkkejä." Tämä tarkoittaa, ettei sivulla pitäisi olla esimerkiksi sellaista kuin "koti talous", missä "koti" ja "talous" ovat erillisiä linkkejä, vaan välissä pitäisi olla jokin erotinmerkki, esimerkiksi "koti | talous". Ongelma koskee edelleen joitakin selaimia, mutta sen merkitys on vähentynyt. Toisaalta on hahmotettavuuden kannalta usein parempi edelleenkin erottaa peräkkäiset linkit toisistaan, jos ne ovat samalla rivillä. On tulkinnanvaraista, tarkoittaako ohje myös tilanteita, joissa linkit ovat eri riveillä. Suomennoksen tulkinta on toinen, mutta jotkin tarkistusohjelmat huomauttavat jopa listarakenteista, jonka kohdat ovat linkkejä, ellei kohtien lopussa ole (linkkitekstin ulkopuolella olevia) välimerkkejä!

11. Käytä W3C:n teknisiä ratkaisuja ja noudata ohjeita

Alkuteksti tarkoittaa ohjeilla nimenomaan W3C:n ohjeita (guidelines). Tämä pääkohta on luonteeltaan toisaalta hyvin laaja, toisaalta melko ylimalkainen. Suuri osa W3C:n tekniikoista ja ohjeista ei mitenkään erityisesti liity esteettömyyteen. Tosin tekniikkaohje perustelee suositusta sillä, että W3C:n tekniikat on kehittelyvaiheessa tarkistettu esteettömyydenkin kannalta.

Alakohdat esittävät huomattavia varaumia, joiden mukaan W3C:n tekniikoita suositellaan tilanteisiin, joissa ne ovat soveliaita (appropriate) ja selainten tukemia (supported). Suuri osa tässä kohdassa ja siihen liittyvissä tekniikkaohjeissa mainituista tekniikoista ei täytä näitä ehtoja tai täyttää ne vain pieneltä osin. Esimerkiksi alakohdassa 11.3 mainittu sisällönvalinta (content negotiation), kuten automaattinen kielivalinta, on sinänsä täysin toimivaa tekniikkaa, mutta selainten ja käyttäjien valmius sen hyödyntämiseen on vielä varsin suppea. Webin kokonaisuuden kannalta taas lähinnä kokeellisiksi tai pelkiksi määrittelyiksi voidaan luokitella mm. puhe-esityksen tyyliohjeet (aural style sheets).

Tässä kohdassa alakohta 11.2 koskee W3C:n tekniikoiden epäsuotaviksi (deprecated) ilmoitettujen piirteiden välttämistä. Jos alakohta tulkitaan niin, että kyseisiä piirteitä ei saa lainkaan käyttää, se merkitsee varsin pitkälle menevää vaatimusta. Erityisesti HTML:ssä on suuri joukko sellaisia laajasti käytettyjä piirteitä, jotka on ilmoitettu epäsuotaviksi, nimittäin useimmat ulkoasua säätelevät piirteet. Niiden välttäminen silloinkin, kun vastaavia ulkoasuefektejä ei voi saada aikaan muilla tavoin (CSS:llä), merkitsee huomattavaa rajoitusta sivujen muotoilulle. Alakohta voidaan kuitenkin lukea niin, että epäsuotavia piirteitä ei pitäisi käyttää ilman erityisiä perusteita ja että niitä käytettäessä tulisi erityisesti selvittää niiden mahdollinen vaikutus esteettömuuteen.

Alakohta 11.4 käsittelee ns. vaihtoehtoisia sivuja. Niillä yleensä tarkoitetaan pelkkää tekstiä sisältäviä (text-only) sivuja, mutta WAI-suosituksessa tarkastelukulma on paljon laajempi. Kuvien käyttöhän ei itsessään tee sivuja esteellisiksi, kunhan sivu tehdään oikein. Vaihtoehtoinen sivu voi sen sijaan olla tarpeen silloin, kun varsinaista sivua ei teknisten tai muiden rajoitusten takia voi tehdä esteettömäksi. Esimerkkinä voisi olla sivu, jossa olennaista sisältöä on kaaviokuvina. Käytännön syyt rajoittavat mahdollisuuksia kirjoittaa kuvaelementeille riittävän hyvät vaihtoehtotekstit, joten voi olla parempi tehdä sivulle kokonaisuutena vaihtoehtoinen esitys ja viitata siihen linkillä.

Suosituksen periaatteena on kuitenkin, että vaihtoehtoiset sivut ovat vihoviimeinen vaihtoehto, jota pyritään välttämään tekemällä normaaleista sivuista eri tilanteisiin mukautuvia. Suositus korostaa, että jos vaihtoehtosivuja tehdään, niiden sisällön tulee olla yhtä hyvin ajan tasalla kuin varsinaisten sivujen. Vaikka tämä voidaankin monissa tilanteissa saavuttaa sopivilla tekniikoilla ja menettelytavoilla, käyttäjät ovat usein oppineet, että "tekstivaihtoehdot" ovat toisen luokan sivuja.

Usein on esitetty, että tekstiversio on hyväksyttävä ja hyväkin ratkaisu, kunhan suosituksessa esitetyt vaatimukset sen laadusta täytetään. Ja vaikka varsin tavallista on, että tekstiversio on suppeampi ja ehkä vanhentuneempikin kuin varsinainen versio, on kyllä mahdollista sopivilla tekniikoilla ja järjestelyillä täyttää mainitut vaatimukset. Periaatteessa suositus kuitenkin lähtee siitä, että tekstiversio on aina ratkaisu, joka ilmaisee epäonnistumista. Monien mielestä kuitenkin oikein toteutetut tekstiversiot voivat parantaa esteettömyyttä ja käytettävyyttä muun muassa siksi, että ne tarjoavat yksinkertaisen vaihtoehdon, muun muassa ikään kuin tekstiselainvaihtoehdon graafisten selaintenkin käyttäjille. Toisaalta on sanottu, että tekstiversion tarjoaminen vaihtoehtona vammaisille on verrattavissa kylttiin "vammaiset takaoven kautta, olkaa hyvä".

Vaikka suositus ei erikseen mainitsekaan vaihtoehtosivujen kuvailemista, sen hengen mukaista on kertoa totuudenmukaisesti, miten ne sisällöltään suhtautuvat varsinaiseen versioon. Jos ne ovat yhtä kattavia ja yhtä ajanmukaisia, niin tämä seikka on käytännössä syytä erikseen mainita, koska monet käyttäjät ovat oppineet odottamaan, että vaihtoehtosivut ovat suppeampia.

Mainittu alakohta, 11.4, on tärkeä muistaa, jotta siihen voi viitata, kun sivujen teosta keskusteltaessa nostetaan esiin tekstimuotoisten vaihtoehtosivujen tekeminen. Saatetaan jopa esittää, että esteettömyys vaatisi sitä. Tavallisempaa on, että esteettömyyden koko ongelmakenttä pyritään kutistamaan kysymykseksi "tekstiversiosta".

12. Tarjoa selkeää tietoa sivujen sisällöstä ja rakenteesta

Tässä pääkohdassa on kyse sivujen varsinaisen sisällön jäsentämisestä, kun taas seuraava koskee sivujen viittauksia toisiinsa (linkitystä, navigointia). Kohdan alakohdat ovat seuraavat:

  1. "Nimeä jokainen kehys erikseen navigoinnin helpottamiseksi." Alkuteksti käyttää nimeämisestä verbiä title, ja tässä viitataan erityisesti frame-elementin title-määritteeseen. Käytännössä näillä määritteillä on vähäinen merkitys. Paljon olennaisempaa on kehysten varsinainen nimeäminen kuvaavilla name-määritteillä (esim. name="navigointi", ei name="left"), joihin kehysten käsittely perustuu useissa selaimissa. Kuitenkin tekniikkadokumentti sisältää esimerkin, jossa name-määritteitä ei ole lainkaan!
  2. "Kuvaa kehysten tarkoitus ja niiden väliset suhteet, mikäli tämä ei käy ilmi kehysten otsikoista." Tässä viitataan erityisesti longdesc-määritteeseen, joka on kuitenkin jäänyt lähes pelkästään teoreettiseksi. Käytännössä kohtaa on järkevää tulkita niin, että kullakin kehyksellä tulisi olla sen sisältöä kuvaava nimi ja että kehyksiä pitäisi olla niin vähän, että niiden suhteiden hahmottaminen on helppoa.
  3. "Jaa suuret informaatiokokonaisuudet sopiviin, helpommin hallittaviin kokonaisuuksiin." Tämä on erittäin keskeinen periaate. Asiaa voi hiukan hämärtää se, että suosituksessa mainitaan ensin pari lomakkeisiin liittyvää yksityiskohtaa (optgroup, fieldset, legend), sitten sisäkkäiset listat ja vasta niiden jälkeen ehkä olennaisin, otsikoiden käyttö rakenteen osoittamiseen. Luonnollisestikin tämän periaatteen alaan kuuluu paljon muutakin, esimerkiksi ulkoasuseikkojen (taustavärit, reunaviivat yms.) käyttö sisällön ryhmittelyyn niin, että rakenne tulee paremmin esille.
  4. "Sijoita ohjeteksti yhteen siihen liittyvän lomake-elementin kanssa." Käännöksestä ei ilmene varsinainen suositus, joka koskee label-elementin käyttöä siihen, että ohjetekstin ja lomakkeen kentän välinen yhteenkuuluvuus osoitetaan merkkauksella. Tämän suosituksen noudattaminen on sinänsä melko suoraviivaista, joskin hiukan työlästä.

13. Tarjoa selkeitä navigointiratkaisuja

Tämän alakohdat koskevat osittain sivuston yleistä rakennetta ja periaatteita, osittain teknisiä yksityiskohtia. Rakennetta koskevat alakohdat ovat luonteeltaan varsin yleisluonteisia, ja on vaikea arvioida objektiivisesti, milloin nämä vaatimukset on täytetty. Toisaalta ne ovat enimmäkseen tärkeämpiä kuin tekniset yksityiskohdat, jotka ovat osittain melko teoreettisia. Esimerkiksi sivujen välisten yhteyksien ilmaisemista link-elementeillä ei IE tue lainkaan, joten käytännössä on syytä käyttää tavallisia linkkejä (a-elementtejä).

Tärkeimmät alakohdat ovat 1, 3 ja 4, ja ne voidaan tiivistää seuraavasti:

Alakohta 13.1 puuttuu hyvin tavalliseen ongelmaan, ja sitä selittää tarkemmin erityisesti HTML-tekniikan ohjeen kohta Link text. Siinä korostetaan myös, että sivulla ei pidä olla kahta linkkiä, joissa on sama linkkiteksti mutta eri kohde. Tätä vastaan rikkovat esimerkiksi sellaiset linkkitekstit kuin "Lue lisää" kunkin uutisen perässä.

Alakohta 13.8, "Aseta erotteleva tieto otsikoiden, kappaleiden, luetteloiden jne. alkuun", sisältää hyvin tärkeän periaatteen. On esimerkiksi vanha hyvä sääntö, että kappaleen tulisi alkaa ydinvirkkeellä, joka esittää kappaleen olennaisimman asian. Näitä asioita kuvailee tarkemmin tekniikkadokumentin kohta Writing Style. Toisaalta aihe ei varsinaisesti kuulu navigointiin vaan pikemminkin edellisen pääkohdan alaan.

14. Varmista dokumenttien selkeys ja yksinkertaisuus

Tämä pääkohta on edellistäkin yleisluonteisempi ja vaikeammin puettavissa täsmällisiksi teknisiksi ohjeiksi saati mittareiksi. Osittain siksi nämä asiat helposti unohtuvat, vaikka on jopa sanottu, että useimmille käyttäjille tässä käsitellyt esteettömyysongelmat ovat tärkeämpiä kuin muut pääkohdat. Kuten edellä mainittiin, Euroopan parlamentti on erityisesti korostanut tämän pääkohdan merkitystä.

Tämä pääkohta on sisällöntuottajille tärkein. Tässä esitettyjen ongelmien havaitseminen ja korjaaminen tai välttäminen edellyttää ennen muuta sisällöntuottajien ja toimittajien panosta. Tarkistusohjelmista ei juurikaan ole apua.

Seuraavassa on alakohdat ja niille selityksiä:

  1. "Käytä niin selkeätä ja yksinkertaista kieltä kuin sivuston sisällön kannalta on mahdollista." Tämä on 1. prioriteettitason vaatimus - ja sellainen, että tuskin minkään sivun voidaan totuudenmukaisesti sanoa täyttävän sen. Kielellistä ilmaisua on yleensä aina mahdollista kehittää selkeämmäksi. Käytännössä joudutaan lopettamaan jossakin vaiheessa. Mutta tavoite on erittäin olennainen. Suomeksi on julkaistu paljon erilaisia kirjallisen esityksen ohjeita ja oppaita. Myös kielenoppaissa (oikeakielisyysoppaissa) on neuvoja, joiden avulla voi selkeyttää kielenkäyttöä, sillä ne usein puuttuvat tyypillisiin vaikeasti ymmärrettäviin tai moniselitteisiin sanontoihin.
  2. Täydennä tekstiä graafisella tai äänimuotoisella esityksellä, jos ne voivat auttaa sivun ymmärtämistä. Tätä periaatetta on hyvä korostaa esteettömyydestä puhuttaessa, sillä hyvin usein esteettömyys ymmärretään kuvattomuudeksi. Tämä kohta esittää kuvat (ja äänen) esteettömyyttä lisäävänä asiana, jolla on suuri merkitys mm. niille, joiden kielitaidossa tai lukutaidossa tai luetun ymmärtämisessä on puutteita, ja myös ihmisille, jotka vain ovat visuaalisesti suuntautuneita. Olennaista on kysyä: voisiko tekstissä esitettyä asiaa havainnollistaa ja selventää kuvilla?
  3. Luo esitystapa, jota käytetään johdonmukaisesti koko sivustossa. Tässä tarkoitetaan sekä navigoinnin johdonmukaisuutta että ulkonaisen esitysasun yhtenäisyyttä sikäli, kuin se auttaa käyttäjää hahmottamaan sivuston sisältöä. Luonnollisin tapa toteuttaa ulkoasun yhtenäisyys on laatia CSS-tiedosto, jota sivuston kaikilla sivuilla käytetään. Tämä ei tarkoita, että esitysasu olisi kaikilla sivuilla sama, vaan yhteisen CSS-tiedoston mukaisesta tyylistä voidaan harkitusti poiketa sivukohtaisella CSS-koodilla.

Pääkohta käsittelee yleisesti dokumenttien selkeyttä ja yksinkertaisuutta ja niiden merkitystä ymmärtämistä helpottavina. Alakohdat kuitenkin tarkastelevat vain joitakin puolia tästä. Erityisesti niistä puuttuu yksi keskeinen asia, joka on sivujen tavallisimpia ongelmia: sivun rakenteen ja ulkoasun sekavuus. Tyypillinen ongelma on, että pääsivulla on liian monia erilaisia asioita ja elementtejä. Sivun ja sen osien hahmottaminen on usein vaikeaa ns. tavallisellekin käyttäjälle, saati ihmiselle, jolla on hahmotuskyvyn, keskittymisen tai muistin häiriöitä. Seuraava kuva havainnollistaa tätä. Kuva on pienennetty näyte erään sivuston (Yle) pääsivusta. Se toisaalta havainnollistaa myönteisellä tavalla alakohdan 14.2 periaatetta kuvien käytöstä. Mutta etsiessään sivulta asiaa, joka on hänen mielessään, esimerkiksi iäkäs käyttäjä helposti unohtaa, mitä etsikään.

[Ylen pääsivu, jossa on sanomalehtimäisesti taitettuna pienehköjä, osittain kuvitettuja juttuja sekä laaja navigointivalikko sekä ylhäällä että vasemmalla.]

Ulkonaisen hahmotettavuuden vaikeuksia ei WAI-ohjeisto kuitenkaan suoranaisesti käsittele. Tämä kuvastaa ohjeiston rajoituksia: vaikka sen pääkohdat kattavat melko hyvin esteettömyyden koko alueen, niin alakohdat muodostavat vain suhteellisen rajoittuneen joukon arviointiperusteita. Kunkin pääkohdan tulisi siis ajatella olevan paljon enemmän alakohtiensa summa.

Pikavinkkien asema

W3C on julkaissut myös lyhyen dokumentin Quick Tips to Make Accessible Web Sites, joka on suomennettu nimellä Pikavinkit Web-sivustojen saavutettavuuteen. Tämä pikaohjeisto, joka on julkaistu myös pienenä referenssikorttina eri kielillä, ei ole WAI-suosituksen osa vaan tiivistelmä sen muutamista periaatteista.

Pikavinkkien mainitaan olevan muistin tuki (memory prompt), mutta käytännössä niitä on käytetty myös esittelytarkoituksiin, valistustyöhön. Sellaiseen ne eivät sovi kovin hyvin sen takia, että niiden sisältö on osittain luonteeltaan aika tekninen. Ne viittaavat sellaisiin käsitteisiin, joiden ymmärtäminen edellyttää WAI-suosituksen melko hyvää tuntemusta.

Seuraavassa on esitetty itse pikavinkkien (referenssikortin) suomennoksen sisältö.

  1. Kuvat & animaatiot. Käytä alt-attribuuttia selittämään tehtävä.
  2. Kuvakartat. Käytä aktiivialueisiin selainpuolen map:iä ja tekstiä.
  3. Multimedia. Liitä audioon tekstitys ja kuvausteksti sekä videoon kuvaus.
  4. Hypertekstilinkit. Tee linkkitekstistä sellaisenaan ymmärrettävä, esim. vältä "klikkaa tästä" tyyppisiä selityksiä.
  5. Sivujen organisointi. Käytä otsikoita, listoja ja yhtenäistä rakennetta. Käytä CSS:ää sommitteluun ja tyyliin kun mahdollista.
  6. Käyrät & kaaviot. Käytä yhteenvetoa tai longdesc-attribuuttia.
  7. Skriptit, appletit & plug-init. Tarjoa vaihtoehtoinen sisältö, jos aktiiviset piirteet ovat saavuttamattomia tai niitä ei tueta.
  8. Kehykset. Käytä noframes:iä ja selventäviä otsikoita.
  9. Taulukot. Tee rivien lukemisesta ymmärrettävää. Tee yhteenveto.
  10. Tarkista lopputulos. Validoi. Käytä http://www.w3.org/TR/WCAG ohjeita, tarkistuslistaa ja työkaluja.

Pikavihjeistä ensimmäinen on helpoimmin väärin ymmärrettävissä: se puhuu alt-määritteestä selittävänä, vaikka sen tulisi olla kuvan tilalla, siis suorittaa kuvan tehtävä eikä selittää sitä. Muissa pikavihjeissä on viitattu osittain vain teoreettiseksi jääneisiin tekniikoihin, kuten edellä on selostettu.

WCAG 2.0 -luonnoksen periaatteet

W3C on jo pitkään tehnyt työtä WAI-suosituksen seuraavan version WCAG 2.0 laatimiseksi. Osittain tarvetta sellaiseen luo jo tekninen kehitys, sillä nykyisessä WAI-suosituksessa on monia kohtia, jotka ovat sidoksissa erityisiin tekniikoihin ja selainten piirteisiin.

On myös koettu tarpeelliseksi tiivistää keskeiset periaatteet muutamaan pääkohtaan. Niinpä kun nykyisessä WAI-suosituksessa on 14 pääkohtaa, sisältää kesäkuussa 2003 julkistettu WCAG 2.0 -luonnos vain 4 pääkohtaa. Ne voidaan vielä tiivistää neljäksi sanaksi:

  1. havaittava (perceivable)
  2. hallittava (operable)
  3. ymmärrettävä (understandable)
  4. lujatekoinen (robust).

Käyttäjän on voitava ensinnäkin aisteillaan havaita sivun sisältö; tästä seuraa, että sisällön pitää olla esitettävissä eri aisteille sopivassa muodossa. Käyttäjän on myös voitava hallita sivun käyttöä omilla tavoillaan, esimerkiksi pelkästään näppäimistöä käyttäen. Lisäksi hänen on ymmärrettävä sivun sisältö ja käyttö. Viimeinen kohta koskee eri tekniikoiden standardinmukaisuutta, luotettavuutta ja tukea esteettömyydelle.

WAI-suosituksen version 2.0 valmistumiseen ja hyväksymiseen kuluu todennäköisesti melko lailla aikaa. Luonnokset ovat vielä suhteellisen yleisellä tasolla. Nykyinen suositus on saavuttanut laajan hyväksynnän, ja on olemassa lukuisia siihen perustuvia teknisiä ohjeita, opetusaineistoja ja testejä. Täten on tuskin ajateltavissa, että se kokonaan korvattaisiin uudella suosituksella ennen kuin on laadittu vastaavaa aineistoa sitä tukemaan.

EU:n kannanotot

Yleisiä kannanottoja

Euroopan unionissa on esteettömyys ollut vahvasti esillä tietotekniikan alalla. Sitä korostaa mm. komission syksyllä 2001 antama tiedonanto Julkisen sektorin verkkosivujen ja niiden sisällön saavutettavuus, jonka liitteissä laajasti selostetaan ja lainataan WAI-aineistoa. Tiedonantoon ottaa kantaa Euroopan parlamentin päätöslauselma saavutettavuudesta (v. 2002), joka korostaa W3C:n suositusten asemaa ja asettaa tavoitetasoksi AA-taso:

Euroopan parlamentti - -

(K.) ottaa huomioon, että World Wide Web Consortium on perustanut verkkosivujen saavutettavuusaloitteen WAI:n (Web Accessibility Initiative), ja viimeksi mainittu on kehittänyt saavutettavuutta koskevat niin kutsutut "Suuntaviivat", "Web Content Accessibility Guidelines 1.0", jota nykyään pidetään maailmanlaajuisena standardina helposti saavutettavien verkkosivujen suunnittelussa;

- -

- -

(15.) kehottaa komissiota painottamaan erityisesti Web Content Accessibility Guidelines -kokonaisuuteen kuuluvan 14. suuntaviivan täytäntöönpanoa; se edellyttää, että asiakirjat ovat selkeitä ja yksinkertaisia ja näin ollen helppoja ymmärtää, jotta henkilöitä, joilla on ongelmia lukemisessa tai älyllinen vamma, ei suljeta vielä enemmän sähköisen hallinnon ja verkon ulkopuolelle;

- -

(30.) korostaa sitä, että jotta verkkosivut olisivat saavutettavissa, on tärkeää, että ne ovat AA-tasoisen luokituksen mukaisia, että WAI-suuntaviivojen painopiste 2 pannaan täysin täytäntöön;

Tässä EU-suomennoksessa tarkoittaa "WAI-suuntaviivojen painopiste 2" sitä, että toteutetaan 1. ja 2. prioriteettitason tavoitteet eli saavutetaan AA-luokitus. Englanninkielisessä versiossa 30. artikla on seuraava: "Stresses the fact that for websites to be accessible it is essential that they are double-A compliant, that priority 2 of the WAI guidelines must be fully implemented".

EU:n komission tietoyhteiskuntasektorin (Information Society) laaja eEurope 2002 -ohjelma sisälsi erityisen eAccessibility-osion. Uudemmassa eEurope 2005 -ohjelmassa rakenne on toinen, mutta siinäkin esteettömyys on mukana. Ohjelman perusasiakirjassa eEurope 2005: Tietoyhteiskunta kaikille sanotaan:

eEurope 2002:n yhtenä tavoitteena on tehdä julkisen sektorin verkkosivustoista helppokäyttöisempiä vammaisille. Lokakuussa 2001 [Euroopan unionin] neuvosto antoi päätöslauselman osallisuudesta tietoyhteiskuntaan ja maaliskuussa 2002 päätöslauselman, jossa kehotettiin jäsenvaltioita nopeuttamaan verkkosivustojen käytettävyyttä koskevien WAI-periaatteiden täytäntöönpanoa. Viranomaisten verkkopalvelujen käyttöä voidaan helpottaa tarjoamalla monikielistä sisältöä monen eri jakelukanavan välityksellä.

EU:n luonteen takia sen omilla sivuilla korostuvat monikielisyyden ongelmat, ja nämä ongelmat vielä lisääntyvät EU:n laajetessa. Tästä ohjelman kohdasta voidaan lukea rivien välistä, että tiedon tarjoaminen monilla kielillä nähdään osana esteettömyyttä. Tämä on tärkeä näkökanta, joka ei WAI-suosituksissa tule esille. WAI-ohjeen alakohta 11.3, "Anna tarpeeksi tietoa, jotta käyttäjät löytävät juuri itselleen sopivia dokumentteja (esim. kieli, sisältötyyppi jne.)", kyllä liittyy siihen, mutta se käsittelee vain sitä, miten erikieliset vaihtoehdot pannaan tarjolle, ei niiden merkitystä sinänsä.

Euroopan unionin neuvosto julkaisi alkuvuodesta 2003 eAccessibility-kannanoton, joka on eräänlainen päätelmä eEurope 2002 -ohjelmasta. Siinä on esteettömyys nostettu korkealle poliittiselle tasolle. Se korostaa, että eEurope 2002:n tavoitteet ovat voimassa, ja ohjaa niiden jatkokehittelyyn. Kannanotto sisältää myös monia viittauksia mahdollisiin uusiin toimenpiteisiin esteettömyyden edistämiseksi, mutta tältä osin se on keskeneräinen, osittain kiistanalainenkin. Niinpä siinä mainitaan vain selviteltävinä ja harkittavina asioina mm. yhteisten metodologioiden kehittäminen WAI-suositusten toteuttamiseksi, julkisissa hankinnoissa asetettavien esteettömyysvaatimusten harmonisointi, tavoite esteettömyyttä edistävän suunnittelun ottamisesta huomioon opetussuunnitelmissa (Design for All curricula) sekä ajatus esteettömyystunnuksesta, eAccessibility mark, joka myönnettäisiin esteettömyysvaatimukset täyttäville tuotteille ja palveluille. (Tämä on erotettava tunnuskuvista, joilla sivun tekijä itse väittää sivua jotkin vaatimukset täyttäviksi.)

Selkokielisuositus

Eurooppalainen selkokielisuositus ei ole varsinainen EU:n kannanotto, mutta se on tehty EU:n tuella. Se ei ole suositus siitä, millaista kirjallisen aineiston yleisesti tulisi olla, vaan se käsittelee aineiston kirjoittamista kehitysvammaisille. Sen monia periaatteita voi kuitenkin noudattaa myös yleisinä kirjoittamisohjeina sen lisäksi, että sitä voi käyttää tehtäessä kehitysvammaisille tai muille selkokieltä tarvitseville suunnattuja sivuja.

Suositus on PDF-muotoisena saatavilla EU:n eri kielillä sivun Inclusion Europe kautta. Suomenkielisestä käännöksestä on myös esteettömämpi (HTML-muotoinen) versio: Tee se helpoksi. Seuraava ote antanee kuvaa suosituksen eräiden kohtien lähestymistavasta:

Suomalaiset kannanotot

Tietoyhteiskuntaohjelma

Tietoyhteiskuntaohjelma, jonka sisältö vahvistettiin valtioneuvoston yleisistunnossa 25.9.2003, käyttää keskeisenä tunnuslauseena periaatetta "koko kansan tietoyhteiskunta". Se on luonteeltaan laaja-alainen puiteohjelma, joka hahmottelee kehittämisalueita ja -toimenpiteitä, eikä siinä siksi ole varsinaisia suosituksia esimerkiksi esteettömyydestä. Siinä on kuitenkin aiheeseen liittyviä periaatteellisia linjauksia mm. seuraavasti:

Julkisen sektorin Web-sivuja koskeva suositus JHS 129

JHS 129 eli Julkishallinnon WWW-sivuston suunnittelun ohjeet on virallisin suomalainen esteettömyyskannanotto. Sen on laatinut JUHTA, joka on valtion ja kuntien yhteistyöelin tietotekniikan ja tietohallinnon alalla. Nimensä mukaisesti JHS 129 koskee julkisen sektorin verkkosivuja. Sen suositukset kyllä olisivat pääosin sovellettavissa muuallakin. Valitettavasti JHS:t (julkisen hallinnon suositukset) ovat melko huonosti tunnettuja ja noudatettuja. Tosin tämä vaihtelee paljon toimialan ja suosituksen mukaan.

Tässä on syytä mainita myös JHS 145, Julkisten palvelujen kuluttajalähtöinen palveluhakemisto. Sen perusajatuksena on, että julkishallinnon tarjoamat palvelut jäsennetään ja luokitellaan kansalaisen tarpeiden pohjalta. Käytännössä tämä merkitsisi, että eri kuntien verkkosivustot olisivat samojen periaatteiden mukaan jäsennettyjä niin, että esimerkiksi toiseen kuntaan muuttanut löytäisi uuden kotikuntansa palvelut tutulla tavalla jaoteltuina. Tästä olisi yleisen käytettävyyden lisäksi erityistä hyötyä muun muassa niille, joilla on hahmotus- ja muistamisvaikeuksia. Valitettavasti JHS 145 on toistaiseksi jäänyt melko vähälle huomiolle käytännössä.

JHS 129 on tunnetumpi mutta toisaalta melko yleisluonteinen, enemmänkin periaatejulistus kuin toimintaohjelma. Luonteeltaan se on yleinen kannanotto verkkosivujen kehittämisestä, mutta se nostaa esteettömyyden varsin keskeiseen asemaan:

Keskeisinä yleisperiaatteina WWW-sivuston laadinnassa tulee pitää saavutettavuutta (esteettömyyttä), löydettävyyttä, palvelevuutta ja osallistuvuutta.

Esteettömyyden suhteellista osuutta korostaa se, että se on suuremmassa määrin arvioitavissa ja ohjeistettavissa kuin muut tavoitteet enimmäkseen ovat. On varsin ongelmallista mitata esteettömyyttä tai sanoa, miten sivuista tehdään esteettömiä, mutta esimerkiksi palvelevuus (miten hyvin sivusto palvelee käyttäjien tarpeita) on vielä paljon hankalammin mitattava ja opetettava asia.

JHS 129 ei esitä saavutettavuudelle (esteettömyydelle) varsinaista määritelmää. Siinä on kuitenkin seuraava luonnehdinta: "Saavutettavuutta voidaan arvioida siten, minkälaisia rajoituksia sivujen käyttö asettaa kuten selainrajoitukset ja erityyppisten käyttäjäryhmien huomioon ottaminen."

Seuraavaan on poimittu ne kohdat JHS 129:stä, jotka suoranaisimmin liittyvät esteettömyyteen. Nämä on hyvä tuntea muun muassa siksi, että JHS 129 on toistaiseksi painavin suomalainen kannanotto, johon voi vedota, kun esteettömyystyölle pyydetään resursseja tai sivuja ehdotetaan muutettaviksi esteettömyyden parantamiseksi. Kohtia on myös lyhyesti kommentoitu.

Julkishallinnon WWW-sivustojen tulee viestittää asiallisuutta. Visuaalinen yksinkertaisuus ja selkeys ovat avainkriteereitä sivujen laadinnassa. Julkisen sektorin sivuille ei yleensä ole syytä sijoittaa mainoksia. Mikäli mainoksia esiintyy, on niiden selkeästi erotuttava virallisesta viestinnästä.

Tämä kannanotto on samansuuntainen kuin WAI-suosituksen 14. kohta, "Varmista dokumenttien selkeys ja yksinkertaisuus". Kannanottoon sisältyy kuitenkin myös asiallisuuden ja virallisuuden ajatus, jota sivustojen luonteen katsotaan edellyttävän. Yleisessä esteettömyystyössä kannattaa pyrkiä siihen, ettei selkeyttä ja yksinkertaisuutta samaisteta "virastoilmeen" kanssa.

WWW-sivuston palvelutaso täytyy suunnitella keskimääräistä teknologiatasoa hyödyntävälle käyttäjälle. Ei ole järkevää käyttää tekniikan viimeisimpiä mahdollisuuksia, koska vain harva käyttäjä pystyy hyödyntämään niitä. Sivujen sisällöstä tai esittämistavasta ei myöskään kannata tinkiä ylettömästi sen takia, että kaikki potentiaaliset käyttäjät eivät pysty hyödyntämään kaikkea. Periaatteena suunnittelussa tulee olla se, että sivut ovat informatiivisia myös selaimilla, jotka eivät esitä kuvia, hitailla tiedonsiirtoyhteyksillä ja että erityisryhmien, esimerkiksi näkövammaisten, tarpeet otetaan huomioon sivuja laadittaessa.

Tämä kannanotto on osittain omituinen ja lienee syntynyt kompromissina. Esteettömyydessähän on olennaista ottaa huomioon paljon muutakin kuin keskiarvot. Mutta viimeisen virkkeen periaate sisältää olennaisen esteettömyysajatuksen, joka on korostamisen arvoinen: huolehditaan siitä, että sivut ovat kaikkien käytettävissä. Tulkinnanvaraa jää kuitenkin sen suhteen, onko hyväksyttävää, että osa sivujen aineistosta on saatavilla vain jossakin sellaisessa muodossa, jota kaikki eivät voi hyödyntää (esim. PDF- tai Word-tiedostoina).

Jokaisen sivun toimivuus on testattava, mielellään usealla selaimella ja eri käyttöjärjestelmissä. WWW-sivuilta on saatavissa ohjelmistoja, jotka tarkistavat koodin oikeellisuuden ja ohjaavat hyviksi havaittuihin käytäntöihin. Tällaisia ohjelmistoja ovat esimerkiksi Bobby ja Lehtori, joiden verkko-osoitteet ovat:
http://lempinen.net/lehtori
http://www.cast.org/bobby/

Myös koodin standardinmukaisuus on hyvä tarkistaa. Validointiin sopivia työkaluja löytyy esimerkiksi seuraavilta sivuilta:
http://validator.w3.org/
http://jigsaw.w3.org/css-validator/

Saavutettavuuden tarkastamiseen sopiva työkalu on
http://www.w3.org/WAI/gettingstarted

Sivujen toimivuutta voidaan lisäksi tarkastella tarkastuslistojen avulla. Muun muassa Jakob Nielsen sekä WWW-konsortio W3C ovat laatineet ohjeita hyvien WWW-sivustojen suunnittelusta. Kriteeristöjen verkko-osoitteet ovat:
http://www.useit.com/
http://www.w3.org/WAI/

Tässä asetetaan laajoja testausvaatimuksia, jotka ovat osittain epärealistisia. Lisäksi eri tietolähteisiin ja välineisiin viitataan sekavasti. Esimerkiksi Lehtori on luonteeltaan validaattori, ja http://www.w3.org/WAI/gettingstarted sisältää yleisen johdannon esteettömyyteen, eikä sitä voi pitää erityisenä tarkastamisen työkaluna. Nielsenin useit.com-sivusto on kyllä laajasti tunnettu ja tunnustettu tietolähde käytettävyyden (ja esteettömyydenkin) alalla, mutta kriteeristönä sitä ei voi pitää. Bobbyn suositteleminen ilman mitään kriittisiä huomautuksia on varsin ongelmallista.

Näistä ongelmista huolimatta nämä lausumat ovat tietysti merkittäviä kannanottoja WAI-toiminnan ja WAI-suosituksen sekä yleensä esteettömyystyön puolesta.

Kun linkkejä luetaan puhesyntetisaattorin avulla, tulkinta on helpointa, kun kukin linkki on omalla rivillään. Samalla rivillä olevat linkit on syytä erottaa pystyviivoilla tai hakasuluilla. Tarpeettomia tyhjiä rivejä tulee välttää, koska ne haittaavat tekstin lukemista puhesyntetisaattorilla.

Tämä kannanotto on osittain vanhentunut, sillä ohjelmat osaavat aiempaa paremmin erottaa linkit toisistaan muutoinkin. Tarpeettomien tyhjien rivien välttäminen on epäselvä ohje, mutta se voidaan parhaiten tulkita niin, että sivun muotoilua ei pidä tehdä tuottamalla tyhjiä rivejä (tai tyhjiä kappaleita) vaan CSS:n tarjoamin keinoin.

Palautteenantomahdollisuus ei saisi perustua teknisesti pelkästään sähköpostin käyttämiseen, koska kaikilla sivujen käyttäjillä ei välttämättä ole sähköpostiosoitetta. Esimerkiksi verkkolomake on hyvä tapa toteuttaa palautteenantomahdollisuus.

Tämä sinänsä aivan oikea suositus on ilmeisesti osittain ymmärretty väärin: usein on palautemahdollisuutena vain verkkolomake (HTML-lomake). Lomakkeiden käyttö aiheuttaa usein ongelmia, ja monelle vammaiselle olisi helpompi käyttää omaa tuttua sähköpostiohjelmaa, jossa on ehkä hänen toimintaansa helpottavia erityispiirteitä. Ongelmia lisää, että nykyisin sielläkin, missä sähköpostiosoitteet on ilmoitettu, ne on ilmoitettu epäselvästi ja jopa sotkettuina ns. spämmin pelossa.

Tekstin pitää selkeästi erottua taustastaan. Parhaat taustavärit ovat neutraaleja. Silloinkin kun henkilö ei ole värisokea, on värien erottaminen varmaa vain kolmen perusvärin (sininen, keltainen, punainen) osalta. Väri on kuitenkin hyvä lisämääreenä tai huomion herättäjänä. Parhaaksi yhdistelmäksi on osoittautunut musta teksti vaalealla, esimerkiksi harmaalla, pohjalla. Käyttäjälle on kuitenkin varattava mahdollisuus muuttaa värejä omassa selaimessaan, eli sivujen värejä ei saisi määritellä kiinteästi sivujen HTML-määrittelyissä. Vilkkuvia kuvia ja liikkuvia tekstijonoja täytyy välttää.

Tässä kiinnitetään huomiota asioihin, jotka kuuluvat lähinnä WAI-suosituksen 2. pääkohdan ("Älä turvaudu pelkästään väreihin") alaan. Joitakin outoja, jopa uskottavuutta heikentäviä lausumia tähän sisältyy, sillä puhtaiden perusvärien käyttö on yleensä epäsuotavaa niiden voimakkuuden takia, eikä harmaata väriä ole vuosiin suosittu verkkosivuilla, eikä ole mitään erityistä syytä mainita harmaata erikseen.

Kaikille kuville, symboleille, Javascripteille ja taulukoille - olivatpa ne sitten linkkejä tai ei - on oltava myös tekstivastine, vähintään kuvan nimi. Taulukoiden lukeminen apuvälineillä voi olla vaikeaa, joten taulukon tiedot on suositeltavaa esittää myös tekstinä erityisryhmiä varten. Myös grafiikalle, videotallenteille ja äänelle on annettava tekstivaihtoehdot. Lisäksi Näkövammaisten kirjasto suosittelee, että taulukossa otsikkotieto merkitään myös soluun eli tiedon arvona ei saisi olla pelkkä ykkönen, vaan mieluummin "1 metri" tms.

Kannanotto on osittain harhaanjohtava, mutta se sisältää selkeästi periaatteen siitä, että kaikille kuville tulee olla tekstivastine. Tosin ilmaisu "vähintään kuvan nimi" vesittää tätä aika lailla, vaikka totta onkin, että joskus tekstivastineen asemesta joudutaan kirjoittamaan pelkkä kuvaus tai jopa vain kuvan nimi. Kappaleeseen on koottu varsin sekalainen kokoelma ajatuksia, jotka ovat osittain (vaatimus kaikkien Javascriptien tekstivastineista) jopa mielettömiä.

Mahdollisimman hyvän saavutettavuuden kannalta sivusto on pyrittävä rakentamaan selainriippumattomaksi. Suositeltava tapa rakentaa sivustoja on käyttää tyylitiedostoja (Cascading style sheets) [= CSS].

Kannanotto on hyvä, mutta se voidaan ymmärtää kahdellakin tavalla väärin, ja nämä väärinkäsitykset ovat melko tavallisia. Selainriippumattomuus yleisenä tavoitteena on pikemminkin normaali hyvä suunnitteluperiaate kuin erityisesti saavutettavuutta eli esteettömyyttä edistävä, eikä se suinkaan takaa esteettömyyttä. CSS:n käyttöä on kyllä aiheellista suosittaa, mutta se ei suinkaan takaa sen enempää selainriippumattomuutta kuin esteettömyyttäkään.

Sivua laadittaessa on otettava huomioon, että tekstipohjainen selain ei välttämättä erottele korostuksia tai tekstityyppejä. Näin ollen korostusten tai tekstityyppien käyttäminen ainoana keinona esimerkiksi otsakkeen ja tekstisisällön erottamiseksi ei ole kaikissa tapauksissa selkeää.

Tässä tarkoitetaan käytännössä erilaisia fonttiasetuksia. Tarkoitus lienee sanoa, että esimerkiksi otsikot tulisi merkata otsikoiksi sen sijaan, että käytetään vain font-elementtejä tai vastaavia CSS:n piirteitä. Rajoitus "kaikissa tapauksissa" on hiukan outo ja voidaan tulkita eri tavoin.

Sivut tai sivuihin liitetyt tiedostot eivät saa olla pelkästään PDF-muotoisia, koska tällaisten tiedostojen käsittely, hakujen kohdistaminen jne. on ongelmallista tai jopa mahdotonta. Lisäksi PDF-tiedostojen saavutettavuus on heikko. Tiedostojen on siksi hyvä olla jossain yleisessä tallennusmuodossa, kuten HTML, ASCII tai RTF. Vähintäänkin tekstin tiivistelmän on oltava HTML-muotoisena, koska on pyrittävä välttämään sitä, että käyttäjä hakee itselleen tekstejä, joista vasta avaamisen jälkeen selviää tekstin hyödyllisyys käyttäjän kannalta. Liitetiedoston koon on oltava näkyvillä, jotta käyttäjä voi arvioida, kuinka kauan tiedoston siirtäminen omalle koneelle kestää. PDF:n käyttö on suositeltavaa niissä tapauksissa, joissa omalle koneelle siirrettävän dokumentin ulkoasu ja sisältö halutaan säilyttää muuttumattomana.

Kannanotto on erittäin tärkeä, koska PDF-tiedostojen laajeneva käyttö esteettömämpien muotojen tilalla on keskeisiä ongelmia. Se aiheuttaa vaikeuksia myös ns. tavallisille käyttäjille, ja kannanotto mainitsee näistä ongelmista muutamia olennaisia. Puutteena kannanotossa on se, että vastaavaa ei todeta Word-muodosta ja että RTF ja ASCII on nostettu HTML:n rinnalle. ASCIIn mainitseminen on lisäksi teknisesti virheellistä, koska esimerkiksi suomen kieltä ei voi kirjoittaa ASCIIlla.

Kehyksiä (frames) pitää käyttää harkiten. Kehysten käytöllä sivuston rakennetta ja käytettävyyttä saadaan helposti parannettua, mutta sivujen löytyminen hakukoneilla hankaloituu, tulostus hankaloituu ja joillakin selaimilla kirjanmerkkien tekeminen sivuille on hankalaa. Mikäli kehyksiä käytetään, ne on nimettävä niin, että myös näkövammaiset pystyvät selvittämään kehyksen sisällön. Käyttäjille pitää tarjota mahdollisuuksien mukaan sivuista myös kehyksetön vaihtoehto.

Esteettömyyden kannalta tämä kiinnittää huomiota kahteen keskeiseen asiaan, kehysten järkevään nimeämiseen ja kehyksettömään vaihtoehtoon. Tosin jälkimmäiseen liitetään outo varaus "mahdollisuuksien mukaan". Sen sijaan kannanotto kehysten vaikutuksesta käytettävyyteen on täysin vastakkainen sille, mitä JHS 129:ssä toisaalla suositeltu käytettävyysasiantuntija Jakob Nielsen esittää!

Sivut on tärkeä laatia (mahdollisuuksien mukaan) myös resoluutioriippumattomiksi: käyttäjän tietokoneen näytön koko ei saisi vaikuttaa siihen, miltä sivut näyttävät. Kiinteäksi määritelty sivu näkyy vain osittain pienellä näytöllä, jolloin tekstiä luettaessa näyttöä joutuu vierittämään sivusuunnassa ja alaspäin, kun taas suurella näytöllä sivu täyttää vain osan näytöstä. Vierittäminen sivulle päin koetaan poikkeuksetta hankalammaksi kuin vierittäminen alaspäin. Tarvittaessa erityisryhmille on tarjottava vaihtoehtoinen sivu, jossa käyttöä rajoittavien graafisten ominaisuuksien (värit, kirjasinkoot, sivun kiinteä asettelu) käyttö on minimoitu.

Tarkoitus on tässä varmaankin ollut hyvä, mutta muotoilu on osittain varsin kummallinen. Resoluutioriippumattomuudenhan pitäisi tarkoittaa sitä, että sivu mukautuu näytön kokoon, ei suinkaan muuttumattomuutt a. Vaihtoehtoisen sivun suosittelu on asiallisesti ristiriidassa WAI-suosituksen kanssa, sillä WAI-suosituksen mukaan vaihtoehtoiset sivut ovat vihoviimeinen vaihtoehto, johon mennään, kun on epäonnistuttu pyrkimyksissä luonnolliseen esteettömyyteen. Lisäksi kannanotto suorastaan ruokkii sellaista käsitystä, että esteettömyys merkitsee graafisten ominaisuuksien käytön välttämistä.

Lyhenteiden käyttöä ei suositella. Mikäli lyhenteitä käytetään, ne on myös selitettävä.

Tässä on selkeästi vaikkakin ykstotisesti esitetty yksi keskeinen esteettömyysperiaate. Myönteistä on, että tässä ei mennä teknisiin asioihin kuten lyhenteitä koskevaan merkkaukseen vaan korostetaan selittämisen tärkeyttä.

Tehtävä: Arvioi JHS 129:ää verkkosivuna siinä esitettyjen esteettömyysperiaatteiden mukaan. Toisin sanoen listaa, missä suhteissa se on erityisen hyvä esimerkki periaatteiden noudattamisesta ja missä se ehkä poikkeaa niistä. Pyri löytämään kummastakin ainakin viisi kohtaa. Sivun HTML-merkkauksen tutkiminen voi tässä olla tarpeen. Tehtyäsi tehtävän voit verrata omaa arviotasi esimerkkiin JHS 129:n esteettömyyttä koskevasta arviosta.

Muita kannanottoja

Organisaatiokohtaiset ohjeet

Periaatteessa organisaation, kuten yrityksen, viraston tai yhdistyksen, sisäisillä ohjeilla on erittäin suuri merkitys. Nehän ovat organisaatiossa toimivia kaikkein lähimpänä, ja ne on usein mahdollista tehdä paljon velvoittavammaksi kuin yleiset suositukset. Lisäksi niitä voidaan yhdistää käytettyihin tekniikoihin ja järjestelyihin niin, että niiden noudattamista voidaan valvoa ja noudattaminen voidaan tehdä helpoksi, joskus ehkä automaattiseksikin.

Kuitenkin organisaatioiden ohjeet verkkosivujen tekemisestä ovat suhteellisen vähäisiä. Lisäksi ne usein pidetään vain sisäisinä, jolloin ulkopuoliset eivät voi suoraan arvioida niitä esimerkiksi esteettömyyden kannalta.

Verkkojulkaisemisen ohjeet käsittelevät usein voittopuolisesti teknistä toteutusta, puuttumatta juurikaan esimerkiksi esteettömyyskysymyksiin. Tämän lisäksi saattaa olla julkaisujen ulkoasua koskevia ohjeita, jotka voivat muodostua ongelmiksi esteettömyyden kannalta, jos niissä vaaditaan esimerkiksi kiinteää fonttikokoa. Jossain määrin on myös yleisen tason linjauksia julkaisemisen tavoitteista ja periaatteista, usein kaikkea viestintää koskevina.

Esimerkiksi Helsingin yliopiston viestinnän ohjeet sisältävät useita ohjeita väittelijöille ja muita vastaavia erityisohjeita sekä graafisen ohjeiston (visuaalisen ilmeen aineistopankki, ei vapaasti saatavilla), mutta verkkoviestintä-otsikon alla viitataan vain Atk-osaston teknisiin ohjeisiin www-materiaalin tuottamiseksi yliopiston palvelimelle. Ohjeistoon ei ainakaan kovin näkyvästi sisälly esimerkiksi esteettömyyttä koskevia periaatteita. Tosin yliopistossa on laadittu erilaisia tietotekniikkaa koskevia strategioita, niistä tuoreimpana tietohallintostrategia 2003-2006. Se ei kuitenkaan käsittele esteettömyyttä.

Toiseksi esimerkiksi voidaan ottaa Vantaan kaupungin viestintästrategia 2002-2004, joka viittaa mm. eriarvoisuuden ongelmaan, eri kohderyhmien huomioon ottamiseen tiedon esittämisen tavassa ja kanavassa, monikulttuurisuuteen jne. Tämä ei kuitenkaan konkretisoidu esimerkiksi esteettömyyttä koskeviksi periaatteiksi, joskin lopussa viitataan yleisesti JUHTA-suosituksiin ja kuntien www-ohjeistukseen.

Erilaisilla strategioilla olisikin todennäköisesti melko vähäinen vaikutus verkkosivujen käytännön toteutukseen yleensä ja esteettömyyteen erityisesti. Strategioita ei koeta esimerkiksi työntekijää velvoittaviksi samassa mielessä kuin konkreettisia määräyksiä ja ohjeita. Luultavasti vain harvassa paikassa on edes harkittu sitä, että organisaation verkkosivuilta vaadittaisiin esimerkiksi WAI-ohjeen joidenkin kohtien noudattamista.

Yhdysvaltain lainsäädäntö

Section 508:n merkitys

Esteettömyyttä koskevat aineistot ja tarkistusohjelmat viittaavat usein Section 508 -nimiseen normiin. Siksi sen pääperiaatteet on hyvä tuntea, vaikka normi päteekin vain Yhdysvalloissa ja sielläkin ensisijaisesti vain liittovaltion sivustoihin ja sellaisten organisaatioiden sivustoihin, jotka saavat liittovaltiolta avustuksia.

Epäsuorasti Section 508 -normilla on huomattava merkitys, koska se vaikuttaa mm. sivunteko-ohjelmiin. Jotta ohjelmat menestyisivät markkinoilla, joilla osa asiakkaista on velvoitettu noudattamaan Section 508:n vaatimuksia, täytyy ohjelmiin toteuttaa piirteitä, jotka auttavat vaatimusten täyttämisessä.

Monissa tarkistusohjelmissa on mahdollista valita tarkistus joko WAI-suosituksen jonkin tason tai Section 508:n mukaisesti. Etenkin jos sivulla epäillään olevan paljon ongelmia, kannattaa ehkä aloittaa Section 508 -vaatimuksista, koska tällöin saadaan yleensä lyhyempi raportti. Kun siinä ilmenneet ongelmat on käsitelty, voidaan sitten siirtyä tarkistuksiin WAI-suosituksen eri tasojen mukaan.

Section 508 voi myös olla hyvä lähtökohta, jos ryhdytään edistämään esteettömyyttä tarkoilla ja sitovilla ohjeilla esimerkiksi jonkin yrityksen sisällä. Tämä johtuu siitä, että sellaisten ohjeiden täytyy olla täsmällisiä, ymmärrettäviä ja valvottavissa. Vaarana tällaisessa lähestymistavassa on, että se johtaa huomion ja toimenpiteiden keskittymisen suhteellisen harvoihin asiakohtiin, jotka suinkaan aina eivät ole olennaisimpia esteettömyyden kokonaisuudessa.

Section 508:n sisältö

Lyhyesti sanottuna Section 508 vastaa lähinnä WAI-suosituksen 1. prioriteettitasoa eli A-tasoa. Vaatimuksia on kuitenkin osittain supistettu, osittain tarkennettu ja lisättykin. Keskeisenä periaatteena on ollut, että normin tulee olla luonteeltaan sellainen, että sen täyttäminen voidaan arvioida objektiivisesti. Tämä merkitsee monien hyvin olennaisten asioiden pois jättämistä mutta toisaalta mahdollistaa tarkan valvonnan.

Section 508 on varsinaisesti Rehabilitation Act -nimisen lain osa, mutta käytännössä tarkoitetaan myös sen nojalla annettuja tarkempia määräyksiä, Section 508 Standards, erityisesti kohtaa Web-based intranet and internet information and applications (§ 1194.22). Tätä normistoa käsittelee virallinen sivusto Section508.gov. Käytännössä perehtyminen kannattaa aloittaa jostakin helppotajuisemmasta esityksestä Jim Thatcher on kirjoittanut laajan koosteen Web Accessibility for Section 508 sekä yksityiskohtaisen Section 508-vaatimusten ja WAI-suosituksen vertailun.

Havainnollisen esityksen Section 508 -vaatimusten täyttämisestä sivujen tekemisessä ja korjaamisessa antaa Access Boardin dokumentti Web-based Intranet and Internet Information and Applications. Se sisältää itse vaatimukset ja melko laajat selitykset.

Vaatimukset ovat suomennettuina seuraavat. Tässä on syytä ottaa huomioon, että alan termistö vaihtelee ja on osittain tulkinnanvaraista, ja tulkinnanvaraisuuden luonne voi käännettäessä muuttua. Sulkeissa on mainittu, mitä WAI-ohjeen alakohtaa vaatimuksen on ilmoitettu vastaavan,

  1. Jokaiselle elementille, joka ei ole tekstiä, tulee esittää sitä vastaava teksti (esimerkiksi alt-määritteellä, longdesc-määritteellä tai elementin sisällössä). (WAI 1.1)
  2. Mitä tahansa multimediaesitystä vastaavien vaihtoehtojen tulee olla esityksen kanssa tahdistettuja. (WAI 1.4)
  3. Web-sivut tulee suunnitella siten, että kaikki värillä esitetty informaatio on saatavilla myös ilman värejä, esimerkiksi asiayhteydestä tai merkkauksesta. (WAI 2.1)
  4. Dokumentit tulee organisoida siten, että ne ovat luettavissa ilman, että tarvitaan dokumenttiin liittyvä tyyliohje (style sheet). (WAI 6.1)
  5. Palvelinpohjaisen karttalinkin (server-side image map) jokaista aktiivista aluetta tulee vastata redundantti tekstilinkki. (WAI 1.2)
  6. Palvelinpohjaisten karttalinkkien asemesta tulee käyttää selainpohjaisia karttalinkkejä paitsi silloin, kun alueita ei voi määritellä käytettävissä olevalla geometrisella muodolla. (WAI 9.1)
  7. Datataulukoille tulee määritellä rivi- ja sarakeotsakkeet. (WAI 5.1)
  8. Merkkausta tulee käyttää liittämään data- ja otsakesolut toisiinsa datataulukoissa, joissa on vähintään kaksi rivi- tai sarakeotsakkeiden loogista tasoa. (WAI 5.2)
  9. Kehyksillä tulee olla nimitykset, jotka helpottavat kehysten tunnistamista ja navigointia. (WAI 12.1)
  10. Sivujen suunnittelussa tulee olla tavoitteena välttää kuvaruudun välähteleminen taajuudella, joka on suurempi kuin 2 Hz ja pienempi kuin 55 Hz. (WAI 7.1)
  11. Pelkkää tekstiä sisältävä sivu, jolla on täysin vastaava informaatio tai toiminnallisuus, tulee tarjota, jotta Web-sivusto täyttäisi tässä osassa olevat vaatimukset, jos vaatimuksia ei voida täyttää millään muulla tavalla. Tämä pelkkää tekstiä sisältävä sivu tulee päivittää aina, kun ensisijainen sivu muuttuu. (WAI 11.4)
  12. Kun sivut käyttävät skriptikieliä sisällön näyttämiseen tai käyttöliittymän elementtien luomiseen, niin skriptin tarjoama informaatio tulee ilmaista tekstillä, joka voidaan lukea esteettömyyttä avustavan tekniikan (assistive technology) avulla.
  13. Kun Web-sivu vaatii, että käyttäjän järjestelmässä on sovelma, lisäosa (plug-in) tai muu sovellus, joka tulkitsee sivun sisältöä, niin sivulla tulee olla linkki lisäosaan tai sovelmaan, joka vastaa [Section 508:n] § 1194.21:n kohtia (a):sta (l):ään.
  14. Kun sähköiset lomakkeet on suunniteltu täytettäviksi verkkoyhteyden ollessa käytössä, lomakkeen tulee sallia avustavaa tekniikkaa käyttävien ihmisten päästä käsiksi siihen tietoon, lomakkeen kenttiin ja toiminnallisuuteen, joita tarvitaan lomakkeen täyttämiseksi ja lähettämiseksi, mukaan lukien kaikki ohjeet ja vihjeet.
  15. Tulee tarjota menetelmä, joka sallii käyttäjien ohittaa samanlaisina toistuvat navigointilinkit.
  16. Kun vaaditaan ajastettu vastaus, käyttäjälle on huomautettava ja hänelle on annettava riittävä aika sen ilmoittamiseen, että hän tarvitsee lisäaikaa.

Vaikka Section 508 on pyritty tekemään objektiiviseksi, tämä ei tarkoita, että sen noudattaminen olisi täysin tarkistettavissa nykyisillä tarkistusohjelmilla. Esimerkki: WAI-ohje mainitsee (kohdassa 7), että epilepsiakohtauksen saattaa laukaista välähtely, jonka taajuus on 4 - 59 hertsiä, ja että vaarallisin taajuus on noin 20 hertsiä. Section 508 puolestaan asettaa ehdottoman säännön, ja siihen on jostakin syystä otettu hiukan eri taajuusalue: kielletty alue on 2 - 55 Hz. Tämän vaatimuksen täyttäminen on objektiivisesti mitattavissa, mutta käytännössä tarkistusohjelmat eivät sitä tee, vaan tarvitaan ihmisen suorittama tarkastus. Ohjelmahan joutuisi analysoimaan mm. kaikki sivulla olevat kuvat ja videot jollakin tapaa, kun taas ihmiselle asia on yleensä selvä vilkaisun perusteella.

Esimerkki suositusten soveltamisesta

Tässä tarkastellaan melko yksinkertaista mutta tavallista tilannetta, jossa sivustolla oleva keskeinen valikko on osittain ongelmallinen:

TEKSTIVERSIO | TIEDOTEARKISTO | AAKKOSET | LOMAKKEET | YHTEYSTIEDOT | SVENSKA | ENGLISH

Tässä on linkkilista kirjoitettu taulukon soluksi ja määritelty sille taustaväriksi tummahkon vihreä. Jotenkin vaikutelma on outo ja hiukan hankala, mutta löytyykö esteettömyysohjeista jotain, joka kehottaisi muuttamaan tällaista sivun kohtaa?

Tehtävä: Arvioi edellä esitettyä linkkilistaesimerkkiä yhden tai useamman edellä mainitun suosituksen, ainakin WAI-ohjeen, pohjalta. Onko jotain ilmeistä tai vähemmän ilmeistä vikaa tai kehittämistarvetta? Entä miten vakavina mahdollisia ongelmia voidaan pitää? Arviointi on tarkoitettu tehtäväksi ilman erityisiä arviointivälineitä. (Joiltakin osin arviointi voi kuitenkin vaatia sivun HTML-merkkauksen tutkimista.) Tehtävän tehtyäsi voit verrata sitä esimerkkiarvioon.

Muita artikkeleita aiheesta:
Seuraa polkua:
Edellinen: Lynx-tekstiselain
Seuraava: Miten esteettömyyttä testataan?