Weblabor

Egy weblap készítésekor sok szempontot figyelembe kell vennünk, ilyenek többek között a szakmai szempontok, a megrendelő kívánságai és a természetesen a rendelkezésre álló idő és erőforrásaink. Ebben a cikkben azokat a szakmai irányelveket gyűjtöttem össze, melyeket a munkám során megpróbálok betartani, s melyek főleg az oldal hozzáférhetőségére, elérhetőségére vonatkoznak. Olvasóink hozzászólásaival kiegészítve, tovább szerkesztett formában szeretnénk a WFSZ ajánlásaként is közzétenni a cikk tartalmát.

A következőkben ismertetendő irányelveket az esetek legnagyobb százalékában természetesen nem lehet 100 százalékosan betartani, a többi szempont sokszor befolyásol, vagy adott esetben akár teljesen el is lehetetlenít egy-egy pontot. A weblap célja és nem utolsó sorban célközönsége is meghatározhatja, hogy egyáltalán éljünk-e ezekkel a korlátozásokkal, így adott esetben egy belső céges oldal esetén teljesen más szempontrendszert is használhatunk, ha a felhasználóink, böngészőink heterogénebb közeget alkotnak, mint maga az internet. Ezek figyelembevétel ajánlom mindenkinek az alábbi pontok betartását, melyek egy átlátható, tartalmat nyújtó weblap esetén jól hozzáférhető és használható végeredmény létrejöttét segítik elő.

A bemutatott elvek a vakok, gyengénlátók, színtévesztők, nem túl rutinos felhasználók számára szolgálnak az esetek többségében előnyökkel, de a többi felhasználó is profitálhat abból, ha figyelembe vesszük ezeket. Elmondható, hogy az előbbi célcsoport összességében sokkal hálásabb lesz, mint az átlagos felhasználók. Mellékhatásként az irányelvek betartása egy átláthatóbb, világosabb, könnyebben emészthető portált is eredményez. A bemutatandó pontok közel állnak azokhoz az elvekhez is, melyek az USA-ban elfogadottak, és kötelezőek állami weblapok készítésekor (lásd Akadálymentes weboldalak cikksorozatunkat). A dolog nem egyedülálló, további országok is szintén hasonló ajánlásokat és betartandó pontokat kezdenek megfogalmazni, mert fontosnak tartják, hogy minden állampolgár hozzáférjen a közpénzen készült weblapokhoz.

Bízom benne, hogy az egyes pontokhoz fűzött megjegyzések, indoklások más számára is érvként felhasználhatóak lesznek, különös tekintettel arra, ha egy ügyfelet, netalán a főnöküket szeretnék meggyőzni egy-egy pont hasznosságáról.

1. Kezdőlap kialakítása

A weblap kezdőlapja ne legyen Flash, DHTML, Java applet alapú, vagy amennyiben ez a választás, akkor mindenképpen biztosítani kell megfelelő kerülő lehetőséget (tipikusan egy link formájában), mely azoknak is továbblépési lehetőséget kínál a további oldalakra, ahol le vannak tiltva, vagy nem elérhetőek ezek a technológiák.

A webfejlesztők sokszor esnek abba a hibába, hogy a kezdőlapra egy szép animációt helyeznek el, vagy valamilyen szemet gyönyörködtető ábrát jelentetnek meg. Esztétikai szempontokat figyelembe véve, ezek tényleg jó benyomást tehetnek a látogatóra, azonban több probléma is lehet velük.

Az egyik ilyen, hogy akinek nincs Flash, DHTML, Java támogatással bíró böngészője, annak nem működik a címlap, és adott esetben el sem tud jutni a belső oldalakra. Ez előfordulhat akkor, ha valaki valamilyen speciális böngészőt használ, vagy speciális környezetben teszi ezt, de akkor is, ha éppen csak feltelepítette böngészőjét, s még nem telepítette a megfelelő bővítményeket. Ezeknek a látogatóknak biztosítani kell egy sima HTML linket, melynek segítségével át tudják ugrani ezt az oldalt, így eljutva a tartalomhoz.

További probléma, hogy zavaró lehet ez a megoldás. Ha egy látogató többször is visszatérne az oldalunkra, elrettentheti, unalamassá teheti az utat a tartalom eléréséhez. Ha belegondolunk, akkor mi sem szeretjük többször megnézni a reklámokat (sokszor egyszer se), kivéve, ha nagyon érdekesek, de ekkor is elegünk lehet belőle, ha már százszor láttuk. Ha ezt a megoldást választjuk, javasolt megoldani, hogy például egy cookie segítségével az oldal megjegyezze, hogy itt már járt a látogató, és lehetőséget kínáljon a kezdőképernyő azonnali átugrására (felhasználói beavatkozás nélkül).

