Informatika és tudomány

Gyurkity Péter

Nem segítik a weboldalak a fogyatékkal élőket

Első alkalommal végeztek globális kutatást a weboldalak akadálymentességével kapcsolatban, amely siralmas eredménnyel zárult. A megvizsgált 100 portálból mindössze 3 felelt meg a minimális követelményeknek.

A brit Nomensa az ENSZ megbízásából végezte el kutatását, amelynek keretében összesen 100 weboldalt vizsgáltak meg akadálymentességi szempontok alapján. Forgalmuk és funkciójuk alapján fontos, gyakran látogatott kormányzati, vállalati és egyéb intézményi portálokat kerestek fel 20 különböző országban, és igyekeztek összevetni ezen oldalakat a WCAG (Web Content Accessibility Guidelines) által felállított követelményrendszerrel. A lista azon alapvető lehetőségeket foglalja össze, amelyek a fogyatékkal élők, mozgásukban, látásukban, stb. korlátozott emberek számára hivatott megkönnyíteni az internetes böngészést.

A kutatás siralmas eredménnyel zárult, mivel mindössze három portál felelt meg az alapvető, vagyis minimális követelményeknek. Ezek sorrendben a német kancellár, a spanyol kormányzat, valamint a brit miniszterelnök weboldala, amelyek tehát eleget tesznek az A-szint követelményeinek. 73 százalékban mérhető azok aránya, amelyeknél Javascriptet használnak a fontosabb funkciók működtetéséhez, ez viszont az internetezők 10 százaléka számára nem elérhető. 97 százaléknál a betűméret skálázása körülményes, 98 százalék pedig nem mindenben követi az eredeti ajánlásokat a kódban. Simon Norris, a Nomensa ügyvezető igazgatója azonban igyekezett leszögezni, hogy több oldal is elérhető közelségben van az alapszint teljesítéséhez, így a közeljövőben javulhat a helyzet.

Az ENSZ vasárnap tartotta meg a fogyatékkal élők nemzetközi napját. Ebből az alkalomból maga Kofi Annan főtitkár jelentette ki, hogy az internetet mindenki számára elérhetővé kell tenni, és a kormányzatok, valamint a privát szektor hamarosan felismeri az ebben rejlő szociális és gazdasági előnyöket. A fogyatékkal élők jogairól szóló nemzetközi egyezmény - amelyet várhatóan ebben a hónapban fogadnak el - segíthet felgyorsítani ezt a folyamatot.

Hozzászólások

