Akadálymentes weboldal: mit nem tár fel a képernyőolvasós teszt?

Ha akadálymentes weboldalról esik szó, sokaknak elsőként egy látássérült ember jut eszébe, aki nem látja a képernyőt.

Neki egy program, a képernyőolvasó hangosan felolvassa az oldal szövegét, gombjait és linkjeit, ő pedig billentyűzettel vagy érintéssel navigál közöttük.

Sok fejlesztőcsapatban ezért az ellenőrzés is ennyiből áll, mielőtt az oldal új változata a felhasználók elé kerülne: valaki elindít egy ilyen programot, és végighallgatja vele a nyitóoldalt.

Ha a program minden gombnál felolvassa, mire való, és minden képhez van szöveges leírás, az oldal mehet élesbe.

Ezzel viszont csak egyetlen felhasználói csoport elakadásai derülnek ki. A többiek akadályai élesben is ott maradnak. A gyengénlátó felhasználónak az oldal nagyításakor szétcsúszik a menü, akinek pedig remeg a keze, az nem tud rákattintani az apró jelölőnégyzetre.

Igaz, a felolvasás mellett sok csapat automata tesztet is futtat, és a kettő másra figyel. A képernyőolvasós próbánál egy ember hallgatja végig az oldalt, az automata eszköz viszont a kódot nézi át, és előre megadott szabályok alapján jelzi a géppel kimutatható hibákat.

Ilyen a Lighthouse, a Chrome fejlesztői eszközeibe épített ingyenes oldalellenőrző is, amely többek között (1) címke nélküli gombokat, (2) alt szöveg nélküli képeket és (3) kontrasztproblémákat jelez.

Amikor azonban az eszköz jelentése ezt a hármat egymás alatt sorolja fel, könnyű mindhármat a képernyőolvasót használók gondjának tartani.

A címke nélküli gomb és az alt szöveg nélküli kép a képernyőolvasót használókat akasztja meg, mert ilyenkor a program nem tud mit felolvasni.

A kontrasztprobléma viszont egy másik csoportot érint:

• a képernyőolvasó a betű színét és a háttérhez mért kontrasztját nem érzékeli,
• a halványszürke feliratot pedig a gyengénlátó felhasználó tudja nehezen kiolvasni.

Az akadálymentesség tehát jóval több a felolvasásnál, és ezt a képernyőolvasót legjobban ismerők is így látják.

Vak akadálymentességi szakemberek, akik naponta NVDA-val vagy TalkBack-kel, a két legismertebb képernyőolvasó programmal használják a webet, maguk hangsúlyozzák, hogy a saját mindennapi használatuk csak a képernyőolvasós teszteléshez mérvadó.

Hogy az akadálymentesség valójában mekkora terület, azt az érintettek száma és a web leggyakoribb hibái mutatják meg a legjobban, és ezekből az is kiderül, hogyan érdemes úgy felépíteni az auditot, hogy egyik csoport se maradjon ki.

Kiket szolgál az akadálymentes weboldal a képernyőolvasót használókon kívül?

Akadálymentes az a weboldal, amelyen a fogyatékossággal vagy tartós betegséggel élő és az átmenetileg korlátozott felhasználó is végig tudja vinni a feladatát, legyen az vásárlás, banki átutalás vagy egy ügyintézési űrlap.

A fogyatékossággal élők számáról a WHO ad becslést: világszerte 1,3 milliárd ember, a népesség 16%-a, vagyis nagyjából minden hatodik ember él jelentős fogyatékossággal.

Még a látássérült emberek között is jóval többen gyengénlátók, mint vakok. Az IAPB adatai szerint világszerte 43 millió vak és 295 millió közepesen vagy súlyosan gyengénlátó ember él. Hallásvesztéssel pedig a WHO szerint 1,5 milliárdan élnek.

Magyarországon a legutóbbi népszámláláson a magukat fogyatékosnak vallók 41%-a mozgáskorlátozott, 15%-a értelmi fogyatékos volt. Ugyanebben a körben a gyengénlátók aránya 13% volt, a nagyothallóké 9%, a vakoké pedig 5% alatt maradt.

