Testarea cititoarelor de ecran: NVDA, JAWS, VoiceOver

O pagină poate trece de fiecare verificare automată, poate fi lansată cu HTML valid și, totuși, să fie inutilizabilă pentru cineva care navighează pe web după ureche. Instrumentele automate detectează aproximativ o treime din problemele de accesibilitate; restul trăiesc în golul dintre ceea ce conține tehnic arborele de accesibilitate și ceea ce anunță de fapt un cititor de ecran unui utilizator. Acoperirea acestui gol înseamnă să puneți interfața dvs. în fața acelorași instrumente pe care se bazează publicul dvs. — și exact pentru asta servește testarea cu cititoare de ecran.

Acest ghid parcurge cum diferă principalele cititoare de ecran, de ce testarea unuia singur nu este niciodată suficientă, ce anume să testați, ce combinații de cititor și browser să folosiți și capcanele care prind chiar și echipele experimentate. Este scris pentru dezvoltatori, ingineri QA și specialiști în accesibilitate care vor să testeze deliberat, nu să ghicească. Dacă preferați să încredințați munca unor specialiști care folosesc aceste instrumente zilnic, serviciul nostru de evaluare a cititoarelor de ecran face exact acest lucru.

De ce un cititor de ecran nu este un instrument de „citire cu voce tare”

Cea mai frecventă neînțelegere este că un cititor de ecran pur și simplu rostește textul de pe pagină. Face mult mai mult de atât, iar înțelegerea diferenței este fundamentul unei testări bune. Un cititor de ecran construiește un model paralel, nevizual, al interfeței pornind de la arborele de accesibilitate al browserului. Anunță numele fiecărui element („Trimitere, buton”), rolul său (buton, link, titlu, casetă de bifare) și starea sa (bifat, extins, dezactivat, obligatoriu). Permite utilizatorului să sară între titluri, repere, câmpuri de formular și linkuri fără a atinge aspectul vizual. Rostește modificările dinamice — mesaje de eroare, rezultate de căutare, actualizări de stare — atunci când aceste modificări sunt expuse corect.

Acest lucru este fundamental diferit de conversia text-în-vorbire, care transformă un bloc de text în audio fără nicio noțiune de roluri, stări sau navigare. Tratăm distincția în detaliu în text-în-vorbire față de cititoarele de ecran, și contează aici deoarece testarea pentru unul nu testează pentru celălalt. Un utilizator de cititor de ecran nu consumă pagina dvs. de sus în jos; o navighează structural și se așteaptă ca fiecare element interactiv să declare ce este și ce face.

Cum diferă NVDA, JAWS, VoiceOver și TalkBack

Cele patru cititoare de care majoritatea echipelor trebuie să țină cont se comportă suficient de diferit încât „funcționează într-unul” nu vă spune aproape nimic despre celelalte.

NVDA (Windows)

NVDA este un cititor gratuit, cu sursă deschisă, și cel mai utilizat cititor de ecran din lume. Se asociază cel mai natural cu Firefox și Chrome. NVDA tinde să urmeze îndeaproape semantica ARIA și HTML, ceea ce îl face o bază excelentă: dacă ceva este defect în marcajul dvs., NVDA îl scoate adesea clar la suprafață. Are două moduri-cheie — modul de navigare (browse mode, pentru citire și navigare structurală) și modul de focalizare (focus mode, pentru tastare în formulare și operarea widgeturilor) — iar o sursă frecventă de erori sunt widgeturile care nu reușesc să declanșeze comutarea corectă a modului.

JAWS (Windows)

JAWS este cititorul comercial consacrat de mult timp, încă dominant în întreprinderi, administrația publică și multe locuri de muncă. Se asociază cu Chrome și Edge. JAWS este renumit pentru că este „săritor”: aplică euristici care ghicesc sensul, anunțând uneori lucruri despre care NVDA tace, și mascând ocazional greșeli de marcaj care ar trebui corectate. Această disponibilitate taie în ambele sensuri — codul care „funcționează în JAWS” poate eșua în NVDA sau VoiceOver deoarece JAWS a acoperit problema. Are de asemenea propriul cursor virtual și un comportament al modului de formular care diferă subtil de cel al NVDA.

