Jelen tanulmányban megpróbáljuk körbejárni azon lehetséges megoldásokat, mellyel egy honlapot a vakok számára is olvashatóvá lehet tenni. Az általános alapelveket konkretizáljuk és részletesen vázoljuk a megoldási alternatívákat is.

Ma már egyre több látássérültnek van alkalma használni az Internetet, de az egyre jobban "elgrafikusodó" világban az információhoz való hozzáférésük nemhogy nőne, inkább csökken - annak ellenére, hogy az 1998-tól érvényben lévő "esélyegyenlőségi" törvény szabályozza az információhoz való hozzájutás jogát.

Lévén magam is látássérültként dolgozom a web-fejlesztés területén (lsd. referenciák), kétfelől közelítem meg a kérdést. Egy részről egy általános áttekintő után, melyben a ma használatos vakos rendszerekről beszélek, felhasználói "szemmel" közelítő módon írom le a web-site jelenlegi (2002. január) állapotát. Más részről a lehetséges alternatívák felsorolása után megpróbálok (olykor magammal is vitatkozva) egy mindenki számára optimálisnak mondható megoldást kidolgozni a honlap szerkezetének felépítéséhez.

Az anyagban felhasználtam a KFKI (http://www.kfki.hu/(hu)/cnc/doku/vakwebelv.html), valamint a W3C ajánlásait a vakok számára is olvasható honlapok témájában (http://www.w3.org).

Ahhoz, hogy betekintést nyerjünk a látássérültek Internet-lehetőségeibe, meg kell vizsgálnunk azt a szoftver környezetet, mely segítségével a legtöbb magyarországi vak ember dolgozik, valamint azt, hogy milyen általános internetes szabványok léteznek, melyeket az adott honlapon alkalmaznak. A vakok által használt beszélőrendszerek áttekintése után néhány szóban összefoglaljuk azon kritikusnak tűnő design és HTML szerkezeteket, melyeken keresztül az internetes felhasználás során naponta találkozunk a weben. Mivel a honlapokon nemcsak a szabványos HTML megoldásokkal programozott oldalak találhatóak, meg kell vizsgálnunk a szerver-oldali programozást, valamint a honlaprendszer szerves részét alkotó adatbázis kezelő rendszerek korlátait és lehetőségeit, azok vakok számára implementálható módját. A cél, hogy egy olyan működő web-site-ot kapjunk, mely egy adott terminológiát követve bármikor bővíthető legyen, ugyanolyan könnyedén mind látók, mind vakok számára egyaránt praktikusan és célirányosan használható legyen.

A látássérültek számára a képernyőt a külön nekik "épített" kijelzőrendszerek jelentik, így akár a számítógéphez képernyő sem szükséges. A vakok két féle módon kaphatnak üzenetet a számítógéptől: 1. Braille-jelek által, 2. hangos beszéd által. A Braille-kijelzők (áruk miatt) hazánkban nem elterjedtek, az a 2-3 darab eltörpül a több ezer beszélőrendszer mellett. Külföldi tapasztalatok alapján az is kiderül, hogy akik Braille-kijelzőt használnak, azok telepítenek egy beszélőrendszert is gépükre és "egyik kiegészíti a másikat" elven hol ezt, hol azt használják, az adott feladatnak megfelelően. így alaptézisként megállapíthatjuk, hogy a látássérültek túlnyomó többsége beszélőrendszerrel használja az Internetet.

Magyarországon egyetlen kizárólag hazai fejlesztés létezik, mely DOS. alatt működik (Brailab). A többi beszélő mind külföldön gyártott termék. Hazánkban szamizdat módon érkeztek be a külföldön drágán beszerezhető Windows-t (is) olvasó software-ek. A két "legjobb" rivális itt is aratott: a Jaws és a Window Eyes. A Window Eyes mellett szól az, hogy a BraiLab PC-vel kis trükkök alkalmazásával egy magyarul beszélő rendszert lehet "összebarkácsolni", mely képes Windows alatt is használhatóvá tenni - bizonyos szinten - a gépet (a BraiLab PC önmagában nem képes, csak DOS. alatt beszélni).

2.1. Brailab

Magyarországon már több, mint 12 éve használnak a vakok beszélő számítógépet. A forgalomban lévő, vakok számára készített beszélő gépek 99 %-át az Arató András és Vaspöri Teréz által fejlesztett brailab eszközök teszik ki. Teréz teljesen vak, ő írta a text-to-speech (szöveget beszéddé alakító) rendszer zömét, egy egykarakteres braille kijelzőt és egy 144 szót tartalmazó fixszavas angol beszédszintetizátort használva. Arató András készítette el a fejlesztőrendszert úgy, hogy vakon is lehetett vele dolgozni. Így indult a BraiLabok fejlesztése 1982-83 telén.

Azóta máig A BraiLab termékcsaládnak 3 tagja van: BraiLab basic alapgép, BraiLab plus és a BraiLab PC.

A BraiLab basic alapgép 1985-ben került forgalomba, összesen négyszáz darabot használtak belőle a látássérültek. 64 Kbyte memóriával ellátott basic interpreter gép volt.

A BraiLab plus-ok eladása 1987-ben kezdődött meg. Ezek a gépek 256 Kbyte-os memóriával, floppy meghajtóval és CP/M operációs rendszerrel rendelkeztek. A hozzájuk adott programcsomag tartalmazott többek között egy 3.0-s WordStar szerkesztőt, braille nyomtatást támogató teljes rendszert, adatbáziskezelőt, különböző programnyelveket, terminálemulációt lehetővé tevő programot. A BraiLab plus-ok már főként munkaeszközként kerültek felhasználásra. 70 darab segítette a vak emberek munkáját.

A termékcsalád következő tagja, melyet ma is a legtöbben használnak, a BraiLab PC, mely 1991-ben került forgalomba. Eddig 4 alkalommal bocsátottak ki a hozzátartozó szoftvercsomagból újabb verziót. Ez az eszköz IBM PC párhuzamos kimenetéhez csatlakoztatható adapter, amely egy vakokat intelligensen támogató rezidens szoftver segítségével beszél. A BraiLab plus-hoz tartozó programcsomag PC-re történő átvitele mellett újabb segédprogramokkal is bővült. Így például:

- többféle kódkészlet használatát és a BraiLab PC paramétereinek megváltoztatását lehetővé tevő program,
- meghangosító rendszer, amely a "rosszul beszélő" programok hangosítását teszi felhasználó baráttá,
- kivételszótár kezelő, amely a rendhagyó kiejtésű szavak helyes kiejtését támogatja.

A beszéd minőségének és a beszéltető program intelligenciájának fejlesztése mellett egyre inkább előtérbe került a hálózatos lehetőségek vakok számára történő elérhetővé tétele.

A rendszer hiányossága, hogy jelenleg karakteres üzemmódban képes dolgozni. A BraiLab család tagjairól elmondható, hogy megbízható hardverrel és szoftverrel kerültek forgalomba, valamint hogy áruk töredéke a hasonló nyugati segédeszközökének. További előnyt jelent, hogy a magyar nyelvű szöveget nem valamely idegennyelv kiejtésén kell hallgatni! A fejlesztés helyes irányának tartom, hogy a hangsúlyt a programok intelligenciájának növelésére helyezik a fejlesztők, és nem a már jól érthető beszéd tökéletesítésére.

A BraiLab CD a BraiLab PC-nek egy tovább fejlesztett változata, amely érthetőbb beszéddel van ellátva, ill. alkalmas digitális könyvek (digibook) felolvastatására is. A termék túl drágának bizonyult és a jelenleg rendelkezésre álló kis számú digibook-ok miatt nem éri meg a felhasználóknak ekkora beruházást eszközölni. így elmondható, hogy a BraiLab családból a BraiLab PC termék a legelterjedtebb hazánkban.

Arató András és Vaspöri Teréz (a fejlesztők):

"A BraiLab PC-s ernyőolvasó legfőbb elve az volt, hogy a vak felhasználónak ne kelljen a gép programjai használatakor sok parancsot megtanulnia, hanem elég legyen csak a program billentyűkről történő használatára koncentrálnia (esélyegyenlőség!). Nagyon fontos szempont volt az is, hogy a szintetizált beszéd gyors reakciójú legyen. A változó ernyő legfontosabb része szólaljon meg először, és a beszéd legyen könnyen leállítható. Az, hogy ma kb. 2000 vak PC-s felhasználó van, az nagyrészt ezen elvek megvalósulásának köszönhető."

2.2. WinTalker

A WinTalker egy Szlovák programozócég terméke, mely az első Magyar nyelvű rendszer, ami képes Windows alatt felolvasni a képernyőt. A software-t folyamatosan fejlesztik, de jelenleg nem érte el a külföldön már jól működő és megbízható Windows-os képernyőolvasást. A vak ember nem közvetlenül olvassa a képernyőt, mint ahogyan a látó, hanem közvetve, tehát egy eszköz segítségével. Míg a látó ember ránéz a képernyőre, meglátja az ott megjelenő összefüggéseket, párhuzamot tud vonni a képen megjelenő információk között és a számára éppen fontosakat hasznosítja csak. Ezzel szemben a vak ember számára egy "unintelligens" gép közli az információt, ebből következik, hogy olyat is, ami esetleg az adott feladatnál nem hasznos, sőt, hátrány (mondjuk egy óra megjelenik a bal felső sarokban). Ezért igen nehéz olyan képernyőolvasó programot készíteni, ami képes megfelelő módon "leválogatni" a szükséges információt a képernyőről. Jó példa erre egy táblázat felolvastatása. Míg a látó ember egyszerre látja a sorokat és oszlopokat, addig a vak kizárólag lineárisan, soronként kapja meg az információt, ami egy több oszlopos táblázatnál teljes használhatatlanságot is eredményezhet. A Wintalker programból kb. 30 darab eladott példány van. Előnye: jelentős olcsósága a többi Windows-os képernyőolvasókhoz képest.

2.3. Window-Eyes

A web browser-ekkel jól együtt tud működni az angol nyelvű program. Úgy alakult, hogy itthon kevesebb legális példány van belőle. Ennek csupán az a magyarázata, hogy igen nehézkes magyar szövegre "idomítani", ámbár több szakmával foglalkozó látássérült írt kis silabuszokat, avagy készített teljes fordítást a dokumentációjából.

2.4. Jaws for Windows

A JAWS rendszerből, mely a Profivox beszélőrendszerrel működik együtt, ma több, mint 100 legális példány áll a vak felhasználók rendelkezésére. A Jaws honosított változatának demo verziója is megvásárolható, így még jóval több felhasználója lehet a programnak, mint az alig több, mint 100 regisztrált felhasználója. Hátránya: igen magas ára.

2.5. LookOUT

A software Magyarországon még kevéssé ismert. Ez lehetne itthon a legolcsóbb ernyőolvasó. Windows XP-től kezdve használható csak magyarul. Jelenleg egy alfa teszt változata működik. Készült hozzá egy olyan, speciálisan vakoknak írt böngésző, mely az Internet Explorer-ből nyeri az adatokat az "Object Linking and Embedding" módszerrel, mintegy motorként használva azt.

Az ilyen speciális browser-ek sok olyan, a mesterséges intelligencia témakörébe tartozó előfeldolgozást végeznek, melyek nyelvspecifikusak. Sokat segíthetnek vakoknak a tájékozódásban. Kigyűjtik például egy helyre a linkeket, és külön a szövegeket. Értelmezni is tudják a szövegeket, és abból egy saját fát ajánlanak fel a vak felhasználónak a navigálás megkönnyítésére.

2.6. Braille-kijelző

Vannak és lesznek néhányan olyanok is, akik Braille-kijelzővel ("Braille-sorral") rendelkező önjáró rendszerekkel szeretnének könyveket olvasni. Az igazi írásbeliség a vakoknál a Braille-olvasást jelenti. Hordozható, saját intelligenciával rendelkező Braille-kijelzős készülékből is van itthon néhány használatban, a PC-hez kapcsolható Braille-kijelzőkből meg több mint két tucat.

2.7. A Speech Technology Kft. beszédszintetizátora.

A cég 2002-ben fejlesztette ki egy új technológiára alapuló rendszerét (www.speecht.com). A technológia neve APR (Automatic Phoneme Recognition). Ez az első és eddig egyetlen nyelvfüggetlen beszédszintézis rendszer. A magyar mellett pillanatnyilag az angol nyelvű változat piacképes. A rendszer természetes hangzású, öntanuló és új nyelvekre viszonylag könnyen adaptálható. Várhatóan a közeljövőben szabad felhasználású változatai is nyilvánosságra kerülnek.

Kétfelé kell bontani a látássérültek internetezési szokásait. A legtöbben DOS alól interneteznek, még akkor is, ha azt mondják, hogy "Linux/Unix alatt dolgozom". Jelenleg a Linux operációs rendszerre nincs beszélő. Ezt a problémát úgy hidalják át, hogy DOS-ból terminálként feljelentkeznek egy Linux/UNIX szerverre és külső felhasználóként futtatják a szerver-oldali alkalmazásokat (levelező, böngésző, stb.). Böngészőként karakteres browser-eket használnak, főként a Kaliforniai Egyetemen kifejlesztett Lynx programot, melyet több platformra (még DOS-ra és Windows-ra is) aplikáltak. A BraiLab PC felhasználói tipikusan Lynx böngészővel olvassák a web-lapokat.

Azon látássérültek, akik Windows alatt böngésznek, igen kevesen vannak, ők általában az angol nyelvű Jaws for Windows-zal használják a gépet, főként angol nyelvű honlapok olvasgatására, általában Internet Explorer-rel (mint ahogyan mások is, ez nem vak specifikus jelenség). A különböző flash és animált jelenségek számukra sem olvashatóak, ill. a java script-es animált gombok nem kattinthatóak, de jóval több funkciót tudnak elérni, mint azok, akik DOS alatt neteznek.

A DOS-os hálózatkezelő programok közül sok fajta alkalmas a beszélőrendszerrel való együttműködésre, bárki saját lehetőségeihez mérten használhat bármilyet. A lényeg, hogy kell egy hálózati kapcsolatot teremtő segédprogram, ezt pedig definiálja a helyi rendszerünk (otthonról modemmel, munkahelyről ethernet vonalon, ISDN, ADSL, vagy csillagpontos kábel-szolgáltatás) van lehetőségünk a használatra. Ha fent van a hálózati kapcsolatot létrehozó segédprogram, onnantól kezdve akármilyen programot használhatunk, ami DOS. alatt is működik: ftp, mail, gopher, Lynx, stb., minden funkcióra más-más kliens (levelező, böngésző, stb.).

A hálózati programok között az egyik univerzális program a ka9q, amely nemcsak a kapcsolatot teremti meg a hálózattal, hanem integráltan tartalmaz kliens programokat is. Az eredeti KA9Q programot Phil Karn amerikai rádióamatőr írta, mind csomagrádiós, mind kábeles hálózaton működik. Oktatási és kutatási intézmények ezt a szoftvert szabadon használhatják. A KA9Q az MS-DOS fölött futó hálózati operációs rendszer (Network Operating System - NOS), mely a következő feladatokat látja el: - Mail/BBS - TELNET (távoli bejelentkezés) - SMTP (Mail transfer) - POP (Post Office Protocol) - NNTP (Network News) - FTP (Fájlátvitel) - CONVERSE (élő konferencia)

Kliensként és szerverként is egyaránt működik.

Az utóbbi évek új hálózati információ szolgáltatási rendszere a WWW (World Wide Web), mely magába foglalja a már előzőleg létező lehetőségeket, és bevezette a HTTP-t (HyperText Transfer Protocol). A hiper text olvasására szolgáló böngészők közül a legalkalmasabb a Lynx, melynek DOS-os változatát a BraiLab PC is hangosítja.

Használata kezdetben kényelmes volt. DOSLynx-el a PC-n helyben olvashatjuk a HTML szövegeket, mert a távoli gépekről mindig letöltődnek. Fejlesztését azonban beszüntették, és ma már egyre többször találkozunk újabb formátumú HTML anyagokkal, melyeket a DOSLynx nem tud kezelni.

Ha terminálról bejelentkezve a VMS operációs rendszer alatt futó Lynx böngészőt SHOW_CURSOR kapcsolóval indítjuk, akkor a már említett beszédszintetizátorokkal jól lehet használni. Egyéb programok Így például Linux-os Lynx, gopher, stb. is használhatóak. A különböző programok beszéddel történő használhatósága között különbségek vannak. Általában azt egyszerűbb használni, ahol a képernyő áttekinthetőbb (pl. gopherek), a cursor elhelyezkedése könnyen felfedezhető (Lynx).

Sokszor én is abba a hibába esek, mely szerint a karakteres felületű programokat "régi"-nek nevezem. Ez az egyre jobban grafikusodó világunkban egy rossz beidegződés eredménye, valamint annak a ténynek köszönhető, hogy a legtöbb karakteres programot valóban régen fejlesztették utoljára, mert egyre kisebb rá az igény. Kivétel erősíti a szabályt: ma is folyamatosan fejlesztik a Net-Tamer nevezetű internetes kezelőszoftvert, mely teljeskörű Internet-szolgáltatást tartalmaz (modemes betárcsázó, packet driver, valamint különböző protokollok - pop3/smtp, telnet, http) egy rendszerbe integráltan. A programcsomagot DOS alatt fejlesztik és direkt módon vakok számára is könnyen kezelhető, ám a látók számára is kellemes kinézetű (amennyiben beszélhetünk egy karakteres felületen ilyenről) változatok jelennek meg. Az egész program egy merész, de sokak által szívesen használt terminológia köré van felépítve: minden menü, nyomógomb, választómező (a web-es böngészést is beleértve) forrógombok segítségével működtethető. A honlapok böngészésekor a program "megcímkézi" az ABC. betűinek megfelelően a választható linkeket és egyéb nem szöveges objektumokat az adott oldal elejétől kezdve: az első az "A", a második a "B", és így tovább... így a honlapot offline módon képernyő felolvastatással a vak ember egy gombnyomással feltudja olvastatni és az általa választott link megfelelő betűjét lenyomva azonnal tovább ugorhat a következő oldalra. Ez az egyetlen szoftver, amely képes DOS alatt alapvető multimédia funkcióra is: külön kérésre megjeleníti a honlapon található képet grafikus formában, az általa ismert hangfile-okat (MP3-mat és Real Audio-t sajnos ez sem) képes lejátszani a hangkártyán. Frame-eket, flash-t és más újabb keletű HTML-tag-eket annak ellenére, hogy folyamatosan fejlesztik, nem képes kezelni.

Érdemes a lehető legegyszerűbbre tervezni a vakos lapokat, mert a vak felhasználók sokféle rendszert használnak és fognak használni Magyarországon.

Célszerű olyan web lapot tervezni, amely nagyon puritán kinézetű, de a szöveges része tartalmas. Ez biztosan jó lesz mindenféle felhasználónak, bármilyen rendszert is használjon.

Egy nagyon jó vakos web felület sem tud olyan jó lenni, mint egy személyre szabott, önálló intelligenciával rendelkező számítógép. Hosszan olvasgatni egy könyvet hálózaton nem lehet. Tekintettel kell lenni arra, hogy a vak felhasználók sok esetben a letöltött állományokat akarják offline felolvastatni.

Ha a navigációt segítő strukturált állományokat fogja Windows rendszerben valaki vakon olvasni, azt is inkább off-line fogja tenni. A Windows-os vakos programfejlesztésben elindult egy olyan irányzat, hogy a Microsoft-os programokat, mint egy motort használják csak, és külön programot fejlesztenek látássérülteknek, ilyen a fentebb már említett, fejlesztés alatt lévő LookOUT rendszer.

Off-line működő, nagyon egyszerű interfésszel rendelkező vakos olvasó programra mindenképpen szüksége van a vakoknak Windows alatt is.

Online használat

Milyen legyen egy vakos web-es felület? Karakteres. Ha a tervező nem használ grafikát, akkor sokkal könnyebb jó vakos felületet tervezni, mintha egyszerre szeretné a látó és a vak felhasználó igényeit kielégíteni. A külön vakos felületen ezt meg lehet oldani.

Az oldalakat, a látó oldalakhoz hasonlóan, hierarchikus struktúrába kell rendezni. Javasoljuk, hogy az egyes választási lehetőségek az egyes lapokon mindig egymás alá kerüljenek. Ezekből, ha lehet, hétnél ne legyen több egy oldalon, így azt az idősebb emberek is jól meg fogják tudni jegyezni. A linkekhez tartozó szövegek legyenek legalább teljes mondatok. Természetesen az olyan típusú linkek, ahol a név csak azt tartalmazza, hogy "További információk itt", nem megfelelőek, mert az ernyőolvasók, ha a linkeken haladnak végig tabulátorral, akkor csak magát a linket olvassák fel.

Az oldalakhoz tartozó "vissza a főoldalra", "vissza a lap elejére" stb. típusú linkek mindig a lap alján legyenek. A lap elején legyen mindig az a kb. 7 link, amely az adott fa- struktúrán a lényeg. Ezen az egyszerű hierarchikus fa-struktúrán a vak felhasználó mindig könnyen tud lépkedni. Az nem baj, ha egy lapon (oldalon) egyszerre csak egy szint látható. Az egyszerre sokat mutatás látó gondolkodásra vall.

Lehetőség szerint ne készítsünk táblázatokat. A kétdimenziós gondolkodás nem vakos. Nem állítjuk, hogy a táblázat vakon nem kezelhető, csak feleslegesen bonyolult. Az oldalak szerkesztése legyen mindig nagyon egyszerű és következetes.

Lényeges szempont a vakos oldalak szerkesztésében az a tény, hogy a vak felhasználónak nagy mértékben kell memóriájára támaszkodnia. Így fontos számára, hogy az egyszer megjegyzett elrendezésekre konvenciókra számíthasson, ne kelljen esetleg különböző oldalak különböző elrendezéseit megtanulnia.

Az úgynevezett adat-táblázatoknál (data tables), melyek összetartozó adatokat mutatnak be táblázatos elrendezésben, nem várható el a vak felhasználótól, hogy több-oszlopos táblázat esetén megjegyezze, az egyes oszlopok milyen adatokat tartalmaznak. A vakos web-lapoknál legfeljebb két- vagy háromoszlopos adat-táblázatok használata elfogadható, ahol az első, vagy első két oszlop a magyarázó szöveget (adat neve, stb.) tartalmazza, a következő oszlop pedig magát az adatot. Web-lap szerkesztésekor szokásos még az ún. layout table-ek használata is, amelyek voltaképpen nem összetartozó adatokat tartalmaznak, csupán az esztétikus megjelenítést szolgálják. Az ilyen táblázatok használata vakos oldalakon általában nem indokolt.

Úgy tűnhet, hogy így nagyon unalmasak lesznek az oldalak. Ez nem baj, sőt, ettől lesznek igazán vakosak. Az érdekes dolog a tartalomban lesz! Az egymás alá kerülő, értelmesen megfogalmazott választási lehetőséget adó linkek egyértelműek, jól használhatóak lesznek. Természetesen először a hierarchia csúcsán lévő választási lehetőségeket írjuk le és a linkeket aktivizálva haladjunk egyre lejjebb a fán, ami így gyökerével felfelé fog állni.

4.1. A karakteres böngészők jellemzői

A DOS vagy Linux/UNIX alatt futtatott karakteres böngészők nem tudnak bármilyen HTML-kódot megjeleníteni, már csak a megjelenítésre alkalmas felület fogyatékosságaiból kifolyólag is. Szimplán betűk/karakterek felhasználásával nem lehet megjeleníteni mondjuk egy képet, ráadásul egy olyat, ami még mozog is. Mivel a karakteres böngészőket jelenleg nem fejlesztik olyan ütemben, ahogyan azt a HTML szabványa megkívánja, folyamatos lemaradásról beszélhetünk. A grafikus böngészőkben a Java script-ek és más kliens oldali interpreter nyelvek futtatása már régóta megoldott, a karakteres browser-ek nem képesek kliens-oldali alkalmazások futtatására. A betűtípusok, speciális kiválasztó mezők, frame-ek kezelése is problémás, hiszen a 80*25-ös fix karakternagyságú képernyő nem enged meg túl nagy változatosságot. Ami a hátrányuk, az előnyük is: mivel a HTML-ben elhelyezett képhivatkozások nem töltődnek le (teljesen fölösleges, hiszen egy képfile-t, vagy mozifilmet nem tudnánk megjeleníteni karakteres képernyőn), így sokkal gyorsabban megkapjuk az oldalon szereplő információkat. A legtöbb információt pedig még mindig a szövegek jelentik, a képek általában a kiegészítést, vagy a design-t prezentálják.

4.2. A kép szöveges megfelelője

A "szövegmegfelelő" szóban mindkét összetétel egyaránt fontos:

A felhasználó számára a szöveges tartalom többféleképp is közvetíthető: mint beszélővel előállított hang, braille, vagy látható szövegként (visually displayed text). Ezen technikák mindegyike különböző érzékszervet használ: a beszélőgép a füleket célozza meg, a braille a tapintást, míg a látható szöveg a szemet - amivel az információt hozzáférhetővé teszik fogyatékosok különböző csoportjai számára. Használhatósága érdekében a kép szöveges megfelelőjének mindenképpen azonos funkciójúnak, azonos szándékúnak kell lennie. Pl. gondoljunk egy színes felvételre a Földről, amely az űrben készült. Ha a kép célja inkább csak dekorációs jellegű, úgy a következő felirat nagyszerűen betölti ezt a funkciót: "Fénykép a Földről, ahogyan az űrből látszik." Ha a kép célja, hogy földrajzi vonatkozású információkat közöljön, úgy a kép szöveges megfelelőjének azt közvetítenie kell. Ha a kép feladata, hogy a felhasználóval közölje, hogy azt kiválasztva (ráklikkelve) további információkat kap a Földről, akkor a megfelelő szöveg a "Információ a Földről" lenne. Így tehát, ha a szöveg ugyanazt a funkciót látja el a fogyatékos számára, mint mások számára a látható kép, akkor azt a kép hű szöveges megfelelőjének tekinthetjük.

Itt jegyzendő meg, hogy a képi információ szövegbe átültetése nemcsak a fogyatékos felhasználók javát szolgálja, hanem minden felhasználó számára előnyös, hiszen a keresőrobotok is mutatóként használhatják a "szövegre" fordított képi információt.

Míg a web-tartalom fejlesztő felelőssége hogy a képi és egyéb multimédiás tartalommal megegyező szövegmegfelelőt szolgáltasson, az információ közlése/átadása a felhasználói közvetítő közegek (böngészők és egyéb segéd technológiák, mint például a "képernyő olvasó" (screen reader) vagy a braille kijelző) feladata.

A szöveg nem szövegi (nem szöveg formátumú) megfelelői (pl. ikonok, előre rögzített beszéd, vagy egy jelbeszédre fordítót bemutató videófelvétel) a dokumentumokat olyanok számára is hozzáférhetővé teszik, akiknek az írott szöveg másképpen nem lenne az, beleértve a tanulási nehézségekkel, kognitív képességek zavarával járó állapotokat, valamint a siketeket.) Ez igaz a nem-olvasókra is (analfabéták, dyszlexiások) A látható információ nem szövegre való fordítására jó példa a hangzó leírás. Egy multimédiás előadás képi sávjának hangzó szöveggé való konvertálása nagy segítség azok számára, akik a vizuális információt nem láthatják.