A fogyatékossággal élőkön túl azok is érintettek, akiket egy sérülés vagy betegség csak egy időre korlátoz (ideiglenes korlát), vagy akiket egy adott helyzet akadályoz a használatban (helyzeti korlát).

A Microsoft inkluzív tervezési anyaga ide sorolja például a törött karral élőket és a csecsemőt karon tartó szülőket is.

Ebből a szemszögből az akadálymentesség előbb-utóbb szinte mindenkit érint: elég hozzá egy sportsérülés, egy szemműtét utáni lábadozás vagy egy tűző napon tartott telefon, amelyen alig látszik a halvány szöveg.

A web leggyakoribb hibáját képernyőolvasóval meg sem lehet találni

A tűző napon alig olvasható halvány szöveg a weben mindennapos jelenség. A WebAIM Million legutóbbi mérése egymillió weboldal nyitóoldalát vizsgálta, és ez volt a leggyakoribb hiba: az oldalak 83,9%-án talált alacsony kontrasztú szöveget, egy évvel korábban még 79,1%-ukon.

A web első számú akadálymentességi hibáját a képernyőolvasós teszt elvből sem észlelheti.

Mivel a kontrasztot a gép jól méri, csábító lehet a többi hibát is automata eszközökre bízni.

Csakhogy a brit kormány digitális szolgálata, a GDS egy tesztben 13 automata eszközt futtatott le egy olyan oldalon, amelybe 142 ismert akadályt építettek. A legjobb eszköz ezek 40%-át találta csak meg!

A mérés már évekkel ezelőtt készült, a WebAIM azonban ma is kimondja, hogy ha egy eszköz nem jelez hibát, abból még nem következik, hogy akadálymentes weboldalról van szó.

Vannak olyan hibák is, amelyeket sem a képernyőolvasós, sem az automata teszt nem hoz elő magától. Az érthetetlen hibaüzenet, a mobilon nehezen megnyomható, apró gomb és a túl rövid időkorlát főként a kognitív és a mozgásszervi korláttal élő felhasználókat akasztja meg, és jellemzően csak akkor derül ki, ha a tesztelő kifejezetten ezeket keresi.

A képernyőolvasós teszt a felolvasás hibáit, az automata teszt a géppel mérhető hibákat mutatja meg, minden más akadályt felhasználói csoportonként kell felkutatni.

Mit kell külön ellenőrizni felhasználói csoportonként?

Minden csoport máshol akad el, ezért mindegyikhez más sikerkritériumok tartoznak a WCAG 2.2-ben, a webes akadálymentesség nemzetközi irányelvében.

Ezek számozott követelmények, mindegyik a három szint (A, AA, AAA) valamelyikébe tartozik, és mivel a jogszabályok jellemzően a középső, AA szintet kérik számon, a teszteknél is ez az alapmérce.

Gyengénlátók és színtévesztők

A legnagyobb látássérült csoportnál a kontraszttal kezdődik a munka.

A fehér háttéren álló halványszürke felirat a tervben letisztultnak hat, ezért sok felületen divatos. A WCAG viszont minimális kontrasztarányt ír elő a szöveg és a háttér között, és az ilyen feliratok könnyen ez alá esnek.

A kontrasztérzékenység ugyanis a gyengénlátók gyakori panasza: a WebAIM gyengénlátó-felmérésében a válaszadók közel fele, 46,8%-uk számolt be róla, és tízből hatan a fényre vagy a vakításra is érzékenyek voltak.

Az irányelv a színhasználatot is szabályozza: információt nem szabad csak színnel jelezni. Ez azért fontos, mert az észak-európai származású férfiak közül minden tizenkettedik vörös-zöld színtévesztő. A színtévesztő felhasználónak a csak pirossal keretezett kötelező mező vagy a piros és zöld vonalakkal rajzolt grafikon könnyen félreérthető. Ezért a szín mellé mindig kell egy második jel is, például szöveges jelzés, egy csillag a kötelező mező mellett vagy eltérő vonaltípus a grafikonon.