VoiceOver (macOS și iOS)

VoiceOver vine integrat în fiecare Mac, iPhone și iPad, și se asociază aproape exclusiv cu Safari. Pe macOS, navigarea funcționează prin rotor și combinațiile de taste VO; pe iOS este în întregime bazată pe gesturi — glisați pentru a vă deplasa, atingere dublă pentru a activa, rotor răsucind două degete. VoiceOver este în general cel mai strict dintre cele patru în privința ARIA: adesea tace în loc să ghicească atunci când lipsesc nume sau roluri, astfel încât un control pe care JAWS îl anunță poate să nu spună nimic în VoiceOver. VoiceOver pentru desktop și cel pentru mobil diferă de asemenea între ele, așa că se consideră două ținte de testare separate.

TalkBack (Android)

TalkBack este cititorul integrat al Android, asociat cu Chrome. La fel ca VoiceOver pe iOS, este bazat pe gesturi, dar gesturile sale, comportamentul de focalizare și gestionarea regiunilor live și a controalelor personalizate diferă de cele ale VoiceOver. Cititoarele mobile în general scot la iveală probleme care nu apar niciodată pe desktop: ținte tactile care nu pot fi atinse prin glisare, focalizare care sare neașteptat după o tranziție de ecran și conținut care este prezent vizual, dar este omis complet de ordinea liniară a gesturilor.

De ce testarea pe mai multe cititoare este esențială

Deoarece aceste cititoare diverg în modul în care interpretează exact același marcaj, testarea unui singur cititor produce un fals sentiment de siguranță. Câteva tipare concrete apar iar și iar:

Un combobox personalizat pe care JAWS îl anunță perfect poate deveni complet tăcut în VoiceOver deoarece VoiceOver refuză să deducă un role sau o stare aria-expanded care lipsește.
O regiune live pe care NVDA o anunță politicos o dată poate fi anunțată repetat, sau deloc, în alt cititor, în funcție de cum interacționează aria-live și momentul inserării în DOM.
Un control cu un nume redundant sau contradictoriu (etichetă vizibilă plus aria-label plus title) poate fi anunțat rezonabil de un cititor și ca un șir confuz de duplicate de altul.
Ordinea de citire care corespunde ordinii vizuale într-o pereche browser/cititor poate diverge în alta atunci când CSS reordonează conținutul, dar DOM-ul nu.

Fiecare cititor este de asemenea legat de un browser diferit, așa că în realitate testați combinații de cititor plus browser, nu cititoare separate. Singura modalitate de a ști că produsul dvs. este coerent pentru toată lumea este să testați combinațiile reale pe care le folosește publicul dvs. Acest principiu este același care stă la baza auditurilor manuale de accesibilitate în general: instrumentele restrâng căutarea, oamenii confirmă experiența.

Ce să testați

Testarea este mult mai eficientă atunci când este structurată. Acestea sunt dimensiunile care contează, aproximativ în ordinea priorității, iar fiecare corespunde unor criterii de succes specifice WCAG 2.2.

Anunțuri: nume, rol, valoare

Pentru fiecare element interactiv, confirmați că cititorul anunță un nume precis (ce este), rolul corect (buton, link, casetă de bifare, filă) și, acolo unde este relevant, valoarea sau starea. Acesta este miezul WCAG 4.1.2 (Nume, Rol, Valoare). Ascultați în mod specific: controale tăcute, controale anunțate doar ca „clicabil” sau „grup”, butoane pictogramă fără nume accesibil și nume care se citesc ca rute de fișiere brute sau nume de clase.

Roluri și stări

