Képernyőolvasó-tesztelés: NVDA, JAWS, VoiceOver

Egy oldal átmehet minden automatizált ellenőrzésen, érvényes HTML-lel jelenhet meg, és mégis használhatatlan lehet annak, aki füllel navigál a weben. Az automatizált eszközök a hozzáférhetőségi problémáknak nagyjából egyharmadát fogják meg; a többi abban a szakadékban él, ami a hozzáférhetőségi fa technikai tartalma és aközött tátong, amit a képernyőolvasó valójában bemond a felhasználónak. E szakadék áthidalása azt jelenti, hogy a felületét ugyanazon eszközök elé tárja, amelyekre a közönsége támaszkodik — és pontosan ezért van a képernyőolvasó-tesztelés.

Ez az útmutató végigveszi, hogy a főbb képernyőolvasók miben különböznek, miért nem elég soha csak az egyiket tesztelni, pontosan mit kell tesztelni, mely olvasó- és böngészőpárosításokat érdemes használni, és azokat a buktatókat, amelyekbe a tapasztalt csapatok is beleesnek. Fejlesztőknek, QA-mérnököknek és hozzáférhetőségi szakembereknek készült, akik megfontoltan akarnak tesztelni, nem találgatni. Ha inkább olyan szakemberekre bízná a munkát, akik nap mint nap használják ezeket az eszközöket, képernyőolvasó-értékelési szolgáltatásunk pontosan ezt teszi.

Miért nem „felolvasó eszköz“ a képernyőolvasó

A legelterjedtebb tévhit az, hogy a képernyőolvasó egyszerűen felmondja az oldalon lévő szöveget. Ennél sokkal többet tesz, és e különbség megértése a jó tesztelés alapja. A képernyőolvasó a böngésző hozzáférhetőségi fájából egy párhuzamos, nem vizuális modellt épít fel a felületről. Bemondja minden elem nevét („Küldés, gomb“), a szerepét (gomb, hivatkozás, címsor, jelölőnégyzet) és az állapotát (bejelölve, kibontva, letiltva, kötelező). Lehetővé teszi a felhasználónak, hogy címsorok, tereppontok, űrlapmezők és hivatkozások között ugráljon anélkül, hogy a vizuális elrendezéshez nyúlna. Felmondja a dinamikus változásokat — hibaüzeneteket, keresési eredményeket, állapotfrissítéseket — amikor azokat helyesen teszik közzé.

Ez alapvetően különbözik a szöveg-beszéd átalakítástól, amely egy szövegblokkot alakít hanggá, a szerepek, állapotok vagy navigáció fogalma nélkül. A különbséget részletesen tárgyaljuk a szöveg-beszéd átalakítás kontra képernyőolvasók cikkben, és itt azért számít, mert az egyikre tesztelni nem teszteli a másikat. A képernyőolvasó használója nem felülről lefelé fogyasztja az oldalát; strukturálisan navigál benne, és elvárja, hogy minden interaktív elem kijelentse, mi az és mit csinál.

Miben különbözik az NVDA, a JAWS, a VoiceOver és a TalkBack

A négy olvasó, amelyekkel a legtöbb csapatnak foglalkoznia kell, eléggé eltérően viselkedik ahhoz, hogy az „egyikben működik“ szinte semmit nem árul el a többiről.

NVDA (Windows)

Az NVDA ingyenes, nyílt forráskódú olvasó, és világszerte a legszélesebb körben használt képernyőolvasó. A legtermészetesebben a Firefoxszal és a Chrome-mal párosul. Az NVDA általában szorosan követi az ARIA- és HTML-szemantikát, ami kiváló alapszintté teszi: ha valami hibás a kódjában, az NVDA gyakran egyértelműen felszínre hozza. Két kulcsfontosságú módja van — a böngészési mód (olvasáshoz és strukturális navigációhoz) és a fókuszmód (űrlapokba gépeléshez és widgetek kezeléséhez) — és a hibák gyakori forrása, amikor a widgetek nem váltják ki a helyes módváltást.