A színkontraszt ellenőrzése géppel percek kérdése, a nagyítást viszont kézzel kell kipróbálni: felnagyítva is olvasható és kezelhető marad-e minden, vagy a sorok kilógnak a képernyőről, és oldalra kell görgetni az olvasásukhoz.

Ez a próba a mindennapi használatot követi: a már idézett WebAIM-felmérésben a válaszadók egy része az eredeti méret négyszeresére vagy még nagyobbra nagyította az oldalt, nagyjából a felük pedig magas kontrasztú módot használt.

Siketek és nagyothallók

A videó képben és hangban is közvetíthet fontos információt, és a nézők egy részéhez ezek közül az egyik nem jut el. Ezért a WCAG az előre rögzített videókhoz hangleírást kér, amely elmondja azokat a történéseket, amelyek csak a képen látszanak.

A beszédhez és a lényeges hangokhoz pedig feliratot ír elő, az előre rögzített videók mellett az élő közvetítésekhez is.

Magyarországon a SINOSZ becslése szerint nagyjából 60 ezer siket vagy súlyosan nagyothalló ember él. A felirat ennél jóval több nézőnek segít: egy amerikai felmérésben a válaszadók 69%-a mondta, hogy nyilvános helyen hang nélkül néz videót, és ilyenkor a beszédet csak a feliratból tudja követni.

A felirat formátuma is számít. A ki-be kapcsolható felirat külön szövegsáv, amelyet a néző maga kapcsol be, és sok lejátszóban a megjelenését is beállíthatja. A beégetett felirat a kép része, így se kikapcsolni, se a néző igényeihez igazítani nem lehet.

Mozgásszervi korlát és mobil

A mozgásszervi korláttal élőknél az alapkövetelmény az, hogy a teljes folyamat csak billentyűzettel is végigvihető legyen.

A WCAG 2.2 egyik új kritériuma emellett alsó határt szab a kattintható és megérinthető elemek méretére, hogy a gombot, a linket vagy a jelölőnégyzetet remegő kézzel vagy mobilon, egy ujjal is el lehessen találni. Ahol az elem kicsi, a körülötte hagyott szabad hely véd attól, hogy a felhasználó véletlenül a szomszédját nyomja meg.

Egy másik új kritérium a húzó mozdulatokhoz kér olyan alternatívát, amely sima kattintással vagy koppintással is működik, például egy csúszka mellé beírható mezőt vagy plusz-mínusz gombot.

A mozgásszervi korláttal élők egy része hangvezérléssel használja a webet. Ilyenkor a felhasználó a képernyőn látható szövegre hivatkozik, például azt mondja: „Kattints a Tovább gombra.” Ez csak akkor működik, ha a gomb kódban megadott neve is tartalmazza a látható szöveget, különben a hangvezérlés nem talál olyan elemet, amelyre a parancs illik.

Vesztibuláris zavarral élők és a mozgó tartalom

A mozgó tartalom egy újabb csoportot érint. A parallaxis, valamint az automatikusan induló vagy végtelenített animáció a vesztibuláris zavarral élőknél, vagyis azoknál, akiknek az egyensúlyérzékelése sérült, tüneteket, például szédülést válthat ki.

Ezért a nagy operációs rendszerek kisegítő beállításai között bekapcsolható a mozgás csökkentése. Egy akadálymentes weboldal ezt ki tudja olvasni, és ilyenkor a parallaxist és a dekoratív animációkat leállíthatja vagy egyszerű áttűnésre cserélheti.

A WCAG azt is kéri, hogy a görgetésre vagy kattintásra induló mozgásanimációt ki lehessen kapcsolni, ha nem nélkülözhetetlen a működéshez. Ez a követelmény viszont csak a legszigorúbb, AAA szinten szerepel, ezért egy AA-ra szűkített audit könnyen átsiklik fölötte.

Hogyan lesz akadálymentes egy űrlap a kognitív korláttal élőknek is?

A webshop pénztároldalán vagy egy online időpontfoglalásnál az űrlap az utolsó lépés, ezért aki ott elakad, nem tudja befejezni a vásárlást vagy a foglalást, akkor sem, ha minden más tekintetben akadálymentes a weboldal.

