ugrás a tartalomhoz

Irányelvek webfejlesztőknek

Bártházi András · 2005. Május. 15. (V), 21.00
Irányelvek webfejlesztőknek
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:

<label for="id_keresztnev">Keresztnév</label>
<input type="text" name="keresztnev" id="id_keresztnev" />
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.
 
Bártházi András arcképe
Bártházi András
Az Emarsys-nál dolgozik vezető fejlesztőként, és az API-ért, integrációkért felelős termékmenedzserként. Szeret profi csapatban profit alkotni.
1

Hozzáfűzések...

kgyt · 2005. Május. 16. (H), 04.48
Örülök a fenti dokumentumnak.

3. pont:
Szerintem ne üres legyen az alt, hanem legyen benne egy nemtörhető szóköz (nbsp), mert karakteres felületen zavaró lehet, ha az általa képezett űr eltűnik.
A szóközt a vakok programjai sem olvassák fel, és a kód is jobban igazodik a nemzetközileg elfogadott akadálymentességi normákhoz.

6. pont:
Külön kihangsúlyozandó, hogy az akadálymentességnek a leges-legfontosabb alapeleme a szabványos kód használata. Ha nincs szabványos kód, az akadálymentesség nem jöhet létre.

7. pont:
A felolvasószoftverek nem minden esetben karakteres felületűek, ám a grafikus felületű felolvasók (mint például az Internet Explorert előszeretettel használó JAWS) is az alt alapján teszik láthatóvá a képeket a vak látogatók számára.

10. pont:
A zavaró elemek, és itt főként a villogásra gondolok, egyes felhasználókból epilepsziás rohamot is kiválthatnak. Akadálymentes oldalon tilos a blink használata!

16. pont:
Nem mellesleg ezzel segítünk az oldalunkat indexelő robotoknak is...

19. pont:
A háttérkép, ha ismétlődik, legyen nagyobb, mint 16x16 pixel, mert egyes asszisztív technológiáknál a kisebb méretű kép replikálásakor memóriaproblémák adódhatnak. Egy ilyen eseményt reprodukálhatóan elő lehet idézni a JAWS képernyőolvasó esetén például.

23. pont:
Ez azért jó, mert a felolvasószoftverek képesek az oldalt soronként is felolvasni, például a hardveres felolvasók egy lynx-et használva ideális felületet adnak a soronként egy link esetén.

26. pont:
Elvileg szabványos flashmentes oldalakon nincs nagy lehetőség a betűtípusok választására, hiszen korlátozott számban állnak rendelkezésre a karakterkészletek. Célszerű a generic type megadása. Ne keverjük a típusokat, legyen egységes az oldalunkon használt fontkészlet (Pl. sans-serif a szöveg, serif a címsor, mint a Weblabor oldalain).

29. pont:
Célszerű a PDF dokumentumok mellé is egy sima szöveges átírat csatolása, ha netalán nem képes egy felhaználó a PDF kezelésére.

+
Érdemes lenne a közhasznú és közszolgálatot ellátó oldalak számára előírásként meghatározni a W3C WCAG minimum dupla A szintjének való megfelelést.
Ezt más civilizált államokhoz hasonlóan (Nagy-Britannia, Németország, Egyesült Államok stb.) törvényi szinten garantálni kellene.

Akár a Weblaboron, akár a WFSZ oldalán, akár egy magánoldalon, de kezdjük el szimpatizánsok toborzását egy petíció létrehozásához, amelyben felszólítjuk az illetékeseket egy az esélyegyenlőséget és a minőséget szemelött tartó, a közpénzen készült weboldalakat szabályozó törvény meghozására.


--
Szeretettel: Károly György Tamás
kgyt&kgyt.hu - http://kgyt.hu
59

Vak-Web

Anonymous · 2006. Ápr. 3. (H), 14.10
Nagyon örülök, hogy manapság, már szinte minden középületi lépcső mellet van rokkantkocsi feljáró is. TÉNYLEG oda kell figyelnünk azokra, akiknek valami miatt gyengébbek a lehetőségeik.
De ne haragodjatok már, hogy a webet vakokra optimalizáljuk?
Arra gondoltam, hogy akkor már csinálhatnánk egy rádiót a süketeknek, nyárom meg a balatonon bandzsidszampingot rokkantaknak. Meg vizisít.
Van egy szobrász barátom. (www.gregorgall.com) A felesége zongaraművész. Ők is kitalálhatnának mindenféle új irányzatot. Szimfóniák Beethoven követőinek, szobrokat a sem látni, sem tapintani nem képeseknek,...
Hát csak hajrá. Én inkább -elnézést érte, minden gyengénlátónak- látókra optimalizálom a dizájnokat.
ÜDV: Oláh Sándor
www.0-8.biz
60

annyi baj legyen

Táskai Zsolt · 2006. Ápr. 3. (H), 14.38
hát a három dimenziós világban esetlenebbül mozgó, türelmetlen embertársakkal körülvett fogyatékkal élők otthonuk védelmében nem a te oldalaiddal fogják eltölteni idejüket, fejleszteni tudásukat, intézni ügyeiket, stb...
nem biztos, hogy ettől szegényebbek lesznek... de LEHET!
jó munkát,
Tasi
(hadd tegyem hozzá, én megütköztem a hozzászóláson)
61

Akadálymentesség != vakokra optimalizálás

pp · 2006. Ápr. 3. (H), 19.38
...bandzsidszampingot rokkantaknak.


Én amióta láttam paraolimpiai közvetítéseket, nem tudok ilyen kijelentéseket tenni, javaslom neked is egy-egy ilyen megtekintését valószínűleg megváltozik ez a sarkos véleményed.

Félreértesz valamit (kgyt kicsit agresszív ebben a témában)
Az akadálymentes oldal készítése azt jelenti, hogy oldalaidat vakok és gyengénlátók is meg tudják nézni. (no meg azok, akik mondjuk képek nélkül, css nem ismerő böngészővel, esetleg mobiltelefonnal, vagy kéziszámítógéppel interneteznek)

Tehát nem a vakokra optimalizálsz, hanem gondolsz rájuk is és azokat a minimális szabályokat betartod amik az akadálymentes oldalak készítéséhez kellenek.

pp
62

feljaro

Jano · 2006. Ápr. 3. (H), 22.39
En mondjuk inkabb azon gondolkodnek el, hogy az hogy minden kozepulet minden lepcsojehezz liftet kell epiteni, vagy a teljes elektronikus ugyinzetes megvalositasa kerulne-e kevesebb penzbe. Es ugye akkor nem csak a mozgaskorlatozottaknak nem kene kimozdulni otthonukbol, de neked vagy nekem se.

Egy rampa a mozgaskorlatozottak mellett a babakocsit tolo kismamanak, a biciklisnek, vagy egy idosebb embernek is konyitheti az eletet. Egy vakok igenyeit figyelembe vevo oldallal hasonlo a helyzet. Pl amit vakok el tudnak olvasi, el tudnak erni azt a Google is!

"Optimalizalni" senki se a vakokra fog, hanem a legnagyobb bevetelt jelento celkozonsegere. Vakbarat oldalt kulon nem kell csinalni, csak figyelni kell, hogy olyan technikat ne alkalmazz amivel nem tudnak megbirkozni. Egy alap HTML oldal ami alap szemantikus elemekkel fel van epitve abszolut vakbarat es keresobarat es elerheto es cross-browser. Ezutan mar csak rontasz rajta. Meg kell talalni azokat a technikakat amik a legkisebbet rontjak rajta. Mert igen ott vannak meg mas szempontok: dizajn, felhasznalobaratsag, eloirt funkciok...
2

Kiegészítések

Jano · 2005. Május. 16. (H), 11.11
Nagyon jó kis összefoglaló cikk, remélem lesz türelme sokaknak végig olvasni!
Jó lett volna az egyes pontoknál kódot, olyan linkeket beszúrni ahol megmutatják a megoldást (mégha csak angolul is).

1. Flash kezdőlap ha megis használjuk akkor:
  • A "GRNK" vagy Villám választás neked mond valamit? Egy nem hozzáértő se fogja tudni, hogy mi az a HTML és Flash! (GRNK a HTML betűktől egyel balra levő billentyűk:)
  • Legyen egy pici Flash mozi elhelyezve az ilyen választó vagy csak sima belép oldalon ami detektálja ha van megfelelő verziójú Flash a gépen!
  • A Skip animation stb link magyarul legyen és ne csak akkor jelenjen meg amikor már betöltődött a mozi!
  • Mindig legyen betöltés számláló ami szintén nem az angol loading...
  • Ne ismétlődjön az animáció. Ha véget ért akkor automatikusan lépjen be vagy jelenjen meg egy egyértelmű link, hogy most már a felhasználónak kell cselekednie mert véget ért a mozi!


2. Framek emulálása CSS-sel:
Fixed positioning

4. Kliens oldali image map-ek CSS-sel átalakított listával is megoldhatók:
CSS sprite-ok: Halálcsók a képdarabolásnak

8. Ha pdf-et linkelünk akkor azt mindig jelöljük és ne tegyünk SOHA az oldal menüjébe olyan menüpontot ami egyből egy PDF dokumentumot nyit!