JAWS (Windows)

A JAWS a régóta bevett kereskedelmi olvasó, amely még mindig domináns a vállalatoknál, a kormányzatban és számos munkahelyen. A Chrome-mal és az Edge-dzsel párosul. A JAWS arról híres, hogy „segítőkész“: heurisztikákat alkalmaz, amelyek kitalálják a jelentést, néha bemond olyan dolgokat, amelyekről az NVDA hallgat, és időnként elsimít olyan kódhibákat, amelyeket javítani kellene. Ez a segítőkészség kétélű — egy kód, amely „működik a JAWS-ban“, megbukhat az NVDA-ban vagy a VoiceOverben, mert a JAWS elkendőzte a problémát. Saját virtuális kurzora és űrlapmód-viselkedése is van, amely finoman eltér az NVDA-étól.

VoiceOver (macOS és iOS)

A VoiceOver minden Macba, iPhone-ba és iPadbe beépítve érkezik, és szinte kizárólag a Safarival párosul. macOS-en a navigáció a rotoron és a VO-billentyűkombinációkon keresztül zajlik; iOS-en teljesen gesztusvezérelt — söpréssel mozog, dupla koppintással aktivál, a rotor két ujj forgatásával. A VoiceOver általában a legszigorúbb a négy közül az ARIA tekintetében: gyakran inkább elnémul, mintsem találgasson, amikor a nevek vagy szerepek hiányoznak, így egy vezérlő, amelyet a JAWS bemond, a VoiceOverben lehet, hogy semmit nem mond. Az asztali és a mobil VoiceOver is eltér egymástól, így két külön teszt-célpontnak számítanak.

TalkBack (Android)

A TalkBack az Android beépített olvasója, a Chrome-mal párosítva. Az iOS VoiceOverhez hasonlóan gesztusalapú, de a gesztusai, fókuszviselkedése, valamint az élő régiók és egyéni vezérlők kezelése eltér a VoiceOverétól. A mobilolvasók általában olyan problémákat tárnak fel, amelyek asztali gépen sosem jelennek meg: érintési célpontok, amelyek söpréssel nem érhetők el, fókusz, amely képernyőváltás után váratlanul ugrik, és tartalom, amely vizuálisan jelen van, de a lineáris gesztussorrend teljesen átugorja.

Miért elengedhetetlen a többolvasós tesztelés

Mivel ezek az olvasók eltérnek abban, ahogyan pontosan ugyanazt a kódot értelmezik, az egyolvasós tesztelés hamis biztonságérzetet kelt. Néhány konkrét minta újra és újra felbukkan:

• Egy egyedi kombinált lista (combobox), amelyet a JAWS tökéletesen bemond, a VoiceOverben teljesen elnémulhat, mert a VoiceOver megtagadja egy hiányzó role vagy aria-expanded állapot kikövetkeztetését.
• Egy élő régió, amelyet az NVDA udvariasan egyszer bemond, egy másik olvasóban ismételten vagy egyáltalán nem hangozhat el, attól függően, hogyan hat egymásra az aria-live és a DOM-beszúrás időzítése.
• Egy fölösleges vagy ütköző névvel rendelkező vezérlő (látható címke plusz aria-label plusz title) az egyik olvasóban értelmesen, a másikban zavaró duplikátumok láncolataként hangozhat el.
• Az olvasási sorrend, amely az egyik böngésző/olvasó párosításban megegyezik a vizuális sorrenddel, egy másikban eltérhet, amikor a CSS átrendezi a tartalmat, de a DOM nem.

Minden olvasó egy-egy másik böngészőhöz is kötődik, így valójában olvasó-plusz-böngésző párosításokat tesztel, nem önmagukban az olvasókat. Az egyetlen mód annak megtudására, hogy a terméke mindenki számára koherens-e, ha a közönsége által használt valódi párosításokat teszteli. Ez ugyanaz az elv, amely általában a manuális hozzáférhetőségi auditok mögött áll: az eszközök szűkítik a keresést, az emberek megerősítik az élményt.