Nem utolsó sorban, ha nincs nem HTML alapú továbbjutási lehetőség a belső oldalakra (azaz nincs egy egyszerű link), akkor a kereső robotok sem fognak tudni bejutni, és leindexelni az ottani tartalmat (kivéve, ha a belső oldalakon már sima linkek vannak, és valamely belső oldalra mutat valahonnan "kívülről" egy link, melyet már megtaláltak).

Itt említeném meg azokat a reklám megoldásokat, melyek a kezdőlap átmeneti lecserélésével, egy bevezető reklámblokkot adnak egy oldalhoz (azaz nem a várt oldal, hanem egy reklám jön be - főként portálok élnek ezzel a lehetőséggel). Ezek minden bizonnyal figyelemfelkeltőek lehetnek, hiszen a látogatónak nincs más választása, mint a reklám megtekintése, azonban olyan agresszív formát képviselnek, melyek a célközönségben valószínűleg pont nem a kívánt hatást fogják elérni.

2. Frame mentesség

A weblapon nem ajánlott frame-ek, iframe-ek használata, mivel felolvasó szoftverekkel ezek oldalai egyszerre nem érhetőek el nem látó felhasználók számára, gyakorlatilag átláthatatlanná téve ezzel az oldalt. A kisebb tudású karakteres böngészők sem kínálnak ezekre megoldást, így azok számára is megnehezítjük az oldal használatát, akik valamilyen okból éppen csak karakteresen tudnak böngészni.

A frame-ek kezelése, programozása is egy külön művészet, sokszor megbonyolítva ezzel a programozást, olyan feladatokat a programozó elé állítva, melyek ellenkező esetben nem okoznának problémát. Egy egyszerű példa erre a beléptetés, kiléptetés: ha a felhasználó belép az egyik frame-ben, attól a másik frame még nem biztos, hogy hozzáfér a munkamenet azonosítójához (GET-es, POST-os munkamenet kezelés esetén), vagy adott esetben a kibővülő, átalakuló menüt sokkal bonyolultabb frissíteni is - a HTML szabvány nem (illetve nem egyértelműen) támogatja egy form több frame-be elküldését.

Az aloldalak, frame-ek könyvjelzőzése sem egy igazán egyszerű feladat, ha ilyen megoldásokat használunk, a felhasználó egy konkrét frame összeállítást nem tud letárolni, csak azt az oldalt, amely betöltötte neki a kereteket.

A frame-ek, iframe-ek helyett sokszor megoldást nyújthat a problémára a CSS overflow tulajdonsága, melyet használva nagyon hasonló hatás érhető el a frame-ekhez, azzal együtt, hogy a teljes tartalom egy oldalon foglal helyet.

A frame-eknek persze megvan a maga helyük, a fentiek nem jelentik azt, hogy ne lenne létjogosultságuk. Speciális, asztali alkalmazásokat utánzó oldalakon, admin felületeken például nagyon jól használhatóak.

3. Töltelék képeket ne használjunk

Ne használjunk üres, átlátszó képeket design megoldásokhoz, pozícionáláshoz. Ez a technika ma már idejét vesztette, a forráskódot átláthatatlanná teszi, és bonyolult lehet a szerkesztése is. Sokkal egyszerűbb és szebb, ha a margin, illetve a padding CSS tulajdonságokat állítjuk be a design kívánalmai szerint.

Amennyiben valamilyen okból mégis ilyen képeket kell használnunk (az esetek kevesebb, mint 1%-ban), adjunk egy üres alt tulajdonságot nekik. Ezzel a képek megjelenítése nélkül, illetve felolvasószoftverrel böngészők számára ezek a képek nem jelennek meg, nem kerülnek felolvasásra - mintha ott se lennének.

4. Image map-ek használata

Az oldalakon ne használjunk szerver oldali image-mapeket, vagy legyenek azok másképp is elérhetőek. A vak felhasználók, vagy akár a karakteres böngészőt használók nem látják a képeken a feliratokat, így nincsen lehetőségük eldönteni, hogy hova kattintsanak a rajtuk (persze a felolvasó szoftverek ilyen kattintási lehetőséget sem adnak valószínűleg).

Kliens oldali image map megoldásokat viszont használhatunk, de lássuk el a linkeket megfelelő leírással (title tulajdonság), hogy azok számára is egyértelmű legyen hogy mire vonatkoznak, akik nem látják a képet.

5. CSS nélkül is használható oldal

CSS formázó elemek nélkül is értelmezhető és használható legyen az oldal. Vannak böngészők, illetve felolvasó szoftverek, melyek nem ismerik, nem ismerik fel a CSS-ben megadott formázó elemeket, vagy csak részben támogatják azokat.

