A színfalak mögött

Akadálymentes weboldalak

2009. május 03.

Az akadálymentes weboldalak készítéséről az elmúlt évekig viszonylag keveset lehetett hallani. A témával foglalkozó nonprofit szervezetek és magánszemélyek erőfeszítéseinek köszönhetően azonban egyre inkább figyelmet kap, mind a magánszektorban, mind pedig a kormányzati szférában.

(Forrás: http://bartal.org/)

Az akadálymentesítés azonban, a kibontakozó kedvező folyamatok ellenére, a website-ok tervezésénél és megvalósításakor számba vett szempontok közül továbbra is a kevésbé hangsúlyosak közé tartozik. A web accessibility célja, hogy a lehető legszélesebb közönség részére elérhetővé váljék egy adott website. A website-tulajdonosok szempontjából tehát ezek az erőfeszítések tisztán üzleti célt szolgálnak: minél többen érik el az általuk szolgáltatott tartalmat, annál jobb.
 
Általános elv, hogy a tartalom kettőzése (szegregált "vakbarát változat") kerülendő: azt kell elérni, hogy a weboldalainkat minden felhasználó ugyanúgy használhassa. Egy akadálymentes website létrehozása tehát mindössze annyiból állna, hogy a hozzáférhetőséget korlátozó tényezőket megszüntetjük — azonban a régi rossz szokásoktól néha nehéz eltérni.
 
Amikor az accessibility szóba kerül, legtöbbször a testi fogyatékosokra gondolunk, azonban ennél szélesebb az a csoport, melynek igényeit az akadálymentes oldalak készítésekor figyelembe kell vennünk. A web fejlődése folyamán volt olyan időszak, amikor a különböző gyártók által készített webböngészők eltérő módon (vagy hibásan, esetleg egyáltalán nem) jelenítettek meg web tartalmakat, így végeredményben a potenciális közönség egy részének valós "accessibility" problémát jelentettek. Ezért az első fontos lépés a webes szabványokban testet öltött közmegegyezés volt — ma már ezeknek a szabványoknak (HTML, XHTML, CSS) illik megfelelnünk, amikor website-ot készítünk, hogy az a legtöbb böngészővel, és így a lehető legszélesebb közönség számára elérhető legyen.
  • A vakok, gyengénlátók, színvakok és színtévesztők nyilvánvalóan érintettek. Ez a csoport a webet használóknak nem elhanyagolható része. Alapvetően érintett minden olyan felhasználó, aki látásában, hallásában vagy mozgásában korlátozott, vagy az információt valamilyen okból nehezen, vagy csak részben képes feldolgozni.
  • Testi fogyatékosok, vagy a mozgásukban valamilyen módon korlátozott felhasználók, akiknek gondot okozhat az egér vagy a billentyűzet használata.
  • Azok a felhasználók, akik a webet mobiltelefonról vagy PDA-ról érik el. Ez a csoport piaci szempontból azért érdekes, mert az átlagosnál magasabb életszínvonalon él, telekommunikációs eszközhasználata intenzív.
  • Régi számítógépet, régi böngészőt használók, modemes internet-használók: azok a szervezetek és magánszemélyek, akik (például anyagi okokból) nem tértek át korszerű szoftverekre, új számítógépekre.
  • A fiatal (5-10 éves) internet-használóknak — akik bár közvetett, de szintén nem elhanyagolható vásárlóerővel rendelkeznek — szintén okozhat problémát a szem-kéz koordináció és az olvasás.
  • Az idősek. A "Silver Surfer" csoport szintén nem elhanyagolható célcsoport, mely a gazdagabb nyugati országokban dinamikusan növekszik, és egyre többet is költ online csatornákon. Ez a csoport az akadálymentes web szempontjából a gyengébb látás, korlátozott mozgás és gyengébb szem-kéz koordináció miatt lehet érintett.
  • Azon felhasználók, akiknek az írott szöveg értelmezése nehézséget okoz, illetve nem beszélik folyékonyan azt a nyelvet, melyen egy adott weboldal íródott.
Bár ezek a csoportok egyenként nem nagy létszámúak, és külön-külön esetleg nem generálnak jelentős látogatottságot, azonban együtt már nem elhanyagolható csoportot alkotnak, és egy közepes forgalmú website-on már számottevő lehet azoknak a száma, akik azért választják a konkurenciát (vagy tesznek panaszt egy állami szerv weboldala esetében), mert az oldal tartalmához nem férnek hozzá.
 
Egy akadálymentes website pozitív hatásai:
  • Az akadálymentes weboldalak — strukturált felépítésüknek köszönhetően — a webes keresőkben jobb helyezést érnek el. A Googlebot az internet legbefolyásosabb vak felhasználója.
  • Pozitív PR — a website tulajdonosa hangoztathatja társadalmi felelősségvállalását és a szabványoknak való megfelelését.
  • A website tulajdonosa olyan piaci csoportokat érhet el, melyek még kevésbé telítettek — a látogatók számának növekedése.
Egy nem-accessible website negatív hatásai:
  • Bár a jogi érvelés önmagában (ma és itt) hatástalan — Magyarországon még nem fordult elő, hogy emiatt akár egy céget is bepereltek volna —, a hatályos törvények szerint tilos bárminemű hátrányos megkülönböztetés. A magyar közigazgatási honlapok egységesítését célzó KIETB ajánlás előírja a kormányzati honlapok akadálymentessé tételét.
  • Potenciális ügyfelek elvesztése. Másodrangú polgárként kezelt, panaszos ügyfelek. A felhasználók általában pozitív tapasztalataikat ritkábban osztják meg egymással, mint a negatívakat. Kisszámú elégedetlen ügyfél véleménye is negatív PR.
A jövőben várhatóan egyre több szervezet igényli majd, hogy website-ja akadálymentes legyen. A kormányzati, egészségügyi és oktatási portáloktól elvárható, hogy megfeleljenek az akadálymentes oldalakra vonatkozó ajánlásoknak (jellemzően WAI-AA). Alapelvként megfogalmazható: törekedni kell arra, hogy az átlagos felhasználók számára készült oldalakat a gyengénlátók, ill. egyéb fogyatékossággal bírók is ugyanúgy használhassák, azaz kerüljük az "ugrás az akadálymentes változatra" szemléletet. Amennyiben azonban ez nem lehetséges (komplex tartalom miatt, vagy a weboldal tulajdonosának kifejezett kérésére), készítsünk olyan alternatív megjelenést, amely az eredeti tartalmat hiány nélkül visszaadja. Sokszor éppen az ilyen "vakbarát" változatok lecsupaszított volta miatt nem használják őket a vakok és gyengénlátók.

Gyors tippek

  • Oldalszerkezet. Használjunk kifejező oldalcímet. Használjunk fejléceket (h1...h6), listákat és következetes struktúrát, használjunk CSS-t a szerkezet és a stílus leírásához, ha lehetséges. A CSS-ben használjunk relatív a betűméreteket (%, em). Adjunk meg alternatív stylesheet-et gyengénlátók részére. Felejtsük el a <b>, <i>, <u> tag-eket, helyettük használjunk <strong>, <em> tag-eket, illetve CSS-t. Használjuk intelligensen a CSS nyújtotta lehetőségeket (pl. médiatípusok: screen, print, handheld, aural), ugyanakkor ügyeljünk arra, hogy a website stíluslapok nélkül is használható maradjon. Az oldal felépítése legyen lineáris: a képernyőolvasó szoftverek az oldal tartalmát a forráskódnak megfelelően olvassák fel.
     
  • Képek, grafikonok és animációk. Használjuk az alt attribútumot a képi információk szöveges leírására. A csak vizuálisan élvezhető, vagy korlátozottan látható tartalmi elemekhez egyenértékű szöveges, tehát képernyőolvasóval is élvezhető tartalmat kell biztosítani.
    A kizárólag esztétikai célú képek esetén
    • A helyőrző képek ALT szövege legyen megadva és legyen üres.
    • Lehetőleg kerüljük képek használatát pszeudo-felsorolásjelként, inkább használjunk CSS-t:
      ul { list-style-image: url('http://www.kutykurutty.hu/brekeke.png'); }
      Ha valamiért mégis szükséges, a felsorolásjelként használt képek ALT szövege legyen "*".
    • Ha egy képet valamilyen okból több darabra kell vágni, az első darab ALT szövege vonatkozzon az egész képre, a többi darab ALT szövege legyen megadva és legyen üres.
    Ha az ALT paramétert nem adjuk meg, a képernyőolvasó szoftver a képfájl nevét olvassa fel (vagy csak jelzi, hogy egy kép található ott), viszont egy oldalban az érdemi információk helyett csak azt hallani, hogy "transparent.gif", "transparent.gif", egy idő után bosszantó.
    Összetett képek esetén készítsünk kivonatot, használjuk a longdesc attribútumot. Tekintettel azokra a kliensekre, melyek a longdesc attribútumot nem támogatják, közvetlenül a kép után adjunk description-link-et. Ez a következőképp nézzen ki:
    <a href="kep_1_longdesc.txt" title="értelmes linkszöveg" class="dlink">d</a>
    a .dlink CSS class használatával a látó felhasználók elől elrejthetjük ezt a típusú linket (display: none;) azonban a felolvasószoftverek részére a generált HTML kódban szerepeltetni kell. A hivatkozás mutasson arra a címre, amit a longdesc attribútumban is megadunk.
     
  • Multimédia. Tegyük elérhetővé a hanganyagok szöveges átiratát, a videó anyagokról pedig készítsünk leírást.
     
  • Táblázatok. Lehetőleg ne használjunk táblázatot formázási céllal, csak akkor, ha tartalma lineárisan olvasva is értelmes marad. Az adattáblázatokhoz készítsünk olyan összefoglaló megjegyzéseket, melyek a sorról-sorra való olvasáskor a megértést segítik, valamint készítsünk összegzést a táblázat tartalmáról (summary attribútum). Használjuk értelemszerűen a thead és tfoot tag-eket. Ne használjuk formázáshoz a TH tag-et, sőt nem adattáblákban egyáltalán ne használjuk.
     
  • Script-ek, appletek, ActiveX objektumok. Nyújtsunk alternatívát arra az esetre, ha a böngésző az aktív elemek megjelenítését nem támogatja. Használjuk a noscript tag-et. Lehetőleg kerülni kell a popup ablakok használatát, és hogy a hivatkozásokban megadott oldalak új ablakban nyíljanak meg. Ha mégis szükség van rájuk, jelezzük, hogy a hivatkozás új ablakban nyílik meg.
     
  • Imagemap-ek. Ha imagemap-et használunk, válasszuk lehetőleg a kliensoldali régiómegadást (a map tag segítségével) a kiemelendő képrészletekhez, és társítsunk ezekhez szöveges leírást. Adjunk redundáns szöveges linkeket is.
     
  • Hivatkozások, navigáció. A hivatkozások szövegezése legyen olyan, hogy a szövegkörnyezetből kikerülve is utaljon a hivatkozás céljára. Erre azért van szükség, mert a vakok számára készített böngészők képesek külön kigyűjteni az oldalon található linkeket, így például a "kattints ide" szövegezés önmagában semmitmondó. Kerüljük az oldalon belül az azonos linkszövegeket, vagy ha mégis szükséges (jellemzően a "Tovább" linkek), a linknek adjunk egyedi title attribútumot. A fontosabb navigációs linkekhez rendeljünk accesskey-t és szükség esetén használjunk taborder-t.
     
  • Frame-ek. Lehetőség szerint kerüljük. Ha mégis szükséges, használjuk a noframes elemet és a tartalomra utaló frame-neveket.
     
  • Űrlapok. Azonosítsuk az összetartozó input mezőket és felirataikat a <label> tag-gel:
    <label for="id_felh_nev">Felhasználónév:</label>
    <input type="text" name="username" id="id_felh_nev" />

    Ez nem csak accessibility szempontból előnyös, de olyan extra szolgáltatást is nyújt a látók számára, hogy az input mezőhöz tartozó szövegre kattintva automatikusan az inputmezőre ugrunk (vagy kijelölődik a checkbox, radio), így a html oldal hasonlóan viselkedik a Windowsban megszokotthoz, tehát használata mindenképpen javasolt.
    A logikailag egy csoportba foglalható beviteli mezőket kapcsoljuk össze a <fieldset> elemmel. Adhatunk címet is a csoportnak (<legend>).
     
  • Nyelv. Adjunk meg HTML DOCTYPE-ot. A website használjon valid (X)HTML-t. Adjuk meg az oldal nyelvét (jellemzően <html lang="hu">). Ha az adott oldalon belül többnyelvű szöveget is megjelenítünk, az eltérő nyelvű szövegrészek jelölésére szintén használjuk a LANG attribútumot (<p lang="en">, <span lang="fr">, <a lang="de">, stb.). A modern képernyőolvasó szoftverek ilyenkor automatikusan megváltoztatják a beszédhang kiejtését, ezzel is elősegítve a vakok számára a leírt szöveg pontos megértését. Így megkímélhetjük a látogatót az angol kiejtéssel felolvasott magyar szöveg szürreális élményétől.
     
  • Ellenőrizzük a kész oldalakat. Használjunk ellenőrző eszközöket, checklist-eket. Az automatikus eszközökkel nem ellenőrizhető accessibility problémák felderítéséről a checklist-ek segítségével magunknak kell meggyőződnünk.

W3C WAI

A WAI (Web Accessibility Initiative), a W3C accessibility munkacsoportja fogalmazta meg a konzorcium akadálymentes webtartalomra vonatkozó ajánlásait (WCAG, Web Content Accessibility Guidelines), mely az alábbi fő koncepciókat tartalmazza:
  • Szöveges alternatívát szükséges nyújtani a vizuális és hallható tartalomhoz (jellemzően vakok, siketek részére).
  • Ne támaszkodjunk egyedül a színekre (rossz: "Kattintson a zöld gombra a továbblépéshez")
  • Valid (X)HTML és style sheet-ek használata.
  • Tartalom nyelvének megadása.
  • Ha táblázatokat használunk, szerkezetük legyen olyan, hogy lineáris szöveggé transzformálva is értelmezhetőek legyenek.
  • Az új technológiák (Java appletek, Flash intrók és menük, illetve más ActiveX objektumok) mellett nyújtsunk szöveges alternatívát.
  • A felhasználói felület minden funkciója legyen közvetlenül elérhető (azaz ne hozzunk létre fontos navigációs linkeket pl. kliens oldali script-tel).
  • Tervezzünk platformfüggetlenül.
  • Vegyük figyelembe a W3C szabványait és ajánlásait
  • Használjunk egyértelmű navigációs elemeket. A használt HTML elemek feleljenek meg a dokumentum struktúrájának. Ne használjunk tehát logikai elemeket formázási célra (h1...h6, blockquote), a h1...h6 hierarchiát tartsuk meg (pl. h1 után ne használjunk h4-et, átugorva a köztes heading szinteket).
  • Érhetően és egyszerűen fogalmazzunk.
Ezek az elvek checkpoint-okban öltenek testet, az egyes checkpoint-okat fontossági szintekre sorolták be. Három prioritási szintet állapítottak meg:
Level 1 (A)
A webes tartalom fejlesztőjének meg kell felelnie ezen követelményeknek, máskülönben egy vagy több érintett társadalmi csoport nem tud hozzáférni a közzétett tartalomhoz. Az első prioritási szintű checkpoint-ok teljesítése szükséges ahhoz, hogy egyes felhasználói csoportok egyáltalán használni tudjanak egy adott webes dokumentumot.
Level 2 (AA)
A webes tartalom fejlesztőjének ajánlott teljesítenie ezen követelményeket, máskülönben egy vagy több érintett társadalmi csoport nehezen tud hozzáférni a közzétett tartalomhoz. A második prioritási szintű checkpoint-ok teljesítése a hozzáférést nehezítő jelentős akadályokat szüntet meg.
Level 3 (AAA)
A webes tartalom fejlesztőjének teljesítenie lehet ezen követelményeket, hogy egy vagy több érintett társadalmi csoport könnyebben férhessen hozzá a közzétett tartalomhoz. A harmadik prioritási szintű checkpoint-ok teljesítése javítja a webes dokumentumok elérhetőségét.
A weboldalak akadálymentesítéséhez részletes útmutató és checklist található a WAI honlapján.
 

US Section 508

Az amerikai esélyegyenlőségi törvény (US Rehabilitation Act) 508. szakasza az amerikai kormányzati szervektől megköveteli, hogy
  • Ha elektronikus formában információt állítanak elő, szolgáltatnak, vagy használnak, azokhoz a megváltozott munkaképességű kormányzati alkalmazottak a többi munkatárs részére elérhető információhoz szintén hozzáférhessenek.
  • A Section 508 azt is megköveteli, hogy a közintézményekhez forduló megváltozott képességű állampolgár hozzáférhessen és használhassa mindazt az információt, amit az intézmény minden állampolgár részére egyébként szolgáltat.
Az S.508 ajánlásai a WAI-nál megengedőbbek, de a fő elvek hasonlóak. Tehát ha megcélozzuk a WAI-AA szintet, az amerikai szabványnak is meg tudunk felelni.

Ellenőrző eszközök

HTML online validator: http://validator.w3.org/
CSS online validator: http://jigsaw.w3.org/css-validator/
Accessibility validátorok:
Watchfire WebXAct: http://webxact.watchfire.com/,
HiSoftware Web-based Site Tester: http://www.hisoftware.com/accmonitorsitetest/
Firefox extension-ök:
HTML és accessibility validátor: https://addons.mozilla.org/extensions/moreinfo.php?id=249
Screen reader emulator: https://addons.mozilla.org/extensions/moreinfo.php?id=402
Internet Explorer:
AIS Web Accessibility Toolbar: http://www.nils.org.au/ais/web/resources/toolbar/index.html
 

Linkek

Általános ismertetők, leírások
How can I make my web site more accessible?
WAI
 

S.508

http://www.section508.gov/,
http://www.access-board.gov/508.htm,
http://www.section508.gov/index.cfm?FuseAction=Content&amp;ID=12.