Mit kell tesztelni

A tesztelés sokkal hatékonyabb, ha strukturált. Ezek azok a dimenziók, amelyek számítanak, nagyjából fontossági sorrendben, és mindegyik konkrét WCAG 2.2 sikerkritériumokhoz kapcsolódik.

Bemondások: név, szerep, érték

Minden interaktív elemnél erősítse meg, hogy az olvasó pontos nevet mond be (mi az), a helyes szerepet (gomb, hivatkozás, jelölőnégyzet, fül), és ahol releváns, az értéket vagy állapotot. Ez a WCAG 4.1.2 (Név, szerep, érték) lényege. Figyeljen különösen: néma vezérlőkre, csak „kattintható“-ként vagy „csoport“-ként bemondott vezérlőkre, hozzáférhető név nélküli ikongombokra, és nyers fájlútvonalként vagy osztálynévként felolvasott nevekre.

Szerepek és állapotok

Az állapotoknak frissülniük kell, ahogyan a felhasználó interakcióba lép. Egy felfedő elemnek, amely kibomlik, „összecsukva“-ról „kibontva“-ra kell váltania; egy jelölőnégyzetnek „nincs bejelölve“-ről „bejelölve“-re kell lépnie; egy rendezőgombnak be kell mondania az aktuális irányát. A statikus kód, amely soha nem frissíti az aria-expanded, aria-checked, aria-selected vagy aria-pressed értékeket, az egyik leggyakoribb hiba, és csak akkor derül ki, amikor a widgetet futó olvasóval kezeli.

Fókuszsorrend és fókuszkezelés

Tabolja végig az egész felületet. A fókusznak logikus, kiszámítható sorrendben kell mozognia (WCAG 2.4.3), mindig láthatónak kell lennie, és soha nem szabad csapdába esnie, kivéve szándékosan egy modális ablakon belül. A nehéz esetek dinamikusak: amikor egy párbeszédablak megnyílik, a fókusznak bele kell mozognia; amikor bezárul, a fókusznak vissza kell térnie ahhoz az elemhez, amely megnyitotta. Ennek kihagyása a leggyakoribb oka annak, hogy egy modális folyamat használhatatlan.

Olvasási és navigációs sorrend

A fókuszon túl a képernyőolvasó-használók a struktúra szerint navigálnak. Ellenőrizze, hogy a címsorok logikus vázlatot alkotnak-e (WCAG 1.3.1), hogy a tereppontok (header, nav, main, footer) lehetővé teszik-e a felhasználóknak az ugrálást, és hogy a listák és táblázatok úgy vannak-e jelölve, hogy az olvasó navigálni és számolni tudja őket. Ellenőrizze, hogy az olvasási sorrend megfelel-e a vizuális szándéknak, és hogy semmi fontos nem hangzik el rossz sorrendben.

Élő régiók és dinamikus frissítések

Az aszinkron változásoknak — érvényesítési hibák, „3 találat“, „mentés…“, toast-értesítések — el kell érniük a felhasználót anélkül, hogy elárasztanák. aria-live="polite" a nem sürgős frissítésekhez, aria-live="assertive" csak a valóban sürgősekhez, és role="status" vagy role="alert" a gyakori esetekhez. Tesztelje, hogy a régió létezik-e a DOM-ban a tartalom megváltozása előtt, hogy a frissítést pontosan egyszer mondja-e be, és hogy nem szakítja-e félbe a felhasználót mondat közben. Ez a WCAG 4.1.3-at (Állapotüzenetek) támogatja.

Egyéni ARIA-widgetek