Stările trebuie să se actualizeze pe măsură ce utilizatorul interacționează. Un element de dezvăluire care se extinde ar trebui să treacă de la „restrâns” la „extins”; o casetă de bifare ar trebui să treacă de la „nebifat” la „bifat”; un buton de sortare ar trebui să-și anunțe direcția curentă. Marcajul static care nu actualizează niciodată aria-expanded, aria-checked, aria-selected sau aria-pressed este unul dintre cele mai frecvente defecte și se dezvăluie doar atunci când operați widgetul cu un cititor în funcțiune.

Ordinea de focalizare și gestionarea focalizării

Tabulați prin întreaga interfață. Focalizarea trebuie să se deplaseze într-o ordine logică, previzibilă (WCAG 2.4.3), trebuie să fie întotdeauna vizibilă și nu trebuie să fie niciodată blocată, cu excepția cazurilor deliberate din interiorul unei ferestre modale. Cazurile dificile sunt dinamice: când se deschide un dialog, focalizarea ar trebui să se mute în el; când se închide, focalizarea ar trebui să revină la elementul care l-a deschis. Omiterea acestui aspect este cel mai frecvent motiv pentru care un flux modal este inutilizabil.

Ordinea de citire și navigare

Dincolo de focalizare, utilizatorii de cititoare de ecran navighează după structură. Verificați că titlurile formează o schiță logică (WCAG 1.3.1), că reperele (header, nav, main, footer) le permit utilizatorilor să se deplaseze, și că listele și tabelele sunt marcate astfel încât cititorul să le poată naviga și număra. Verificați că secvența de citire corespunde intenției vizuale și că nimic important nu este anunțat în afara ordinii.

Regiuni live și actualizări dinamice

Modificările asincrone — erori de validare, „3 rezultate găsite”, „se salvează…”, notificări toast — trebuie să ajungă la utilizator fără a-l copleși. aria-live="polite" pentru actualizări neurgente, aria-live="assertive" doar pentru cele cu adevărat urgente, și role="status" sau role="alert" pentru cazurile obișnuite. Testați că regiunea există în DOM înainte de a se schimba conținutul, că actualizarea este anunțată exact o dată și că nu întrerupe utilizatorul la mijlocul unei propoziții. Acest lucru susține WCAG 4.1.3 (Mesaje de stare).

Widgeturi ARIA personalizate

Tot ceea ce ați construit dvs. înșivă — meniuri, file, comboboxuri, selectoare de dată, carusele, grile de date, vizualizări arborescente — necesită cel mai mare grad de atenție. Testați față de ARIA Authoring Practices pentru interacțiunea de tastatură și anunțurile așteptate, apoi confirmați că cititoarele reale se comportă într-adevăr astfel. APG descrie idealul; cititoarele îl implementează imperfect, motiv pentru care un tipar funcțional tot trebuie verificat în fiecare cititor.

Un exemplu concret: un comutator inaccesibil față de unul accesibil

Considerați un comutator de setări. O versiune stilizată vizual, dar goală semantic:

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

Pentru un cititor de ecran acesta este, în cel mai bun caz, o bucată de text static. Nu există rol, așa că nu este anunțat ca un control; nicio stare, așa că utilizatorul nu poate spune dacă notificările sunt pornite sau oprite; și nu se află în ordinea de tabulare, așa că un utilizator de tastatură sau de cititor de ecran nu îl poate nici măcar atinge sau opera. La testare, NVDA citește „Notifications” și merge mai departe; VoiceOver îl poate omite complet.

Echivalentul accesibil folosește elementul nativ și expune starea:

<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));
});

Acum fiecare cititor anunță „Notifications, buton comutator, neapăsat”, este accesibil cu Tab, operabil cu Enter sau Spațiu, iar starea se schimbă audibil când este activat. Lecția se generalizează: preferați semantica nativă, iar atunci când trebuie să folosiți ARIA, testați că fiecare cititor respectă într-adevăr rolul și starea. Tipare precum acest defect de stare lipsă se numără printre problemele frecvente de accesibilitate de evitat.

Combinații recomandate de cititor și browser

Testați combinațiile pe care le folosesc utilizatorii reali, nu perechi arbitrare. O matrice practică ce acoperă marea majoritate a utilizatorilor de cititoare de ecran:

NVDA + Firefox (Windows) — cea mai curată bază pentru depistarea problemelor de marcaj
NVDA + Chrome (Windows) — cea mai frecventă combinație de cititor gratuit în practică
JAWS + Chrome (Windows) — dominantă în mediile de întreprindere și guvernamentale
VoiceOver + Safari (macOS) — singura combinație VoiceOver pentru desktop complet acceptată
VoiceOver + Safari (iOS) — mobil bazat pe gesturi, o țintă separată de desktop
TalkBack + Chrome (Android) — combinația standard pentru Android

Combinațiile contează deoarece cititoarele sunt acordate pentru browsere specifice; VoiceOver cu Chrome sau JAWS cu Firefox produc un comportament care nu reflectă modul în care publicul dvs. experimentează de fapt pagina. Acolo unde analiticele dvs. arată un anumit public — să zicem, un produs din sectorul public cu utilizare intensă a JAWS, sau o aplicație de consum înclinată spre mobil — ponderați matricea în consecință. Serviciul nostru de evaluare a cititoarelor de ecran acordează această matrice la analiticele fiecărui client, în loc să testeze o listă fixă.

Capcane frecvente

Chiar și echipele atente se împiedică de aceleași lucruri. Fiți atenți la acestea:

Testarea cu ochii deschiși. Dacă puteți vedea ecranul, veți compensa inconștient ceea ce cititorul nu vă spune. Stingeți monitorul, sau cel puțin priviți în altă parte, și navigați doar după audio.
Testarea unui singur cititor. Tratată mai sus — este cea mai mare sursă individuală de falsă încredere.
Omiterea modului de formular/focalizare. În NVDA și JAWS, widgeturile personalizate au adesea nevoie ca utilizatorul să fie în modul corect. Dacă testați doar în modul de navigare, veți rata interacțiuni care se strică în modul de focalizare.
Suprautilizarea aria-label. Adăugarea de etichete ARIA peste tot poate suprascrie textul vizibil, poate desincroniza numele accesibil de ceea ce se afișează și poate deruta utilizatorii de control vocal. Preferați etichetarea nativă; recurgeți la ARIA doar atunci când HTML nu poate exprima relația.
Presupunerea că APG garantează succesul. ARIA Authoring Practices descriu comportamentul intenționat, nu ceea ce face fiecare cititor. Verificați întotdeauna față de cititoare reale.
Încrederea în widgeturile de suprapunere. Widgeturile de suprapunere și de „accesibilitate cu IA” care pretind că rezolvă accesul cititoarelor de ecran în timpul rulării nu oferă o experiență fiabilă și adesea înrăutățesc navigarea pentru persoanele pe care pretind că le ajută. Nu există substitut pentru un marcaj accesibil confirmat prin testare reală. Auditați DOM-ul și anunțurile reale, nu marketingul suprapunerii.
Tratarea mobilului ca o idee de moment. VoiceOver pe iOS și TalkBack pe Android scot la iveală propriile probleme de gesturi, focalizare și regiuni live pe care testarea pe desktop nu le dezvăluie niciodată.

De ce testarea de către persoane cu dizabilități adaugă valoare

Rularea unui cititor de către dvs. înșivă depistează foarte mult — dar există o diferență semnificativă între a trece tehnic și a fi cu adevărat utilizabil, iar acea diferență este locul unde experiența trăită contează cel mai mult. Un utilizator zilnic de cititor de ecran navighează din reflex: se deplasează după titlu, parcurge cu rotorul, recunoaște când un anunț este prolix sau redundant, și simte imediat când un flux îl forțează pe un drum ineficient, chiar dacă fiecare element individual este „conform”.