A cél az, hogy ilyenkor is áttekinthető, használható oldalt nyújtsunk, sohasem lehet eleget hangsúlyozni: nem a megjelenés, hanem a tartalom a fontos! A tartalom pedig legyen minden körülmények között elérhető, függetlenül a használt eszköz lehetőségeitől. Ezt sem mindig könnyű elérni, de törekedni törekedjünk rá!

6. Szabványosság

Éljünk a szabványok adta előnyökkel, fejlesszünk úgy, hogy az oldal szabványos legyen. A CSS 2, XHTML 1.0 Transitional és a Javascript/DOM szabványok általában egyáltalán nem kötik meg a kezünket, viszont egy átláthatóbb oldal forrás mellett ellenőrizhetőséget is kínálnak.

Ha valami probléma van az oldal megjelenésével, sok esetben célravezető ilyenkor, hogy egyszerűen validáltassa az ember, és voálá, a hiba már látható is, amit kijavítva a probléma már meg is szűnik. Persze ne gondoljunk csodaszerre, csak egy hasznos további eszközre.

Ha egy a szabványt pontosan és jól támogató böngésző alatt fejlesztünk például Javascriptet, mely további eszközöket is nyújt (például a Venkman JS Debugger), azzal sokkal könnyebbé tehetjük a fejlesztést a semmitmondó hibaüzenetekkel történő munkához hasonlítva.

7. Képek hozzáférhetősége

Minden kép állományhoz, mely funkcionális szereppel bír, megfelelő alt tulajdonságot kell hozzárendelni. Amennyiben például szöveget tartalmaz egy kép, akkor a szöveget egy alt tulajdonságba is bele kell írni. Ez karakteres böngészőt használó (felolvasó szoftverek), illetve a képeket kikapcsoló felhasználók miatt szükséges. Az alt szöveg akkor jelenik meg, ha a kép nem elérhető, le van tiltva a megjelenítése, vagy pedig karakteres (vagy hasonló) böngészővel nézi az oldalt a látogató.

A képekhez még egy title tulajdonságot is rendelhetünk, ez arra szolgál, hogy további információt nyújtson a képről, mintegy címet adva neki. Ez a szabványos böngészőkben akkor jelenik meg, ha az egérkurzort a kép felé visszük.

8. Tartalmak alternatív formában közzététele

Alternatív tartalmak, mint például Flash, videók, PowerPoint bemutatók, Java alkalmazások, amennyiben szöveges információt tartalmaznak, mutatnak meg, karakteres formában is elérhetőek legyenek, hogy a felolvasó szoftverekkel legalább kivonatos formájuk rendelkezésre álljon.

Ezek megvalósítása persze nem túl egyszerű, ilyen funkciókat nem túl sok rendszer támogat. Egyedileg, minden dokumentumhoz alternatív tartalom készítése nem biztos, hogy megengedhető, illetve elég erőforrásunk van rá. A megoldást az automatizálás hozhatja, a különböző formátumokhoz elérhetőek konvertáló eszközök, melyek hű megjelenést egyáltalán nem, de a tartalmi kivonatot tudnak nyújtani, ami nagy segítség lehet azoknak, akik éppen nem rendelkeznek azzal a megjelenítővel, ami kellene az adott tartalomhoz.

Ilyet persze egy videó, vagy Java alkalmazás esetén elég nehéz kivitelezni. Ha lehetséges, ezeknél próbáljuk meg legalább röviden összefoglalni, hogy mit tartalmaznak. Ha egy előadásról van szó például, akkor próbáljunk meg egy leiratot közzétenni, vagy az előadás anyagait (prezentációját) átkonvertálni olyan formátumba, amihez vannak eszközök olyan felhasználóknak is, akik nem férnek hozzá az adott videóhoz (lehet, hogy csak azért, mert nincs kodekük). Ilyen formátum lehet a PDF például.

9. Navigáció

A navigáció nem épülhet nem hozzáférhető navigációs elemekre, mint Flash, Javascript, stb., hiszen ha nem rendelkezik a látogató ezekkel, vagy pedig ki van kapcsolva számára, akkor használhatatlanná válik számára a weblap. Mindenképpen egy alternatív lehetőséget kell biztosítani ilyen technológia használata esetén, illetve a legszerencsésebb az ilyen technológiát csak kiegészítésre használni, mely a minden körülmények között működő megoldásokat kiegészíti, a felhasználó számára megkönnyítve ezzel a navigációt.

A Flash menü, Javascriptre épülő megoldások (menü, vagy legördülő, azaz selectes linkgyűjtemény, stb.) bár a navigációt jelentősen megkönnyíthetik, az oldalt használhatatlanná tehetik az ezeket nélkülöző böngészők, felhasználók számára. Az egyik távközlési cég weblapja így volt egy ideig használhatatlan számomra, míg végre volt egy kis időm feltelepíteni a legújabb Flash-t a böngészéséhez.