Minden, amit saját maga épített — menük, fülek, kombinált listák, dátumválasztók, körhinták, adatrácsok, fanézetek — a legtöbb figyelmet igényli. Tesztelje az ARIA Authoring Practices alapján a várt billentyűzet-interakciót és bemondásokat, majd erősítse meg, hogy a valódi olvasók valóban így viselkednek. Az APG az ideált írja le; az olvasók tökéletlenül valósítják meg, ezért egy működő mintát mégis ellenőrizni kell minden olvasóban.

Konkrét példa: egy hozzáférhetetlen kontra hozzáférhető kapcsoló

Vegyünk egy beállítási kapcsolót. Egy vizuálisan stilizált, de szemantikailag üres változat:

<div class="toggle" onclick="setNotifications()">
  <span class="dot"></span> Notifications
</div>

Egy képernyőolvasó számára ez legjobb esetben is egy darab statikus szöveg. Nincs szerep, így nem mondja be vezérlőként; nincs állapot, így a felhasználó nem tudja megállapítani, hogy az értesítések be vannak-e kapcsolva vagy ki; és nincs benne a tabsorrendben, így egy billentyűzetes vagy képernyőolvasó-használó egyáltalán nem éri el és nem kezeli. Tesztelés közben az NVDA felolvassa, hogy „Notifications“, és továbblép; a VoiceOver lehet, hogy teljesen átugorja.

A hozzáférhető megfelelő a natív elemet használja, és közzéteszi az állapotot:

<button type="button" aria-pressed="false" id="notif">
  Notifications
</button>

const btn = document.getElementById('notif');
btn.addEventListener('click', () => {
  const on = btn.getAttribute('aria-pressed') === 'true';
  btn.setAttribute('aria-pressed', String(!on));
});

Most már minden olvasó bemondja, hogy „Notifications, kapcsológomb, nincs lenyomva“, Tabbal elérhető, Enterrel vagy szóközzel kezelhető, és az állapot aktiváláskor hallhatóan átvált. A tanulság általánosítható: részesítse előnyben a natív szemantikát, és amikor ARIA-t kell használnia, tesztelje, hogy minden olvasó valóban tiszteletben tartja-e a szerepet és az állapotot. Az ehhez hasonló, hiányzó állapot hibák a kerülendő gyakori hozzáférhetőségi problémák közé tartoznak.

Ajánlott olvasó- és böngészőpárosítások

Azokat a párosításokat tesztelje, amelyeket a valódi felhasználók futtatnak, ne önkényes párokat. Egy gyakorlati mátrix, amely a képernyőolvasó-használók nagy többségét lefedi:

• NVDA + Firefox (Windows) — a legtisztább alapszint a kódproblémák felderítéséhez
• NVDA + Chrome (Windows) — a leggyakoribb ingyenes olvasó párosítás a gyakorlatban
• JAWS + Chrome (Windows) — domináns a vállalati és kormányzati környezetekben
• VoiceOver + Safari (macOS) — az egyetlen teljesen támogatott asztali VoiceOver-párosítás
• VoiceOver + Safari (iOS) — gesztusalapú mobil, az asztalitól külön célpont
• TalkBack + Chrome (Android) — a szabványos Android-párosítás

A párosítások számítanak, mert az olvasók konkrét böngészőkhöz vannak hangolva; a VoiceOver Chrome-mal vagy a JAWS Firefoxszal olyan viselkedést produkál, amely nem tükrözi, hogyan tapasztalja meg ténylegesen a közönsége az oldalt. Ahol az analitikája egy bizonyos közönséget mutat — mondjuk egy közszférás termék erős JAWS-használattal, vagy egy mobilra hajló fogyasztói alkalmazás — súlyozza ennek megfelelően a mátrixot. A képernyőolvasó-értékelési szolgáltatásunk minden ügyfél analitikájához hangolja ezt a mátrixot, ahelyett, hogy egy rögzített listát tesztelne.

Gyakori buktatók

Még a gondos csapatok is ugyanazokba botlanak bele. Figyeljen ezekre:

• Tesztelés nyitott szemmel. Ha látja a képernyőt, tudat alatt kompenzálni fogja azt, amit az olvasó nem mond el. Kapcsolja ki a monitort, vagy legalább nézzen félre, és kizárólag hang alapján navigáljon.
• Csak egy olvasó tesztelése. Fentebb tárgyaltuk — ez a hamis magabiztosság legnagyobb egyetlen forrása.
• Az űrlap-/fókuszmód kihagyása. Az NVDA-ban és a JAWS-ban az egyéni widgetekhez gyakran szükséges, hogy a felhasználó a megfelelő módban legyen. Ha csak böngészési módban tesztel, kihagyja azokat az interakciókat, amelyek fókuszmódban elromlanak.
• Az aria-label túlhasználata. Az ARIA-címkék mindenhová hozzáadása felülírhatja a látható szöveget, eltávolíthatja a hozzáférhető nevet a megjelenítettől, és összezavarhatja a hangvezérlést használó felhasználókat. Részesítse előnyben a natív címkézést; csak akkor nyúljon az ARIA-hoz, ha a HTML nem tudja kifejezni a kapcsolatot.
• Annak feltételezése, hogy az APG sikert garantál. Az ARIA Authoring Practices a szándékolt viselkedést írja le, nem azt, amit minden olvasó tesz. Mindig ellenőrizze valódi olvasókkal szemben.
• Az overlay-widgetekben való bizalom. Az overlay- és „MI-hozzáférhetőség“-widgetek, amelyek azt állítják, hogy futásidőben javítják a képernyőolvasó-hozzáférést, nem nyújtanak megbízható élményt, és gyakran rontják a navigációt éppen azok számára, akiknek állítólag segítenek. A valódi teszteléssel megerősített hozzáférhető kódnak nincs helyettesítője. Auditálja a tényleges DOM-ot és a bemondásokat, ne az overlay marketingjét.
• A mobil utógondolatként kezelése. Az iOS VoiceOver és az Android TalkBack saját gesztus-, fókusz- és élőrégió-problémákat tár fel, amelyeket az asztali tesztelés soha nem fed fel.

Miért ad hozzáadott értéket a fogyatékossággal élők általi tesztelés

Egy olvasó saját futtatása sok mindent megfog — de a technikai megfelelés és a valódi használhatóság között jelentős különbség van, és éppen ebben a különbségben számít a legtöbbet a megélt tapasztalat. Egy mindennapi képernyőolvasó-használó reflexszerűen navigál: címsoronként halad, a rotorral fut át, felismeri, amikor egy bemondás terjengős vagy fölösleges, és azonnal érzi, amikor egy folyamat hatékonytalan útra kényszeríti, még ha minden egyes elem „megfelelő“ is.

Egy látó fejlesztő, aki először tesztel, hajlamos a jelenlétet ellenőrizni — „a gombot bemondja“ — míg egy szakértő felhasználó az élményt értékeli — „a gombot bemondja, de a címke kétértelmű, a megerősítést nem mondja ki, és idejutni tizenkét extra söprésbe került“. Ezek a használhatósági megállapítások ritkán jelennek meg egy megfelelőségi ellenőrzőlistán, mégis pontosan ezek döntik el, hogy valaki ténylegesen el tud-e végezni egy feladatot. Ezért a QualiBooth az automatizált hozzáférhetőségi szkennelő szoftvert és hozzáférhetőségi eszköztárunkat párosítja a fogyatékossággal élők általi auditokkal: az eszközök megtalálják a nyilvánvalót, a szakértők megtalálják azt, ami valóban elrontja az élményt. A gyakran változó termékek esetében az ismétlődő hozzáférhetőségi auditok megakadályozzák, hogy ez a lefedettség a kiadások között elsodródjon.

Hová illeszkedik a képernyőolvasó-tesztelés a programjában