9. Navigáció
Ha lehulló/kibomló menüket alkalmazunk akkor jelöljük egy kis nyillal, hogy az a menüpont almenüpontokat tartalmaz! (Nézd meg a Start menüben is egy kis jobbra nyil mutatja ahol almenük vannak!) Ez föleg akkor fontos, ha nem minden menüpontnak van almenüje, ilyenkor a felhasználó elbizonytalanodik, hogy nem jó helyre vitte a kurzort, töltődik, nem működik vagy mi történt, miért nem nyílik le a menü.)

11. Menüknél vagy máshol ha azt szeretnénk, hogy ne csak a link szövege hanem egy téglalap alakú területen körülötte is megváltozzon a háttérszín akkor ne Javascriptet használjunk erre! A CSS display:block tulajdonságot alkalmazzuk!

18. Weben az aláhuzás csak linket jelölhet! Egy word dokumentumot ha kapunk, hogy tegyük fel és abban egyes címek alá vannak húzva akkor ott találjunk más jelölést! Más szín, betűméret, dőlt, kis diszítő ábra bármi...

Ami link az legyen tényleg link vagyis az "a" elemmel jelölt! Ha máshogy csináljuk akkor sokminden megszokott dolog nem fog működni a böngészőben! Pl Firefox-ban középső gombra új lapra nyitás, nem lehet a link célját a "helyzeti" menüből kimásolni, lementeni, betenni könyvjelzőnek, stb.

19. Ha megadunk háttérképet akkor színben hozzá hasonló háttérszínt is adjunk meg, külöben előfordulhat, hogy amíg nem jött le a háttérkép nem tudjuk elolvasni a szöveget!

22. Menü elválasztó vonal CSS-sel
3

Tovább...

kgyt · 2005. Május. 16. (H), 13.00
Ha pdf-et linkelünk akkor azt mindig jelöljük és ne tegyünk SOHA az oldal menüjébe olyan menüpontot ami egyből egy PDF dokumentumot nyit!

Mondjuk szerintem ezt e-mail címekre is alkalmazni kellene.
Ha a menüből az e-mail küldésre megyünk, akkor legyen egy oldal, ahol az e-mail cím megtalálható, vagy egy e-mail küldő űrlap.
Ha lehulló/kibomló menüket alkalmazunk...

Ám, ha csak tehetjük, kerüljük a lehulló menük használatát!
Weben az aláhuzás csak linket jelölhet!

Ezt duplán aláhúznám. Nagyon fontos. Maximálisan támogatom.
Ami link az legyen tényleg link vagyis az "a" elemmel jelölt!

Szvsz kiegyezem azzal is, ha űrlap elküldőgombja alkot egy linket, egyes speciális esetekben, ahol például dinamikus adatátadást is szeretnénk POST metódussal... (És nem egy tipikus űrlap esetéről beszélek, hanem egy css-sel linkszerűvé formázott submitgombról...)
Az Opera lehetőséget nyújt a link elemek megjelenítésére is. Ezt sem tartom rossz megoldásnak egyes speciális esetekben.
Végül, ha muszáj, nyugodtan alkalmazzunk kliens oldali térképet egy bonyolult képen (pl. Európa atlasz), de minden area legyen kellőképpen felparaméterezve.
Ha megadunk háttérképet akkor színben hozzá hasonló háttérszínt is adjunk meg...

Ez képek nélküli nézetben is fontos, hiszen így az oldal olvasható marad.
Javaslom, hogy a stílusdefinícióknál a WCAG 1.0 ajánlásnak megfelelően mindig legyen a background definiálása mellett a color is definiálva (és fordítva), és a background (ha megadjuk) mindig tartalmazzon háttérszínt (átlátszóság esetén a transparent meghatározást).


--
Szeretettel: Károly György Tamás
kgyt&kgyt.hu - http://kgyt.hu
4

gomb vs link

Jano · 2005. Május. 16. (H), 13.49
Az urlap gombjat en nem tekintem linknek. Az egy gomb, egy mas tipusu interakcios elem. Amire gondoltam, hogy ne onclick es hasonlo javascriptes megoldasokkal legyen megoldva a kovetkezo oldalra jutas (lasd pl startlap nyito oldal).
5

Re: gomb vs link

kgyt · 2005. Május. 16. (H), 13.58
Tudom, hogy mire gondoltál és egyetértek, csupán kiegészítettelek.
A gomb is funkcionálhat linkként bizonyos esetekben szvsz.

--
Szeretettel: Károly György Tamás
kgyt&kgyt.hu - http://kgyt.hu
8

Lehulló menük

aries · 2005. Május. 17. (K), 13.29
Ám, ha csak tehetjük, kerüljük a lehulló menük használatát!


Mi a gond a lehulló menükkel? Sok esetben gyorsítja a navigációt - feltéve, hogy elegendően széles menüpontok vannak, és a mutató nem csúszik el akaratunk ellenére. A JavaScript hiányát pedig könnyű detektálni.
--
Aries
9

re: lehulló menük

Anonymous · 2005. Május. 17. (K), 13.42
Csupán az a gond a lehulló menükkel, hogy sokak számára használhatatlanok (pl: látás és mozgássérült emberek). Nekik kifejezetten lassitja, sőt akár lehetetlenné is teszi a navigációt. Akadálymentes oldalon elfogadhatatlan szerintem a lehulló menü, ha nincs alternatív elérése.
10

elfelejtettem bejelentkezni

kmm · 2005. Május. 17. (K), 13.44
--
üdv: kmm...
12

Miért ne lenne alternatív elérése?

aries · 2005. Május. 19. (Cs), 08.01
Term. kell(ene) lennie alternatív elérésnek, DE ettől még, egy ilyen hasznos funkciót nem kellene kigyomlálni, hanem alternatívát adni.
--
Aries
11

lehulló menü

kgyt · 2005. Május. 17. (K), 19.39
Próbáld meg a lehulló menüket egér nélkül használni... Például.

--
Szeretettel: Károly György Tamás
kgyt&kgyt.hu - http://kgyt.hu
13

Térbeli navigáció

attlad · 2005. Május. 19. (Cs), 10.58
Spatial Navigation-nak hívják azt a feature-t, amikor nem csak a tabbal lineárisan linkről-linkre haladva lehet végigmenni az oldalon, hanem a kurzor billentyűkkel lehet mind a négy irányba haladni és mindig a legközelebbi linkre kerül a fókusz. Operában ez CTRL+kurzor, bár ez gondolom neked nem újdonság. :-)

Firefox 1.1-ben is benne lesz ez, ha a lehulló menü almenüi nem csak a :hover eseményre, hanem a :focus-ra is megjelennének, akkor egész szépen lehetne ezt itt is használni, kb. ugyanolyan jól lehetne navigálni a kurzorral le/fel/jobbra/balra egy többszintű CSS menüben, mint rendes/nem weboldalon lévő menükben.

Persze a gyakorlatban ez nem működik, mert nem támogatják a böngészők, karakteres böngészők meg megint máshogy működnek, az a baj, hogy elég sok hiányuk van a böngészőknek, sokkal jobban használhatók is lehetnének..

Attila
14

itt egy példa

Jano · 2005. Május. 19. (Cs), 12.01
Itt található egy szépen megoldott példa elérhető, billentyűzettel is kezelhető menüre:
Accessible contents menu
6

kérdések és megjegyzések

warchief · 2005. Május. 16. (H), 18.31
nagyon örülök, hogy végre megjelent egy összefoglaló jellegű cikk a témában. csak csatlakozni tudok az elöttem szólókhoz, mind flash-, mind linkügyben.
1. Az űrlapok tervezéséhez azonban feltétlenül hozzátenném, hogy a fent leírtakon kívül a vizuális konzisztenciára is ügyeljünk, ugyanis az űrlapok megértését nagyban megkönnyíti a logikusan kialakított űrlapok használata. egy egyszerű példán keresztül talán érthetőbb, mire gondolok: http://www.lukew.com/resources/articles/web_forms.html

2. a táblázatok (rövid összefoglaló) és képek (ne törjünk szét sorokat, szavakat, bekezdéseket) használatára vonatkozó irányelvek már inkább a szerzők, az oldalt használók dolga - lenne -, mint az oldalt építő vagy tervező szakemberé, bár lehet, hogy tévedek.

Remélem hozzászólásaimat építő jellegűnek találják. További jó munkát!
7

Nem minden esetben a szerző

tiny · 2005. Május. 16. (H), 19.41
Nem minden esetben a szerző dolga, s lehet olyan is, hogy a webmester egyben a szerző is. Én örülök ennek a cikknek, meg így azt még senki sem fogalmazta meg, hogy attól, hogy nekünk tetszik valami, az nem biztos, hogy szép. És fontos, hogy kisebbtől is el lehet fogadni a tanácsot, de legalább fontoljuk meg. Egy idősebb barátom sosem hallgat rám a weboldalával kapcsolatban, pedig szörnyű ergonómiai szempontból. Aki ezt elolvasta, remélem nem lesz ilyen, s nekem is nagyon sokat segített. Érdekes, kimeríthetetlen téma, újabb érdekes cikk. Köszönet érte. (Már megint sokat írtam... :) )
Mr.Tiny
15

WFSZ doksi