A probléma mint már a címlapnál ilyen alapú megoldások használatakor is meg lett említve, ráadásul képes kizárni a keresőket (al)oldalinkról, így azok képtelenek lesznek leindexelni, és a kereséseknél megjeleníteni az oldalt. Jelentős látogatottságot veszíthetünk, ha erre nem figyelünk.

Ez az irányelv azonban nem jelenti azt, hogy ne használhatnánk ezeket a megoldásokat, csak azt jelenti, hogy használható legyen az oldal ezek nélkül is. Erre több megoldás is van, például egy legördülő menüs navigációnál kitehetünk egy OK gombot, mely elküldi a kivásztott elemet formként, így lehetővé téve a használatot (egy robot pedig például egy oldaltérképen keresztül tud eljutni az adott oldalhoz). További lehetőség, ha egy menüt úgy jeleníttünk meg, hogy sima linkhalmazt képez, majd egy kis Javascript program variálja át az oldalt úgy, hogy a megjelenítés ezután már Javascriptre épüljön. Ismerős? Erről írtam a Diszkrét Javascript cikkünkben.

10. Zavaró elemek mellőzése

Marquee (fényújság), blink (villogás) elemek, villogó és más figyelemfelkeltő, elterelő képek (animált GIF-ek, ugráló Flash-ek) használata nem kifejezetten javasolt. Ezek rontják az oldal olvashatóságát, adott esetben a gyengén látó felhasználók számára lehetetlenné, vagy nagyon nehézzé téve a befogadást (de az átlagos felhasználót is zavarhatja az olvasásban). Nem gondolom magamról, hogy különös gondjaim lennének tartalmak befogadásával, vagy a figyelmem összpontosításával, de egy-egy ugráló Flash tartalom kifejezetten zavarni szokott.

A korábban szóba került reklámokat újra felemlegetném, s egy rossz megoldásra hívnám fel a figyelmet. Ha egy reklám valamilyen (főként Javascript) megoldással a tartalom felé lesz pozícionálva, s onnan egy idő letelte után, vagy felhasználói közbeavatkozással tűnik csak el, az rendkívül zavaró és idegesítő tud lenni. E mellett, ha valamilyen hiba van a kivitelezésben, s a megoldás nem minden böngészővel működik, könnyen előfordulhat (sajnos nagy portálokon láttam ilyet), hogy a reklám nem tűnik el, rossz helyre mozog, stb. Ekkor nem csak idegesítő lesz, de a látogató első lépése az lesz, hogy elkezd keresni egy megoldást arra, hogy többet ez ne forduljon elő. Vagy elgondolkodik egy másik oldal felkeresésén, vagy pedig - ha van hozzá szakértelme - gyökerestül eltávolítja az odldalról a reklámokat.

A figyelemelterelő szerepen kívül egy rosszul megválasztott kép még az igénytelenség látszatát is keltheti. A kezdő webfejlesztők tipikus hibája, hogy sok aranyos, szép képet, vagy más elemet az oldalon elhelyeznek, és az összhatás szörnyű lesz. Akkor is, ha őszerintük az oldal szép.

11. Javascript nélkül is használható oldal

Az oldal legyen 100%-ban(!) használható Javascript nélkül is. Van, akik számára ki van kapcsolva a Javascript, vagy pedig a böngészője nem támogatja.

A 9. pontnál (navigáció) már volt szó erről, de kiemelném külön is, annyira fontos szempont. Ez persze nem csak a navigációra, hanem más funkció nyújtása esetén is igaz. Az alapfunkciót próbáljuk meg úgy megvalósítani, hogy a Javascript már csak hab legyen a tortán, és az alapfunkciót mindenki élvezni tudja.

12. Hang nélküli oldal

Ne legyen háttérzenéje az oldalnak, ne legyen hang alapú visszajelzés az oldalon (például ha valami felé viszi a látogató a kurzort). Ez egyrészt zavaró lehet egy átlagos felhasználó számára is (például bekapcsolt hangszóró mellett éjjel az oldalra lép, és elkezd zenélni a gép - a család felébred), másrészt a felolvasó szoftver használata lehetetlenné válik a háttérzene miatt.

Erre az irányelvre sokszor mondják, hogy hülyeség. A titok abban rejlik, hogy a célközönséget és az oldal funkcióját kell megnézni, és ezek alapján dönteni. Egy olyan brosúraszerű oldalon, ahol a hangulatkeltés a cél, valóban célszerű hangok (például háttérzene) használata. Egy tartalmat nyújtó oldalon viszont nem, sőt, zavaró is lehet. Ha az oldal hangot bocsát ki, akkor is gondoskodjunk róla egy könnyen elérhető megoldással, hogy ez kikapcsolható legyen (s a család tovább tudjon aludni).