Az űrlapon ráadásul az eddig sorra vett csoportok akadályai gyakran egyszerre jönnek elő. Ugyanazon a pénztároldalon a gyengénlátó felhasználó nem veszi észre a halvány mezőkeretet, a billentyűzettel navigáló pedig nem tud eljutni a Fizetés gombig.

Sokszor már az alapok is hiányoznak: a WebAIM már idézett mérése szerint a nyitóoldalak 51,0%-án van címke nélküli űrlapmező, ami az előző évhez (48,2%) képest nőtt. Címke nélkül a képernyőolvasó nem tudja megmondani, mit vár a mező, és a hangvezérlés sem talál olyan nevet, amellyel a mezőre hivatkozni lehetne.

A címke mellett az is sokat számít, hogyan jelzi az űrlap a hibát. Erről a Nielsen Norman Group és a W3C kognitív akadálymentességi útmutatója hasonlóan gondolkodik. Eszerint a jó hibaüzenet:

• a színen kívül ikonnal is jelez,
• a mező mellett jelenik meg, miután a felhasználó elhagyta a mezőt,
• megnevezi a problémát, az okát és a javítás módját,
• és ismételt hibánál több segítséget ad, akár egy telefonszámot is.

Ehhez a mércéhez mérve egy általános „Hibás formátum” felirat kevés: nem derül ki belőle, mi a pontos gond, és mit kell másképp beírni a mezőbe.

A kognitív korláttal élő felhasználónak sokszor az okoz gondot, ha kitöltés közben fejben kell tartania valamit, például egy korábbi lépésben már megadott adatot vagy egy jelszót.

Ezért kéri a WCAG 2.2, hogy:

• egy folyamatban ne kelljen ugyanazt az adatot kétszer beírni,
• a belépéshez pedig ne kelljen kognitív tesztet megoldani, például kódot fejből átírni, ha nincs más lehetőség.

A kognitív korláttal élőknél a hibaüzenet szövegén is sok múlik. Hogy egy üzenet érthető-e, azt automata eszköz nem tudja megmérni, ezért a hibaüzeneteket kézzel, a felhasználó szemével érdemes egyenként végigolvasni.

Magyar oldalon: nyelvi jelölés

Egy magyar nyelvű akadálymentesített weboldalon az érthetőség már a nyelvi jelöléssel kezdődik. Ha az oldal html eleméről hiányzik a lang=”hu” attribútum, a képernyőolvasó a felhasználó alapnyelvének kiejtési szabályaival olvashat fel. A WebAIM mérésében a hiányzó dokumentumnyelv a nyitóoldalak 13,5%-án fordult elő.

Ugyanezért az idegen nyelvű szavakat és a termékneveket is külön nyelvi jelöléssel érdemes ellátni.

A csoportonkénti ellenőrzések ebben a sorrendben adnak teljes auditot:

1. automata vizsgálat, például WAVE-vel vagy axe DevTools-szal, kiindulópontként,
2. bejárás csak billentyűzettel, látható fókusszal,
3. az oldal felnagyítása többszörösére,
4. szürkeárnyalatos nézet, amelyben minden állapotnak és hibának szín nélkül is érthetőnek kell lennie,
5. a videók lejátszása némítva és kép nélkül,
6. célméret és gesztusok mobilon, egy kézzel és egy ujjal,
7. teszt bekapcsolt csökkentett mozgással,
8. a hibaüzenetek kognitív végigjárása,
9. és végül a képernyőolvasó és a hangvezérlés.

A képernyőolvasó azért kerül a sor végére, mert a hiányzó címkéket és alt szövegeket addigra az automata vizsgálat, a fókuszhibákat pedig a billentyűzetes bejárás már előhozta. Így ebben a körben arra figyelhetsz, hogy felolvasva is követhető-e az oldal, és hangparancsokkal is végig lehet-e vinni rajta a feladatot.

A teljes körű auditot a jog is indokolja: a 2022. évi XVII. törvény, az Európai Akadálymentesítési Irányelv (EAA) magyar átültetése, már hatályban van, és többek között az e-kereskedelemre és a lakossági banki szolgáltatásokra is vonatkozik.