Bártházi András · 2005. Május. 19. (Cs), 12.15
Köszönöm mindenkinek a hozzászólását, ezek be lesznek építve a készülő doksiba, aminek a kiadását minimum két-három hónap múlvára tervezzük. Aki szeretne akár aktívan, akár passzívan részt venni a dokumentáció elkészültében, kérem jelezze nekem e-mailben. Úgy tűnik, hogy a legcélszerűbb egy levelezőlista indítása lesz, ahol az ajánlást közösen kidolgozhatjuk.

-boogie-
16

Pár kérdés

Anonymous · 2005. Május. 19. (Cs), 13.27
Nem olyan régen kezdtem el készíteni egy honlapot, amelyen kísérletezés végett kipróbáltam ezeket az új dolgokat is.

Az oldal fejlécében egy képet akartam megjeleníteni, viszont azt szerettem volna, hogy akkor is legyen ott a neki megfelelő szintű fejléc, amikor pl Firefoxban kikapcsolom a stílus megjelenítését. Ezt úgy oldottam meg, hogy létrehoztam egy hide osztályt CSS-ben (display: none) és ezt adtam meg minden olyan elemnek, amit el kívántam rejteni a "normál" nézetben, és meg kívántam jeleníteni alap nézetben. Főleg hr tagokra és hx tagokra használtam, amivel az oldal szerkezetét próbáltam tagolni. Az ötlet nem teljesen saját, egy css szerkezetekkel foglalkzozó oldalon találtam.
A fejlécben található képet viszont egy div-ben helyeztem el, és ennek adtam háttérképet. Nem növeli túlzottan a HTML kódot, viszont szerintem megéri.

Egy hátránya van: ha csak a képek letöltése van kikapcsolva nem jelenik meg semmi, viszont jól használható hr tagok elrejtésére.

Várom a véleményeteket a módszerről.

#30 Képek vs képcsere: A tutorial.hu -n találtam egy css rollover megoldást. Szerintem érdemes megfogadni. (Lényege, hogy nem külön képekben tároljuk az "aktív" és a "normál" állapotokat, hanem egyben egymás alatt - eleve kevesebb szerverkérés - és :hover esetén background-position -nal eltoljuk. Ügyes trükk, nem kell hozzá javascript, valamint kevesebb kód is.

- sauxs -
17

IR vagyis SZöCSKe

Jano · 2005. Május. 19. (Cs), 14.22
Az image replacement vagyis kep csere, kep helyettesites vagy nevezzuk SZÖveg CSeréje KéprE röviden SZÖCSKE? (ezt most talaltam ki :) technikák közül én az itt is leírt technikát használom és javaslom. Ugyan ebben az esetben van egy felesleges span elem is, de az ominozus képek kikapcsolva, stilus bekapcsolva esetben is működik. (A display:none-nál már a felolvasó programok is elhasalnak, úgy veszik mintha nem lenne ott az adott elem!)
Accessible Header Images With CSS And XHTML (Elérhető fejléc képek CSS és XHTML-lel)
18

Sőt...

kgyt · 2005. Május. 20. (P), 02.29
Az újabbak már css-t is értelmeznek, komolyabban...

--
Szeretettel: Károly György Tamás
kgyt&kgyt.hu - http://kgyt.hu
19

komolyabban?

Őry Máté · 2005. Május. 20. (P), 16.54
Mire gondolsz? A különböző hangszíneket, sebességeket, megállásokat, ismétlések számát és ilyesmiket szabályozó css21 és css3 beállításokra?
kérdés: a felolvasók a screen mediatypeot használják?
Maat
20

Példa...

kgyt · 2005. Május. 20. (P), 23.17
Torma Zsolt kolléga majd kiegészít (ha akar)...
A JAWS például kezeli a CSS-ben beállított display:none értéket,
a szövegek attribútumait, mint például szín, méret,
lista stílusokat (arab, római, bigyózott stb.)...
A JAWS talán a 4.51 óta tudja kezelni a CSS-t (most a 6-os verzió aktuális).

Kiegészítés:
A vakok leginkább Internet Explorerrel, vagy Webformatorral böngésznek,
ez utóbbi talán egy IE patch, épp most tervezem megvizsgálását...


--
Szeretettel: Károly György Tamás
kgyt&kgyt.hu - http://kgyt.hu
21

szabvány

Jano · 2005. Május. 21. (Szo), 12.14
A szabvány szerint a média típussal meghatározható, hogy melyik eszköz melyik CSS fájlt vegye figyelembe. Ezek közül a legismertebb a nyomtatható változat a "print". A hagyományos képernyős megjelenetéshez (screen), ezenkívül van még kézi számítógépek számára (handheld) és felolvasó programoknak (aural).

Hogy pontosan melyik program mit vesz figyelembe azt nem tudom.
22

WFSZ-hez

Anonymous · 2005. Május. 23. (H), 09.14
Köszönöm!

Remek gondolatok!

Én a következőkkel egészíteném ki:

Mindeképpen külön választanám az ajánlások témakörét:
pl. - akadalymentesweb;
- Flash
- Javascript
- PHP
- stb.
Szerintem az általános elvek lehet, hogy ütik egymást a különböző témákban!

Szükségesnek érzem /eddig nem gondoltam rá:(/, hogy minden oldalnak készüljön el az akadálymentes változata is! Ehhez persze ismerni kellene azokat a progikat amik felolvassák az oldalt!

Minden oldalt úgy kellene kezdeni, hogy felismeri a lehetőségeket (pl.telepítve van-e a flash lejátszó.) illetve alternatív tovább-lépésekkel.

Zárásként egy gondolat. Sajna akit csak a profit érdekel annak mondhatjuk, hogy mit veszit, ha azt látja, hogy a profit viszont nem ez hozza:(
23

Re: WFSZ-hez

kgyt · 2005. Május. 23. (H), 11.21
minden oldalnak készüljön el az akadálymentes változata is!

Ne készüljön el...
Az érintettek közül nagyon sokan kirekesztőnek, gettósításnak tartják a külön akadálymentes változatot.
Egyébként sem célszerű, mert dupla munka.
Legyen az alap oldal akadálymentes!
Ehhez persze ismerni kellene azokat a progikat amik felolvassák az oldalt!

A JAWS letölthető, de csak Windows alatt használható. 40 percig beszél, majd a gép újraindításáig csendben van. Újraindítás utá ismét használható 40 percig (akárhányszori alkalommal).
Az akadálymentesség nem csak a vakokról szól!
Vannak siketek, mozgáskorlátozottak, értelmi fogyatékosok, epilepsziások és más fogyatékkal élők is...
telepítve van-e a flash lejátszó

Az akadálymetes szemlélet szerint a flash nem megengedhető pl.
Ha van flash, akkor annak teljes értékű megfelelőjét is biztosítani kell...
Sajna akit csak a profit érdekel...

Az akadálymentes weboldalak hosszú távon komolyabb (anyagi) profitot termelnek, mint a nem akadélymentesek.
Az akadálymentes weboldalak rövid távú extra-profitja nem mérhető anyagi, dologi profithoz, mert erkölcsi.


--
Szeretettel: Károly György Tamás
kgyt&kgyt.hu - http://kgyt.hu
24

Meggyőzni valaki nem lehet úgy, hogy nem akarod meggyőzni...

pp · 2005. Május. 23. (H), 20.48
Az akadálymentes weboldalak hosszú távon komolyabb (anyagi) profitot termelnek, mint a nem akadálymentesek.


Ilyen, mindenfajta alapot nélkülöző bődületesen hatás vadász általánosításokkal szerintem nem hogy elősegítenéd, hanem inkább hátráltatod azt amiért harcolsz. Na nehogy már a webprogramozó/dizájner mondja el a managernek, hogy mi hozza a profitot. Lehet, hogy én nem látom az erdőt, de mondd már el nekem, hogy egy autó kereskedőnek milyen komolyabb haszna származik abból, hogy látássérültek is el tudják olvasni az oldalát? Te hány vak autó tulajdonost ismersz? Nem kirekeszteni akarok, ez van.
Szerintem avval nem lehet meggyőzni egy mai managert, hogy azért legyen akadálymentes az üzleti weboldala, hogy "pár vak ember is elolvashassa". Érveidre maximum annyi választ kapsz majd:
- És akkor most kedves György engedje meg, hogy elmorzsoljak egy könnycseppet itt a szemem sarkában. Akkor holnapra ugye kész lesz az a flash-es animációs oldal amit kértünk, mert ugye a konkurenciának is olyan van.

Szerintem többre mennél, ha elmondanád azt, hogy ha akadálymentes lesz a weboldalad, akkor a sok-sok mobiltelefonos XHTML-es böngésző is meg fogja jeleníteni a tartalmat, meg a managerek is kényelmesen olvashatják a palmtopjukon.
Ettől függetlenül neked nem kell így gondolnod. Te csinálhatod azért az akadálymentes oldalakat, hogy azok is megnézhessék aki egyébként nem tehetnék ezt.

Az akadálymentes weboldalak rövid távú extra-profitja nem mérhető anyagi, dologi profithoz, mert erkölcsi.

Ezt a mondatodat nem értem;))

