Szövegfelolvasás vs. képernyőolvasók

A tartalmadnak hangja van

A szövegfelolvasó (TTS) technológia az írott információt hanggá alakítja. Segít a vak, látássérült, diszlexiás és ADHD-s embereknek abban, hogy a számukra megfelelő módon fogyasszák a tartalmat. A TTS-t széles körben használják az iskolákban, nyelvtanulók és olyan szakemberek is, akik füllel, nem pedig szemmel olvassák a szöveget.

Mivel mind a TTS, mind a képernyőolvasók szintetikus hangot állítanak elő, az emberek gyakran feltételezik, hogy ugyanazok — vagy hogy egy „felolvasás” gomb hozzáadása egy webhelyhez akadálymentessé teszi azt a vak felhasználók számára. Ez a feltételezés téves, és az e szerinti cselekvés egy olyan webhelyet eredményezhet, amely akadálymentesnek hangzik, de sokak számára valójában lehetetlen használni. Ez a cikk elmagyarázza, hogyan működik mindegyik technológia, kik támaszkodnak rá, hol húzódik valójában a határ közöttük, és mi szükséges ahhoz, hogy megfelelően építsünk képernyőolvasókra. Ha csak egy dolgot jegyzel meg, legyen ez az: a felolvasó widget kényelmi funkció, nem akadálymentességi funkció.

Hogyan működik a TTS?

A TTS három nagy szakaszban dolgozza fel a szöveget:

• Szövegelemzés — a hangnem, a nyelvtan és a szerkezet meghatározása, a számok és szimbólumok kiírása („$5” ebből „öt dollár” lesz), valamint a mondatok szegmentálása.
• Nyelvi feldolgozás — a kiejtés, a hangsúly és a kiemelés kiszámítása, gyakran kiejtési szótár, valamint az ismeretlen szavakra vonatkozó szabályok segítségével.
• Hangszintézis — beszéd generálása matematikai hangmodellekből, egyre inkább neurális hálózatok használatával, amelyek sokkal természetesebben hangzanak, mint a régebbi összefűző motorok.

A modern rendszerek hangtestreszabást kínálnak, például sebesség, hangmagasság, hangszemélyiség és nyelvválasztás. A döntő pont az, hogy mit vesz a TTS bemenetként: egy szövegblokkot, amelyet valaki már kijelölt, beillesztett vagy rámutatott. A TTS alapvetően egy tartalom-ki technológia. Azt mondja ki, amit kap. Nem fedezi fel a felületet, és nincs fogalma gombokról, űrlapmezőkről vagy oldalstruktúráról.

Milyen korlátai vannak a TTS technológiának?

A TTS valóban hasznos, de nem tökéletes, és a korlátai fontosak az előttünk álló összehasonlítás szempontjából:

• Kiejtési hiányosságok — hibásan ejtheti a ritka szavakat, a tulajdonneveket, az orvosi vagy jogi kifejezéseket és a rövidítéseket.
• Egyenetlen nyelvi támogatás — sok eszköz jól kezeli a fő nyelveket, de küzd a kevésbé elterjedt nyelvekkel és a regionális dialektusokkal.
• Hangnem és árnyalat — a TTS nehezen boldogul a szarkazmussal, a humorral és az idiomatikus kifejezésekkel, így a tartalom rossz hangnemben adható át.
• Nincs interakciós modell — és ez a nagy dolog: a TTS olvas; nem enged csinálni semmit. Nem tudsz pénztári űrlapot kitölteni, modális ablakot bezárni vagy menüpontok között mozogni pusztán TTS-sel.

Pontosan ez az utolsó korlát az, ahol a képernyőolvasókkal való összekeverés elkezdődik.

Mi a különbség a szövegfelolvasó és a képernyőolvasó technológia között?

Itt keletkezik a gyakori félreértés. A szövegfelolvasó hangosan felolvassa a szöveget — ez az elsődleges funkciója. A képernyőolvasó sokkal többet tesz: lehetővé teszi a felhasználók számára, hogy egy egész számítógépet vagy mobileszközt füllel és billentyűzettel (vagy érintőgesztusokkal) kezeljenek és navigáljanak benne.

A képernyőolvasók bejelentik a felület címkéit, az űrlapmezőket, a gombokat és a hivatkozásokat; felolvassák a képek alternatív szövegét, hogy a felhasználók megértsék a vizuális tartalmat; és felszínre hozzák a komponensek állapotát — hogy egy jelölőnégyzet be van-e jelölve, egy menü ki van-e bontva, egy lap ki van-e választva, vagy megjelent-e hiba. A vizuális, egérrel vezérelt felületet lineáris, hallható, kezelhető felületté alakítják.