A műszaki mérce közben szigorodik: az EN 301 549 uniós akadálymentességi szabvány legfrissebb, V4.1.1-es változata a webre már a WCAG 2.2-t veszi alapul, és az ezzel bekerülő új kritériumok éppen azokat a csoportokat szolgálják, amelyek akadályait a képernyőolvasós teszt nem mutatja meg.

Az új változatra viszont csak akkor lehet támaszkodni a jogi megfelelés igazolásánál, ha az EU Hivatalos Lapja is kihirdette. Ennek várt időpontja a Deque összefoglalója szerint már módosult, ezért érdemes utánanézni, hogy megtörtént-e.

Amit a lista sem pótol

Az ellenőrzőlista a hibák megtalálásában segít, az érintett felhasználókat viszont nem helyettesíti.

A Microsoft inkluzív tervezési anyaga szerint a bekötött szemmel vagy füldugóval végzett szimuláció félrevezető lehet. Azt, hogy hogyan alkalmazkodik valaki a saját korlátjához, csak az érintettektől lehet megtanulni.

A képernyőolvasót nap mint nap használó szakemberek is ezt kifogásolják leginkább: ha egy terméket valódi felhasználói teszt nélkül neveznek akadálymentesnek, csak mert átment egy automata ellenőrzésen, vagy mert a fejlesztő hallotta, hogy a képernyőolvasó felolvas valamit. Ha teheted, mielőtt akadálymentes weboldalnak neveznéd a kész felületet, tervezz be a lista végére legalább egy kört érintett tesztelőkkel.

Az AI-eszközök sem változtatnak ezen: gyorsítják a kódolást, a felhasználók ismerete és a belőle fakadó döntések viszont az akadálymentes felületet tervező és fejlesztő szakembernél maradnak. A generált kód hamar összerak egy címkézett űrlapmezőt vagy egy billentyűzettel is kezelhető menüt, azt viszont a felhasználói csoportokat ismerő ember dönti el, hogy érthető-e a hibaüzenet, eltalálja-e a gombot a remegő kezű felhasználó, és melyik hibát kell elsőként javítani.

Csoportonkénti audit a gyakorlatban: így épül fel a képzésünk

Az Akadálymentes frontend a szabványtól a kész auditig képzésünkön ezt a csoportonkénti szemléletet teljes munkamódszerré fejleszted.

6 hét alatt a WCAG mind a négy alapelvét végigveszed, és közben többek között ilyen feladatokon dolgozol:

• a felhasználói csoportok és a jogi keret (EAA, EN 301 549) után egy választott felületen keresel akadályokat,
• átvizsgálod a vizuális réteget a kontraszttól a feliratokig, majd egy kulcsfolyamat értelmezhetőségét a címkéktől a hibaüzenetekig,
• kijavítasz egy interaktív komponenst, hogy billentyűzettel és mobilon, érintéssel is jól kezelhető legyen,
• strukturáltan felméred a felületet billentyűzettel, képernyőolvasóval és automatizált eszközökkel, és megnézed, mit hagy ki a gépi ellenőrzés,
• és végül véglegesíted a felmérést, majd priorizált javítási ütemtervet készítesz hozzá, így a képzés végére egy valós, akár saját szoftverről készült audit lesz a kezedben.

Az oktatód és mentorod Kiss Lőrinc kognitív mérnök lesz, aki több mint nyolc éve végez nagyvállalati kutatói és UX-tervezői munkát. A szabvány mellett azt is tanítja, hogyan érzékeli és értelmezi a felületet a valós felhasználó. Ez a hibaüzenetek és az űrlapok vizsgálatánál különösen sokat számít.

A tananyagot hétről hétre, tanegységenként kapod meg, a képzés pedig heti 8-12 óra ráfordítással munka mellett is elvégezhető. Minden tanegység végén élő online konzultáció van, amelyet vissza is nézhetsz, közben pedig Lőrinc visszajelez a beadott feladataidra.

Ha a csapatodban többen felelnek a megfelelésért, érdemes a vezetőddel csapatszintű képzésről is beszélni. Erre az adatlapon cégként is érdeklődhettek.

Gyakori kérdések

Mit jelent az akadálymentesség egy weboldal esetében?