Szerintem amiért harcolni kell és érdemes, az az, hogy a mindenki számára szóló oldalak akadálymentesek legyenek. pl a köz pénzekből(tehát minden magyar állampolgár pénzéből) létrehozott köz szolgálati oldalak, a hír oldalak, stb.
A profitra dolgozó cégek csak akkor fognak foglalkozni a kérdéssel, ha ez nekik megéri. Ezért haragudni rájuk nem érdemes. Én se mérgelődöm azon, hogy a közértes drágán adja a kiflit, vagy lejárt sört próbál rám tukmálni. Elmegyek egy másik boltba, és kész.


pp
25

akadalymentesseg nem egyenlo vakok

Jano · 2005. Május. 23. (H), 21.51
Ezt mar kifejtettem nehanyszor! Akadalymenetesseg nem a (teljesen) vakokat jelenti hanem nagyon sok mindenkit erint! NEm csak a szelsoseget kell nezni!

Egyebkent a legelso szempont, hogy a Google is hasonlithato egy vak emberhez! NEm tudja indexelni a flash-t, nem tudja felimerni a kepeken a betuket, nem tud javascriptet ertelmezni stb!

Egy uzleti oldalon ha csak nehany % az a latogato aki otthagyja, akkor lehet pont az a nehany %-nyi bevetel kieses lesz az ami nem hozza meg a nyereseget!

A statisztikak szerint 10% nezelodik javascript nelkul! Ha egy managernek azt mondod, hogy akkor mi most minden tizedik embert elkuldunk ha nem figyelunk erre a dolgora, akkor mar egybol mashogy fog hozzaallni a dolgokhoz! Tegyunk hozza meg egy szamot ha egy oldal csak IE-n mukodik az megint maximum a felhasznalok 90%-a. A 90%-nak 8-10%-a js nelkul netez. Hoppa, maris minden 5-6dik latogato (15-20%) nem tud vasarolni! Es ezek csak azok akik eljutottak a boltig! Mivel a google nem tudta leindexelni a keresobol nem talaljak meg! Ez vajon hany szazalek.....

Es ha mar vakok vasarlasi szokasanal tartunk. En nem ismerek konkretan egy vakot se, de azt feltetelezem, hogy a webes vasarlas ha az oldal megfeleleo szoveges informaciokkal van ellatva akkor lenyegesen megkonyithati az o vasarlasukat, hiszen nehezebben kozlekednek, a boltban az informacio kereshez masok segitseget kell igenybe venni stb.
A vak emberek akkor is vasarlo erot jelentenek ha olyan termekrol van szo amit ok nem hasznalhatnak, hiszen ajandekot is vasarolnak lato ismeroseik, rokonaik szamara.
26

Rosszul fogalmaztam

pp · 2005. Május. 24. (K), 05.43
Én ugyan ezt próbáltam leírni!
Az olyan megjegyzésekre reagáltam, mint:

Csupán az a gond a lehulló menükkel, hogy sokak számára használhatatlanok (pl: látás és mozgássérült emberek).


Próbáld meg a lehulló menüket egér nélkül használni... Például.


Ezekkel az érvekkel nem nagyon lehet meggyőzni egy profitorientált céget, amit te írtál(és amire én is gondoltam) avval igen:

A statisztikak szerint 10% nezelodik javascript nelkul! Ha egy managernek azt mondod, hogy akkor mi most minden tizedik embert elkuldunk ha nem figyelunk erre a dolgora, akkor mar egybol mashogy fog hozzaallni a dolgokhoz! Tegyunk hozza meg egy szamot ha egy oldal csak IE-n mukodik az megint maximum a felhasznalok 90%-a. A 90%-nak 8-10%-a js nelkul netez. Hoppa, maris minden 5-6dik latogato (15-20%) nem tud vasarolni! Es ezek csak azok akik eljutottak a boltig! Mivel a google nem tudta leindexelni a keresobol nem talaljak meg! Ez vajon hany szazalek.....


pp
28

Meggyőzés...

kgyt · 2005. Május. 24. (K), 11.22
Ezekkel az érvekkel nem nagyon lehet meggyőzni egy profitorientált céget...

Nos itt éppen nem volt szempont, hogy meggyőzzek egy profitorientált céget...
Ez tudtommal nem a managerek portálja...
Hmm...

Szóval egy választ írtam, és nem marketingesnek, hanem webfejlesztőnek (tudtommal).


--
Szeretettel: Károly György Tamás
kgyt&kgyt.hu - http://kgyt.hu
56

20%???

Marcell · 2006. Feb. 23. (Cs), 14.06
Ha egy oldal csak IE-n mukodik az megint maximum a felhasznalok 90%-a. A 90%-nak 8-10%-a js nelkul netez. Hoppa, maris minden 5-6dik latogato (15-20%) nem tud vasarolni!
Gondolom már lerágott csont a téma, de én most futottam át és egy elég nagy ferdítást találtam ebben a hozzászólásban.

Aki letiltja a JS-t, az valószínüleg konyít már annyit a témához, hogy nem IE-t használ. Sőt. Meg merem kockáztatni, hogy a JS-t tiltók 90%-a Firefoxot vagy Operát használ. Szóval a Te érvelésed szerinti 20% max 12% körül mozog.

És szerintem ezen felhasználók nagy része weblaptervező (is). Egy átlag netező fiatal lány / középkorú férfi nem is tud ilyen JS tiltásokról. Azok használnak ilyen dolgokat, akik tisztában vannak ezzel, ők pedig nyilván azzal is tisztában vannak, hogy ez milyen rizikókat hordoz.
57

nem mindenki otthonrol netezik!

pp · 2006. Feb. 23. (Cs), 14.32
Vagy a cég rendszergazdája tíltja le a js-t, ráadásul úgy, hogy a szegény juzer át se tudja állítani.

pp
58

<Nincs cím>

Marcell · 2006. Feb. 23. (Cs), 14.37
azért ez nem túl gyakori... a cégeknek a nagy tömeg számít, nem az egy-két egyedi eset. Több ilyen helyen neteztem már (BME, MTV - egyik sem kis putri), de egyiknél sem volt ilyen korlátozás - és sztem nem is ez a követendő.
29

Nem is akarok managereket győzködni!

kgyt · 2005. Május. 24. (K), 11.53
Kit érdekel, hogy mit mond a manager, ha nem készíthetem el akadálymentesen, akkor nem kell a munka. Van elég kereslet, mint ahogyan kínálat is.
Elegem van abból, hogy olyanok diktáljanak, akik nem értenek hozzá, nekem ne mondja meg egy manager, hogy az oldalt hogyan építsem fel!
Úgy gondolom, hogy a szakmában töltött tizeniksz év alatt megtanultam pár fontos szabályt. Nem fogok senki kedvéért gányolni. A managernek elmondom, hogy miért jó az akadálymentes oldal, és ha olyat javasol, ami nem megoldható akadálymentesen, akkor lebeszélem róla.

Most van párhuzamosan pár projektem, amely nem közhasznú oldal, de mégis megértették, hogy jobb nekik az, ha minden látogató megtalálhatja az információkat. Ezek nem nulla cégek, az egyik egy nemzetközi mérnöki iroda (olasz központtal), amely főleg minőségbiztosítással foglalkozik, másik egy európai uniós információs adatbázis, megint másik egy olasz-magyar kozmetikai cég, de van még ingatlanos, autós cég stb.
Aki nem ért meg ilyen alap dolgokat, az más gonoszságra is képes, lehet, hogy nem is fizetne, vagy mást sem lehetne vele rendesen megbeszélni.

Ilyen, mindenfajta alapot nélkülöző bődületesen hatás vadász általánosításokkal...

Valami baj van? Fáj is? Milyen alapon állítod ezt? URL?
Ha rákérdezel nem jobban járunk? Talán elmagyaráztam volna...
Mellesleg éppen ma tárgyaltam reggel egy cégnél, ahol az egyik érvem a jano által is említett mobiltelefonról történő adatelérés volt. A manager nem úgy reagált, ahogy te...
Amikor az akadálymentességet megemlítettem, akkor örült, és megkérdezte, hogy miért jó neki. Értelmesen elbeszélgettünk és a végén már neki is mindenképpen akadálymentes oldal kellett... ;-)

Az akadálymentes weboldalak rövid távú extra-profitja nem mérhető anyagi, dologi profithoz, mert erkölcsi.

Ezt a mondatodat nem értem;))

Pedig magyarul van.
Egy cégnek erkölcsi profitra is szüksége van, ezt pedig rövid távon garantálja az, ha az oldala akadálymentes. Marketing célokra is használható... (pl. még a vak is látja, milyen jó a cégünk...) Állami (nem feltétlenül csak magyar állami) finanszírozási pályázatokon előnyt jelent, ha akadálymentes az oldal.
Az erkölcsi haszon sokkal fontosabb hosszútávon, mint az anyagi, mert az garantálja a további anyagi haszon biztosítását.
Tudod olyan ez, mint amikor az étteremben nem lenyúlnak, hanem felsegítik a kabátodat. Máskor is visszamész.


--
Szeretettel: Károly György Tamás
kgyt&kgyt.hu - http://kgyt.hu
31

kgyt, te melyik forumot olvasod?

pp · 2005. Május. 24. (K), 12.41
Igazan fekete a humorod, de en ertem ;)))

Csak egy gyongyszem:

Ezt irtad:
Mellesleg éppen ma tárgyaltam reggel egy cégnél, ahol az egyik érvem a jano által is említett mobiltelefonról történő adatelérés volt. A manager nem úgy reagált, ahogy te...

