A Picture Says a Thousand Words, But Not Really

Zoey imád az interneten böngészni. Élvezik, hogy elvesznek az információkkal teli, összekapcsolt hálóban, és olyan tudásdarabokat bogoznak ki, amelyek megérnek egy könyvjelzőt. De nem élvezik a nagy szövegtömegek átfutását. Jobban szeretik a képeket. Sok képet. Előbb nézik végig a szerelmük fotóit a Facebookon, minthogy egyáltalán fontolóra vennék az életrajzuk elolvasását. A mémek és vizualizációk iránti vágyakozásuk senkihez sem fogható ezen a bolygón, és az Instagram-sztorik is ezt tükrözik. Egyszerűen, tudod, erősen kötődnek a vizuálisan tanuló természetükhöz. És ezzel nincs is semmi baj.

De a világban nem csak Zoey van. Ott van Trung-Anh, ott van Sewon, ott van Nayon, ott van Venkatesh, ott van Zeqiu, ott van Dinko, ott van Sade, ott van Ivan, és ott van Mohammed. A WHO szerint a világ népességének (7,7 milliárd) legalább 29%-a (2,2 milliárd) valamilyen formában látássérült, ami a fent említett listán legalább 3 embert jelent. Hmm, szóval, umm … most, hogy tudjuk, hogy a lakosság 29%-a nem látja a vizuális tartalmakat, mit tegyünk? Továbbra is ragaszkodunk Fred Barnard “Egy kép többet ér ezer szónál” idézetének szó szerinti értelmezéséhez? Merem állítani, hogy nem. Nem mindig.

A gyakran feltett kíváncsi kérdés az, hogy – hogyan használják a látássérült emberek a számítógépet? Először is, azt hiszem, fontos megérteni, hogy a látáskárosodás nem a vakság szinonimája. Tehát, ha valakit fehér bottal látunk, tévedés lenne azt feltételezni, hogy teljesen vak. Ha a számítógép használatáról van szó, a látásuk szintjétől függően használhatnak képernyőolvasót a képernyőn megjelenő tartalom felolvasásához. Néhány népszerű képernyőolvasó a JAWS, az NVDA (ingyenes és nyílt forráskódú) és a VoiceOver (az Apple készülékekbe beépítve).

A világ helyzete

Nagyszerű! Tehát van módunk arra, hogy a képernyőolvasó felhasználók interakcióba lépjenek a számítógépeikkel vagy mobil eszközeikkel. De hogyan tudja egy képernyőolvasó elolvasni a rajongóik fotóit? Vagy a mémeket? Vagy grafikonokat/vizualizációkat? Az egyik lehetséges válasz erre az, hogy orvosi fejlesztéseket kellene tennünk, hogy meggyógyítsuk a látásukat, vagy bármi olyasmi, ami arra irányul, hogy legyen egy személyi gondozójuk/barátjuk/családjuk, aki elmagyarázza nekik, mi van a képernyőn. Egy másik lehetséges válasz egy olyan világ megteremtése, ahol lehetőségük van arra, hogy ezt ők maguk is megtehessék. Ha az Ön válasza az előbbihez állt közelebb, akkor egyértelműen képeznie kell magát, és meg kell ismerkednie a fogyatékosság társadalmi modelljének fogalmaival.

Képek

Fókuszáljunk a képekre. Ahhoz, hogy a képernyőolvasó képes legyen felolvasni egy képet, tudnia kell, hogy miről szól a kép, majd értelmesen kell bemutatnia azt a felhasználónak. Vegyünk például egy képet, amelyen egy család játszik az iker Husky-ikrekkel (Hajrá Husky-k!). Nem képernyőolvasó felhasználóként könnyű kitalálni, hogy mi történik a képen – nemcsak azt, hogy mi történik az előtérben, hanem a háttérben is. Például Jialin, a család egyik tagja olyan pólót visel, amelyen az áll, hogy “100% ember”. A képernyőolvasó teljes egészében ki tudja fejteni a jelenetet? Ehhez a képernyőolvasók arra támaszkodnak, hogy a fejlesztők vagy tartalomszerzők alternatív szöveget adjanak a képekhez az “alt” attribútummal, amelyet 1995-ben vezettek be a nyilvánosság számára a HTML 2.0 részeként (ha nem tudja, mi az az alt attribútum, vagy milyen jelentősége van, ez a cikk remek áttekintést nyújt az alt attribútumról). A HTML img elem így néz ki:

<img src="image1.jpg" alt="This is an image of two Huskies" />

A képernyőolvasó mostantól azt fogja olvasni: “Kép, Ez egy kép két Huskyról.”