4.3. A Gördülékeny Átalakítás Biztosítása

Elválasztani a struktúrát az előadásmódtól(megjelenítéstől) (utalás a tartalom, felépítés és megjelenítési mód megkülönböztetésére).

A szöveget "szövegmegfelelőkkel" együtt szolgáltatni! A szöveg alakítható, hogy szinte minden böngésző számára értelmezhető, és így szinte minden felhasználó által hozzáférhetővé váljon.

Nem látó/halló felhasználók számára is használható dokumentumok készítése során az audio vagy video anyag mellé hasznos olyan információ szolgáltatása, mely a helyettes érzékelési csatornán keresztül közvetíti ugyanazt a tartalmat és ugyanazt a funkciót látja el. Ez alatt nem egy site (vakok számára) egy az egyben való hangzó megfelelőjének létrehozását értendő. Vak felhasználók használhatják a képernyőleolvasót akármilyen írott szöveg átalakítására. Ezért nem szükséges semmiféle hangállományban (wav, MP3, Real Audio) felrakni az anyagot. Ez fölösleges is volna, hiszen a karakteres böngészők nem alkalmasak média elemek megjelenítésére, vagy lejátszására. Valamint egy teljes honlap hanganyaggá konvertálása igen sok időt és pénzt emésztene fel, hiszen gondoljunk bele, hogy kell stúdiót bérelni, felolvasót, technikust, stb. Ráadásul a honlap frissítéseit azzal a bemondóval kellene megoldani. És még itt szó sem esett a vendégkönyvi, számláló, stb. szolgáltatásokról, melyek egy honlapon folyamatosan változnak, bővülnek, tehát egy dinamikus felületet kapunk. Míg a statikus felület fix dokumentumból áll, a dinamikus felület akár percenként is változhat.