13. Formázás ne hordozzon információt

Formázások nélkül is használható legyen az oldal (ne közöljön kizárólagosan színek vagy bármilyen más szövegformázás - dőlt, vastagított - segítségével információt). Ez karakteres böngésző esetén is gond lehet, illetve gyengén látó felhasználó nem biztos, hogy megfelelően észlelni tudja ezeket az általában apró megjelenéseket. Ezzel igazából minden el is lett mondva: próbáljuk meg egy extra kis képpel, plusz karakterrel (például felkiáltójel) jelezni az információt, és ne csak mondjuk piros helyett kékkel jelenítsük meg.

Hogy ne csak általánosságban, hanem konkrétumokat bemutatva is beszéljünk erről az irányelvről: az aktív menüpont jelzése, a kiválasztott elemek jelzése (ha éppen egy JavaScript megoldást használunk), ne csak vastagítással, vagy eltérő háttérszínnel történjen. Ezt az irányelvet sajnos mi sem tartjuk be a Weblaboron a felső menüvel, de ettől még fontos!

14. Oldalszerkezet

Az oldal forrásában található sorrendet tekintve is értelmezhető legyen a tartalom, vizuálisan egymás mellett megjelenő kapcsolódó információk (például egy cikkhez tartozó letölthető állományok, kapcsolódó linkek, vagy képaláírás, szövegdoboz stb.) a forrásban is egymás mellett legyenek, ne csak vizuálisan. Ez azért fontos, mert karakteres böngésző nem biztos, hogy értelmezni tudja, hogy vizuálisan mi kerülne egymás mellé, illetve a felolvasó szoftver végképp nem tud két egymástól számára távol levő információt összekapcsolni, ezáltal eljuttatni a felhasználó számára.

Tipikus probléma az lehet, mikor egy cikkhez, hírhez kapcsolódó anyagot nem a cikk, hír után, hanem valahol az oldalon máshol jelenítjük meg. Ez lehet, hogy vizuálisan közel van, viszont előfordulhat, hogy formázások nélkül az oldalon rendkívül nehezen összekapcsolható lesz ez az információ mindenki számára, aki olyan böngészőt használ, mely nem tudta megjeleníteni, értelmezni a szerkezetét az oldalnak.

15. Helyes kód

A portál űrlapelemei logikailag kapcsolódjanak, a magyarázó szövegük helyesen legyen használva. Ez az irányelv gyakorlatilag a helyes szabványhasználatról szól, mely egy korábbi irányelvben szerepelt, de ezt olyan egyszerű megvalósítani, s olyan hatásos, hogy külön is kiemeltem. Íme a helyes kód:Ezzel nem csak azt érjük el, hogy egy erre felkészített szoftver, például a felolvasószoftver értelmezni tudja, hogy melyik felirat melyik beviteli mezőhöz tartozik, és ezzel segítséget tud nyújtani, hanem azt is, hogy ha egy felhasználó rákattint az adott szövegre, a fókusz a hozzá tartozó beviteli mezőre áll (nagyon kényelmes, mikor nem kell eltalálni egy checkbox-ot, hanem a mellette levő szövegre is kattinthatunk!).

A for használatától, id hozzárendelésétől eltekinthetünk, ha a beviteli mezőnk a label elemen belül kap helyet.

16. Teljes oldaltérkép

A site egyes oldalairól (nyilván nem az összesről, a logikailag - pl. kategóriákba soroltakhoz lehet egy linket biztosítani) biztosítsunk egy listát oldaltérkép formájában. Ez az oldaltérképe legyen teljes az oldalnak, ne maradjanak ki belőle részek, ezáltal segítve az eligazodást, és a navigációt azok számára is, akik esetlegesen elvesznek a linkekben, nem találnak valamilyen oldalt.

Ez persze nem mindig oldható meg, és tényleg nem azt jelenti, hogy az összes tartalmat itt elérhetővé kell tenni. Itt inkább arra kell törekedni, hogy az oldaltérképről két-három kattintással el lehessen jutni "minden" tartalomhoz.

Az oldaltérkép azért is fontos, mert lehet, hogy a látogató - bármilyen okból - nem talál meg egy tartalmat az oldalon. Ekkor, ha nincsen semmilyen alternatív navigációs lehetősége, képtelen lesz eljutni az általunk kínált tartalomhoz.

17. Táblázatok

Az oldal táblázatai "lineárisan" is értelmezhetőek legyenek, mindegyikről legyen összefoglaló információ. A felolvasó szoftverekkel egy vak ember teljesen elveszhet egy nagy táblázatban, egy egyszerű összefoglaló szöveg sokat segíthet neki. A "lineárisan" értelmezhetőség azt jelenti, hogy ha valaki folyamatosan olvassa a táblázat tartalmát (lásd HTML forrás folyamatossága), akkor is kiigazodjon.