A alt attribútum üresen hagyása vagy olyan értelmetlen szöveg megadása, mint a “Kép 1”, amint azt elképzelheti, nem túl hasznos. Még a “This is an image of two Huskies” alternatív szöveggel is, a továbbított információ közel sem közelíti meg azt, amit egy képernyőolvasót nem használó személy képes lenne kivenni, mint például a Jialin pólóján lévő szöveget. Ráadásul a képernyőolvasó már “képként” vagy “grafikaként” jelzi a tartalmat, ami a “Ez egy kép” szöveget feleslegessé teszi. Mindezt azzal a feltételezéssel, hogy a képet olyan felhasználó tette közzé, akinek hozzáférése van az alternatív szöveg beírásához szükséges kódhoz.

De mi a helyzet olyan helyekkel, mint például a közösségi médiaplatformok, ahol a képeket olyan felhasználók töltik fel, akiknek egyáltalán nincs hozzáférésük a kódhoz. A Facebook 2016-ban, több mint egy évtizeddel az indulás után kezdett mesterséges intelligenciát alkalmazni, hogy automatikusan generált alternatív szöveget adjon a képekhez, és lehetővé tette a felhasználók számára, hogy szükség esetén szerkesszék ezt a szöveget. Az Instagram követte, és tavaly, 8 évvel az indulása után bevezette ezt a funkciót. A kérdések azonban továbbra is ugyanazok: Mennyi információt kell tartalmaznia az alternatív szövegnek? Elég egy alapvető, magasabb szintű leírás? Amikor arról döntünk, hogy mit mutassunk be a képernyőolvasó felhasználóknak, feltételezzük és általánosítjuk, hogy a képernyőolvasó felhasználók mit keresnek a képen? Ha egy kép többet ér ezer szónál, akkor – átvitt értelemben – az alternatív szövegnek nem kellene ezer szónál többet mondania?

GIF-ek és animált képek

Leo erős mémjátékkal rendelkezik, és szakértője annak, hogy bármilyen alkalomra találjon macska-GIF-et. Tekintettel arra, hogy egy GIF több különböző kép kombinálásával jön létre úgy, hogy a végeredmény egy nagyon rövid videó benyomását kelti, vajon ugyanazokkal a problémákkal kell szembenéznünk, mint a képekkel? Rosszabb. Fejlesztőként természetesen hozzáadhatunk (és kellene is) egy alternatív szöveget, hasonlóan ahhoz, ahogyan azt a képek esetében tesszük (a GIF végül is egy képfájl). A közösségi médiaplatformokon azonban attól függően, hogy a GIF-et hogyan dolgozza fel a platform, vagy egy img elemmel jelenik meg alt attribútum nélkül, vagy egy video elemmel. A video elem egyáltalán nem támogatja a alt attribútumot.

Az összes GIF widget, amit eddig arra használtunk, hogy animált mémeket posztoljunk a Facebookon és az Instagramon, amik miatt menők vagyunk, meg minden, a képernyőolvasó felhasználók számára elérhetetlenek. Itt nem az a célunk, hogy megakadályozzuk Leót abban, hogy GIF-eket posztoljon (mert, miaú), hanem az, hogy az ilyen tartalmakat mindenki élvezhesse, és ne csak a lakosság egy részhalmaza.

Grafikonok és vizualizációk

Mindezzel még el sem jutottunk a “nehéz dolgokhoz”. A grafikonok és interaktív vizualizációk bemutatása. Yisu és Xuhai totális vizualizációs kockák, és minden kutatóhoz hasonlóan úgy vélik, hogy a grafikonok és a vizualizációk rendkívül értékesek; ritkán van tudományos dolgozat legalább egy grafikon vagy vizualizáció nélkül. A grafikon rendkívül vizuális tudást közvetít, és általában három fő technika egyikével ágyazzák be egy weboldalba:

1. képként statikus tartalom esetén.
2. HTML canvas elemként vagy SVG grafikonokként (képből különböző szempontok szerint frissítve) statikus tartalom esetén.
3. és/vagy interaktív vizualizációként JavaScript-könyvtárak használatával (amelyek általában HTML canvas vagy SVG-t használnak mögöttes mechanizmusként) dinamikus tartalom kiszolgálására és a felhasználóknak a grafikonnal való interakcióra.

Képként való használat esetén ugyanazok a megfontolások érvényesek, mint amelyeket fentebb tárgyaltunk, a tudományos információk bemutatásának további összetettségével. Mit mondjon az alternatív szöveg? Adjon áttekintést a grafikonról? Tartalmazzon-e statisztikai adatokat, például átlag, átlag, medián, módusz stb. És ha igen, melyeket? Mennyi információ túl kevés és mennyi túl sok? Ezek nehéz kérdések.

A HTML canvas maga is bittérképként jelenik meg, és a megfelelő tartalék tartalom megvalósítása nélkül számos hozzáférhetőségi kihívást jelent. Azonban számos technika létezik arra, hogy hozzáférhetővé tegyük őket, és csak egy Google-keresésnyira vannak. De természetesen a fejlesztők felelőssége, hogy ismerjék ezeket a technikákat és beépítsék a munkájukba – ez az, amit az idő múlásával javulni láttam, de nem tartanám vissza a lélegzetemet. Ezzel szemben az SVG-t bátorítják a hozzáférhető diagramokhoz, mivel a W3C specifikációi szerint a gyermekelemek elérhetőek az akadálymentesítési API számára. A böngészőtámogatáson azonban még mindig dolgoznak, és egy teljesen hozzáférhető SVG-grafikon elkészítése erőfeszítést és legalább némi alapvető SVG-ismeretet igényel, ami ismét a fejlesztők vállára háruló felelősség.