Nyilvan erre, amit mellesleg en irtam:
Szerintem többre mennél, ha elmondanád azt, hogy ha akadálymentes lesz a weboldalad, akkor a sok-sok mobiltelefonos XHTML-es böngésző is meg fogja jeleníteni a tartalmat, meg a managerek is kényelmesen olvashatják a palmtopjukon.
Ettől függetlenül neked nem kell így gondolnod. Te csinálhatod azért az akadálymentes oldalakat, hogy azok is megnézhessék aki egyébként nem tehetnék ezt.


pp
32

jólvanna...

kgyt · 2005. Május. 24. (K), 12.51
Akkor izé... ;-)

--
Szeretettel: Károly György Tamás
kgyt&kgyt.hu - http://kgyt.hu
27

sok huho ...

Anonymous · 2005. Május. 24. (K), 09.49
A cikk jó, valóban összefoglalja azokat az irányelveket, amelyeket egy akadálymentes weboldal létrehozásánál figyelembe kell venni. Ezért mindenképpen elismerés jár a szerzőnek.

Viszont amit pp leírt, az teljesen helytálló. Adott cég menedzsere le sem szarja azt a pár mozgássérült vagy vak embert, aki a cégek 99%-nak amúgy sem tartozik a célcsoportjába, illetve nem jelent olyan vásárlóerőt, ami miatt megérné beleinvesztálni egy teljesen akadálymentes weboldal kialakításába.

Erkölcs? Szubjektív. Ahol pénz van, felesleges az erkölcsöt számonkérni. Ehelyett az önjelölt Don Quijote-knek le kéne szállni az ilyen utópisztikus rózsaszín felhőcskékből a földre szerintem és nem ezt a maszlagot nyomatni a "kirekesztésről" meg "erkölcsi harcról". Ezek csak weboldalak, könyörgöm.

Ellenben teljesen jogos az a megközelítés, hogy válasszuk szét a közpénzekből, közfeladatok ellátására készülő weboldalakat a "céges" weboldalaktól. Az első kategóriában én is kötelezővé tenném a teljesen akadálymentes oldalkialakítást. A kecske is jóllakik, a káposzta is megmarad.

A saját gerilla blogokon meg amúgy is annyit pöröghet mindenki az akadálymentesítésen, amennyit csak akar és akkor a lelkiismeret is rendben van.

Szal én amondó vagyok, hogy ez az egész hűhó az "akadálymentes" weboldalak körül most teljesen túl van pörögve, mert most ez a divat. Jön majd helyette valami más, amiről megint több ezer megabájtnyi felesleges hozzászólás, írás, stb. születik, hogy idővel ugyanúgy a /dev/null-ban végezze...

-t-
30

Ami miatt megérné????

kgyt · 2005. Május. 24. (K), 12.01
...nem jelent olyan vásárlóerőt, ami miatt megérné beleinvesztálni egy teljesen akadálymentes weboldal kialakításába.

Marhaság! Az akadálymentes oldal nam drágább (kivéve, ha sztriming van rajta). Csak egy kicsit jobban oda kell figyelni.

Ezek csak weboldalak, könyörgöm.

Egyes emberek egyetlen kommunkációs lehetősége az internet.

...kötelezővé tenném a teljesen akadálymentes oldalkialakítást.

Ez a mondat szakmai hozzá nem értést árul el. Olyan nincs, hogy teljesen akadálymentes oldal. Vannak prioritások, akadálymentességi szintek, de nincs teljesen akadálymentes weboldal...

Vágasd le a kezedet, és meglátod, hogy mégsem feleslegesen tépjük a szánkat!

--
Szeretettel: Károly György Tamás
kgyt&kgyt.hu - http://kgyt.hu
33

vegyel vissza

Jano · 2005. Május. 24. (K), 13.50
KGYT vegyel kicsit vissza, erzelmi alapon nem fogod meggyozni.

Teljesen igaza van PP-nek amikor arrol beszel, hogy nem mindenkinel mukodnek bizonyos ervek. Ezen gondolkoztam el egy kicsit amikor a managerek elokerultek.

Hiaba akarsz meggyozni fejlesztoket, kozben ket tuz koze kenyszerited oket amitol kellemetlenul kezdik erezni magukat. Egyik oldalrol papol nekik valaki elerhetosegrol( vagy ugyanigy szabvanyokrol, felhasznalobaratsagrol, CSS-rol) masik oldalrol elvarjak tole, hogy azt csinalja amit kiadnak neki, ugy ahogy azt alairattak az ugyfellel.

Azt varod (varjuk) toluk, hogy konstruktivan alljanak hozza a fejlesztesekhez es igenis tegyenek javaslatokat az oldal minosegenek javitasara. Ez sokaknal egyszeruen nem igy mukodik. Sok helyen a HTML koder mar csak miutan lezajlott az oldal tervezese, elkeszult a design akkor kapja mag a feladatot, hogy akkor ezt most vagja ossze es nincs beleszolasa a tervezesi folyamataba.

Ahhoz, hogy a vele egyutt dolgozokat meggyozze nem elegek szamara azok az indokok, hogy "etika", "jo erzes" stb.

Vannak olyan reszei az ajanlasnak amiket anelkul tud es anelkul is kell megvalositani, hogy azt a tobbi fel eszre sem veszi. Vannak olyan reszek ahol a grafikussal kell beszelnie es vannak olyan mukodesi dolgok ahol akar az egesz koncepcio borulhat.

Ezert valami olyan felosztast kene csinalni az ajanlasban ahol kulon szerepelnek azok a megoldasok amik a koder feladatai es olyanok ahol egyutt kell mukodni masokkal is.
Az erveknel szinten ket csoportositas lehetne, a szigoruan penzbeli elonyok vagyis amik merhetok es utana a nem merhetok.
35

Nos, kicsit lehiggadtam... :-)

kgyt · 2005. Május. 24. (K), 14.51
Vannak olyan reszei az ajanlasnak amiket anelkul tud es anelkul is kell megvalositani, hogy azt a tobbi fel eszre sem veszi. Vannak olyan reszek ahol a grafikussal kell beszelnie es vannak olyan mukodesi dolgok ahol akar az egesz koncepcio borulhat.

A WCAG-kialakításakor is hasonló szempontok vezethették a W3C-t, mert az A szint elérése a dizájn sérülése nélkül általában kivitelezhető.


--
Szeretettel: Károly György Tamás
kgyt&kgyt.hu - http://kgyt.hu
36

re: Ami miatt megérné???

Anonymous · 2005. Május. 25. (Sze), 09.31
Nos, ha jól látom, nem azt írtam, hogy szerintem totális baromság akadálymentes oldalakat kialakítani :)

Sőt, mivel én is fejlesztő vagyok és egy alapvetően innovatív környezetben dolgozom, ezért nekem LEHETŐSÉGEM is van arra, hogy a legfrissebb kvázi-szabványokat követve (xhtml strict, anyone?) fejlesszek, ezért én így is fejlesztek.

De. És itt jön, amit pp, jano és én leírtam. Az esetek 99%-ban egy "igáslóként" dolgozó fejlesztőnek kisebb gondja is nagyobb annál, hogy adott oldal akadálymentes-e vagy épp valid xhtml... a határidők, a konzervatív, szakmailag elmaradott főnökök, a megrendelő/ügyfél faszságai mind közrejátszanak abban, hogy adott fejlesztő nem tud a saját maga által megszabott követelményrendszer szerint dolgozni .. ha meg akarja tartani az állását természetesen :)

Mindezek mellett bizonyos oldalak esetében én se tartom elsődleges fontosságúnak az akadálymentesítést (egy kis flash itt, ott, amott ;), csak ott, ahol a közönség várható összetétele a teljes spektrumot lefedi, nem csak egy adott, kissebb méretű célcsoportot (lásd pp hozzászólásában egy autó-dealer honlapja, vakoknak :).

No offense kgyt, de mi még szerencsésnek mondhatjuk magunkat, hogy úgy dolgozunk, ahogy a kedvünk tartja és annyi figyelmet fordítunk a managerek által "faszságnak" tartott dolgokra, amennyit csak akarunk. Szal szerintem ne hőbörögj ;))

üdv,
-t-
37

Dehogy höbörgök