És nem csak egy vak embernek segíthet, hanem mindenkinek, aki egyből nem látja át, hogy miről szól a táblázat, egy összefoglaló, a mondanivalót leíró rövid szöveg jól jöhet. Ezt sem szokták támogatni a szerkesztőségi rendszerek, a megoldás talán az lehet, hogy a táblázat melletti szövegben is kifejtjük annak tartalmát, a táblázat pedig illusztrációként, extra (nem alapvető) információk közlésére szolgál csak.

18. Linkek

Az oldal linkjei ne nyissanak új ablakokat (ez az ablakok elszaporodásához vezethez, a böngészés során történő visszalépés ellehetetlenülésével jár, és egyszerűen zavaró lehet). Ezzel nem mindenki szokott egyetérteni, egy biztos, egy oldalon belül mindenképpen próbáljuk meg mellőzni a popup ablakokat, hagyjuk a felhasználónak eldönteni, hogy mire akarja és hogyan használni a böngészőjét. Az XHTML 1.0 Strict szabvány a target tulajdonságot nem is támogatja linkek esetén.

Ha ezzel a menüponttal nem értünk egyet, kialakíthatunk különböző irányelveket saját magunknak is, de ehhez tartsuk magunkat, s legyen a felhasználó számára egyértelmű, hogy mi nyit új oldalt, s mi nem. Ilyen irányelv lehet, hogy az oldalról kifele mutató linkeket új ablakban nyitjuk meg, pár kisebb, segítő tartalmat popupban, s az összes többi linket ablakon belül. Az egyes megoldásokat, hogy melyik link melyikbe tartozik, kis ikonnal jelöljük a link szövege mellett!

19. Háttérszín

Az oldal háttere egyszínű legyen, ne tartalmazzon mintákat, képeket. Ha mégis tartalmazna, akkor legyen minél inkább elmosódott, minél kevésbé kontrasztos. A gyengén látó felhasználók számára olvashatatlan, de a többi felhasználó számára is erősen zavaró lehet egy kontrasztos háttér.

A weblap összetartozó hátterei és szövegei is erős kontrasztot kell, hogy képezzenek, akár 256 és 16 szín használata esetén is, az indok megint az, hogy a gyengén látó felhasználók képtelenek lesznek használni az oldalt, az átlagos felhasználóknak pedig nehezen olvasható lesz, vagy pedig "csak" zavaró a megoldás.

Ha CSS-ből egy elemnek megadunk vagy háttérszínt, vagy betűszínt, adjuk meg a másikat is, különben előfordulhat, hogy a felhasználó CSS-e felülbírálja a színeket, és az összhatás olvashatatlan lesz számára.

20. Űrlapok választási lehetőségei

Amennyiben az űrlapoknál választható elemek esetén kevés opció van, akkor listaszerűen (több soros lista, vagy rádio gombos megjelenéssel), ellenkező esetben pedig egysoros select-tel (combobox, lenyíló menü) jelenjen meg (utóbbi esetben csak az aktuális, ellenkező esetben pedig az összes lehetőség felolvasásra kerül a felolvasószoftverek által). Ez az átlag felhasználó számára is átláthatóbb megjelenést eredményez.

Ez a gyakorlatban azt jelenti, hogy egy rövidebb lista esetén az űrlap átláthatóságát jelentősen növeli, ha látható az összes választási lehetőség, és nem kell minden ilyen esetben rákattintani a select elemre és így elolvasni a lehetőségeket. Ha hosszabb listáról van szó, akkor a helykímélés, és a kérdések áttekinthetősége miatt ajánlatos a legördülő menüs megoldás.

Nagyon sok elemet ne tegyünk egy listába, hacsak nem intranet oldalról van szó, hiszen ezzel jelentősen megnőhet az oldal mérete is. Előtte végezzünk egy szűkítést, és csak a szükséges lehetőségeket küldjük el. A nagy lista a mérettől függetlenül is áttekinthetetlen, kezelhetetlen lehet.

21. Mindig a megfelelő elemet

Listázáshoz, tördeléshez, behúzáshoz az oldalban a megfelelő HTML elemeket használjuk, ne szóközöket, képeket, egymásba ágyazott táblázatokat. A felolvasószoftverek képesek ezeket jelezni a nem látó felhasználó számára, míg egy kép funkcióját képtelenek kitalálni (rossz esetben felolvassák, hogy ott kép van, értelmezhetetlen szöveget okozva). Erről is volt már szó részben (ne használjunk távtartó képeket), de ez is egy olyan fontos szempont, melyről nem árt, ha többször, több oldalról megvizsgálva is szó esik.