Ezek közül néhány aggály kezelésére létrehoztam az evoGraphs-t – egy jQuery plugint hozzáférhető grafikonok létrehozására, amely 2015-ben a W4A konferencián elnyerte a Delegate’s Award-ot az akadálymentesítési kihívásért. Kétségtelen, hogy nem kezeli az összes kiemelt kérdést a tudományos információk bemutatásának összetettségével kapcsolatban. Ezért a hozzáférhető grafikonok aktív kutatási területet jelentenek számomra és más kutatók számára.

Az interaktív vizualizáció (mint például a ChartJS, a Google Charts és a D3) esetében a dinamikusan frissülő információk megjelenítése trükkös. A legtöbb képernyőolvasó felhasználó nem használ mutató eszközt (például egeret, Trackpadet stb.), és a legtöbb interakció vagy kizárólag arra korlátozódik, vagy praktikusabban használható, ha bizonyos elemek fölött lebegés történik. Ilyen interakciók nélkül az interaktív vizualizációk célja a képernyőolvasó felhasználó számára ködössé válik, és vitathatatlan, hogy megfelelő megfontolás nélkül a tartalom megértése még zavarosabbá válhat.

Egyebekben számos modern grafikus könyvtár lehetővé teszi a dinamikus tartalommódosítást. Az információ továbbítása a képernyőolvasók felé, amikor a tartalom módosul, az ARIA-attribútumok megfelelő használatával kezelhető, amely 2014-ben W3C-ajánlássá vált, és őszintén szólva istenáldás. Az SVG-khez hasonlóan azonban a böngészők stabil támogatása az összes ARIA-funkcióra vonatkozóan még mindig folyamatban van, különösen az SVG-ken belüli használat esetén. Az ARIA nyújtotta lehetőségek teljes körű kihasználásához még mindig megfelelő fejlesztői képzésre van szükség.

A jövő útja

Azóta, hogy Tim Berners-Lee megalkotta a világhálót, napjainkig a technológia drasztikusan fejlődött. Sajnos ugyanez nem mondható el az ilyen technológiák hozzáférhetőségéről. Mire egy adott technológia hozzáférhetővé válik a fogyatékkal élők számára, a világ már továbblépett a fejlettebb technológiák felé. A felzárkózási játéknak tehát sosincs vége. És nem is fog – hacsak a hozzáférhetőség nem válik alapvető szemponttá az újabb technológiák fejlesztésénél.

De még nincs minden remény veszve. Nagy előrelépéseket tettünk és teszünk a webes akadálymentesítés területén, mind a tudományos kutatás, mind az ipari termékek terén. A hallgatókat és az új fejlesztőket megtanítják a hozzáférhetőség fogalmaira és a web akadálymentesítésének technikáira. A jövőre nézve úgy képzelem, hogy egy lépést hátrébb lépünk, és a szoftverek felhasználói igényekhez való igazításán gondolkodunk, nem pedig azon, hogy a felhasználók alkalmazkodjanak a szoftverhez. Például továbbra is azt feltételezzük, hogy egy képernyőolvasó felhasználó milyen információkat szeretne kinyerni egy képből, vagy olyan eszközöket építünk, amelyek többet tudnak meg a felhasználóról, és olyan információkat jelenítenek meg, amelyeket a felhasználó jobban szeret felfogni? Számomra a jövő az általánosítástól távolodik, és közelebb kerülünk a személyre szabáshoz – egy olyan világhálóhoz, amely valóban felhasználó-központú.

1. “Látáskárosodás és vakság”. Egészségügyi Világszervezet, World Health Organization, https://www.who.int/news-room/fact-sheets/detail/blindness-and-visual-impairment. Hozzáférés: 2019. okt. 20.
2. “A Picture’s Worth: D. H. Hepting, Ph.D.” A Picture’s Worth | D. H. Hepting, Ph.D., http://www2.cs.uregina.ca/~hepting/projects/pictures-worth.
3. HTML 2.0 Materials, https://www.w3.org/MarkUp/html-spec.
4. Sharif, Ather, and Babak Forouraghi. “evoGraphs-A jQuery plugin to create web-accessible graphs”. 2018 15th IEEE Annual Consumer Communications & Networking Conference (CCNC), 15. IEEE éves fogyasztói kommunikációs & konferencia. IEEE, 2018.
5. “WAI-ARIA áttekintés”. Web Accessibility Initiative (WAI), https://www.w3.org/WAI/standards-guidelines/aria.