See ülevaade oli planeeritud pikemaks ja põhjalikumaks. Ajast tuli nappus kätte ja jäi pooleli. Kuna aga nvajadus taolise info järgi on olemas, siis panen selle avalikuks kasutamiseks. Ja ega need 7 - 8 lehekülge nüüd nii vähe ka pole. Kasulikku leiab siit küll.
Artur Räpp

< tagasi avalehele

Lühidalt probleemist

Vahendid nägemispuudega inimestele kodulehtede lugemiseks

Võimaldamaks nägemispuudega inimestel arvutiga töötada on välja töötatud mitmeid abiprogramme ning tehnoloogiaid. Abiprogrammide põhijaotus on järgmine:

1. ekraanilugemisprogrammid – kasutajateks täispimedad või väga väikese nägemisjäägiga inimesed
2. ekraanisuurendusprogrammid – kasutajateks inimesed, kes vajavad ekraanil oleva teksti ja ekraanijuhtelementide suurendamist (tavaliselt jääb suurendus 1 ja 8 vahele, kuid võimalik on kasutada ka suuremat suurendust. Mida suurem on suurendus, seda suurem on ülevaatlikuse kadu
3. tarkvaralised kõnesüntesaatorid – kasutajateks ekraanilugemisprogrammide kasutajad. Ka paljud tasemel ekraanisuurendusprogrammid oskavad “oma juttu” kõnesüntesaatorite abil kuuldavaks teha. Ekraanil oleva kujutisega kõnesüntesaator ei tegele. Selle töö teeb ära kas ekraanilugemis- või ekraanisuurendamisprogramm, mis siis “ütleb ette”, mida kõnesüntesaator peab ütlema. Lisaks tarkvaralistele kõnesüntesaatoritele on selle kirjutise kirjutamise ajal (2007 aastal) Eestis kasutusel ka mõned riistvaralised kõnesüntesaatorid.
4. punktkirjakuvarid – kasutajateks ekraanilugemisprogrammide kasutajad. Punktkirjakuvarid on nagu kõnesüntesaatoridki mõeldud vaid etteantud info väljastamiseks. Punktkirjakuvarid võimaldavad ekraanilugemisprogrammide poolt etteantud infot lugeda kombitavas punktkirjas.

Lisaks on olemas ka vahendeid, mis kas seotuna konkreetse veebilehe, rakendusprogrammi või mööndustega isegi operatsioonisüsteemiga annavad info edasi vahetult kõnesüntesaatorile või kasutavad info edastamiseks varem salvestatud häälega helifaile. nn iserääkivaid kodulehti ja programme siiski eriti palju ei ole. Minirakendustest on ehk enimkohatud Gmaili ja hotmaili häälega inimese tuvastussüsteem (gapca). Operatsioonisüsteemidest on väidetavalt hääleväljundi kasutamine kõige tugevamalt sisseintegreeritud Mac OS X uuemate operatsioonisüsteemide puhul (arvamusi on erinevaid)

Kasutatav tarkvara

Ekraanilugemisprogrammidest on hetkel Eestis kasutusel valdavalt firma Freedom Scientific poolt toodetava JAWS erinevad versioonid. JAWS töötab vaid Microsoft Windows keskkonnas. Ekraanisuurendusprogrammidest kasutatakse Eestis enim firmade Freedom Scientific poolt toodetava Magic ning Ai Squared poolt toodetava Zoomtext Xtra eri versioone ning Microsoft Windowsiga kaasa tulevat Magnifier nimelist programmi. (kõik nimetatud programmid töötavad vaid Microsoft Windowsi keskkonnas. täpne ekraanisuurendusprogrammide kasutajate hulk ning jaotus on teadmata)

Veebilehitsejatest kasutavad ekraanilugemisprogrammide kasutajad pea-aegu eranditult vaid Internet Explorerit (versioon 5 või uuem). Põhjuseks on see, et teistelt veebilehitsejatelt ei saa JAWS piisavas koguses infot ekraanil oleva kohta. Alles viimane JAWS-I versioon (versioon 7) suudab töötada uusima Mozilla versiooniga (versioon 1.5 või uuem.

Põhiprobleemidest veebilehtedel

Veebilehel oleva info kasutatavus ja ligipääsetavus

Kõige pealt oluline täpsustus: tihti pööratakse kodulehtede puhul pearõhk selle ligipääsetavusele. Põhjuseks võib olla see, et ligipääsetavus annab aluse lehe kasutatavuseks ja ligipääsetavusealased soovitused on kergemini ja konkreetsemalt kirjjapandavad. Kuid kõigi nende soovituste eesmärk on kasutatav leht. Lehe ligipääsetavus on vaid eelaste lehe kasutatavuseks. Samas võib ligipääsetavuse parandamisega tegeledes saavutada olukorra, kus reeglite ja soovituste järgi on lehega kõik korras, kuid lehe kasutatavus jääb alla keskmiselegi veebilehele.

Ligipääsetavussoovituste ja reeglite Üksnes järgimine võib anda, kuid ei pruugi anda kasutatavat lehte. Sama seaduspärasus kehtib ka ju veebilehe disainireeglite ja veebilehe välimuse ilu kohta: veebilehe struktuurisoovituste ja veebilehe ülesehituse mugavuse kohta.

Veebilehtedega seotud probleemidest üks peamistest on veebilehel esitatud info kasutatavus. Kõige ilmekamalt tuleb see probleem esile piltide puhul. Pilte ei suuda kaasaegsed (2007 a.) nägemispuudega inimestele mõeldud tarkvarad mingiks sisukaks kõneks muuta. Kuid sellest probleemist ümberminekuks saab veebmeister pakkuda kõrvalteid.

On oluline meeles pidada, et pildid on küll sagedaimad kuid mitte ainsad taolise probleemi tekitajad.

Info paiknemine lehel

Nägemispuudega inimestele mõeldud abiprogrammid pakuvad veebilehe sisu oma kasutajale harilikult vastavalt lehe koodi järjekorrale. Nii võib juhtuda, et Veebmeistri poolt kenasti ekraani keskele- kergesti leitavale kohale - paigutatud info jõuab nägemispuudega inimestele mõeldud tarkvara kasutajani alles mitmekümnendal või mitmesajandalgi real. Õnneks pakuvad nii kaasaegsed veebilehekirjutamisstandardid kui ka nägemispuudega inimestele mõeldud tarkvarad mitmeid võimalusi veebilehel liikuda ka millegi muu kui reakaupa. Peamine, et veebmeister on neid võimalusi oma lehel kasutanud.

Võimalus lehel soovitud kohani kiiresti liikuda või ebaolulist piirkonda vahele jätta on nägemispuudega inimestele väga oluline. Veebilehte ei saa lugeda kergesti kasutatavaks, kui vajalik info on lehel loetaval kujul olemas, kuid selleni jõudmine võtab liiga kaua aega.

Lehe koodis eraldatult paikneva info seostamine

Oluliste probleemide hulgast võib veel välja tuua raskused lehe eri osades oleva info omavahelisel seostamisel. Näiteks tabelis lahtri ja lahtri selgituse sidumisel, veebivormide puhul sisestuselemendi juurde kuuluva teksti leidmisel, lingi "loe edasi" või "klõpsa siia" vms juurde kuuluva teksti leidmisel vm.

Kasutatava abitarkvara ja veebitehnoloogia kokkusobivusest

Olulise probleemideringi moodustavad ka kasutatava tarkvara toimetulek kasutatavate veebitehnoloogiatega: JavaScript ja VBScript, Java Applet'id, Flash filmid jm. Ükski neist pole just päris "lootusetu", kuid kõige "lootusetum" nimetatuist on Java appletid. Ka standardile mittevastava või lihtsalt vigase koodiga koduleht võib tekitada suuri probleeme.

Nägemispuudega inimeste erisoovide kokkulangevused
teiste kasutajarühmadega

Muutes kodulehe nägemispuudega inimestele kergesti kasutavaks, muutub see leht ka paljude teiste inimeste jaoks märksa mugavamaks. Samas ka vastupidi: arvestades veebilehe kavandamise juures mitmete lehe külastajagruppidega, on samaaegselt arvestatud ka mitmete nägemispuudega inimeste soovidega.

Kui kodulehe loomisel on:

v     järgitud kehtivaid standardeid (HTML, XHTML, XML (vastavalt lehel kasutatavale)),

v     arvestatud sellega, et leidub inimesi, kes kasutavad üsna vanu veebilehitsemisprogramme (sealhulgas ka tekstipõhiseid nagu Lynx)

v     arvestatud aeglase internetiühenduse kasutajatega (ka neid on veel ja neile on piltidega ülekülvatud lehed üsna tülikad)

v     arvestatud inimestega, kes on alles algajad internetis surfajad.

v     kirjeldavad tekstid (lingitekstid, vormiväljade selgitused, pealkirjad jm) on hästi valitud. (nägemispuudega inimestel on nii või naa aeganõudvam lehe sisust ülevaadet saada. Selle pärast on oluline, et nad jõuaksid soovitud tulemuseni väikseimate eksirännakutega)

siis on osa JAWS-i kasutajate või teiste nägemispuudega inimeste soove juba arvesse võetud.

Kuid mitte kõiki.

Pildid

Pildid on olulised veebilehe disaini ja ka edastatava info komponendid. Pildi mittenägemist ei kompenseeri 100 protsendiliselt mingil moel, kuid osaliselt on see siiski võimalik. Pildil olevat infot võib edasi anda lehel oleva tekstiga - infot tekstiliselt dubleerides. Mõnikord on pilt vaid tekstis oleva info visuaalne dubleerimine (illustratsioon). Pildi olemasolule võib teksti kaudu ka viidata ("nagu on näidatud joonisel" vm). Pildi kirjeldamiseks või sellel oleva info edasiandmiseks võib luua ka eraldi lehe. Lisaks neile pakub HTML standard võimaluse määrata piltidele alt atribuudi abiga alternatiivse kirjeldava teksti. Alt atribuudiga määratav tekst on soovitavalt lühike, kuna pikem segaks lehe lugemist. (vahel tehakse ka erandeid). Puhtalt kujunduslikele või lehe kujunduse ülesehitamiseks kasutatavatele piltidele ei ole soovitav alt atribuudiga alternatiivset teksti määrata.

piltidele alt atribuutide määramine:

1. pildid, mida kasutatakse tabeli lahtrite laiuse määramiseks vms varjatud kujunduselemendid, peavad olema tühja alt atribuuti väärtusega
   alt=""
2. Puhtalt lehe ilustamiseks mõeldud pildid oleks soovitav varustada samuti tühja alt atribuudiga (alt="").
   märkus: päris ilma alt atribuudita ei maksaks neid pilte jätta, sest kui lehte hakatakse automaatsete lehe ligipääsetavuse kontrollivahenditega kontrollima, hakkavad need alt atribuutideta piltide üle "nurisema" ning põhjustavad liigset tööd lehe koodi kontrollimisel. Lisaks ei saa lehele (soovi korral) testi edukat läbimist tähistavat märki panna, sest testi ei läbita.
3. Kui lehel on pilte, mis tähistavad uue osa algust või juhivad mõnel muul põhjusel tähelepanu mingitele lehe osadele, võiks need varustada pildi tähendust kirjeldava alt atribuudiga. Enne tuleks aga lahendused läbi kaaluda. Probleemiks võib olla näiteks see, kui n-ö pilgujuhte on liiga palju või nende kirjeldamine vajab liiga pikka teksti.
4. Lehel olulist rolli omavad pildid tuleks varustada pildi tähendusele vastava alt atribuudiga. Seda ka siis, kui pilt annab edasi vaid esteetilist/visuaalset infot (logo, perefoto, meremaal, jne). Korrektse alt atribuudi korral võib näiteks nägemispuudega inimene pöörduda mõne tuttava poole palvega kirjeldada pilti. Ilma korrektse alt atribuudita poleks tal aimugi pildi olemasolust või tähendusest.
5. Kui pilt annab edasi konkreetset infot, tuleb see kindlasti varustada edastatavale infole vastava alt atribuudiga. Kui pildil on joonis, skeem, diagramm vm, info, mida ei ole võimalik lühidalt alt atribuuti kasutades edasi anda ja tekstis pole edastatavat infot piisavalt selgitatud või infoedastust tekstiga dubleeritud,tuleks kaaluda eraldi pilti kirjeldava lehe loomist. Sama soovitus kehtib ka eelmise punkti kohta (esteetilise või visuaalse infoga pildid).
6. Kui pilte kasutatakse mingi kindla fondi või värviga teksti näitamiseks, tuleb see kindlasti varustada edastatava tekstiga identse alt atribuudiga. Võimaluse korral tuleks vältida pildina edastatava teksti kasutamist, kuna inimesed, kes näevad halvasti, ei saa kasutada oma veebilehitsemisprogrammi tekstisuurendusfunktsioone sellise teksti suurendamiseks või värvimuutmiskäske tausta- või tekstivärvi muutmiseks.

Võimaluse korral tuleb pildifaili nimena kasutada pildi tähendust kirjeldavat nime. Pildifaili nimi on lisainfoallikas juhuks, kui alt atribuut on ununenud määrata või kasutatav tarkvara ei oska mingil põhjusel alt atribuuti kasutada.

Lehe struktuur ja HTML siltide kasutamine

Pealkirjad

Üks tavalisemaid ja lihtsamini kõrvaldatavamaid vigu veebilehe tegemisel on lehel olevate pealkirjade tähistamine vaid visuaalselt.

Tüüpilisel veebilehel on uue osa alguses lühike rida järgneva teksti kirjeldamiseks - pealkiri. Kahjuks kasutatakse pahatihti pealkirja märkimiseks tavalõiku märkivat silti (tag) <P>...</P>, millele on CSS abil antud soovitud kujundus. Taolist pealkirja ei suuda nägemispuudega inimestele mõeldud programmid üles leida. Kasutades selle asemel pealkirjade jaoks määratud silte (h1 kuni h6) ning andes neile CSS abil vajaliku kujunduse, on lehe visuaalne välimus sama, kuid JAWS ja teised vastavad eriprogrammid leiavad lehel olevad pealkirjad üles ja nii on ka nende programmide kasutajatel palju-palju kergem lehel liikuda. Ulatuslikemate veebilehtede puhul tuleks kindlasti jälgida ka pealkirjatasemetega määratud lehe struktuuri vastavust soovitule. Esimene tase - kõige kõrgem, esimese tasemega pealkirja "all" on teise tasemega pealkirjad, jne kolmas, neljas tase vastavalt lehe struktuurile.

Pikkade dokumentide puhul muudab pealkirjasiltide ja pealkirjatasemete õige rakendamine JAWS-i ja teiste vastavate programmide kasutajatel antud lehel liikumise mitmeid kordi kiiremaks.

Lingigruppide grupeerimine

Omaette probleemideringi moodustavad rohkearvulised lingid. Grupeerides linke vaid visuaalselt jääb linkide struktuuriline grupeerimine juhuse hooleks. Juhusliku meetodiga aga tavaliselt head tulemust ei saavuta. Näiteks on delfi.ee (21.veebr.2007) üle 700 lingi ja puudub kergesti märgatav struktuur linkide vahel liikumiseks.

Kahjuks puudub selle probleemi lahendamiseks üks ja kindel lahendusvõte. Muude lahendusteede hulgas võib kaaluda ka järgmisi:

linkide arvu vähendamine lehel; linkide grupeerimine ja eri gruppide paigutamine eraldi lehe struktuurielementide sisse; pealkirjade paigutamine lingigruppide vahele või lingigrupi esimese lingi muutmine pealkirjaks; lingigrupist mööda minemiseks "link samale lehele" kasutamine; kiirklahvide määramine (accesskey);

võimalikke lahendusteid on veel. Nende kasutamine sõltub konkreetsest olukorrast.

Märkus: “link samale lehele” on võimalik muuta ka tavakasutaja jaoks nähtamatuks. Selleks võib lingi kirjeldavaks tekstiks kasutada väikest läbipaistvat pilti, mis on varustatud sobiva alt atribuudi väärtusega või kasutada selleks css võimalusi (http://www.webaim.org/techniques/skipnav/)

Tabelid

Veebilehtedel kasutatakse väga tihti tabeleid. Kuna tabelite kasutusalad on väga mitmekesised ja ka tabelite struktuur erineb tabeliti suuresti, siis on nende nägemispuudega inimeste jaoks "sõbraliku" struktuuri kujundamiseks antud palju soovitusi.

Lihtsaim neist:

Kui tabel on lihtsa struktuuriga (ridade ja veergude arv tabeli sees ei muutu) ja tabelis on veergude kaupa andmed (sama tüüpi andmed ühes veerus), siis tabeli esimeses reas peab olema andmeid kirjeldav tekst (ravimi nimi, pakendi tüüp vm).

Tabel on soovitav varustada kas summary atribuudiga, mille sisu vastab tabeli tähendusele või korrektse caption sildiga. Summary atribuudi kasutamisel tuleb järgida sarnaseid põhimõtteid piltide alt atribuutidega varustamisel - kujunduslikud tabelid on soovitav jätta ilma tekstiga summary atribuudita.

Keerukama struktuuriga tabelite puhul võib kasutada HTML keele võimalusi tabeli päiserea märkimiseks (scope, headers atribuudid vm vastavalt standardile)

Lehe struktuurist üldisemalt

Lihtsamal juhul on lehe struktuuri ülesehitamisel tehtavad vead sarnased "pealkirja probleemiga" - silte (tag) kasutatakse vales tähenduses või kontekstis. Näiteks UL ja OL elemente taandatud tekstiploki tekitamiseks või üksteisesees BLOCKQUOTE silte keskjoonduse saamiseks. Või ka seotud loetelus avatakse iga erineva elemendi jaoks uus loetelu, mis pärast elemendi lõppu suletakse ja mille järel avatakse uue elemendi jaoks uus loetelu.

Näide:

<ul>

<li>leib</li>

</ul>

<ul>

<li>sai</li>

</ul>

...

või muud sarnased vead. Veebmeistri taseme tõustes selliste vigade hulkk õnneks väheneb.

Lehe struktuuri märgistamine

Lehe struktuuri on soovitav märgistada korraga mitmel erineval moel. näitena: standardhäälestuse puhul on hüperlingid muust tekstist erinevat värvi ja allajoonitud. Kui inimene kas ei erista määratud värve või on muutnud teksti ja linkide värvi samasuguseks (näiteks parema loetavuse huvides), siis leiab ta potensiaalsed lingid üles allajoonituse abil.

Kasutades taanet, joondamist, raame, teksti- või taustavärve, fonti ja selle suurust, markeerivaid pilte (pilgujuhte), erisümboleid (näiteks püstjoon linkide vahel) vm ning markeerides nende abil linke ja navigatsioonilinkide osa, pealkirjad, üldteksti või muud lehe struktuurilised piirkonnad, leiaksid inimesed, kelle nägemine on piisavalt hea, et lugeda silmadega, kuid küllalt halb, et lugemine oleks väsitav ja vaevarikas, kergesti üles soovitud lehe struktuuri osa ja ei peaks nii lehel orienteerumiseks pidevalt lehe teksti lugema. Selline kujundus aitab ka hea nägemisega veebilehe külastajat, kuna kiirendab lehel soovitud info – otsitud lehepiirkonna - ülesleidmist.

Oluline! teksti- ja taustavärvi valikul tuleks hoolikalt jälgida, et need oleksid piisavalt kontrastsed.

Mahukamate lehtede korral on soovitav, et iga osa algaks (pealkirja järel esimene lõik) järgneva osa kokkuvõttega. See muudab lehel liikumise kiiremaks, kuna nii saab lehe külastaja rutem infot, mis selles lehe osas järgneb. (kehtib kõigi lehekülastajate kohta).

Lehestiku struktuur

Kogu lehestiku struktuuri valimisel ühtset ja head lahendust ei ole. Hea lahendus sõltub veebilehestiku sisust ja külastaja soovidest, eelistustest ja harjumustest ja selge, et need on igal külastajal erinevad. On mitmesuguseid soovitusi, kuidas lehe struktuuri paremaks muuta, kuid vähegi keerukama lehe jaoks ühtegi pärisideaalset pole. Selle pärast on soovitav pakkuda peamisele lehestruktuurile mingi alternatiiv (lehe sisukaart/sisukord, võimalus interaktiivselt lehe struktuuri muuta, varustada leht otsimisvõimalusega vm).

Vormi elemendid

veebivormide kasutamise puhul tekib pahatihti mitmesuguseid probleeme. Tihti (kuid siiski mitte alati) saab neid lahendada järgides järgmisi nõuandeid:

veebivormi elementidena kasutada vaid W3C poolt standardiseeritud vormielemente;

määrata LABEL sildi abiga igale vormi elemendile selgitav tekst.;

Viimasel juhul võib probleemiks saada, kui ühele veebivormi elemendile tuleks määrata kirjeldav tekst kahe LABEL sildi abiga. hetkel (2007 oktoobris) pole selline lahendus JAWS poolt veel toetatud. Ehk edaspidi, sest W3C standard lubab sellist lahendust.

mitmele sisestusväljale ühe kirjeldava teksti määramiseks võib kasutada fieldset ja legend silte.

NB Kui veebivormielemendid asuvad tabeli lahtrites ja nende selgitavad tekstid asuvad samas tabelis, kuid mingites teistes lahtrites, on LABEL sildi kasutamine ainuke lootus saada normaalselt JAWS-ga toimivat veebivormi.

Kui veebivormi elemendid asuvad väljaspool tabelit, siis üldjuhul toimib järgmine paigutus:

kirjeldav tekst tekstisisestusväljast vasakul,

kirjeldav tekst raadionupust ja märkeruudust paremal,

kirjeldav tekst valikukasti kohal.

Lähtudes lehe kujundusest võib veebivormi elementide kirjeldamiseks kasutada ka alt või title atribuuti.

märkus: vahel tekib probleeme raadionuppude ja grupeeritud märkeruutude gruppi kirjeldava teksti lehele paigutamisega nii, et seda loetaks korrektselt ette.

Interaktiivsed lehed

Kui lehele paigutatud skriptid "teevad tööd" lehe avanemise ajal aidates vaid lehte üles ehitada, siis _valdavalt_ probleeme ei ole.

Kui skriptid kontrollivad veebivormiväljade täitmist, siis mõningatel juhtudel on probleeme esinenud, kuid need ei ole õnneks väga sagedased.

Kui skriptide abiga pannakse mõni lehe ebaharilik piirkond (väljastpoolt linke) hiire klõpsu peale uusi lehti avama, on probleemide esinemine täiesti märgatav.

Kui skriptide abil pannakse "lisalinkide menüüsid" ekraanile nihkuma, siis on sellised lahendused tihti suurte probleemide allikad.

Mõningasi neist probleemidest on kaasaegsed ekraanilugejad suutelised küll lahendama, kuid kuna õnneks ei ole taolised probleeme tekitavad lahendused veel väga levinud, ei tea paljud JAWS (vm sellise tarkvara) kasutajad, kuidas simuleerida oma programmi abil (klaviatuurilt) hiirekursori viibimist mõne lingi või muu lehe osa kohal, et nii lisamenüüd avada ning seda kuidas pärast lisamenüü avanemist hõlpsasti uude menüüsse jõuda.

soovitused:

veebilehtedele paigutatud skripte tuleb kas vastava eritarkvaraga testida või

kasutada skripte kui nende kasutamine on möödapääsmatu (hinnakalkulaatorid jne) või hädavajalik (veebivormi sisestuse kontroll vm, mõningatel juhtudel)

kasutada skripte kui need ei lae pidevalt midagi (kiiresti muutuvad piltfilmid) või ei häiri teisiti võrgu või arvuti tööd ja skripti töö on veebilehestiku eesmärgi suhtes kõrvaline (ekraanikell või taimer aastavahetuseni vm)

Valikukastid, milles ühe elemendi valimisel avatakse automaatselt kohe uus leht, on küll JAWS-i kasutajatele kasutatavad, kuid kui sellist lahendust planeeritakse pigem efekti kui kasutajate mugavuse pärast, siis oleks mõistlik sellist lahendust vältida.

Muudel juhtudel tuleks kaaluda kas skriptidest loobumist või mingi alternatiivi pakkumist.

Loota, et just teie kodulehel käivad ainult it-spetsialistist nägemispuudega inimesed ja nende kasutada on ekraanilugejad, mis suudavad igasuguse lehega toime tulla, lihtsalt ei tasu. Olen elus kohanud lehte, kus ühelt lehelt teisele sai pärast lingil hiireklahvi vabastamist (onmouseup sündmus). Ei tolleaegne ega ka hetke kõige uuem JAWS ei suuda sellist sündmust simuleerida.

( järgmisele lehele viis mind seal vaid HTML koodi uurimine )

( märkus: nii lühikese ülevaate juures on jäänud mitmed skriptide kasutamise juhtumid vaatluse alt välja ja nende käsitlus on üsnagi lihtsustatud )

Artur Räpp