Gyors módja annak, hogy megérezd a különbséget: a TTS arra a kérdésre válaszol, hogy „Mit mond ez a bekezdés?” A képernyőolvasó arra a kérdésre válaszol, hogy „Hol vagyok, mit tehetek itt, és mi történt épp az imént?” Az első a tartalom fogyasztásáról szól. A második a szoftver vezérléséről.

Hogyan mozog valójában egy képernyőolvasó-felhasználó egy oldalon

A látó felhasználók másodpercek alatt átfutják az oldalt. Egy képernyőolvasó-felhasználó szekvenciálisan épít fel egy mentális modellt, és a struktúrára támaszkodik, hogy hatékonyan mozogjon. A gyakorlatban:

• Címsorok között ugrálnak, hogy megértsék az oldal vázlatát (ezért olyan fontos a helyes címsorhierarchia).
• Listát hívnak elő az összes hivatkozásról vagy az összes űrlapmezőről, hogy tájékozódási pontok szerint navigáljanak, ahelyett, hogy fentről lefelé olvasnának.
• Tájékozódási régiókat (fejléc, navigáció, fő tartalom, lábléc) használnak, hogy egyenesen a kívánt tartalomhoz ugorjanak.
• Az interaktív elemek között a Tab billentyűvel mozognak, és elvárják, hogy a fókusz valahol láthatóan és logikusan landoljon.
• Élő bejelentésekre figyelnek, amikor valami megváltozik az oldal teljes újratöltése nélkül.

Mindebből semmi sem működik, hacsak a mögöttes jelölés őszintén nem írja le az oldalt. A „felolvasás” funkció egyik navigációs lehetőséget sem biztosítja — csupán elmondja, milyen szöveg van a képernyőn, vizuális sorrendben, anélkül, hogy a vezérlőket működtetni lehetne.

Ki melyiket használja, és miért számít ez

A TTS-t széles közönség használja, gyakran helyzetfüggően: diszlexiás, ADHD-s vagy gyengénlátó emberek; multitaskerek; nyelvtanulók; és mindenki, aki egyszerűen szívesebben hallgat. E felhasználók többsége továbbra is látja a képernyőt, és tud egeret használni.

A képernyőolvasó-felhasználók közé tartoznak a vak vagy súlyosan látássérült emberek, valamint néhány kognitív vagy mozgásszervi fogyatékossággal élő ember, akik a technológiától függenek ahhoz, hogy egyáltalán használjanak egy eszközt. Számukra ez nem egy preferenciaréteg egy használható felület tetején — ez a felület. A leggyakoribb eszközök az NVDA és a JAWS Windowson, a VoiceOver az Apple eszközökön, valamint a TalkBack Androidon. Mindegyik kissé másképp értelmezi ugyanazt a weboldalt, ami az egyik oka annak, hogy fontos mindegyiken tesztelni.

Miért nem helyettesítik a felolvasó widgetek az akadálymentességet

Egyre több webhely csatol magához egy „hallgassa meg ezt az oldalt” gombot vagy egy harmadik féltől származó widgetet, amely kiemeli és felolvassa a szöveget. Ezek az eszközök néhány olvasónak segíthetnek, és semmi rossz nincs abban, ha kényelmi funkcióként kínálják fel valamelyiket. A probléma az, hogy a valódi képernyőolvasó-támogatás helyettesítőjeként kezelik. Az nem az, több konkrét okból sem.

• Csak olvasnak; nem működtetnek. Egy felolvasó widget felolvassa az árazási táblázatodat, de nem engedi, hogy egy vak felhasználó kiválasszon egy csomagot, megnyissa a kosarat, megadja a fizetési adatokat és befejezze a vásárlást. A valódi feladatok kezelhető vezérlőket igényelnek, nem felolvasást.
• Nem tudják felszínre hozni az állapotot vagy a szerepeket. Hogy egy gomb meg van-e nyomva, egy mező kötelező-e, egy szakasz össze van-e csukva, vagy épp megjelent-e egy hibaüzenet — mindezt nem közvetíti a látható szöveg felolvasása. A képernyőolvasók a jelölésben lévő szerepekre, nevekre és állapotokra támaszkodnak, hogy bejelentsék ezeket.
• A képernyőolvasó-felhasználóknak már van eszközük. A vak felhasználók saját képernyőolvasójukat hozzák magukkal, finoman ráhangolva a preferenciáikra és az izommemóriájukra. Egy oldalszintű widget versenyez vele, néha zavarja, és semmit sem tesz a hibás jelölés kijavításáért, amelyen a képernyőolvasójuk fennakad.
• Elfedik a problémákat ahelyett, hogy megoldanák. Ha egy űrlapmezőnek nincs címkéje, a widget átugorja, ugyanúgy, mint egy képernyőolvasó tenné — de most a hiányzó címke egy hasznosnak tűnő funkció mögé van rejtve. Az alapvető hiba megmarad.