A témához csak regisztrált és bejelentkezett látogatók szólhatnak hozzá!
Bejelentkezéshez klikk ide
(Regisztráció a fórum nyitóoldalán)
  • Dj Faustus #22
    "Például elég banális az, hogy "a weboldalon hangos háttérzene szól ami túlkiabálja a felolvasást" - hát egy felolvasós böngészőnek nem az lenne a dolga, hogy csak a szöveget játssza le, a zenét ne?"
    1. Ez nem csak a felolvasószoftverek felhasználóit zavarja, hanem másokat is - ugyanis általában az ember akkor szeretne zenét hallgatni, ha ő azt kívánja (megnyomja a lejátszás gombot).
    2. A felolvasószoftverek a böngészőket (és egyéb programokat) egészítik ki (tehát a szöveg->hang konverziót hozzák létre), így a hang letiltását a böngészőben kellene megoldani.
    Ez még normál audió/videó formátumoknál könnyedén megoldható (nem rakod el a böngészőhöz a médialejátszó kiegészítést), de Flash esetén ezt hogy iktatod ki (ha a Flasht azért használni szeretnéd)?
    3. A felelősség elsődlegesen a tartalomszolgáltatóé. Ugyanúgy mint a műszaki eszközök használati utasításaiban a figyelmeztető bekezdéseknek (Ne használja a készüléket vizes helyiségben!); illetve a játékokban az epilepsziásokra vonatkozó dolgok (villódzás).

    "Nem igazán világos számomra, áruljátok már el, hogy miért is baj a táblázat, mi benne a nem akadálymentes?"
    1. Mivel a HTML nyelv első változatait nem professzionális layoutok kialakítására hozták létre, ezért nem volt a HTML nyelvben olyan megoldás, amivel ezt el lehetett volna érni.
    Viszont az Internetet gyorsabban elfoglalták a designos oldalt kívánó piaci szereplők, mielőtt valami elterjedt, bejáratott megoldás lett volna rá (közben meg dúlt a böngészőháború). Így szükségmegoldásként a táblázatok jöttek be a képbe.
    Közben viszont a böngészők valamelyest "letisztultak", a különböző webes nyelvek lehetőséget kezdtek biztosítani a design-os kinézethez.
    2. A táblázatokat lehet használni, csak nem az oldalszerkezet kialakítására. Az egyik ok az, hogy a klasszikus egymásba ágyazott táblázatokkal történő pozícionálás során az egyes elemek vizuális sorrendje nem egyezik meg a HTML forráskódjában található tartalmi részek sorrendjével. Másrészt a csak táblázatos oldalszerkezet használata szükségtelenül naggyá, többször betöltendővé (a külön CSS file-t elég csak egyszer betölteni) teszi az oldalt. Bővebben erről itt, illetve itt.

    "Ez az ügyes kis progi átkonvertálja úgy az oldalskat, hogy a táblázatban levő dolgokat egymás alá teszi, tehát nem jeleníti meg a táblázatot, csak az egyes cellák tartalmát, egymás alatt. "
    Nehezebb egy programnak átkonvertálni a megfelelő sorrendre való sorbarendezés, mint eleve logikusan sorrendbe szervezni az oldalt.

    "teljesen felesleges lenne akadálymentesíteni, mivel a vakok általában nem szoktak"
    Persze vannak olyan esetek, ahol eléggé nehéz a teljes akadálymentesség megoldása (például egy zenét hogyan közvetítesz egy süketnek? vagy egy absztrakt művészeti alkotást/képet hogyan mutatsz be egy vaknak? vagy hogyan mutatod meg a virágok illatát egy olyan embernek aki elveszítette szaglóérzékét?), de az esetek többségében azért megoldható (és sok esetben elvárható is lenne) az akadálymentesítés.
  • Gerygrey #21
    Fejleszteni kéne a felolvasóprogramokat. Például elég banális az, hogy "a weboldalon hangos háttérzene szól ami túlkiabálja a felolvasást" - hát egy felolvasós böngészőnek nem az lenne a dolga, hogy csak a szöveget játssza le, a zenét ne?
    Nem igazán világos számomra, áruljátok már el, hogy miért is baj a táblázat, mi benne a nem akadálymentes? Mondok egy példát: én most egy se p910 mobilról vagyok fent, opera mini böngészővel. Ez az ügyes kis progi átkonvertálja úgy az oldalskat, hogy a táblázatban levő dolgokat egymás alá teszi, tehát nem jeleníti meg a táblázatot, csak az egyes cellák tartalmát, egymás alatt. Szerintem innen csak egy lépés az olyan webböngésző, amelyfogja ezt a táblázatból kiszaaított szöveghalmazt, és felolvassa.

    Különben szomorú hogy a weboldalak mindössze 3%-a akadálymentes, de ez az összes weboldalra vonatkozik. Például egy photoshop tutorialokkal foglalkozó lapot, vagy az én sims 2 oldalamat teljesen felesleges lenne akadálymentesíteni, mivel a vakok általában nem szoktak photoshopoz ni vagy simssel játszani...
  • mogyi925 #20
    Élő példaként a GMail levelezőt érdemes megvizsgálni: egy brutáljó AJAX-os felület, de JS nélkül links alatt is kényelmesen és hatékonyan használható; erről a szemléletről próbálok beszélni, csak 30 óra ébrenlét után már nem megy annyira. :-)
  • mogyi925 #19
    Pedig nem egy halálbonyolult dologra kell gondolni. A szerveroldali osztályokban (amelyek a honlap egyes funkcióinak felelnek meg) az XML-kimenetet előállító metódus mellé kell implementálni egy HTML-kimenetet generáló metódust is, illetve a honlapot a HTML-kimenetre felépíteni, a felhasználónál a böngészőben pedig diszkrét JS-tel szépen felülbírálni a linkek, formok eseményeit. Vázlatosan úgy érdemes gondolni erre a mókára, mint egy szerver-kliens modellre: a honlap lelke (ez többnyire leginkább a honlap mögött dolgozó adatbázis elérését és manipulálását megvalósító osztályokat jelenti) a szerver, amelyhez két kliensed van, ami tulajdonképpen a megjelenítést végzi. Ami a főlap megnyitásakor betöltődik, az lesz egy olyan kliens, ami a szerveroldalon elintézi a megjelenítést, azaz a HTML-kód generálását (nem a képernyőn való megjelenítést értem ezalatt). Ez persze üzemel rendesen, keresőbarát linkekkel, ha viszont van JS-támogatás, akkor a főoldal betöltődése után elindul az AJAX-kliens, ami a megjelenítést illetve a szerverrel (ezalatt az adatbázis-manipuláló és input-feldolgozó scripteket értve, nem pedig magát a webszervert) való kommunikációt végzi.

    Tulajdonképpen a beolvasó- és adatfeldolgozó, adatelőállító osztályok mellé kétféle megjelenítőt kell írni: az egyik megjelenítő a szerveroldalon fut, és HTML-kódot generál (mindig előállítva egy teljes oldalt), ez gyakorlatilag ugyanaz, mint egy mezei honlap, illetve egy AJAX-os megjelenítőt, ami az iménti osztályokkal a háttérben kommunikál, és az adatok alapján a kliensnél állítja elő a HTML-kódot, dinamikusan.

    Például nézzünk egy Google Maps-oldalt, pl. egy útvonalkeresőt. JavaScript nélkül nyilván nem fog megjelenni maga a térkép, tehát az adatok vízuális megjelenítését rábízhatjuk egy csilli-villi ablakozós AJAX felületre. JavaScript nélkül viszont a térkép helyett szerveroldalon előállíthatunk egy listát az útvonal checkpoint-jaiból, amit egy igényes táblázatba rendezve HTML-ként jeleníthetünk meg. A checkpointokat előállító scriptet elég egyszer megírni, hiszen egy útvonalat nyilván ezek a pontok fognak meghatározni, ami megjelenítéstől függetlenül mindig ugyanaz. Csak egyrészt egy interaktív térképen kis ikonokkal jeleníted meg, másrészt pedig ezen pontok adatait állítod elő egy táblázatban. Alapból a táblázat töltődik be, amit JS-ből rögtön elrejtesz, és előállítod a helyére a térképet a kis ikonokkal együtt.

    Persze vannak olyan alkalmazások, amik mindenképp igénylik a JavaScriptet (pl. egy komplex szövegszerkesztő), de érdemes gondolni arra, hogy egy alkalmazás adatait JS nélkül is el lehessen érni (pl. egy webshophoz, kvízjátékhoz, szochálós portálhoz illik JS-mentes felületet is gyártani).
  • Inquisitor #18
    Minap csodálkoztam rá egy Weboldalon egy csúszkára(!) amivel a betü és képméret állítható a weboldalon azok részére akik tényleg rosszul látnak. Hát nem sok helyen találkoztam ilyennel se mostanában.
  • Griphons #17
    Nem lehetetlen feladat a diszkrét JavaScript, és a fentiek az AJAX-szal és a "webkettő" mizériával is összhangban tudnak maradni.


    Én még csak most ismerkedem az AJAX-szel, de amit eddig tudok annak sok köze nincs a diszkrét javascripthez. Egy nemlátónak egy AJAX-szel készített oldal nem lehet sokkal jobb mint a Flash-sel készített. Hiszen az AJAX technológia lelke maga a javascript. Persze, lehet, hogy kis odafigyelés és nagy szakértés mellett ezt is meg lehet oldani, de az már biztos nagyon sokba kerül.

    A linkeket kösz, átolvasom.
  • mogyi925 #16
    Akkor egy-két előadás anyaga, amit minden komoly webfejlesztőnek illene ismernie:

    Bártházi András: Diszkrét JavaScript
    Károly György Tamás: Elérhetőség...
    Beszélgetés a webes programozás vakokat érintő kérdéseiről

    Nem kell kétségbeesni, ha 2005-ben vagy 2006-ban lemaradtatok a fenti előadásokról, mert idén is lesz WebKonferencia, és valószínűleg ott lesz Torma Zsolt és Károly György Tamás is, akik a témával minden Konferencián szoktak foglalkozni, érdekes előadásokon. Mondjuk - egyszerre általában három előadás zajlik a Konf-on - sajnos látszik a résztvevők számán, hogy ez elég kevés embert érdekel, viszont a kijövők arcán az szokott tükröződni, hogy megértették az elmondottakat, és hatással volt rájuk. (Zsolt vak programozó, és mindig meg szokta mutatni, hogy egy weboldalból mit érzékel a felolvasóprogram. Döbbenet, hogy némelyik - látók számára teljesen triviális - lap használhatatlan, ha csak hallod a rajta lévő szöveget. [A felolvasó általában megmondja azt is, hogy az adott szöveg milyen elemként szerepel a honlapon, pl. egy képfeliratnál, linknél, táblázatfejlécnél, header-nél külön kiemeli, hogy miről van szó. Példának okáért az sg.hu fórumaira egy vaknak kevés esélye van képet feltölteni, hiszen pl. a hozzászólás alatti gombokról csak annyit tud meg, hogy az ott egy kép objektum, pedig az alt="" tag helyes kitöltése esetén a program meg tudná neki mondani, hogy ez egy kép, a felirata "képfeltöltés", és kattintható.)

    A legtöbb flash-weboldal pedig egyenesen használhatatlan a vakok számára, főleg, ha a szövegeket is képként tárolják.

    Az SG egyébként elég minimálisan kezeli a problémát: van egy külön vakbarát oldal, de képzeld el, hogy szemüveges vagy, és az SG külön oldalt kínál a szemüvegesek, vagy épp a kövérek számára - ez így elég diszkriminatívan hangzik. Sokkal barátságosabb, ha maga a főoldal vakbarát (szebben kifejezve: elérhető), és a látássérült olvasó nem érzi magát kirekesztve.

    A másik ok, ami miatt érdemes ügyelni ezekre a dolgokra, az, hogy egy weboldal célja nyilván a minél több látogató elérése, ehhez pedig kulcsfontosságú a keresőkben elért helyezés. Nos, a keresők is körülbelül annyit "látnak" egy oldalból, amennyit egy vak, hiszen a kereső adatbázisába illetve a felolvasóprogram hangkimenetére sok szempontból hasonló szűrésen keresztül kerül be a weboldal tartalma. Keresőoptimalizálás és vakbarátság (elég rossz kifejezések, együttesen elérhetőt szoktak mondani ezek helyett) szempontjából a minimum az, hogy az adott weboldal teljes funkcionalitású legyen JavaScript nélkül, karakteres böngészőben (pl. links) is. Nem lehetetlen feladat a diszkrét JavaScript, és a fentiek az AJAX-szal és a "webkettő" mizériával is összhangban tudnak maradni.
    Van egy kék tó a fák alatt,
    Ha belet eszem, lehűti a lábamat.
  • Dj Faustus #15
    "sly007 jól látta a dolgot amit írtam, de te Dj Faustus nem"
    Nono, azért eléggé reklámszagú - bár csak a régi oldaladat is hozod fel példaként, és tegyük fel nem szándékosan - ha az oldalad címét/nevét három egymást követő hozzászólásban (nem az aláírásban) tünteted fel. Ha ezt egy hozzászólásban tetted volna meg, egy szavam nem lett volna.

    "egy vak hogyan tudná elolvasni azt ami a weboldalakon található"
    Számára az olvasás folyamata auditív módon történik, vagy tapintással (Braille-képernyő).
    Gyengénlátók számára pedig ott a megnövelt betűméret, esetleg a megnövelt kontrasztú változat vagy a felolvasószoftver.
  • FLD #14
    sly007 jól látta a dolgot amit írtam, de te Dj Faustus nem, de nem gond(ezt most nem gúnyolódásként írtam, hanem hogy ki értelmezte jól amit írtam pár órája)
  • FLD #13
    "Na ez amit fennt is látsz az tényleg reklám" ezalatt a WOLFISHNET-es dolgot értem.
További bejegyzések a fórumban...