Miről is van szó? Ha egy szöveghez címsort írunk, használjuk valamelyik h? elemet, ha listaszerű tartalmat (menü, navigáció más elemei, stb.), akkor lista elemeket, stb. Ezeket aztán CSS segítségével elég szabadon átformázhatjuk - számos dokumentum szól erről a neten. Ez a megoldás sokkal jobban áttekinthetőbbé teszi a forrást, továbbá a keresők is jobban tudnak súlyozni az oldal tartalmán belül, tehát ha így járunk el, a keresőkben is sokkal jobb eredményeket érhetünk el. Ezen kívül a "helyes elemet használjunk" filozófia megfelelő alkalmazása az oldal későbbi átszervezését, az egységes oldalkialakítást is egyszerűbbé teszi.

22. Designt ne karakterrel valósítsunk meg

Formázáshoz, díszítéshez karakteres szöveget (pl. >>) ne használjunk, a szövegesen nem megjeleníthető megoldások használata az ajánlott (entity-k segítségével dupla jobbra nyíl, kis pont, stb.) Így a felolvasó szoftvereknek nem kell megküzdeniük például "nagyobb, nagyobb" jelet felolvasva, illetve ezeknek a karaktereknek a megjelenése is szebb tud lenni. A legcélszerűbb az ilyen formázóelemket grafikával (de nem képpel!) megvalósítani, például az adott elemhez nem ismétlődő háttérkép beállításával.

23. Navigációs elemek helyzete

A navigációs elemek lehetőségei szöveges böngészőkben felsorolásszerűen és ne egymás mellett jelenjenek meg, mivel a felolvasó szoftverek hibái miatt az összes lehetőség felolvasásra kerülhet, úgy, hogy nincs jelölve, melyiken áll éppen a felhasználó. Ennek az irányelvnek kifejezett célja, hogy a felolvasószoftverek támogatottak legyenek.

A lehetséges megoldás a listákkal történő kivitelezés, melyet utána CSS segítségével formázunk át, a designhoz illeszkedve.

24. Csak az aktuális almenüpontok

Az oldal aktuális almenüpontjai jelenjenek csak meg, ne az összes lehetséges (különben minden felolvasásra kerül). Ez grafikus böngészés esetén nem biztos, hogy zavaró, de egy felolvasószoftverrel böngésző számára igen. Ha a választási lehetőségek számát csökkentjük, a többi felhasználó számára is egyértelműbb navigációt nyújthatunk, ami az oldal általános használhatóságát növeli.

Ezt nem egyszerű kivitelezni, illetve van, amikor tényleg ki szeretnénk tenni az összes lehetőséget, hiszen minél egyszerűbb navigációt szeretnénk biztosítani a látogatónak. Mérlegeljünk, hogy mi lesz a jobb, s ennek fényében járjunk el. Ha szemantikailag helyesen oldjuk meg a problémát, azaz megfelelő HTML elemeket használunk, az már segítség lehet egy felolvasószoftver számára.

25. Átméretezhető betűk

Az oldal betűinek mérete átméretezhető legyen egy felhasználó által megadott CSS segítségével, azaz ne konkrét pixelméretek legyenek megadva (hanem százalékosan, vagy pedig em segítségével történjen a definiálása a méretnek).

Ez nem csak azt jelenti, hogy biztosítsunk átméretezési lehetőséget a felhasználónak például JavaScript segítségével, hanem azt is, hogy megfelelő felhasználói CSS segítségével a felhasználó is egyszerűen, a body elemnek nagyobb betűméretet adva át tudja méretezni az oldal összes szövegét.

Ha az irányelv szerint járunk el, egy JavaScriptet átméretezés megvalósítása is elég egyszerűen megvalósítható lesz a későbbiekben. Erre egy nagyszerű példa a Weblabor megoldása.

26. Jól olvasható betűket használjunk

A weblap szövegei gyengénlátók számára is olvasható betűkészlettel (pl. Arial) jelenjenek meg. A design elemek és a szépség nem lehet a használhatóság és áttekinthetőség kárára. Egy rosszul megválasztott betűkészlet mindenki számára zavaró lehet, és ronthatja a tartalom befogadásának hatékonyságát. Ez nem csak a valódi szöveges tartalomra, hanem a grafikákban használt betűkre is érvényes. Ne használjunk túldíszített, rosszul elkészített karakterkészleteket, ha nem muszáj!

27. Navigáció és tartalom aránya

A tartalmi rész előtt levő szöveg ne legyen túl nagy, mert minden oldalon felolvasásra kerül, amit rendkívül zavaró lehet mindig végigolvasni, vagy egyszerűen csak akár átugorni rajta. A letöltendő oldal méretét is növeli, ha minden oldalon minden lehetőséget kiteszünk. Sokszor egy link elég, amivel visszajuthatunk egy előző oldalra.