A képernyőolvasó-tesztelés egy diszciplína egy szélesebb gyakorlaton belül. Természetesen párosul a kizárólag billentyűzetes teszteléssel és azokkal az adaptív webes eszközökkel, amelyekre a felhasználói támaszkodnak, és olyan bizonyítékot állít elő, amely támogatja az EAA, az ADA és a Section 508 szerinti jogi kötelezettségeket. A megállapítások közvetlenül táplálják a dokumentációt is: csapatunk az olvasónkénti eredményeket VPAT-jelentésekké és prioritizált hibajavítási tervekké fordítja, amelyeket hozzáférhetőségi tanácsadás keretében szállítunk. Ha hosszú távú programot épít, nem pedig egyszeri ellenőrzést, ez az integráció az, ami megakadályozza, hogy a hozzáférhetőség visszacsússzon.

Következtetés

A képernyőolvasók nem felcserélhetők, és egy tiszta automatizált jelentés nem használható termék. Az NVDA, a JAWS, a VoiceOver és a TalkBack mind másképp értelmezi a kódját, különböző böngészőkkel párosul, és különböző hibákat tár fel — így a közönsége által használt valódi párosítások tesztelése az egyetlen mód a biztonságra. Strukturálja a tesztelését a bemondások, szerepek és állapotok, fókusz, olvasási sorrend, élő régiók és egyéni widgetek köré; részesítse előnyben a natív szemantikát az ARIA-foltokkal szemben; hagyja figyelmen kívül az overlay-eket; és ahol csak lehet, hagyja, hogy azok az emberek, akik nap mint nap használják ezeket az eszközöket, megmondják, mi működik valójában.

Amikor ezt a biztonságot szakemberekkel szeretné megerősíttetni, a QualiBooth képernyőolvasó-értékelése az összes főbb olvasón tesztel, és pontos kódjavításokkal együtt adja vissza a megállapításokat. Akár kezdheti egy ingyenes szkenneléssel is, vagy kérhet bemutatót, hogy lássa, hol áll ma a felülete.

GYIK

Hány képernyőolvasót kell valójában tesztelnem?

Legalább az NVDA-t, a JAWS-t és a VoiceOvert tesztelje asztali gépen, plusz a VoiceOvert iOS-en és a TalkBacket Androidon, ha mobilélményt szállít. Ennél kevesebb tesztelése vakfoltokat hagy, mert az olvasók eltérnek abban, hogyan kezelik az ARIA-t és a dinamikus tartalmat.

Helyettesíthetik-e az automatizált eszközök a képernyőolvasó-tesztelést?

Nem. Az automatizált eszközök megbízhatóan csak a problémák egy részét fogják meg — hiányzó alt-szöveg, néhány kontrasztprobléma, bizonyos szerkezeti hibák — de nem tudják megítélni, hogy egy bemondás világos-e, hogy a fókusz értelmesen mozog-e, vagy hogy egy feladat ténylegesen elvégezhető-e kizárólag hang alapján. Ehhez valódi olvasó kell, és ideális esetben valódi felhasználó.

Megszüntetik-e az overlay- vagy „MI-hozzáférhetőség“-widgetek a tesztelés szükségességét?

Nem. Az overlay-ek nem nyújtanak megbízható képernyőolvasó-élményt, és gyakran új problémákat vezetnek be. A tartós javítás a valódi olvasóteszteléssel megerősített hozzáférhető kód, és pontosan ezt nyújtja a képernyőolvasó-értékelési szolgáltatásunk.

Mely WCAG-kritériumokat fedi le a képernyőolvasó-tesztelés?

Közvetlenül támogatja az 1.3.1 (Információ és kapcsolatok), a 2.4.3 (Fókuszsorrend), a 4.1.2 (Név, szerep, érték) és a 4.1.3 (Állapotüzenetek) kritériumokat, többek között. Egy strukturált értékelésből származó minden megállapítás hozzárendelhető a vonatkozó WCAG 2.2 sikerkritériumhoz.