kgyt · 2005. Május. 25. (Sze), 09.59
Kifejezetten elégedett vagyok a munkakörülményeimmel, a főnököm jó fej és minden feltételem adott a jó munkavégzéshez, de ezt bárki elérheti, ha elég kitartó, és nem ragad le az összebarmolós módszernél.
Persze volt nekem is barmolós időszakom, de szégyenlem...
Azért próbálom elősegíteni az akadálymentesség ügyét, hogy jobb legyen mindenkinek, neked, nekem...
Az akadálymentesség nem kíván mást, mint gondos tervezést, ami a munkát jobb minőségűvé is teszi, azon túl, hogy a későbbi javításokra és módosításokra szükséges idő is lecsökkenthető drasztikusan.
Gondolj csak arra, hogy tableless strict technikát használsz, amiben a képek csak akkor szerepelnek, ha a tartalom részei (egyébként a css teszi ki a dizájnképeket), és jön a dizájncsere...
Hopplá, a kódhoz nem kell nyúlni, a templéthez sem, csak elkészítjük a képeket és lecseréljük a css-t.
Ez pedig nem szokatlan kívánság.
Vagy jön egy új menüpont, mert a cég kiegészítette a szolgáltatási palettát... Mennyivel könnyebb beilleszteni egy gondosan elkészített oldalba?
Ha a tervezésen spórolunk, az visszaüt.
Az akadálymentességhez pedig tervezés kell csupán, főleg az alap szinten.
A rajzoló meg ne szóljon bele, hogy a menüt egy táblázattal, vagy egy rendezetlen listával oldja meg a htmlkóder, vagy nehogymár a címsoroknak divben kelljen lenniük két font teggel formázva...
A szemantikusság egy nagy lépés az akadálymentesség felé, és nagy segítség az oldal szerkezetének későbbi módosításakor. Egy összedobált kódot nem lehet gyorsan kijavítani. Elsősorban magadnak teszel jót, ha figyelsz a kód minőségére, másodsorban másoknak is segítesz...
Nem mondtam volna karitatív szempontokat? Nahát... Azzal a felsorolással, hogy még kinek jó ez, nem végeznék estig. :-)


--
Szeretettel: Károly György Tamás
kgyt&kgyt.hu - http://kgyt.hu
38

En ezt mind ertem ...

Anonymous · 2005. Május. 25. (Sze), 14.51
... de az en eddigi palyafutasom alatt is voltak olyan helyzetek, amikor mar tegnapra is keso lett volna a ma megkapott feladat es olyankor bizony nincs ido se tervezesre, se usability/accessibility szempontok figyelembe vetelere. Ha csak egy utolso elotti alkalmazott/palyakezdo/stb vagy, akkor ilyenkor mit csinalsz? Felmondasz? :)

Persze en az ilyen helyeket kerulom es hala istennek, vagyok olyan helyzetben, hogy ezt meg is tehetem. De sokan nem tehetik meg. En csak erre akartam kicsit ravilagitani.
39

Nem várom el a pályakezdőtől...

kgyt · 2005. Május. 25. (Sze), 15.05
Nem várom el a pályakezdőtől, hogy mestere legyen a szakmának, de azt igen, hogy (a lehetőségekhez képest) igyekezzen mesterré válni.

--
Szeretettel: Károly György Tamás
kgyt&kgyt.hu - http://kgyt.hu
34

Egy érintett pár gondolata

tormazs · 2005. Május. 24. (K), 14.25
Először is azt kell tisztázni, hogy a hazánkban szinte kizárólagosan használt képernyőolvasó (JAWS for Windows) "igyekszik mindent megtenni" azért, hogy a weboldalakat egy látássérült is használhassa. Erről terveim szerint nem sokára egy cikkben részletesen írok.

A fentiektől függetlenül azonban a legtöbb látássérült otthagyja azokat az oldalakat, melyek nem akadálymentesek semmilyen szempontból sem. Személy szerint "azért sem" böngészem egy zenekar honlapját, mert FLASH-animáció van rajta. Kényelmetlen, csaka gond van vele, nem is látogatom az oldalt. Pedig engem még csak nem is az zavar, hogy zenél, csörög, zakatol, mert szakmailag meg tudom oldani, hogy ne tegye. Egyszerűen elvből nem látogatom, illetve azért, mert nem hozzáférhető a tartalom.

Azokat az oldalakat viszont, melyek akadálymentesek, szívesen használom. Nem azért, mert akadálymentes, hanem azért, mert könnyű használni, tehát azért, mert akadálymentes. Ez hasonlít a Kis herceg és a részeges esetére. Tehát egy oldalt nem azért használok, mert akadálymentes és csak ez az oka annak, hogy használom, hanem azért, mert az akadálymentesség megadja a könnyű kezelhetőséget (címsorok, accesskey-k, stb.)

Nem tudom, gondolkodtatok-e már rajta, most elmondom, hogy nekünk vakoknak az internet egy nagyon jelentős információszolgáltató lehetőség. Személy szerint nem játszom, nem chat-elek, nem töltögetek le gigabyte-okat, egyszerűen információkat keresek (termékekről, cégekről, levlisták anyagában, fórumokon, stb.) Egyszóval bárhonnan, ahol információ van. Munkámhoz tájékozottnak kell lennem, s nem csak a hazai helyzetről kell információkkal rendelkeznem. Ezért bátran állíthatom, hogy rengeteg féle oldallal találkoztam már, s bizony keresek másikat, ha egy oldal akadálymentesség szempontjából nem felel meg.

Azért harcolok és dolgozom (Freedom Scientific (a JAWS készítője) termékek honosítása), hogy az információk mindenki számára egyformán elérhetőek legyenek. Ez azt jelenti, hogy igyekszem az eszközök (képernyőolvasó) képességeit bemutatni másoknak, kidolgozni velük olyan módszereket, melyek nem eredményeznek külön akadálymentes oldalt.
Nem segítség ugyanis nekem, ha van egy Origo hírmondó (http://www.origo.hu/hirmondo), vagy társai, mert például ott nincs "küldje el ismerősének", illetve "szóljon hozzá a fórumban", de nincs letöltés oldal sem, hírlevél sem. Soroljam még?

Vásárlás:
Igen, gyakran vásárolok az interneten. Fogok a jövőben is. Virtuálisan körül tudok nézni, s ez nagy segítség. A megrendelés előtt tételes listát kapok a megrendelt termékekről, melyeket ellenőrzés után megrendelhetek. Soha nem jutott eszembe a kényelem (fotelból rendelem meg), ehelyett annak örültem/örülök, hogy azonos esélyekkel tudok vásárolni, mint bárki más.

A végére maradt, de nem a fontossági sorrend miatt: az oktatás. Tudjátok, hogy például az ELTE-n a dolgaikat a diákok csak az ETR-en keresztül intézhetik? Tudjátok, hogy ez mennyivel könnyebb, mint vakon kóborolni az épületrengetegben, s sok sikertelen próbálkozás után végre találni valakit, aki ismeri azt a valakit, aki hallotta, hogy hol kell megkérdezni az adott dolgot?
Tudjátok azt, hogy mennyit segíthet az ETR a feliratkozáskor (nem kell valakit megkérni, hogy olvassa fel a papírokról a kurzusok adatait)?
Igaz, az ETR-t néhol nehézkes használni, de megoldjuk, amennyit tudok segítek benne azoknak, akik használják.
Tudjátok, mennyit jelent, ha egy diák megtalál egy jegyzetet az interneten? Tudjátok, mennyivel könnyebb dolga van, ha az oldal akadálymentes (ne felejtsük el: nem feltétlenül számítástechnikai szakember, "csupán" diák)?

Az előző hozzászólásokban szerepeltek a managerek. Nekem mindegy, ki mit gondol, innen üzenem a managereknek, hogy ha nem akadálymentes az oldaluk, nem is fogom látogatni. Nem fogok rajta információkat keresni a termékeikről és meg sem fogom venni, ha tehetem még akkor sem, ha valaki elkísérne a boltba. Ez elv, válaszul arra, hogy a managert nem érdekli az, hogy én képernyőolvasóval böngészem az internetet.

Üdv:
Torma Zsolt
43

Várjuk a cikket!

Anonymous · 2005. Május. 29. (V), 14.30
Várjuk a cikket! Egyébként te vagy az első vak ember, akivel találkozok az interneten. Legalábbis, akiről kiderült. Éppen ezért tartottam irreálisnak a statisztikákat, melyek szerint a látogatóknak akár 10%a is lehet vak.
Csináltam magamnak egy kis felmérést és még az informatikai és hírközlési (asszem így hívják) minisztérium weboldala azért valamit hallott az akadálymentességről. Egy akadálymentes link egész jó ötlet volt, csak fekete háttéren sárga betűktől az egyébként jó szemem is majdnem kifolyt. Na most aki amúgy is gyengénlátó, az egy cikk után mehet új szemüvegért. És volt alt a képhez! Ez azért már haladás azt hiszem.
40

Weblabor menü

Anonymous · 2005. Május. 27. (P), 23.10
Picit off, ezért kövezzetek meg, de szépen rímel a 9. pontra, hogy a weblabor legördülő menüje konqueror (3.4) alatt meglehetősen esetlegesen működik, ami piszkosul zavaró bír lenni.

Az anyag máskülönben nagyon jó, az azt követő diskurzus pedig nemkülönben ;)

üdv, Aew
41

FRAME

eMeLA · 2005. Május. 29. (V), 09.58
FRAME (igen/nem)

Általános: baloldali FRAME -> itt van az "állandó" menü
jobb oldali FRAM -> ide töltődik be a tartalom,
ha kattintunk a baloldalon

Ha minden oldalon vagy valami ismétlődő információ pl. menü,
hogyan lehet FRAME, IFRAME, javascript nélkül megoldani azt,
hogy minden oldalhoz egy helyről (fájlból) töltödjön be az, igy ha változás van, ne 20-30 helyen kelljen javítani, hanem csak egy helyen ?

PHP, ASP használata nélkül ! HTML és CSS segítségével !
42

Re: FRAME

attlad · 2005. Május. 29. (V), 11.46
Hát mindenképpen szerver oldali cucc lenne jó hozzá. Használhatsz pl. SSI-t is.