Ha ez nem megvalósítható, akkor próbáljuk meg azt, hogy maga a menüszerkezet a dokumentum végére kerül, és CSS segítségével kerül a végső helyére. Így a vak felhasználóknak sem kell minden oldalon átvágniuk a menükön és egyéb tartalmakon.

Ennek megvalósítása nem kifejezetten egyszerű, viszont sokat segíthet. Egyes felolvasószoftverek képesek a header elemeken végigugrálni, így ha az oldalunk tartalmának címe (azaz egy cikk címe például) header elemmel jelenik meg, gyorsabban el tudnak jutni rá a nem látó felhasználók, ezzel megoldva a navigációs rész átugrásának problematikáját.

28. HTML forrás

Az oldal szövegei értelmezhető blokkokra legyenek tördelve, azaz ha beszúrunk egy képet egy paragrafusba, akkor próbáljuk meg nem a bekezdés közepén, egy szót kettválasztva beszúrni a balra vagy jobbra illesztett képet, hanem ezt a bekezdés elejére helyezni.

Ezen a ponton sokat nem lehet magyarázni, egyszerűen arról van szó, hogy ne vágjunk szét egy szót, mondatot valamilyen látványelemmel, mert akkor azt a felolvasó szoftver, vagy karakteres böngésző is széttörve fogja megjeleníteni. Ilyen akkor fordulhat elő, ha egy szöveg vizuális szerkesztővel van összeállítva, és nem látjuk a forrást, véletlenül egy szó közepére szúrjuk be az adott (float-olt) elemet.

29. Elérhető formátumok

Az esélyegyenlőség kapcsán, a letölthető állományok ne egy konkrét cég saját formátumában, hanem általános, kicsit konkrétabban nyílt forrású eszközökkel, minél több operációs rendszer, felhasználói program által elérhető, megjeleníthető formátumban legyenek közzétéve. A legjobb erre a célra szöveges, nem megváltoztatandó dokumentumok esetén a PDF formátum, melyhez minden operációs rendszerre érhetőek el ingyenesen megjelenítők. Olyan dokumentumoknál, melyeket meg kell változtatni, szöveg esetén érdemes az RTF formátumot használni, vagy pedig mind a DOC, mind az SXW (XML alapú, OpenOffice.org szövegszerkesztő formátum, mely szintén minden operációs rendszer alatt, ingyenesen elérhető) használata (kitehetünk csak DOC formát is, de győződjünk meg róla, hogy egy OpenOffice értelmezni tudja jól) kínálhat megoldást. Más esetekben, formátumoknál is hasonlóan, minden platform és rendszer számára olvashatóan, használhatóan kell közzétenni a közzéteendőket.

30. Képek vs. képcsere technológiák

A képcsere technológiák lehetővé teszik, hogy a dokumentumba valódi kép elem beszúrása nélkül megjelenítsünk valamilyen grafikát. Ezt a megoldást ne használjuk olyan képek esetén, melyek a tartalomhoz tartoznak, viszont használjuk akkor, ha a grafika a design részét képezi!

Ez az irányelv nem csak a különböző felolvasószoftverek, oldalunkat látogató programok számára teszi könnyebben feldolgozhatóvá a tartalmat, de praktikus megoldást is nyújt, egy szerkesztőségi rendszerből érkező képet általában sokkal nehezebb különböző képcsere eljárásokkal megjeleníteni egy sima képhez képest. Általában, ha egy kép a szerkesztőségi rendszerből érkezik, elmondható, hogy az a tartalom részét képezi, s képként szúrandó be az oldal forrásába.

Összefoglalás

Természetesen a fenti harmincas lista nem teljes, nem lehet teljes abból a szempontból, hogy minden olyan gondolatot összefoglal, melyet az embernek célszerű használnia egy oldal kialakításakor, de talán elég sok javaslatot tartalmaz, mely sokak számára hasznos lehet.

A bevezetőben is említettem, a WFSZ keretében szeretnénk "hivatalos" irányelveket összegyűjteni a magyar webfejlesztők számára. Ez, ha sohasem lesz valóban hivatalos ajánlás, akkor is egy jó hivatkozási alap lehet bárki számára, aki webfejlesztő, s segítséget nyújthat azoknak, akik szeretnének valaki meggyőzni az egyes pontok helyességéről, ha más nem, lehet arra hivatkozni, hogy egy ezzel hivatalosan is foglalkozó szervezet is ilyen és ilyen megoldásokat ajánl. Ennek kapcsán kérjük olvasóinkat, véleményezzék a fenti irányelveket, bármilyen észrevételük, javaslatuk, kiegészítenivalójuk van, tegyék meg, s igyekszünk azt a végleges ajánlás részévé tenni.