Akadálymentes weboldalról akkor beszélünk, ha a fogyatékossággal vagy tartós betegséggel élő és az átmenetileg korlátozott felhasználó is végig tudja vinni rajta a feladatát. Ez lehet vásárlás, banki átutalás vagy egy űrlap kitöltése. Az akadálymentesség a vakokon kívül érinti a gyengénlátókat, a színtévesztőket, a siketeket és nagyothallókat, valamint a mozgásszervi, kognitív és vesztibuláris zavarral élőket. A WHO szerint világszerte 1,3 milliárd ember, nagyjából minden hatodik él jelentős fogyatékossággal. A legutóbbi magyar népszámláláson a magukat fogyatékosnak vallók 41%-a mozgáskorlátozott volt, a vakok aránya 5% alatt maradt.

Hogyan tegyem akadálymentessé a weboldalamat úgy, hogy ne csak a képernyőolvasót használókra figyeljek?

Bontsd az ellenőrzést felhasználói csoportokra, és mindegyiket külön teszteld, mert a képernyőolvasós teszt csak a felolvasás hibáit mutatja meg. Kezdd automata vizsgálattal, például WAVE vagy axe DevTools segítségével. Utána járd be az oldalt csak billentyűzettel, és nagyítsd fel többszörösére. Nézd meg szürkeárnyalatosan, játszd le a videókat némítva, próbáld ki mobilon egy ujjal, és teszteld bekapcsolt csökkentett mozgással. Ezután járd végig a hibaüzeneteket, és csak a végén jöjjön a képernyőolvasó és a hangvezérlés.

Mi az a kontraszt, és miért fontos a gyengénlátó felhasználóknak?

A kontraszt a szöveg vagy egy felületi elem és a háttere közötti világosságkülönbség aránya. Ha túl alacsony, a gyengénlátó felhasználó nehezen vagy egyáltalán nem tudja elolvasni a szöveget. A WebAIM gyengénlátó-felmérésében a válaszadók 46,8%-a számolt be kontrasztérzékenységi problémáról. A WCAG 2.2 AA szinten szövegnél 4,5:1, nagy szövegnél és nem szöveges elemeknél 3:1 arányt kér, mégis a nyitóoldalak 83,9%-án van alacsony kontrasztú szöveg.

Mi a különbség a beégetett és a ki-be kapcsolható felirat között?

A ki-be kapcsolható felirat külön szövegsáv, amelyet a néző maga kapcsol be, és sok lejátszóban a megjelenését is beállíthatja. A beégetett felirat a videókép része, ezért nem lehet kikapcsolni, és a néző igényeihez sem igazítható. A felirat jóval több nézőnek segít, mint ahány siket és nagyothalló ember van: egy amerikai felmérésben a válaszadók 69%-a mondta, hogy nyilvános helyen hang nélkül néz videót.

Milyen akadályokba ütközik egy weboldalon az, aki enyhe kognitív zavarral él?

A kognitív korlát az emlékezés, a figyelem vagy a szövegértés tartós vagy átmeneti nehézségét jelenti. Az ezzel élő felhasználó leginkább ott akad el, ahol fejben kell tartania valamit, vagy ahol a szöveg nem mondja meg egyértelműen, mi a teendő. Tipikus akadály az általános „Hibás formátum” típusú hibaüzenet és a túl rövid időkorlát. Ezeket sem a képernyőolvasós, sem az automata teszt nem hozza elő magától, ezért kifejezetten keresni kell őket.

Milyen kognitív képességekre épít egy weboldal használata, és mire figyeljek a tervezésnél?

Egy webes felület többek között az emlékezetre és a szövegértésre épít. A felhasználónak fejben kell tartania a korábban megadott adatokat, és meg kell értenie a feliratokat és a hibaüzeneteket. A WCAG 2.2 ezért kéri, hogy egy folyamatban ne kelljen ugyanazt az adatot kétszer beírni. A belépéshez se kelljen kognitív tesztet megoldani, például kódot fejből átírni. A hibaüzenet nevezze meg a problémát, az okát és a javítás módját, és ismételt hibánál adjon több segítséget, akár egy telefonszámot.