Ugyanez a logika érvényes, még erősebben, az úgynevezett akadálymentességi átfedésekre (overlay) — szkriptekre, amelyek azonnali megfelelést ígérnek azáltal, hogy automatizált javításokat és egy eszköztárat rétegeznek egy meglévő webhelyre. Nem javítják a mögöttes kódot, gyakran ütköznek a felhasználók saját segítő technológiájával, és nem képesek valódi megfelelést nyújtani. A megbízható út a forrás javítása. A felületi javítások elégtelenségének részletesebb magyarázatáért lásd útmutatónkat a valódi digitális akadálymentességről.

Egy konkrét példa: a pénztár, amely „beszél”

Képzelj el egy online boltot, amely hozzáadott egy felolvasó widgetet, és biztos benne, hogy a webhely most már akadálymentes. Egy vak vásárló érkezik a saját képernyőolvasójával futtatva. A termékleírás rendben felolvasódik — az a rész csak szöveg. De a „Kosárba” vezérlő egy stilizált div egy kattintáskezelővel egy valódi gomb helyett, így a képernyőolvasó soha nem jelenti be gombként, és a billentyűzet nem éri el. A mennyiségválasztó élő régió nélkül frissíti az összeget, így a változás néma. A kedvezménykód-mezőnek van helyőrző szövege, de nincs hozzá tartozó címkéje, így csak „szöveg szerkesztése” formában jelenik be. A szállítási űrlap vizuálisan piros hibát mutat, de a hiba nincs a mezőhöz kapcsolva, és egyáltalán nem jelenik be. A felolvasó widget vidáman felolvassa a látható szöveget, és semmit sem változtat ezen. A vásárló hallja a marketingszöveget, de nem tudja befejezni a vásárlást. Ez a szakadék — a tartalom hallása és a termék működtetése között — a teljes különbség egy kényelmi funkció és az akadálymentesség között.

Mit igényel valójában a képernyőolvasókra való építés

A képernyőolvasók támogatása nem egy funkció hozzáadásáról szól — hanem az oldalaid úgy való felépítéséről, hogy a jelentés, a struktúra és a viselkedés elérhető legyen a szoftver számára, ne csak az emberi szem számára. A fő összetevők:

Szemantikus, strukturált HTML

Használj valódi címsorokat (h1–h6) logikus sorrendben, natív gombokat és hivatkozásokat a megfelelő célokra, listákat a listákhoz, és tájékozódási elemeket az oldalrégiókhoz. A szemantikus HTML ingyen hordozza az akadálymentességi információt; az általános konténerek fala semmit sem hordoz.

Szöveges alternatívák a nem szöveges tartalomhoz

Minden értelmes képnek pontos alternatív szövegre van szüksége, a dekoratív képeket pedig úgy kell megjelölni, hogy átugorják őket. A gombként működő ikonoknak hozzáférhető nevekre van szükségük. A diagramoknak és infografikáknak olyan szöveges megfelelőre van szükségük, amely ugyanazt az információt közvetíti.

Hozzáférhető nevek, szerepek és állapotok

Az űrlapmezőknek programozottan társított címkékre van szükségük. Az egyéni komponenseknek — lapok, harmonikák, kombinált listák, modális ablakok — a megfelelő szerepekre és állapotokra van szükségük, hogy a képernyőolvasó bejelentse, mik azok, és hogyan viselkednek. Ahol a natív HTML nem elég, az ARIA tölti be a rést, de pontosan kell használni; a hibás ARIA rosszabb a semminél.

Billentyűzettel való kezelhetőség és fókuszkezelés

Mindennek, ami egérrel működik, működnie kell billentyűzettel is, a fókuszsorrendnek logikusnak kell lennie, a fókuszjelzőnek láthatónak kell lennie, és a dinamikus változásoknak (egy párbeszédablak megnyitása, egy hiba felfedése) megfelelően kell mozgatniuk vagy bejelenteniük a fókuszt. A billentyűzet-támogatás és a képernyőolvasó-támogatás mélyen összefonódik.

A dinamikus változások bejelentése

Amikor a tartalom oldalújratöltés nélkül frissül — egy űrlapérvényesítési üzenet, egy kosárszámláló, egy betöltési állapot — használj élő régiókat, hogy a képernyőolvasó megmondja a felhasználónak, hogy történt valami. A néma frissítések láthatatlanok azok számára, akik nem látják a képernyőt.