Ha semmi ilyen nincs, akkor vagy normális szervert kéne használni, ahol van erre lehetőség vagy írsz egy pár soros szkriptet, ami megcsinálja helyetted a módosításokat (cseréket) a 20-30 fájlban. Erre a normális szövegszerkesztő programok többsége is képes, meg biztos van erre konkrét célalkalmazás is.

Attila
44

10%

Anonymous · 2005. Jún. 1. (Sze), 13.57
Miért ne lenne elképzelhető a 10%? Csak a magam példáját tudom mondani: egyszerűen nem olvasok el olyan szöveget, ami 9px alatti méretű. Mert kifolyik tőle a szemem. Pedig nem kell szemüveget hordanom, mégsem látok olyan jól.

Jó lenne, ha egy-egy oldalon nem használnának 10-12 px-nél kissebb betűket a szövegre. Nekem a weblaboré is kicsi egy kicsit, de ez még a határeset. (Mind1, firefoxban lehet nagyítani, szerencsére)

- saxus -
45

Re: 10%

kmm · 2005. Jún. 1. (Sze), 14.18
Én meg operában beállítottam, hogy min fontméret 9px, és így ha kisseb is lenne akkor is 9pxre felveszi.
Mellesleg usercss rulez, csinálj egyet a weblaborra. vmelyik hozzászólásban találsz rá jó példákat az megújult a veblavor cikknél

--
üdv: kmm... ( http://kmm.hu )
46

Firefox is

bbalint · 2005. Jún. 1. (Sze), 14.43
Firefoxban is be lehet állítani, hogy hánymennyi legyen a legkisebb betűméret ...

weblavór betűk megnagyításához meg van ilyen "A" betű kék háttéren és a plusszosra kell kattintani... az már nem olyan kicsi, egész jó

bbalint
47

+ jel

kgyt · 2005. Jún. 1. (Sze), 15.30
Pont az nem látja, hogy van ott + jel, akinek szüksége lenne rá... :-(


--
Szeretettel: Károly György Tamás
kgyt&kgyt.hu - http://kgyt.hu
48

+ jel nono

Hojtsy Gábor · 2005. Jún. 1. (Sze), 15.40
Először is alternatív stíluslapként válaszható a nagybetűs változat, tehát akinek szüksége van olvashatóbb megjelenésre, az ott megtalálja. Másodszor is pedig a (navigációs) linkek elsöprő többségén van hover információ, az ikonokon is, ami szövegesen is megmagyarázza, hogy mit jelentenek.
49

Igaz, de

kgyt · 2005. Jún. 1. (Sze), 15.49
Ez mind való igaz, de
  1. Nem egyértelmű, hogy van alternatív stíluslap, így nem is keresi a juzer.
  2. Akkor látja a title szövegét, ha rá tudja húzni az egeret a buttonyra...

Mindazonáltal a Weblabor közönsége az IT területén érdekeltek köréből kerül ki, tehát elvárható, hogy képes legyen az olvasó megfelelő méretre állítani az oldalt, és a betűket...
A Weblabornak nem feladata, hogy magasszinten akadélymentes legyen, a jelenlegivel is többet nyújt ilyen szempontból, mint elvárható, minden tisztelet a készítőknek.
Mellesleg a magyar weben kiemelkedő szinvonalával példát is mutat a fejlesztőknek.


--
Szeretettel: Károly György Tamás
kgyt&kgyt.hu - http://kgyt.hu
50

Lehetne egyértelműbb(?)

Hojtsy Gábor · 2005. Jún. 1. (Sze), 16.02
Én azért nem érzem ezt a problémát, mert megszokott, hogy ilyen ikonokkal jelzik a különböző lehetőségeket (ajánld másnak, nyomtatási nézet, betűtípus váltás stb). Ezek jellemzően az oldal tetején vannak valahol. Ha ezt a megszokást már valaki magára szedte, akkor fel fog neki tűnni az ikonsor, és ott ki fogja tudni deríteni, hogy melyik mire jó - ha van olyan optimista, hogy magyarázatot vár az egeret az ikonok fölé mozgatva. Tehát szerintem az eszköztár felismerhetősége a kérdés, mert onnantól kezdve egy szokásos eszköztár metafora vezeti végig a felhasználót. Ha a mi eszköztárunk nem ismerhető fel jól, akkor azon azért lehet javítani. Módosított, de az eszköztárba illő ikonokat különben nagyon szívesen fogadunk, vagy teljesen le is cserélhetjük az eszköztár ikonokat, ha van jobb (és megfelelő licencfeltételekkel használható) alternatíva.
51

RE: + jel

Anonymous · 2005. Jún. 1. (Sze), 16.37
Na ja, ez kissé lamerség :) Tényleg nem vettem észre, hogy van nagyobb betűméret. :) De mint írtam, a weblaboré nálam még a határeset.

Talán nem vagyok hozzászokva ahhoz, hogy van ilyen. :( Más kérdés, hogy megszoktam, hogy a firefoxban nyomok egy CTRL+ -t, az minden oldalon működik.
52

Igaz rég volt de nem bírom ki

arpadosso · 2005. Dec. 17. (Szo), 20.34
hogy ne szóljak hozzá. Volt itt minden csevegés, elméletek javítása-színezése, indulat, félreértés, még kézlevágás is azután kisarkítottátok azaz megragadtátok a managerek hozzánemértését, és még sorolhatnám de nem ezért szólnék hozzá.

Először is nem vagyok büszke magamra, de fejlődök és lassan tükörbe tudok nézni, azaz olyan internet oldalakat készítek, mind megjelenés, mind használhatóság szempontjából, amikre a jó szót használhatom, de sort a következőképpen kezdtem:

először nagyon sokat rajzoltam géppel, azután html szerkesztővel raktam össze az oldalakat, ami ugyebár nem nagyon készít valid kódokat, sőt még csak jól használhatót sem, éppen csak megjelenik. Azután rá kellet jönnöm, hogy nincs más megoldás meg kell tanulni a programnyelvet és nem egy programnyelvet. Halkan mondhatom, hogy kezd alakulni, kezd az agyam is átalakulni amikor egy Internet oldalt rakok össze szimpla szövegszerkesztőben. És igen itt volt egy olyan pillanat amikor azt gondoltam már elég jó vagyok. De aztán kiderült hogy a kereső-optimalizás is van olyan fontos mint az előző kettő. És amikor ezt megtudtam azonnal előtérbe került a piackutatás, és itt ragadnám meg az alkalmat hogy beszálljak a vita egyes részébe.

Hiába minden tapasztalat a weboldalkészítés terén, ha a kívánt feladat nem igényli azt hogy könnyen lehessen navigálni. (Előre is elnézést kérek azoktól akiket a következő soraimmal megbántanék, de arról hogy az életben kinek mi jutott, arról nem tehetek, ezeak a bizonyos korlátok tények és el kell fogadni azokat, de együtt érezni sohasem fog senki aki nem járta még meg azt az utat, hogy valamilyen cselekvésre képtelen, bocsánat mégegyszer).

Figyelembe kell venni ha olyan dologról van szó, akkor igenis kell a flash és kit érdekel hogy nem tudja megnézni, flash nélkül meg sem lehet úgy mutatni a dolgot ahogy szeretné a megrendelő. Nem lehet egy takaró alá húzni egy információs cégbemutató oldalt egy márkanépszerűsítést végrahajtó és aként is funkcionáló oldalal. Lehetetlen. Gondolj csak bele ha bemész a kenyérért a boltba melyik kenyeret veszed meg amelyik ki van rakva gőzölög érzed az illatát, még talán meg is kóstolhatod (igaz sokan állnak körülötte és nehéz odajutni), vagy amelyiknél ki van írva hogy kenyér és egy nyíl mutat arra amerre menned kell. Nem tudom magamat ismerve a gőzölgő jobban érdekelne.

És most én is sarkítottam egy kicsit, ezzel kapcsolatban, de ha brandingre használják az oldalt, akkor szerintem ez a helyzet, igaz elektronikai műszerész a végzettségem... :)

És még egy amíg nekem hat év kellett ahhoz hogy rájöjjek arra, hogy egyre több mindenhez nem értek addig kérek mindenkit ne jöjjön ki a sodrából.

...a végtelen itt folytatódik...
53

a látogatói kör fontos

aries · 2005. Dec. 19. (H), 10.00
Hidd el, sokan mennének a nyíl irányába, ez nem ilyen egyszerű. Weboldalaknál lehet koncentrálni a látogatókra. Nyilván, egy gördeszkás-koris oldalnak pörgősnek kell lennie, mert ez az elvárás. A vakok és gyengén látók nem fognak korizni. Ellenben egy zenekar vagy újság esetében igen is fontos az ilyen látogatók megbecsülése, sőt! Jó gyakorlat az, ha célközönség szerint készíted el az oldalt.

Én nagyon nem szeretem a flash-t, ezért csak díszítő, figyelemfelkeltő eszközként tekintek rá. Egy egész weboldalt flashben elkészíteni pedig
annyit jelent: lusta vagyok/nem értek a webes technológiákhoz/nem fizetik meg, hogy szőrőzzek vele. Ez pedig elég negatív.
--
Aries
http://aries.mindworks.hu
55

Flash