Un dezvoltator văzător care testează pentru prima dată tinde să verifice prezența — „butonul este anunțat” — în timp ce un utilizator expert evaluează experiența — „butonul este anunțat, dar eticheta este ambiguă, confirmarea nu este rostită, iar ajungerea aici a necesitat douăsprezece glisări în plus”. Aceste constatări de utilizabilitate apar rareori într-o listă de verificare a conformității, însă sunt exact ceea ce determină dacă cineva poate finaliza efectiv o sarcină. De aceea, QualiBooth combină software-ul automat de scanare a accesibilității și setul nostru de instrumente de accesibilitate cu auditurile efectuate de persoane cu dizabilități: instrumentele găsesc evidentul, experții găsesc ceea ce strică de fapt experiența. Pentru produse care se schimbă frecvent, auditurile de accesibilitate recurente împiedică această acoperire să devieze între versiuni.

Unde se încadrează testarea cu cititoare de ecran în programul dvs.

Testarea cu cititoare de ecran este o disciplină în cadrul unei practici mai largi. Se asociază natural cu testarea doar cu tastatura și cu instrumentele web adaptive pe care se bazează utilizatorii dvs., și produce tipul de dovezi care susțin obligațiile legale conform EAA, ADA și Section 508. Constatările alimentează de asemenea direct documentația: echipa noastră traduce rezultatele cititor cu cititor în rapoarte VPAT și în planurile de remediere prioritizate pe care le livrăm prin consultanță în accesibilitate. Dacă construiți un program pe termen lung în loc de o verificare unică, această integrare este ceea ce împiedică accesibilitatea să regreseze.

Concluzie

Cititoarele de ecran nu sunt interschimbabile, iar un raport automat curat nu este un produs utilizabil. NVDA, JAWS, VoiceOver și TalkBack interpretează fiecare diferit marcajul dvs., se asociază cu browsere diferite și dezvăluie defecte diferite — așa că testarea pe combinațiile reale pe care le folosește publicul dvs. este singura modalitate de a fi siguri. Structurați-vă testarea în jurul anunțurilor, rolurilor și stărilor, focalizării, ordinii de citire, regiunilor live și widgeturilor personalizate; preferați semantica nativă în locul peticelor ARIA; ignorați suprapunerile; și, ori de câte ori este posibil, lăsați persoanele care folosesc aceste instrumente zilnic să vă spună ce funcționează cu adevărat.

Când doriți ca această certitudine să fie verificată de specialiști, evaluarea cititoarelor de ecran de la QualiBooth testează pe toate cititoarele majore și returnează constatări cu corecții exacte de marcaj. Puteți de asemenea începe cu o scanare gratuită sau solicita o demonstrație pentru a vedea unde se află interfața dvs. astăzi.

Întrebări frecvente

De câte cititoare de ecran am nevoie cu adevărat să testez?

Cel puțin, testați NVDA, JAWS și VoiceOver pe desktop, plus VoiceOver pe iOS și TalkBack pe Android dacă oferiți o experiență mobilă. Testarea mai puținelor lasă puncte oarbe deoarece cititoarele diverg în modul în care gestionează ARIA și conținutul dinamic.

Pot instrumentele automate să înlocuiască testarea cu cititoare de ecran?

Nu. Instrumentele automate detectează în mod fiabil doar o parte din probleme — text alternativ lipsă, unele probleme de contrast, anumite erori structurale — dar nu pot judeca dacă un anunț este clar, dacă focalizarea se deplasează rezonabil sau dacă o sarcină este efectiv realizabilă doar prin audio. Acestea necesită un cititor real și, ideal, un utilizator real.

Elimină widgeturile de suprapunere sau de „accesibilitate cu IA” nevoia de testare?

Nu. Suprapunerile nu produc o experiență fiabilă de cititor de ecran și introduc frecvent probleme noi. Soluția durabilă este un marcaj accesibil confirmat prin testare reală cu cititoare, ceea ce oferă serviciul nostru de evaluare a cititoarelor de ecran.

Ce criterii WCAG acoperă testarea cu cititoare de ecran?

Susține direct 1.3.1 (Informații și relații), 2.4.3 (Ordinea focalizării), 4.1.2 (Nume, Rol, Valoare) și 4.1.3 (Mesaje de stare), printre altele. Fiecare constatare dintr-o evaluare structurată poate fi corelată cu criteriul de succes WCAG 2.2 relevant.