Mindezek az elvárások a WCAG 2.2 sikerkritériumaiban vannak kodifikálva, amelyek az European Accessibility Act és a webre alkalmazott ADA technikai gerincét alkotják. Ha a gyakorlati részleteket szeretnéd, képernyőolvasó-tesztelési útmutatónk lépésről lépésre végigvezet azon, hogyan ellenőrizd mindegyik viselkedést valódi eszközökkel.

Miért félrevezető a „nekem rendben felolvassa”

Egy látó fejlesztő bekapcsolhatja a felolvasás funkciót, tiszta mondatokat hallhat, és arra a következtetésre juthat, hogy az oldal akadálymentes. A csapda az, hogy a felolvasás a látható olvasási sorrendet és a látható szöveget reprodukálja, amelyek mindketten már értelmesek annak, aki a képernyőre néz. Semmit nem mond arról, hogy egy egyéni legördülő menü bejelenti-e a beállításait, hogy a fókusz csapdába esik-e egy megnyitott párbeszédablakon belül, hogy egy csak ikont tartalmazó gombnak van-e neve, vagy hogy a tabulátorsorrend megfelel-e a vizuális elrendezésnek. Pontosan ezek azok a dolgok, amelyek elromlanak a képernyőolvasó-felhasználók számára, és pontosan ezek azok a dolgok, amelyeket egy felolvasási bemutató nem tud felfedni. Az egyetlen módja annak, hogy megtudd, az, hogy úgy tesztelsz, ahogy a valódi felhasználók teszik.

Hogyan teszteld mindkettőt — és miért nem elég önmagában az automatizálás

Nem tudod megerősíteni, hogy egy oldal működik a képernyőolvasó-felhasználók számára, ha egy felolvasó gombot hallgatsz. Úgy erősíted meg, hogy ellenőrzöd a struktúrát, a neveket, a szerepeket, az állapotokat, a billentyűzetes kezelést és a tényleges képernyőolvasó-élményt több eszközön és platformon keresztül.

Egy szilárd folyamat három réteget kombinál:

• Automatizált vizsgálat a nagy mennyiségű, géppel észlelhető problémák felderítésére — hiányzó alt szöveg, üres címkék, hibás ARIA-hivatkozások, kontraszthibák. Akadálymentességi vizsgáló szoftverünk és egy ingyenes akadálymentességi vizsgálat gyors módja annak, hogy felmérd, hol állsz.
• Szakértői manuális tesztelés mindannak az értékelésére, amit az automatizálás nem tud megítélni: hogy egy név értelmes-e, hogy a fókuszsorrend értelmes-e, hogy egy egyéni widget valóban kezelhető-e. Az e réteg mögötti érvelés manuális akadálymentességi auditok útmutatónkban szerepel.
• Tesztelés valódi segítő technológiával és valódi felhasználókkal. Semmi sem helyettesíti az oldal kezelését NVDA-val, JAWS-szal, VoiceOverrel és TalkBackkel — és ideális esetben olyan emberek megfigyelését, akik ezeket az eszközöket naponta használják. Fogyatékossággal élő emberek által végzett auditjaink pontosan ezt a megélt szakértelmet hozzák.

Az automatizált eszközök jellemzően a WCAG 2.2 sikerkritériumainak csak egy részét észlelik; a többi emberi ítéletet igényel. Egy sikeres automatizált vizsgálatot az akadálymentesség bizonyítékaként kezelni ugyanabba a hibakategóriába tartozik, mint egy felolvasó widgetet képernyőolvasó-támogatásként kezelni.

Hol illik bele a QualiBooth

A QualiBooth a webhelyedet mind a TTS, mind a képernyőolvasó használati esetei ellen teszteli, hogy a tartalmad akadálymentes legyen a bármelyik technológiára támaszkodó felhasználók számára — és hogy a képernyőolvasótól függő emberek ne csak hallhassák a tartalmadat, hanem ténylegesen működtethessék a termékedet. Akadálymentességi eszköztárunk és az Agora platform a vizsgálatot strukturált manuális felülvizsgálattal kombinálja, és akadálymentességi tanácsadó csapatunk segít kijavítani azt, amit a tesztek feltárnak, és igazodni a WCAG 2.2, az EAA és az ADA követelményeihez.

A lényeg egyszerű. Hangot adni a tartalmadnak kellemes hozzáadás. A tartalmadat egy képernyőolvasó számára navigálhatóvá, kezelhetővé és helyesen bejelentetté tenni akadálymentesség — és csak az egyik elégíti ki a törvényt és az embereket, akiket véd.