attlad · 2005. Dec. 19. (H), 18.32
Nem értek egyet a Flash-ről alkotott véleményeddel. Bár én se szeretem bizonyos okokból, de vannak dolgok, amikre jelenleg a legjobb, legfelhasználóbarátabb, stb. megoldást nyújtja. (Erre írtam régebben valamelyik topikban hogy több, jobb "szabványok" kellenének.)

Pont egy zenekar oldalán elég kényelmes megoldás, ha egy kattintásra bele lehet hallgatni/nézni a számokba/klipekbe a böngészőn belül, ezt Flash-sel lehet jól megoldani. (Persze attól még ott lehet link az OGG, MP3, video, stb. fájlokra.)

Az persze rossz megoldás ha egy bármilyen weboldal nincs felkészítve arra, hogy mi van ha nincs Flash plugin.
54

Igazad van

Jano · 2005. Dec. 19. (H), 14.23
Abszolút jogos a felvetésed. A megoldás pedig egyszerűen az, hogy a cikk irányelveket és nem kőbe vésett minden áron betartandó és követendő szabályokat fogalmaz meg. Pont az a nehézség, hogy ezek az irányelvek sokszor még egymásnak is ellentmondanak és akkor még a megrdendelő tartalmi, funkcionális igényeiről, a marketing osztály kívánságairól, a grafikus elkepzeléseíről, a pénzügyi határokról, szerver-sávszél stb-ről nem is beszéltünk.

A lényeg az, hogy mindenki mielőtt belekezd a megvalósításba mérlegeljen. Itt az elöttön van a hangsúly. Szedje össze mik a követelmények, melyek a fő pontok és kevésbé fő pontok amiknek meg kell felelni. És aztán lehet pontozni, előnyöket, hátrányokat felsorolni és végül dönteni.
63

Megkésve bár, de törve nem!

pgx · 2006. Szep. 23. (Szo), 01.27
Kicsit későn kapcsolódom be e majd' másfél éves cikk kapcsán, de ahogyan egy újszülöttnek, így nekem, mint friss regeltnek is minden vicc (bocs, cikk!) új.

Elöljáróban hadd fejezzem ki maximális elismerésem a szerzőnek a remekül összeszedett irányelvekhez - minden kritikai észrevételem ellenére.:)

A cikk olvasása és a hozzászólások átlagos hangulata alapján erősen hiányoltam azokat a fejlesztői szempontokat, amelyek legalább olyan fontosak, mint a cikkben szereplők.
Esztétikai és ergonómiai szempotokra gondolok itt elsősorban.

Nekem úgy tűnt a cikkből, hogy nem is kifejezetten az általános irányelveket szedi csokorba, hanem inkább az akadálymentesítés van a fókuszban.
(erre talán érdekes megerősítés, hogy a felolvasószoftver szó hússzor, a CSS pedig csak 13 alkalommal szerepel a cikkben...

Belátom, fontos az akadálymentesítés, de talán nem ennyire.
Fontos még az adaforgalom minimalizálása, a validitás, a keresőoptimalizálás, az adatbáziskérések minimalizálása, a kliens oldali szkriptek és a Flash mellőzése, a grafikus elemek mérsékelt használata, a stíluslapok nélküli helyes megjelenítés, satöbbi...

Lássuk be, ha ezen irányelvekből minél többet valósítunk meg maradéktalanul, annál szürkébb és jellegtelenebb weboldalakat készítünk.

Úgy vélem, sokan estek abba a hibába, hogy a fokozott technológiai és szakmai megfelelés miatt nem veszitek észre a design, a komfort és a kreativitás jelzőit, figyelmen kívül hagyjátok a laikus, ám mégis nagyrészt diktáló pozícióban levő általános megrendelői attitűdöt.

Persze saját honlap esetében nincs ilyen fék, de - és most jöhet a megkövezés - sok weblaboros tag egyéni honlapja ugyan technológiai bravúr, viszont felejthetően szürke és unalmas.

Érdekes ellenpólus viszont, egy hazai Flash-es portál törzstagjainak egyéni honlapjai kivétel nélkül full-flash oldalak másfél-két mega fájlméretekkel, izgő-mozgó, szemet gyönyörködtető csodák remek zenei aláfestésben.
Ez a másik véglet.

Valahol középen van az igazság - Mulder minden törekvése ellenére...;-)
64

a sorrend nem mindegy!

pp · 2006. Szep. 23. (Szo), 07.20
Az én tapasztalatom az, hogy amikor valaki honlapot akar, akkor a következő sorrendbe helyezi a különböző elvárásokat:

1. Szép legyen
2. Olcsó legyen
3.... amit a webes mókus(tehát a weblaboros olvasó) mond. Elérhetőség, validitás,ergonómia, diszkrét javascript....

Nyílván való, hogy nem lehet egy olyan sorrendet felállítani, ami minden weboldalra igaz lenne, hisz egy egyéni weboldal, webáruház, közösségi szájt vagy egy "újtermék" promó oldala nem ugyan abból a célból készül. Pontosan ez a baj evvel a sorrendel ;)

Nyílván egy promó oldalon az első a szép legyen(full flash), egy webáruháznál, hogy elérhető legyen, egy személyes honlapnál, hogy olcsó legyen.(persz ez is változik attól függően, hogy pontosan mi a feladat és ki a megrendelő)

Tehát nem középen van az igazság!

Van egy cél(vagy több) amit el kell érni. A célhoz vezető utat felhasznólói és szakmai szempontok szegélyezik, de minden út más más sorrendben tartalmazza ezeket.

Egy autó promó oldalnál nyílván az első szempont, hogy olyan vizuális és hang élményt adjuk a látogatónak, ami hatására fellángol benne a vágy, hogy megvásárolja a terméket. Ekkor a weblaboros tag véleményére nincs szükség a reklám szakember megálmodja a weblaboros tag meg valósítsa meg. Kgyt őrjönghet, de ekkor az, hogy egy vak is élvezhesse a tartalmat "érdektelen".

Azonban egy kormányzati oldalnál, amit az állampolgárok pénzéből az állampolgárok részére készítenek, amin információt szeretnének közölni velük elengedhetetlen, hogy az tényleg mindenki számára elérhető legyen. Ekkor az első az elérhetőség(nem külön vakbarát oldal), a használhatóség, kezelhetőség, ergonómia és csak ezek után jöhet az, hogy szép is legyen. Itt a szépségnél nem is a szépre, hanem inkább olyan tipográfiai elvekre kell gondolni, ami az előbb említett célokat támogatja.

A cikk arról szól, hogy vannak olyan szepontok, amiket még a weblaboros tag sem vesz figyelembe. Legalább is régen erről volt szó, de remélhetőleg ez a helyzet, hála KGYT(és többek) kemény munkájának mára már megváltozott ;)

A cikk célja ismeretterjesztés és nem egyedüli út kijelölése.
Persze saját honlap esetében nincs ilyen fék, de - és most jöhet a megkövezés - sok weblaboros tag egyéni honlapja ugyan technológiai bravúr, viszont felejthetően szürke és unalmas.


Pontosan azért, mert a weblaboros tag (webes mókus) nem grafikus, tehát az oldalának nem az a célja, hogy bemutassa valaki más munkáját. ;)

pp
65

enyém?

Marcell · 2006. Szep. 23. (Szo), 15.28
És az enyém (bár még félkész)? Én direkt erre törekedtem, hogy szép legyen és egyben használható is.
66

Hááát

krey · 2006. Szep. 24. (V), 15.59
Kicsit zavaró, hogy van flash player-em de szépen kiírja, hogy töltsem le :) Így elsőre :)

üdv. krey
67

SWFObject

Marcell · 2006. Szep. 25. (H), 09.46
Pedig a 'szabványnak' mondható SWFObjectet használom az alábbi sima kóddal:
var so = new SWFObject("kepek.swf", "kepek", "540", "300", "7", "#C1C18F");
Más oldaknál is láttál már ilyet???
68

böngészés képek nélkül

QXY · 2007. Ápr. 29. (V), 04.52
Én sajnos most épp abban a helyzetben vagyok, hogy GPRS-t kell használnom. Mivel az internetezésnek ez a módja nem éppen pénztárca kimélő, az ember próbál spórolni az adatforgalmon. Ennek a legegyszerűbb módja hogy kikapcsoljuk a képek megjelenitését. Tessék megnézni pár oldalt próbaképp és máris szembesülünk vele hogy bizony ezek az emberek sok helyen tényleg nem jutnak hozzá a kivánt információhoz. Sajnos nagyon elvétve követik a cikkben leirtakat de reméljük ezek után egyre többen. Tehát nem feltétlenül kell fogyatékosnak lenni, hogy előnyünkre váljanak ezek a dolgok!

Ui: A weblabor kiválóan használható képek nélkül is! :)
69

további célszerű elvek

gphilip · 2007. Aug. 26. (V), 07.06
nem tudom, elhangzott-e (nem olvastam végig mindent):

+1. minden esetben, amikor hosszabb szöveget jelenítünk meg, célszerű sorkizárás és viszonylag rövid sorok használata, hiszen így a legkönnyebb a felhasználó szemének az olvasás.

+2. termszetes dolog, de mindig tartsuk szem előtt a kereső robotokat is (ne csak a vakokat). egy javascriptes link, funkció, vagy akár ajax megoldás nem mindig befogadható a robotok számára, így értékes rank helyezéseket veszíthetünk.