Olyan dokumentumok létrehozása, melyek nem kizárólag egy hardware-re épülnek: Egérrel nem rendelkező, kis képernyőt birtokló, alacsony felbontással vagy csak fekete fehér (monochrome) képernyővel rendelkező - sőt képernyővel, hang vagy szöveg output-tal nem rendelkezők számára is elérhető, használható kell hogy legyen.

4.4. Alapelvek, melyekre egy honlap fejlesztésénél érdemes odafigyelni

Az elmúlt időszakban egyre több ajánlást dolgoztak ki a web oldalak vakok által való használhatóságának követelményeire. Itt elsősorban a W3C (World Wide Web Consortium) Web Accessibility Initiative (WAI) ajánlásai a mértékadók (http://www.w3.org/WAI/).

Több magyar honlapon is megtalálhatók ennek alapján készült rövid összefoglaló ajánlások, pl.

a Média az Emberekért Alapítvány felkérésére 2001-ben e tanulmány szerzőjének munkája: http://www.meaea.hu
a Magyar Vakok és Gyengénlátók Országos Szövetsége honlapján (http://www.mvgyosz.hu/vakoslap.htm),
Ajánlások az elérhető médiáért (http://www.paramedia.hu/ajanlas.html),
KFKI RMKI Számítógép Hálózati Központ ajánlásai (http://www.kfki.hu/cnc/archivum/vakwebelv.html).

- Az egyik legfontosabb kérdés inkább szervezői, mint honlapkészítői procedúra: mi az, amit vakok számára is olvashatóvá szeretnénk tenni? A vak ember számára olykor teljesen mást jelent a kapott információ, mint egy látó számára. Egyszerű példa, amikor egy zöld ház jelenik meg egy képen. A látássérült számára a "zöld" nem jelent szimbólumot, használható információt, míg a látó ember számára a szín árnyalatai is jelenthetnek tartalmat. Nem biztos, hogy közölnünk kell azt, hogy egy adott képen mi van, inkább azt érdemes tudatni, hogy mit szeretnénk ezzel szimbolizálni, ugyanis a látássérültek nagy részéből (főként azokból, akik már vakon születtek) nincs meg a látvány-fogalom közvetlen asszociációs képessége. Amíg a látó számára egy megjelenő honlap alapszíne is sugall valamit, addig egy látássérült számára az sem információ, ha kiírjuk, hogy milyen háttérre milyen színeket alkalmazunk. Ez nem jelent hangulati összképet, érzelmi harmóniát. Hasonló kategóriába sorolható a képernyőn megjelenő betűk, kiemelések, betűtípusok és más nyomdagrafikus eljárások alkalmazása. Fogalmi szinten ismerős a kövér, félkövér, dőlt, stb. betűtípus, de lényegi információt nem hordoznak. így amíg egy látó számára egy szövegből ránézésre kitűnik a lényeg (ha az jól van megszerkesztve), addig a látássérült a beszélőrendszerrel végig kell olvastassa a teljes dokumentumot ahhoz, hogy megkapja a lényegi információkat. Mivel egyszerre túl sok információ érkezik számára és szubjektíven szelektál, így alapos félreértésekkel találhatja magát szemben az ember. Amíg a szöveg írója egyértelműen jelezte egy információról, hogy azt tartja fontosnak, amit kiemelt betűtípussal írt, a többi csupán kiegészítő anyagként funkcionál, lehet, hogy a vak ember számára első olvasatra éppen egy mellékesnek szánt adat/információ kap nagyobb prioritást és ezzel teljesen más értelmezést is kap(hat) egy adott szöveg.

A honlap szerkesztésénél ügyelni kell arra, hogy a látássérült csak azt az információt kapja meg első körben, ami alapján eltudja dönteni, hogy az számára éppen szükséges-e, vagy nem.

Ha pontosan tudjuk, hogy mit szeretnénk "elmondani" honlapunkkal, azt a megfelelő technikák alkalmazásával vihetjük át a gyakorlatba. Mivel a látássérültek software-technikailag el vannak maradva, olyan honlapot kell készíteni, amely bármely böngészővel olvasható, bele értve ebbe a régebbi kiadású browser-eket is. A frame, inline, image map használata korlátozott, hiszen ne felejtsük el, hogy szöveges információt kell továbbítanunk a böngésző felé, így bizonyos alapvető szabályokat be kell tartanunk. Ezek használatával egy vak ember is remekül el tud boldogulni egy honlap olvasásakor, hiszen megkapja a számára szükséges/fontos információkat. Ezek a szabályok nem szervezési, mindinkább technikai jellegűek:

- A HTML dokumentum legyen Lynx-kompatibilis, vagy más karaktermódú browser-rel jól olvasható! (W3, Cern Line Mode Browser) Ezt legegyszerűbb módon a Roxen WWW szerver makróinak alkalmazásával lehet elérni, a Roxen-nel ugyanis automatikusan előállíttatható sormódú dokumentumváltozat (pl. táblázatok). Más WWW szerverek (pl. Apache) is "rábírhatók" erre, legfeljebb kicsit bonyolultabb módon. Ha a szerver beállításával nem megoldható a probléma, kétféle dokumentumot kell készíteni átváltási lehetőséggel. Hasonlóan a több nyelvű honlapokhoz, egyszerűen fel kell kínálni egy választási lehetőséget, hogy "grafikus", vagy karakteres verziót szeretnénk-e olvasni. A külön verzió létrehozása lehetőséget ad arra, hogy kizárólag vakok számára fontos információt közöljünk az oldalon, ill. olyanokat, melyek a karakterspecifikus böngészővel olvasók számára hasznosak: kép részletes leírása, vázlatrajzok szöveges kifejtése, stb. Hátránya ennek a megoldásnak az, mint ami a két, vagy több nyelvű honlapoké is: nehéz és fáradtságos munka szinkronban tartani a közel azonos tartalmú oldalakat. Ez főként a továbbfejlesztésnél, vagy egyszerű "anyagbővítésnél" jelentkező emberi probléma: hanyagságból, feledékenységből nem történik meg a módosítás a másik verzióban. Egy idő után a "rosszabbik", karakteres felület fejlesztésével le is álnak és csak a jobb, szebb honlapot szerkesztik tovább.

- Inline image (IMG) alkalmazásakor minden esetben használjuk az ALT attribútumot, mégpedig kissé részletesebb leírással, pl. egy városkép "mögé" ne csak azt írjuk, Budapest, hanem, hogy budapesti látkép.

Itt tipikus példákat lehet felsorolni a már említett asszociatív képzelőerőről. Egy virágüzlet praktikus megjelenése a világhálón elképzelhető úgy, hogy az egész honlap egy virágot szimbolizál és különböző, az adott linkre jellemző színű levelek, hajtások és azok elhelyezkedése jelenti a mutató linkeket. Ilyen esetben egy látó egyből arra gondol, hogy itt a virágot kell kihangsúlyozni, hiszen erre épül a honlap. A vak számára teljesen mindegy, hogy milyen virág az (habár érdekességképpen biztosan rácsodálkozna, ha közöljük vele, hogy egy virág levelei alkotják a linkeket), számára fontosabb az, hogy megtalálja azt a linket, ahol virágot rendelhet, vagy lexikont olvashat, vagy a honlap üzemeltetőinek üzenhet valamit.

- Kerülendő a frame, a Java és az image map használata, ezeket csak alternatívaként alkalmazzuk! Ha nem zavarja a karakteres böngészést a Javascript alkalmazása, valamint az nem közöl semmiféle vakok számára használható információt (design-t emelő kép, mutatópálca, net-idő kijelző), akkor megfelelő körültekintéssel beszerkeszthető az oldalba.

A frame szerkesztés tipikus rossz példája, amikor egy frame-et tartalmazó oldal szövegébe bele írjuk: "ez az oldal frame-eket tartalmaz. Kérjük, kattintson ide egy "új" böngésző letöltéséhez!" Ha már ezt a szöveget bele tudtuk írni a HTML-be, egyszerűbb és praktikusabb dolog volna, ha nem újabb böngészőt töltetnénk le a felhasználóval (főként a vak nem passzióból használja a "buta" böngészőt), hanem a szöveg helyére beraknánk az esetlegesen fő frame-nek titulált keretet, vagy a frame-eket szépen egymás alá helyezve, vagy az egyes keretek által mutatott file-okra való hivatkozást sima, egyszerű linkként.

- Ha HTML-től különböző file formátumot használunk (pl. PDF, DOC, stb.), legyen HTML megfelelője!

Tipikus példa erre különböző letöltendő űrlapok, nyomtatásra kész dokumentumok, jelentések, melyek Postscript-ben, Word-ben, Excel-ben készültek. Ezeket le lehet tölteni és később felhasználni. Egy látó számára evidens, hogy rákattint, letölti és mivel a legtöbben Windows operációsrendszert használnak, egyből meg is nézi. Ezzel szemben a vak ember hiába tudja letölteni, nem tudja elolvasni, így számára nem hozzáférhető az információ. így ha egy fontos tanulmány, vagy egy egyszerű űrlap kerül fel az oldalra, elérhetővé kell azt tenni online is olvasható verzióban, a honlap részeként. Javasolt megoldás erre az, hogy megjelenik a linkre kattintás után a dokumentum teljes szövege és a tetejére, vagy aljára rakjuk a "letöltés" linket, így aki szeretné, az le is tudja tölteni, aki pedig online tudja/szeretné olvasni, megteheti.

- Az elkészült dokumentumot teszteljük több browserrel több operációsrendszerben!

Egy honlapot gyakorlatilag bármilyen rendszerrel fejleszthetünk, amelynek van ilyen funkciója és bármilyen rendszerrel el is tudjuk azt olvasni. A mai fejlesztő és view rendszerek ezzel szemben nem 100 %-osan kompatibilisek egymással. Akár két azonos operációsrendszer alatt futó böngészőprogram is generálhat teljesen más képet/megjelenést egy adott HTML-oldalnak. Gondoljunk csak az Internet Explorer és a Netscape böngészők inkompatibilitási problémáira. Ha Windows alatt szerkesztjük a honlapot, hajlamosak vagyunk azt hinni, hogy ezt Windows-os gépről fogják nézni az Interneten is. Az esetek 70-80 %-ában ez valószínűleg így is van. De már ott elkövettük a hibát, hogy a szerverek nagy része, amin a honlap tárolódik, az nagy valószínűséggel Linux, vagy UNIX, vagy ezen rendszerek mutánsa. Ha ezt még tovább bonyolítjuk, akkor hozzávehetjük azt, hogy egy látássérült DOS alól fogja "nézegetni" az oldalt. Így aztán operációsrendszerek kavalkádját kapjuk: egy Windows alatt szerkesztett web-oldalt UNIX alatti Web-szerverről DOS-os böngészővel olvasnak. Ha még hozzávesszük azt, hogy a világon nemcsak a közismert PC gépek rendelkeznek böngésző lehetőséggel, hanem a Macintosh és más konstrukciójú gépek is, könnyen elveszhetünk az univerzálás útvesztőiben. Fontos az, hogy igyekezzünk minél általánosabban használható honlapot generálni, mert az a látogató, aki nem kap információt, az többet nem jön vissza a honlapra.

- Kerülendő a flash és egyéb macromedia termékek használata, ill. ha feltétlenül ragaszkodunk hozzá, az oldal elején a HTML-kódban érdemes valami "használható" szöveget megjeleníteni, nem csak annyit, hogy "az oldal megjelenítéséhez töltse le a macromedia termékét". Ilyenkor lehetőleg alá rakjuk be a honlap főoldalát (célszerűen a választható menüsort).

Hasonló a helyzet a flash betétekkel is, mint a frame alkalmazással. Egy flash-es oldal behívásakor vagy megjelenik egy mozgó, dudáló, ki tudja milyen effektusokat művelő effektus, vagy pedig kiírja a honlap szövege, hogy ez az oldal Macromedia termék nélkül nem jeleníthető meg. Pedig dehogy nem, csupán a fejlesztéseknél kellene jobban odafigyelni arra, hogy mit is szeretnénk közölni a látogatókkal. Ugyanúgy a szöveg helyére lehet illeszteni egy főmenüt, ami segítségével szimpla HTML-böngészővel is gond nélkül hozzáférhetőekké válnának a honlapon tárolt információk.

- Ha több menüpontot szeretnénk elhelyezni egymás mellett, azt rakjuk olyan táblázatba, amely a karakteres böngészővel úgy jelenik meg, hogy az egymás melletti mezők egymás alá kerülnek, így grafikus böngészőn jól látszanak az egymás melletti menüpontok, a karakteres felületen pedig egy sorban csak egy menüpont olvasható.

- Ügyeljünk arra, hogy az ékezetek helyesen jelenjenek meg, amennyiben lehet, a HTML-szabványnak megfelelően.

Ma már a HTML-szabványban meghatározott ékezetes karakterek - nagy helyigényük miatt - kezdenek kiszorulni a web-es alkalmazásokból. Az újabb HTML definíciók lehetővé teszik a viszonylag pontos ábrázolását a karakter készleteknek. Két szabvány terjedt el: a Windows 1250-es kódtábla, valamint az ISO-8859-1/2 kódkészlet terjedt el. Mind DOS, Linux, valamint Windows környezetben az ISO-8859-2. ékezettel ellátott szövegek használhatóak teljesértékűen.

A karakteres böngészők ékezethelyes megjelenítését az éppen aktuálisan használt terminál is befolyásolja. A Linux környezetre csatlakozó DOS-os terminálok nem mindegyike van felkészítve az ékezetes karakterekre. A telnet protokoll, melyen keresztül a legtöbb vak felhasználó csatlakozik egy-egy Linux szerverhez csak 7 bit-es karakterekkel kommunikál a felhasználó felé, azaz az ASCII 0-128 karaktereket engedi át (ez írható fel 7 bit-en). Az újabb és biztonságosabb SSH protokollt kezelő DOS-os program, melyből jelenleg tudomásom szerint egy létezik, sajnos nem eléggé közismert a Linux-ozó látássérültek között, pedig a protokoll képes a 1 byte-os karakterátvitelre is, így viszonylag helyesen jelennek meg. Persze itt is függ attól, hogy a terminál milyen karakterhozzárendelést képes megjeleníteni. Ez leginkább az ékezetes karaktereknél fontos szempont, ahol nem alakult ki egy teljeskörűnek mondható szabvány az ASCII. táblán belül. A vakok által használt Brailab PC eszköz 3 különféle kódtáblát képes megjeleníteni: CWI-1, 852, Windows 1250. A honlapok a szabványnak számító Windows 1250-es karakterkészlettel készülnek, vagy az ISO 8859-es definíciók alapján, mely gyakorlatilag a Magyar alapékezeteket azonosan definiálja. Ennek ellenére az ékezetes honlapok olvasásakor az "ő" karakter nem jelenik meg, csak úgy, ha a HTML-ajánlásban megadott "ô" formulát alkalmazzuk.

- Amennyiben nem teljesen világos az amúgy látók számára abszolút triviális információ, a vakok számára külön információt is elhelyezhetünk az oldalon úgy, hogy azt a látók számára nem is jelenik meg. Egyszerű "trükk"-el, a fehér alapon fehér betűvel ez igen jól megoldható.

Mivel a beszélőrendszer a képernyőmemóriából olvassa ki a karaktereket (ott külön byte-on tárolódik maga a karakter és annak színe), így a látó számára nem látható információ, ami tulajdonképpen megjelenik a képernyőn, csupán a színazonosság következtében szemmel nem látható.

A fejezet elején egy talán triviálisnak tűnő dolgot érdemes tisztázni: a gyengénlátó az gyengén lát. Nem vak, de nem is lát 100 %-osan. Ahány gyengénlátó, annyiféle látásminőség. Van, aki lát közlekedni (nagyobb tárgyakat), de a sík-írást már nem látja. Van, aki olvasni lát, de már messzebb lévő nagyobb tárgyakat nem.

Mi az, amit figyelembe kell venni a gyengénlátók számítógép használatánál?

Számítógép beszerzés: fontos az asztal, amin dolgoznak. A helyes testtartás miatt fontos a dönthető felületű pad.

- Általános észrevétel, hogy a szem-kéz koordináció nem tökéletes a gyengénlátóknál, az egér használata jóval nehezebb. Minél közelebb vannak egymáshoz az ikonok, annál nehezebben tudja elvégezni a kijelölést, rákattintást. Érdemes ilyenkor a kliens gépen az egér sebességét lassítani.

- Figyelni kell a képernyőn való tájékozódásra. Az ikonok formái ne legyenek hasonlóak (pl. alma mellett egy kör).

- Megvilágításnál jó a szórt fény (nem jó a napfény). Megvilágítás tekintetében a gyengénlátók igényei eltérőek, helyi megvilágítással alkalmazkodik.

- Fontos a jó kontraszt, sötét háttéren világos kép, ne legyen háttérminta (vonalazott).

- Képek, ábrák használata a látóképességtől függ.

- A videót nem tudja megfigyelni, mert nagyon gyors.

- Dia használatnál nagyon fontos a minőség, ez használható, mert állókép.

- Ábra használatnál fontos a leegyszerűsített forma, bármiféle díszítés zavarhatja a pontos felismerést.

- A betű nagyságával legyen arányos a vastagsága.

- Fontos a kontraszt, legjobb a fehér alapon fekete betű. (háttér világos, előtér sötét, vagy háttér sötét, előtér világos)

- A betűforma legyen leegyszerűsített, zárt, a díszített betű megnehezíti az olvasást.

- A betű mérete a gyengénlátás mértékének függvénye. Amit lehet, ne konkretizáljunk egy honlapon, engedjük, hogy a felhasználó maga méretezhesse át a letöltött oldalt. így kerülendő a stíluslapok használatakor a stíluslapban megadni az oldal betűjellemzőit, ugyanis a css-ben definiált értékeket a kliens böngészőjében nem lehet felülbírálni.

- Olvasótévé: egy felvevőkamerával összekapcsolt monitor. A kamera alá helyezik a szöveget, görgős, egymásra merőleges irányba mozgatható tálcán. A nagyítás változtatható, átkapcsolható pozitív-negatív képre: fehér alapon fekete, vagy fekete alapon fehér betűk. Kisméretű ábrák, szövegrészek, tárgyak, esetleg élőlények pontos vizsgálatára alkalmas; Egyéni olvasóeszköz aliglátók számára. Az olvasótévé drága eszköz, de az újabb konstrukciókat már számítógéphez is lehet kötni monitor gyanánt. Ez amolyan "hardveres nagyítóeszköz".

- A szoftveres nagyításra is lehetőség nyílik, hazánkban a Zoomtext nevű programot használják a gyengénlátók. A program szintén sok pénzbe kerül, de demo változata letölthető a www.zoomtext.com oldalról.

- Fontos a nagyító fénymásolás is, alkalmazkodik az egyéni képességekhez, a szemléltetés során nincs szükség a nagyító használatára.

- Írásvetítő: azért jó, mert használat közben is lehet a fóliára írni, pótolja a táblát, speciális toll kell hozzá. Fontos a besötétítés, a jó kontraszt miatt - minél messzebbről vetítsünk.

- A gyengénlátóknál probléma az olvasásnál: a közel nézés miatt a centrális látótér nagy mértékben beszűkül, nem látják egyszerre az egész szót, így nehéz egy egész szóképet globálisan megjegyezni. Sokuknak nehéz a képet is felismerni (emiatt). Betűtípus kiválasztásánál fontos, hogy a látóképességnek megfelelő méretűek legyenek. Legyen jól látható, minden vonal egyforma vastagságú legyen. Ne legyenek a képekre írt szövegek. További probléma a sorkövetés, szövegben való keresés, tájékozódás. Ezek nem az olvasásban, hanem a szövegfeldolgozásban okoznak gondot. (Másfeles sortáv alkalmazása.) Ez főleg azoknál okoz gondot, akiknek szemmozgási rendellenességük van; felléphet még a fixálási nehézség is. A szövegben az egyes részek bejelölése másféle színnel történik (megkönnyíti a tájékozódást), vagy pl. címeknél (fejezet cím) más betűvel (vastagabb). Ha valamire felhívjuk a figyelmet a képernyőn, használjunk élénk színeket, nagyobb betűméretet, avagy mindkettőt, ugyanis monochrome monitornál nem érvényesülnek a színek.

- A gyengénlátók kevesebbet rajzolnak, így az egér mozgatása is problémát okoz(hat).

Finommozgás (finommotorika): a gyengénlátó gyermekek finommozgása lassan fejlődik, gondot okozhat az eszközhasználatban, nehézkes lehet a mozgás indítása, kivitelezése, befejezése (megállítása) - egér használatakor. A látó és gyengénlátó gyerekeknél nagy különbség van a mozgások kivitelezésének pontosságában és tempójában. A gyengénlátás csak az ismeretszerzés és feldolgozás körülményeit módosítja. Fontos a motiváció (egész életre kihat). A gyengénlátóknál nagyobb erőfeszítésre van szükség (figyelem, koncentrálás). A gyengénlátó mindig azt az érzékszervét használja, amely a leglényegesebb információt szolgáltatja a leggazdaságosabb módon. Ezáltal tehermentesíti a szemet (hallás, tapintás). (a szem terhelhetősége egyénileg változik, diagnózishoz köthető)

- Egy folyamatos szöveg legyen egyforma betűtípussal írva, csak szükség esetén legyen más betűtípus (elkerülhetetlenül fontos kiemelés esetén). Félkövér betűk használata a preferált, legalább 14-es betűméret szükséges, de igen gyakran ennél nagyobb is szükséges lehet.

- Fontos, hogy a képernyőn elhelyezett szövegezés ne legyen túl zsúfolt. Zavaró a túl kicsi betűméret, a betűtípusok keveredése, valamint a betűk, vagy szavak különböző írásiránya.

- Ne legyen különböző színű a háttér (egy színű háttér). A sötét színeket nehezebben különböztetik meg. Ezeken a fekete írás nem nagyon látható.

- A különböző jelölések ne csússzanak egymásba és ne menjenek át egymáson.

A web-es fejlesztések során két féle programozási nyelv közül választhatunk: 1. szerver-oldali 2. kliens-oldali alkalmazások használata. A szerver-oldali programok jobban megfelelnek egy platform-független honlap számára, hiszen magát a programot a web-szerverünk futtatja, ahol tároljuk az oldalunkat. Ezzel biztosítjuk magunkat afelől is, hogy adatainkhoz nem könnyen tudnak hozzájutni "illetéktelen" felhasználók, hiszen kisebb trükkökkel (pl. .htm a program kiterjesztése a szerveren) a felhasználónak fogalma sincs róla, hogy ami HTML-oldal letöltődött a gépére, azt éppen egy program kimenetén keresztül generáltuk a kliens számára. Szerver oldalon bármilyen program, vagy script-nyelven írt kód futtatható, amelynek elkészült az adott operációs rendszerhez az implementációja (Linux-os, Windows-NT-s, Solaris-os változata). Ezek a programok vagy interpreter-es script-ek (Linux/UNIX shell script-ek, PERL-ben írt rendszerek, vagy PHP-alkalmazások), vagy már lefordított, futó programok (C nyelven elkészített software). A Linux/UNIX fejlesztők leginkább az interpreter-es script-nyelveket részesítik előnyben, ugyanis ezeket akár Windows, vagy nomád körülmények esetén DOS. környezetben is fejleszthetik és mindenféle fordítóprocedúra nélkül átvihető egyik rendszerről a másikba, ugyanis a program futtatását, értelmezését a szerverre telepített interpreter végzi. A C-ben írt alkalmazásokat is lehet akár más rendszeren fejleszteni, de "ahány ház, annyi szokás", a DOS., vagy a Windows környezetben fejlesztett program nem fut le Linux/UNIX környezetben, tehát ide is "forrásszintű" programkódot kell feljuttatni és ott újból egy az adott operációsrendszerre készült compiler-rel újra kell fordítani. Az ebből adódó inkompatibilitások pedig (Linux nem ismeri a DOS-os megszakításrendszert) megnehezítik a programozó munkáját. Egy compilált programot kizárólag azon a rendszeren érdemes fejleszteni, amelyiken futni fog. Viszont az interpretált script-nyelvekkel szemben az az előnye, hogy nem kell külön értelmeznie (lefordítania) a szervernek minden futásnál, így az sokkal gyorsabban legenerálja számunkra a kimenő HTML-t.

A szabvány HTML-nek több továbbfejlesztett változata van, mint például az XML, vagy az SHTML. Ha a fejlesztő kénytelen kiterjesztett HTML-t használni, általában az SHTML-t választja, ugyanis abba igen egyszerű beilleszteni bármilyen szerver-oldali program futtatását (például számláló, reklámcsík kezelő - banner). E technikával, valamint a SSI. (Server Side Include) alkalmazásával igen jól helyettesíthető a Javacript-es megoldások 98 %-a (kivéve például a folyamatosan változó állapotokat generáló kódrészleteket, mint mondjuk egy a képernyőn megjelenő órát). A SHTML és az SSI. alkalmazásával könnyedén megoldható a fejléc/lábléc közé elhelyezendő változó tartalom kérdése, számlálók, régebbi vendégkönyv programok által generált text file-ban tárolt bejegyzéseinek azonnali "behúzása". Az "ijedősebb" programozók előszeretettel használják, ugyanis itt nincs közvetlen programfutás, nem generálható könnyedén futási hiba egy figyelmetlenségből adódóan.

Az új, ingyenes PHP technika már jóval szélesebb lehetőségeket kínál, viszont egy rosszul megírt programkód vonzza a hacker-ek/cracker-ek hadát a honlapra és kiskaput biztosítva akár az egész szerver feltörésére, tönkretételére. Míg a CGI alkalmazásoknál egy script-nyelv kimeneteként (PERL) HTML-parancsok segítségével generálunk honlapot, addig a PHP épp a fordítottját csinálja: egy HTML-oldalt kell írnunk, melyben elhelyezhetünk különböző jelölésrendszer által programkódot, akár egy számlálót, egy SQL, vagy Oracle lekérdezőrendszert. Nagyobb portáloknál előszeretettel alkalmazzák kicsinysége, gyorsasága és jó programozhatósága miatt.

Néhány vakos szoftverek fejlesztésével foglalkozó szervezet több olyan rendszert is kifejlesztett, amelyek ellenőrzik a web-lapokat, elsősorban abból a szempontból, hogy mennyire követik a W3C ajánlásait.

Az ilyen rendszerek általában a HTML szintaxis szempontjából is megvizsgálják a web-lapot. Felhívják a figyelmet a vakos ajánlások (esetleges) megsértésére, valamint ezen túlmenően azokra a web-lapon alkalmazott sajátságokra is, amelyeket esetleg nem minden böngésző támogat, amelyek elavultak, tehát nem célszerű őket alkalmazni. A megvizsgált web-lapokról általában hosszabb jelentést készítenek, amely sorról-sorra véve jelzi az ott alkalmazott eszközöket, és jelzi, hogy ezek megfelelnek-e a W3C ajánlásoknak, illetve nem tartalmaznak-e olyan sajátságokat, melyeket nem minden böngésző támogat.

Az alábbiakban felsorolunk néhány ilyen ellenőrző rendszert:

CynthiaSays (http://www.cynthiasays.com/)
UsableNet (http://liftonline.usablenet.com/)
Bobby (http://bobby.watchfire.com)

Az utóbbi rendszerrel kapcsolatban megjegyzendő, hogy azok a honlapok, amelyeket az általa elvégzett ellenőrzés megfelelőnek talál, jogosulttá válnak az ún. "Bobby approved" jelzés és ikon használatára.

Megjegyzendő azonban, hogy a formális ellenőrzés nem pótolja az "élő" tesztelést, de megbízhatóan felhívja a figyelmet az ellenőrzendő sajátságokra.

- Az egyik legfontosabb kérdés inkább szervezői, mint honlapkészítői procedúra: mi az, amit vakok számára is olvashatóvá szeretnénk tenni? A vak ember számára olykor teljesen mást jelent a kapott információ, mint egy látó számára. Egyszerű példa, amikor egy zöld ház jelenik meg egy képen. A látássérült számára a "zöld" nem jelent szimbólumot, használható információt, míg a látó ember számára a szín árnyalatai is jelenthetnek tartalmat. Apelláljunk kizárólag a szöveges információra, ahol csak lehet.

- A honlap szerkesztésénél ügyelni kell arra, hogy a látássérült csak azt az információt kapja meg első körben, ami alapján eltudja dönteni, hogy az számára éppen szükséges-e, vagy nem.

- A HTML dokumentum legyen Lynx-kompatibilis, vagy más karaktermódú browser-rel jól olvasható! (W3, Cern Line Mode Browser) Ezt legegyszerűbb módon a Roxen WWW szerver makróinak alkalmazásával lehet elérni, a Roxen-nel ugyanis automatikusan előállíttatható sormódú dokumentumváltozat (pl. táblázatok). Más WWW szerverek (pl. Apache) is "rábírhatók" erre, legfeljebb kicsit bonyolultabb módon. Ha a szerver beállításával nem megoldható a probléma, kétféle dokumentumot kell készíteni átváltási lehetőséggel.

- Inline image (IMG) alkalmazásakor minden esetben használjuk az ALT attribútumot, mégpedig kissé részletesebb leírással, pl. egy városkép "mögé" ne csak azt írjuk, Budapest, hanem, hogy budapesti látkép.

- Kerülendő a frame, a Java és az image map használata, ezeket csak alternatívaként alkalmazzuk! Ha nem zavarja a karakteres böngészést a Java script alkalmazása, valamint az nem közöl semmiféle vakok számára használható információt (design-t emelő kép, mutatópálca, net-idő kijelző), akkor megfelelő körültekintéssel beszerkeszthető az oldalba.

- Ha HTML-től különböző file formátumot használunk (pl. PDF, DOC, stb.), legyen HTML megfelelője!

- Az elkészült dokumentumot teszteljük több browserrel több operációsrendszerben!

- Kerülendő a flash és egyéb macromedia termékek használata. Amennyiben elengedhetetlenül fontosnak tartjuk (az oldal tartalmának, vagy potenciális látogatóinak szempontjából, biztosítsunk lehetőséget akár ugyanabban a HTML-kódban a nem flash-es verziójú eléréshez is.

- Ha több menüpontot szeretnénk elhelyezni egymás mellett, azt rakjuk olyan táblázatba, amely a karakteres böngészővel úgy jelenik meg, hogy az egymás melletti mezők egymás alá kerülnek.

- Amennyiben nem teljesen világos az amúgy látók számára abszolút triviális információ, a vakok számára külön információt is elhelyezhetünk az oldalon úgy, hogy azt a látók számára nem is jelenik meg: fehér alapon fehér karakter.

- Érdemes hírlevél formájában (honlapon történő feljelentkezés után) értesíteni a látogatók az újdonságokról, heti/havi aktualitásokról.

Beszélőrendszerek Magyarországon (cikk) Pál Zsolt: Új Alaplap, 1994. szeptember

Vakok és a Windows (cikk) Pille: PC-world, 1996. január

Pille-online (első magyar vakokról szóló honlap) http://www.pille.hu, 1997. március

Hogyan interneteznek a vakok? (előadás) Pál Zsolt: Network Shop, 1998. Győr

Az Internet használata vakon (cikk) Pille: Internet Kalauz, 1998. április

Hobby Rádió honlap http://www.hobbyradio.hu, 2000. szeptember

Vak repülés színjátszó Egyesület http://www.pille.hu/vakrep

Neumann Digitális Könyvtár: http://www.neumann-haz.hu

CHIP magazin, 2003. február Pál Zsolt (alias "Pille"): Beszélőrendszerek látáskárosultaknak, http://www.mek.iif.hu/porta/bbs/pille.txt

Szakdolgozat: http://www.mek.iif.hu/porta/szint/muszaki/szamtech/alkalmaz/varhelyi/

Forrás: - Arató András és Vaspöri Teréz "Gondolatok a vakos MEK kialakításáról" c. tanulmánya (2003. augusztus 1.) - a külön erre a projektre létrehozott (Vakadmin) levelezőlistán elhangzott hozzászólások - - Pál Zsolt (Pille) 2003. májusában elkészített javaslatgyűjteménye

Megj.: a szövegeket módosítottam, de tartalmi mondanivalójukon nem változtattam. A könnyebb olvashatóság kedvéért nem használtam idézőjeleket, ugyanis az egész dokumentum egy nagy idézőjelben lehetne.

Bevezetés

A Magyar Elektronikus Könyvtár (MEK) a vakok és gyengénlátók által intenzíven használt, kilenc éve működő webes szolgáltatás, amely szépirodalmi és szakirodalmi szövegeket is tartalmaz, melyek magyar nyelvűek, vagy magyar a szerzőjük. Az eddig használt rendszer elavult, ezért új tárolási, keresési és szolgáltató felületet dolgozott ki a könyvtár, melybe a dokumentumok áttöltése folyamatban van. A gyűjtemény jelenlegi mérete kb. 4500 dokumentum, amelyeket folyamatosan válogatnak, ellenőriznek és töltenek fel az új rendszerbe (http://mek.oszk.hu). Az új képernyőoldalak a hozzájuk kapcsolódó keresési és letöltési lehetőségekkel felolvasó programmal jóval nehezebben kezelhetőek az előző verzióhoz képest az összetettebb funkcionalitás miatt. A MEK olvasói között kérdőíves felmérés szerint 1.5% a vak vagy gyengénlátó személy. A napi 6000 látogatói átlagot tekintve, ez körülbelül napi 90 embert jelent.

Hogyan is alakult ki az a statisztikai tény, hogy a magyar vakok a látó lakossághoz viszonyított számarányukhoz képest nagyobb arányban lettek a MEK olvasói? Vegyük sorra, hogy mi kellett ehhez. Először is szükséges volt hozzá, hogy a MEK egyszerű karakteres szövegállományokat is tartalmazzon, szöveges könyvtár struktúrával és egyszerű karakteres TCP protokollokkal rendelkezzék. Másodszor kellettek hozzá az olcsó BraiLab PC-k beépített ernyőolvasóval.

A Magyar Elektronikus Könyvtárért Egyesület (http://www.mek.iif.hu/egyesulet/) kezdettől fogva felvállalta, hogy hátrányos helyzetű olvasóinak igényeit figyelembe veszi, a gyűjtemény használatát minél jobban megkönnyíti. Az eddig használt MEK rendelkezik karakteres gopher és ftp eléréssel, amit a vak felhasználók jól tudnak kezelni, azonban az új rendszerben ilyen lehetőség már nincs. Az új, kialakítás alatt lévő Web helyet ezért szeretnénk ellátni a Magyarországon elterjedt képernyőolvasó programokkal, a DOS-os felületen, vagy a UNIX/Linux alatt használatos Lynx-szel is használható külön belépési oldallal és navigációval, valamint a kívánt szövegek felolvasását megkönnyítő formátumokkal. A tervezésnél a gyengénlátók igényeit is figyelembe vettük, a színeket és betűméreteket szabadon változtathatóra terveztük.

A MEK könyveit fiatal, a számítógép használatában esetleg már gyakorlatot szerzett vak emberek is fogják olvasni, de fel kell készülni arra, hogy nagy számban vannak közöttük olyan emberek is, akik idősebb korban veszítették el látásukat, és a számítástechnikához alig értenek. Az utóbbi csoport tagjainak az a lényeges, hogy minél egyszerűbben tudják használni a számítógépet. Az ő számukra voltaképpen a DOS-os rendszeren alapulóhoz képest is egyszerűbben használható rendszert kell kifejleszteni.

A W3C által közzétett Web Accessibility Initiative (http://www.w2c.org/WAI) anyagát tekintjük nemzetközi irányadónak, így magyar nyelvre való lefordítását és a MEK-ben való közzétételét tervezzük. A WAI abban látja küldetését, hogy elősegítse az internetes oldalakon "a használhatóság magas fokát a fogyatékos emberek számára".

"Ha egy mondatban szeretnénk összefoglalni azt, hogy milyen legyen az új vakos MEK akkor azt írnánk, hogy legyen olyan, mint a régi. Tudván, hogy a régi MEK rendszer belseje nem tartható meg, így azt javasoljuk, hogy törekedni kellene a régi ember-gép kapcsolati interfészek megtartására." (Arató-Vaspöri tanulmány)

Off-line használat (Arató-Vaspöri tanulmányból)

Egy nagyon jó vakos web felület sem tud olyan jó lenni, mint egy személyre szabott, önálló intelligenciával rendelkező számítógép. Hosszan olvasgatni egy könyvet hálózaton nem lehet. Tekintettel kell lenni arra, hogy a vak felhasználók sok esetben a letöltött állományokat akarják offline felolvastatni.

Az ISO 8859-2-es kódkészletű, letölthető sima szöveges állományokat meg kell tartani. Jó lenne az FTP-vel való letöltés lehetőségét is megtartani, ha lehetséges. Ha a navigációt segítő strukturált állományokat fogja Windows rendszerben valaki vakon olvasni, azt is inkább off-line fogja tenni. A Windows-os vakos programfejlesztésben elindult egy olyan irányzat, hogy a Microsoft-os programokat, mint egy motort használják csak, és külön programot fejlesztenek látássérülteknek, ilyen a fentebb már említett, fejlesztés alatt lévő LookOUT rendszer. Off-line működő, nagyon egyszerű interfésszel rendelkező vakos olvasó programra mindenképpen szüksége van a vakoknak Windows alatt is.

File-formátumok, tárolás

Az "előző" verzióban ún. "beszédes" linkek voltak: www.mek.iif.hu/irodalom/aranyj/... A MEK 2 rendszerben ún. 100-as gyűjtőkbe rendezve jelennek meg a dokumentumok a könnyebb kezelhetőség végett: http://mek.oszk.hu/00500/00582/

A dokumentumok a fenti hierarchikus filerendszerben vannak a MEK 2-ben, a róluk szóló adatok pedig adatbázisba kerülnek. De ezek a leíró adatok - többféle formában - a dokumentumok mellett, az adott alkönyvtárban is megtalálhatóak. Lényegében a katalogizálás folyik egy MySQL adatbázisba és onnan megfelelő programok konvertálják és pakolják a metaadatokat a dokumentum mellé is.

Egy tagolt, ún. címkés formátumban: http://mek.oszk.hu/00500/00582/cimkes.html

A címkés formátum mellett HUNMARC, USMARC és XML formátum van. A címkés formátum egy emberek által jól olvasható táblázatos formátum. A két MARC formátum arra szolgál, hogy más könyvtári rendszerbe is betölthetők legyenek az adatok (a legtöbb könyvtári adatbázisnál van MARC-input). Az XML pedig azért kell, hogy egyéb internetes adatbázisokba átemelhetők legyenek az adatok, vagy azok egy része.

Ebből egyelőre az ún. HUNMARC készült el: http://mek.oszk.hu/00500/00582/hunmarc.html

A nyitó, ún. borítólap szintén magában rejti a leíró adatok készletét Dublin Core formátumban. Ez nem jelenik meg, a forrásfile-ban található: http://mek.oszk.hu/00500/00582/index.phtml

A különböző formátumok külön vannak tárolva, amelyek online elérhetőek (pl. .pdf, .doc, .rtf, .ps, stb. formátumú file-ok).

A különböző formátumok ugyancsak egységes néven találhatóak a számozott alkönyvtárban, pl.

HTML változat http://mek.oszk.hu/00500/00582/00582.htm
Word változat (DOC) http://mek.oszk.hu/00500/00582/00582.doc
RTF változat http://mek.oszk.hu/00500/00582/00582.rtf
PDF változat http://mek.oszk.hu/00500/00582/00582.pdf

Ide kerülnek ugyanezen állományok letöltésre szánt, tömörített változatai is, valamint a szöveges állományok tömörített változata. A szöveges állományokból nem lesz megnyitásra szánt forma.

Előfordulhat, hogy egy dokumentum nem egy file-ból áll, mint a fenti példában, akkor egy formátumra utaló alkönyvtárból egy INDEX.HTM nevű file nyitja a többrészes dokumentumot. Többrészes, nem HTML formátumú dokumentum esetén is egy INDEX.HTM a nyitó file (egységes sablon), onnan tölthetőek le szükség esetén a különböző file-ok. Pl.

http://mek.oszk.hu/00500/00583/html/

Jelenleg az esetek nagy többségében a fenti formátumokat használja a rendszer, kisebb mértékben előfordulnak más típusú dokumentumok, pl. JPG, LIT, DVI.

A MEK-ben ideális volna egy egységes tárolási formátum, mely igen nehéz feladatot jelent, hiszen több helyről származnak a különböző dokumentumok, amelyeket nem is biztos, hogy lehet konvertálni (kódolt PDF). A MEK az egységesítésre is tett kísérletet: a Galateia Linux-os rendszer talán megoldást jelent(het) a problémára, ámbár így is lesz olyan dokumentum, melyet nem lehet bevonni az "uniformizálásba". Az XML előnye, hogy viszonylag könnyedén, akár online is generálható belőle text-formátum. A kidolgozás alatt álló XML formátum alapja a TEI LITE.

A text-file jellemzői

- Ékezetek: iso-8859-2

Az ebben a kódkészletben nem szereplő karakterképek #unicode;-ként jelennek meg. A felolvasó számára ez ún. "kivételszótár" használatával (mi helyett mit mondjon) könnyedén áthidalható.

- egy sorban max. 75 karakter - sorok végét a CR+LF páros (#13,#10) sorvég kell, hogy zárja - két fejezetet legalább egy üres sor (két sorvégjel) zárjon

- Az egyik javaslat szerint a szöveg formátumokat majd az XML fogja generálni és a címek után pontot is tesz a szebben hangzó felolvasás kedvéért. Azt javasoljuk, hogy a kidolgozók tartsák meg az eredeti preparálatlan szöveget, vagy azt generálják le az XML-ből. Jó az, ha tudja a vak ember (tanuló), hogy nem írunk a cím után pontot. Hallani fogja ezt a szintetizátor monoton hangjából. Ha történetesen Braille-kijelzővel olvassa az illető a szöveg- file-t (pl. off-line), akkor kifejezetten hibás, ha a szintetizátor segédleteit látja. Ez rontja a vak felhasználó írásbeliségét is.

- A szöveges állományok részekre szabdalását nem tartjuk szükségesnek, ha azok mérete nem haladja meg a 250-300 kbyte-ot.

- A több file-ból álló dokumentumoknál a tömörítés nemcsak helyspórolást jelent, hanem egy egységes letöltési formát, egységben tartja a könyvet maga az archív file. Mindenképpen egy univerzális tömörítőformátumot kell választani, mely mindegyik rendszeren (DOS, Linux/UNIX, Windows, MAC, stb.) gépeken használatos. Ezen kritériumoknak a ZIP formátum felel meg a legjobban. Alternatívaként a RAR is hasonló kondíciókkal rendelkezik, viszont a felhasználók többsége a ZIP-et jobban ismeri, gyakrabban használja.

A file-ok elnevezéséről: érdemes a DOS. által generált 8+3 karakterszámot betartani, ill. az ékezetlen file-neveket. A tömörített .zip file neve egy 8 karakteres, ékezetlen változatban szereplő név, ami utal a műre (MEK-id)+ a formátum rövidítése. Ha több fájlból áll a dokumentum, az elnevezésnél a sorrend legyen a gépi rendezés szerint.

Online használat (Arató-Vaspöri tanulmányból)

Az oldalakat, a látó oldalakhoz hasonlóan, hierarchikus struktúrába kell rendezni. Javasoljuk, hogy az egyes választási lehetőségek az egyes lapokon mindig egymás alá kerüljenek. Ezekből, ha lehet, hétnél ne legyen több egy oldalon, így azt az idősebb emberek is jól meg fogják tudni jegyezni. A linkekhez tartozó szövegek legyenek legalább teljes mondatok. Természetesen az olyan típusú linkek, ahol a név csak azt tartalmazza, hogy "További információk itt", nem megfelelőek, mert az ernyőolvasók, ha a linkeken haladnak végig tabulátorral, akkor csak magát a linket olvassák fel.

Az egymás alá írt linkek, ill. szövegek formájától ne térjünk el. Egy sorban ne legyen több link.

Világhalló applikálása

Azon látássérültek, akik otthon használják az internetes lehetőséget, saját rendszerükkel olvassák az oldalakat (így a MEK-et is).

A Windows-os felolvasó lehetővé tenné, hogy bármilyen gépről, pl. egy hagyományos könyvtárban vagy teleházban - ahol viszont csak Windows-os gépek vannak - is felolvastathassák maguknak a könyveket a vakok, főleg azok, akiknek nincs saját gépük és internet-hozzáférésük.

A Világhalló rendszer használatához a felhasználónak szüksége van egy a www.vilaghallo.hu oldalról letölthető kliens programra, amelyet feltelepít saját gépére és hozzárendeli egy file-formátumhoz (.vhk) a programot. így ha a böngésző az adott file-t kapja meg, automatikusan elindítja a vilaghallo.exe alkalmazást. A program felveszi a kapcsolatot a saját szerverével és a .vhk file által meghatározott szövegfile-t (pl. MEK-es dokumentum) leindexeli egy saját formátumba és azt felolvastatja a kliens gépen futó vilaghallo.exe-vel. A programban lehet keresni, könyvjelzőket tenni az adott szövegben.

A kliens oldalon fut egy alkalmazás, az ún. VilágHalló. Ez Javában készült, és a szerverről érkező egyesített hang-szöveg folyam felolvasására szolgál. (A hang-szöveg folyam alatt egy olyan adatfolyamot értünk, amely egyrészt tartalmazza a kimondható szöveget - pl. GSM-mel tömörített wave - másrészt a hangzó hang és az olvasható szöveg közötti szinkronizáló jeleket.)

A felolvasásra vonatkozó igény a klienstől jön, aki az OSZK valamelyik page-éről választja ki az olvasnivalót. Ezt az igényt egy web szerveren futó szervletnek (ún. reader szervlet) küldjük, ami egy - akár másik gépen futó - másik szervlettől (ún. book szervlet) kapja meg a könyv adatait és szövegét. (Ezek az információk egy - akár harmadik gépen futó (mondjuk MEK.) - adatbázisból származnak. A jelenlegi konkrét konfigurációban a web szerver egy Linux-apache-tomcat, az alkalmazás szintén Java, az adatbázis szerver pedig Windows NT, MS-SQL, amit a web szerverről JDBC-n keresztül ér el az említett szervlet.)

A book szervlettől érkező szöveget a reader szervlet továbbítja a szintetizálást végző gép felé, ahonnan válaszként a fent említett hang-szöveg folyam érkezik. A TTS engine ezen a (Windows NT, ProfiVox) gépen fut. A TTS engine felett helyezkedik el az a - szintén Java - réteg, ami a beérkező szöveget fogadja, alkalmas módon odaadja a ProfiVoxnak, majd a Profivoxtól kapott wave-et tömöríti (most GSM-mel) és a nála lévő szöveggel és a szinkronjelekkel egyesített hang-szöveg folyammá alakítja. Ez MS Speech API-n keresztül történik. Ezt a folyamot elküldi a reader szervletnek, ami továbbítja a kliens felé.

Ennek a komplikáltnak látszó megoldásnak az a lényege, hogy kliens oldalon szinkronizált a hang és a szöveg, azaz a felolvasást bármikor abba lehet hagyatni, pontosan ugyanonnan folytatni, könyvjelzőt letenni, stb. Ezek a funkciók feltétlenül szükségesek hosszabb szöveg olvasásánál.

Hátránya, hogy jelenleg csak Windows alatt nyújtja szolgáltatásait, de a fejlesztők jelenleg a Linux-os megvalósításával foglalkoznak a programnak.

Ahhoz, hogy a MEK 2 rendszerébe integrálható legyen a felolvasórendszer, át kell dolgozni a Világhallót, egyszerűbbé tenni a használatot, ill. bármilyen file felolvastatásához "idomítani". így a kifejlesztendő szoftver nem azonos a Világhalló-val. Nevezhetjük majd az új szoftvert is Világhallónak (mert ez egy igen jó név), de ez már eddig is sok félreértésre adott okot. (Javasolt név: ÚjVilághalló)

Az ÚjVilágHalló elérhető lesz mind a vakos mind a "látó" MEK felületeiről.

Az ÚjVilágHalló bizonyos vonatkozásban - stream kezelés, speciális hang-szöveg szinkronformátum használata, stb. hasonló lesz a VilágHalló-hoz, de a leglényegesebb különbség az, hogy az internetes on-line felolvasás - egy lehetséges - szabványrendszerének egy konkrét megvalósulása, tehát:

- browser-ből indítható,

- központi kivételszótárat kezel,

- nem kötelező a regisztráció és ennek ellenére lesznek könyvjelzői és navigálási lehetőségei a felhasználónak,

- nem felhasználóhoz, hanem kliensgéphez kötöttek az információk,

- az XML-ben ábrázolt struktúrát képes lesz interpretálni,

- a felhasználói felületének két verziója lesz, vakos és látóknak szóló,

- a látó felülete kis ablakos lesz, nem fedi tehát el a MEK felületet,

- gyengénlátók esetén nagyra nyitható, a betűméret és a szín állítható, highight követi a szövegben a felolvasást,

- a MEK megfelelő felületéről indulnak (vakos, látó),

- a letölthető verziók mellett, megjelenik a meghallgatható verzió linkje is. Ez a link egy speciális file-ra mutat, mely tartalmazza a könyv felolvasásához szükséges adatokat. Ennek a file-nak speciális kiterjesztéssel kell rendelkeznie, mely kiterjesztést a browser-ben az ÚjVilághalló kliens-lkalmazáshoz kell társítani. Az ÚjVilághalló egy ilyen file-ra úgy indul el, hogy kiolvasva a file-ban szereplő paramétereket, felveszi a kapcsolatot a szerver oldali alkalmazással és elkezdi felolvasni a könyvet.

Design

Az oldal elkészítésénél a lehető legkevesebb formázást használtuk azért, hogy a gyengénlátó látogatók a saját beállításaik szerint tudják az oldalt olvasni. Nem használunk stíluslapokat, csak HTML-tageket, ugyanis amit stíluslappal állítunk be az oldalon, azt a böngészők egyéni beállításai nem bírálják felül, így a gyengénlátók nem élvezhetik a nekik szükséges saját beállításokat.

A MEK vakos honlapja a következő alkotóelemeket tartalmazza:

Főlap:

Újdonságok a MEK-ben: (egyszerű lista, csak cím és szerző)

Tematikus oldalak: A tematikus oldalak HTML formában, az altémák szintén kinyithatóan, majd a végső listáról kattintható a mű vakos borítója, ami nem statikus oldal, esetenként generálódik.

Keresés a gyűjteményben: űrlap Szerző, Cím, Téma szerint.

Listák: Újdonságaink, Előző havi sikerlista, Teljes lista

Egyéb: Könyvismertetők (Legeza Ilona ismertetői), Letölthető programok látássérültek számára (A látássérültek számára fontos konverziós programok, freeware, vagy shareware beszélőprogramok (a Világhalló programra való hivatkozás) és más, hasznos segédletek számára egy külön menüpont)

A MEK működése: Hírek a MEK fejlesztésével kapcsolatban Statisztikák Bemutatkozás Irattár: dokumentumok és publikációk Vendégkönyv. (Ezek egyszerű HTML lapok.)

Keresés a gyűjteményben : teljes szövegű keresés, szűkíteni lehet és kell a fő témakörök valamelyikére.

Link a grafikus változatra: a felolvasó a lap végén olvassa fel, a látók számára viszont a lap tetején van.

És végül: Fenntartónk az Országos Széchenyi Könyvtár. Az oldal az IHM-ITP-2/E pályázat, 2002 keretében készült. Impresszum

A menüpontokat (ez vonatkozik bármelyik különálló linkre is) külön sorba kell írni. Bármely menüpont, vagy link, mely "kattintható", mindenképpen külön sorban, egyedülállóként kell, hogy szerepeljen a könnyebb felolvastathatóság miatt.

A listák azonosak azokkal, melyeket keresés eredményeként kapunk, és a kész, kattintható listák:

A listák programozás szempontjából nem különböznek a látók számára készített grafikus MEK 2-ben a vakok számára készülttől, csak megjelenés szempontjából térnek el. Mindenképpen törekedni kell az egyszerű megjelenésre. A listáknál fontos, hogy az "oszlopok" tükrözzenek egyfajta fontossági sorrendet is. Egy listaelem több oszlopból tevődik össze: dokumentum szerzője, címe, file-neve, feltöltés dátuma, stb. Fontos, hogy balról jobbra tartsuk be a fontossági sorrendet. Egy dokumentum legfontosabb információja az írója, ill. címe. Az egyéb információk (pl. feltöltés dátuma) kevésbé fontosak, így a beszélővel való munkát lassítja is a rosszul strukturált lista. Javaslat: max. 3 cella megjelenítése, max. 80 karakter hosszan (egy sorban). Pl.:

1. Az Athenaeum repertóriuma (1892-1947) - 189 olvasó Philosophiai és államtudományi folyóirat URL: http://mek.oszk.hu/00000/00002

2. Herczeg Gyula: Olasz-magyar, magyar-olasz miniszótár - 131 olvasó Számítógépes segédlet Herczeg Gyula Olasz-magyar szótárához URL: http://mek.oszk.hu/00000/00074

3. A katolikus Biblia - 130 olvasó URL: http://mek.oszk.hu/00100/00176

A listák eredményeképpen egy olyan felsorolást kapunk (akár kézzel, akár menüből kiválasztott keresés után), melyből azonnal rákerülünk a vakos borítóra.

Az egyes dokumentumok borítólapja:

Ezen az oldalon kell megjelenni a különböző formátumú állományoknak, az online felolvasásnak, a letölthető tömörített text változatnak, valamint a fülszövegnek.

Pl.:

A web oldalnak külön, egyszerű belépési címmel kell rendelkeznie, hogy ne csak a számukra nehezen kezelhető grafikus változatról tudják az olvasók elérni. Javasolt web cím: http://vmek.oszk.hu.