Proves amb lectors de pantalla: NVDA, JAWS, VoiceOver

Una pàgina pot superar totes les comprovacions automatitzades, publicar-se amb HTML vàlid i, tot i així, ser inutilitzable per a algú que navega per la web amb l’oïda. Les eines automatitzades detecten aproximadament un terç dels problemes d’accessibilitat; la resta viuen al buit entre el que tècnicament conté l’arbre d’accessibilitat i el que un lector de pantalla anuncia realment a un usuari. Tancar aquest buit significa posar la teva interfície davant de les mateixes eines en què confia el teu públic — i això és precisament per al que serveixen les proves amb lectors de pantalla.

Aquesta guia recorre com es diferencien els principals lectors de pantalla, per què provar-ne només un mai no és suficient, què s’ha de provar exactament, quines combinacions de lector i navegador cal utilitzar i els paranys que enxampen fins i tot els equips experimentats. Està escrita per a desenvolupadors, enginyers de QA i especialistes en accessibilitat que volen provar de manera deliberada en lloc d’endevinar. Si prefereixes deixar la feina a especialistes que utilitzen aquestes eines cada dia, el nostre servei d’avaluació de lectors de pantalla fa exactament això.

Per què un lector de pantalla no és una eina de «llegir en veu alta»

L’error més habitual és pensar que un lector de pantalla simplement llegeix el text de la pàgina. Fa molt més que això, i entendre la diferència és la base d’unes bones proves. Un lector de pantalla construeix un model paral·lel i no visual de la interfície a partir de l’arbre d’accessibilitat del navegador. Anuncia el nom de cada element («Enviar, botó»), el seu rol (botó, enllaç, encapçalament, casella de selecció) i el seu estat (marcat, expandit, desactivat, obligatori). Permet a l’usuari saltar entre encapçalaments, fites, camps de formulari i enllaços sense tocar la disposició visual. Anuncia canvis dinàmics — missatges d’error, resultats de cerca, actualitzacions d’estat — quan aquests canvis s’exposen correctament.

Això és fonamentalment diferent de la conversió de text a veu, que converteix un bloc de text en àudio sense cap noció de rols, estats o navegació. Tractem aquesta distinció amb detall a text a veu enfront de lectors de pantalla, i és rellevant aquí perquè provar l’un no prova l’altre. Un usuari de lector de pantalla no consumeix la teva pàgina de dalt a baix; la navega estructuralment i espera que cada element interactiu declari què és i què fa.

Com es diferencien NVDA, JAWS, VoiceOver i TalkBack

Els quatre lectors que la majoria d’equips han de tenir en compte es comporten prou diferent perquè «funciona en un» no et digui gairebé res sobre els altres.

NVDA (Windows)

NVDA és un lector gratuït i de codi obert, i el lector de pantalla més utilitzat del món. S’aparella més naturalment amb Firefox i Chrome. NVDA tendeix a seguir de prop la semàntica d’ARIA i HTML, cosa que el converteix en una base excel·lent: si alguna cosa està trencada al teu marcatge, NVDA sovint ho mostra clarament. Té dos modes clau — mode de navegació (per llegir i navegar estructuralment) i mode d’enfocament (per escriure en formularis i operar ginys) — i una font freqüent d’errors són els ginys que no aconsegueixen activar el canvi de mode correcte.

JAWS (Windows)

JAWS és el lector comercial establert de fa temps, encara dominant a les empreses, l’administració pública i molts llocs de treball. S’aparella amb Chrome i Edge. JAWS és famós per ser «servicial»: aplica heurístiques que endevinen el significat, anunciant de vegades coses sobre les quals NVDA calla, i ocasionalment dissimulant errors de marcatge que s’haurien de corregir. Aquesta servicialitat talla en tots dos sentits — el codi que «funciona a JAWS» pot fallar a NVDA o VoiceOver perquè JAWS va tapar el problema. També té el seu propi cursor virtual i un comportament de mode de formularis que difereix subtilment del de NVDA.

VoiceOver (macOS i iOS)

VoiceOver ve integrat a tots els Mac, iPhone i iPad, i s’aparella gairebé exclusivament amb Safari. A macOS, la navegació funciona a través del rotor i les combinacions de tecla VO; a iOS és totalment basada en gestos — llisca per moure’t, doble toc per activar, rotor girant dos dits. VoiceOver és generalment el més estricte dels quatre quant a ARIA: sovint calla en lloc d’endevinar quan falten noms o rols, de manera que un control que JAWS anuncia pot no dir res a VoiceOver. El VoiceOver d’escriptori i el mòbil també difereixen entre si, així que compten com a dos objectius de prova separats.

TalkBack (Android)

TalkBack és el lector integrat d’Android, aparellat amb Chrome. Igual que el VoiceOver d’iOS, es basa en gestos, però els seus gestos, el comportament d’enfocament i la gestió de les regions actives i els controls personalitzats difereixen dels de VoiceOver. Els lectors mòbils en general revelen problemes que mai no apareixen a l’escriptori: àrees tàctils que no es poden assolir lliscant, enfocament que salta inesperadament després d’una transició de pantalla i contingut que és visualment present però que s’omet completament en l’ordre lineal de gestos.

Per què és essencial provar amb diversos lectors

Com que aquests lectors divergeixen en com interpreten exactament el mateix marcatge, provar amb un sol lector produeix una falsa sensació de seguretat. Uns quants patrons concrets apareixen una vegada i una altra:

Un combobox personalitzat que JAWS anuncia perfectament pot quedar completament en silenci a VoiceOver perquè VoiceOver es nega a inferir un role o un estat aria-expanded que falti.
Una regió activa que NVDA anuncia educadament una vegada pot anunciar-se repetidament, o gens, en un altre lector segons com interactuïn aria-live i el moment d’inserció al DOM.
Un control amb un nom redundant o contradictori (etiqueta visible més aria-label més title) pot anunciar-se de manera sensata per un lector i com una confusa cadena de duplicats per un altre.
L’ordre de lectura que coincideix amb l’ordre visual en una parella navegador/lector pot divergir en una altra quan el CSS reordena el contingut però el DOM no.

Cada lector també està lligat a un navegador diferent, així que en realitat estàs provant combinacions de lector més navegador, no lectors sols. L’única manera de saber que el teu producte és coherent per a tothom és provar les combinacions reals que utilitza el teu públic. Aquest principi és el mateix que hi ha darrere de les auditories manuals d’accessibilitat en general: les eines estrenyen la cerca, les persones confirmen l’experiència.

Què s’ha de provar

Les proves són molt més efectives quan estan estructurades. Aquestes són les dimensions que importen, aproximadament per ordre de prioritat, i cadascuna correspon a criteris d’èxit específics de WCAG 2.2.

Anuncis: nom, rol, valor

Per a cada element interactiu, confirma que el lector anuncia un nom precís (què és), el rol correcte (botó, enllaç, casella de selecció, pestanya) i, quan sigui rellevant, el valor o estat. Aquest és el cor de WCAG 4.1.2 (Nom, rol, valor). Escolta específicament: controls silenciosos, controls anunciats només com a «clicable» o «grup», botons d’icona sense nom accessible i noms que es llegeixen com a rutes de fitxers o noms de classes en brut.

Rols i estats

Els estats han d’actualitzar-se a mesura que l’usuari hi interactua. Un desplegable que s’expandeix hauria de passar de «contret» a «expandit»; una casella de selecció hauria de passar de «no marcada» a «marcada»; un botó d’ordenació hauria d’anunciar la seva direcció actual. El marcatge estàtic que mai no actualitza aria-expanded, aria-checked, aria-selected o aria-pressed és un dels defectes més habituals, i només es revela quan operes el giny amb un lector en marxa.

Ordre d’enfocament i gestió de l’enfocament

Tabula per tota la interfície. L’enfocament s’ha de moure en un ordre lògic i previsible (WCAG 2.4.3), ha de ser sempre visible i no ha de quedar mai atrapat excepte deliberadament dins d’una finestra modal. Els casos difícils són dinàmics: quan s’obre un diàleg, l’enfocament s’hi ha de moure; quan es tanca, l’enfocament ha de tornar a l’element que el va obrir. Saltar-se això és el motiu més habitual pel qual un flux modal és inutilitzable.

Ordre de lectura i navegació

Més enllà de l’enfocament, els usuaris de lectors de pantalla naveguen per estructura. Verifica que els encapçalaments formen un esquema lògic (WCAG 1.3.1), que les fites (header, nav, main, footer) permeten als usuaris moure’s, i que les llistes i taules estan marcades de manera que el lector pugui navegar-les i comptar-les. Comprova que la seqüència de lectura coincideix amb la intenció visual i que res important no s’anuncia fora d’ordre.

Regions actives i actualitzacions dinàmiques

Els canvis asíncrons — errors de validació, «3 resultats trobats», «desant…», notificacions toast — han d’arribar a l’usuari sense aclaparar-lo. aria-live="polite" per a actualitzacions no urgents, aria-live="assertive" només per a les realment urgents, i role="status" o role="alert" per als casos habituals. Comprova que la regió existeix al DOM abans que canviï el contingut, que l’actualització s’anuncia exactament una vegada i que no interromp l’usuari a mitja frase. Això dona suport a WCAG 4.1.3 (Missatges d’estat).

Ginys ARIA personalitzats

Tot el que hagis construït tu mateix — menús, pestanyes, comboboxos, selectors de data, carrusels, graelles de dades, vistes d’arbre — necessita el màxim escrutini. Prova-ho contra les ARIA Authoring Practices per a la interacció de teclat i els anuncis esperats, i després confirma que els lectors reals es comporten realment així. L’APG descriu l’ideal; els lectors l’implementen de manera imperfecta, i per això un patró que funciona encara s’ha de verificar a cada lector.

Un exemple concret: un commutador inaccessible enfront d’un d’accessible

Considera un commutador de configuració. Una versió estilitzada visualment però semànticament buida:

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

Per a un lector de pantalla això és, en el millor dels casos, un fragment de text estàtic. No hi ha rol, així que no s’anuncia com a control; cap estat, així que l’usuari no pot saber si les notificacions estan activades o desactivades; i no està en l’ordre de tabulació, així que un usuari de teclat o lector de pantalla no pot ni tan sols assolir-lo ni operar-lo. En les proves, NVDA llegeix «Notifications» i continua; VoiceOver pot ometre’l completament.

L’equivalent accessible utilitza l’element natiu i exposa l’estat:

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

Ara cada lector anuncia «Notifications, botó de commutació, no premut», és accessible amb el Tab, operable amb Enter o Espai, i l’estat canvia de manera audible quan s’activa. La lliçó es generalitza: prefereix la semàntica nativa, i quan hagis d’utilitzar ARIA, prova que cada lector respecta realment el rol i l’estat. Patrons com aquest defecte d’estat absent estan entre els problemes d’accessibilitat habituals que cal evitar.

Combinacions recomanades de lector i navegador

Prova les combinacions que utilitzen els usuaris reals, no parelles arbitràries. Una matriu pràctica que cobreix la gran majoria d’usuaris de lectors de pantalla:

NVDA + Firefox (Windows) — la base més neta per detectar problemes de marcatge
NVDA + Chrome (Windows) — la combinació de lector gratuït més habitual a la pràctica
JAWS + Chrome (Windows) — dominant en entorns empresarials i governamentals
VoiceOver + Safari (macOS) — l’única combinació de VoiceOver d’escriptori totalment compatible
VoiceOver + Safari (iOS) — mòbil basat en gestos, un objectiu separat de l’escriptori
TalkBack + Chrome (Android) — la combinació estàndard d’Android

Les combinacions importen perquè els lectors estan ajustats per a navegadors específics; VoiceOver amb Chrome o JAWS amb Firefox produeixen un comportament que no reflecteix com experimenta realment la pàgina el teu públic. Quan les teves analítiques mostrin un públic concret — diguem, un producte del sector públic amb molt ús de JAWS, o una aplicació de consum que s’inclina cap al mòbil — pondera la matriu en conseqüència. El nostre servei d’avaluació de lectors de pantalla ajusta aquesta matriu a les analítiques de cada client en lloc de provar una llista fixa.

Paranys habituals

Fins i tot els equips acurats ensopeguen amb les mateixes coses. Vigila aquestes:

Provar amb els ulls oberts. Si pots veure la pantalla, compensaràs inconscientment el que el lector no t’està dient. Apaga el monitor, o almenys mira cap a una altra banda, i navega només per àudio.
Provar només un lector. Tractat més amunt — és la font individual més gran de falsa confiança.
Saltar-se el mode de formularis/enfocament. A NVDA i JAWS, els ginys personalitzats sovint necessiten que l’usuari estigui en el mode correcte. Si només proves en mode de navegació, et perdràs interaccions que es trenquen en mode d’enfocament.
Abusar de aria-label. Afegir etiquetes ARIA pertot arreu pot sobreescriure el text visible, dessincronitzar el nom accessible del que es mostra i confondre els usuaris de control per veu. Prefereix l’etiquetatge natiu; recorre a ARIA només quan l’HTML no pugui expressar la relació.
Suposar que l’APG garanteix l’èxit. Les ARIA Authoring Practices descriuen el comportament previst, no el que fa cada lector. Verifica sempre contra lectors reals.
Confiar en els ginys de superposició. Els ginys de superposició i d’«accessibilitat amb IA» que afirmen solucionar l’accés dels lectors de pantalla en temps d’execució no ofereixen una experiència fiable i sovint empitjoren la navegació per a les persones que diuen ajudar. No hi ha substitut per a un marcatge accessible confirmat amb proves reals. Audita el DOM i els anuncis reals, no el màrqueting de la superposició.
Tractar el mòbil com una idea secundària. El VoiceOver d’iOS i el TalkBack d’Android revelen els seus propis problemes de gestos, enfocament i regions actives que les proves d’escriptori mai no revelen.

Per què les proves amb persones amb discapacitats aporten valor

Executar tu mateix un lector detecta moltíssim — però hi ha una diferència significativa entre passar tècnicament i ser genuïnament utilitzable, i aquesta diferència és on l’experiència viscuda importa més. Un usuari diari de lector de pantalla navega per reflex: es mou per encapçalament, fulleja amb el rotor, reconeix quan un anunci és verbós o redundant, i sent immediatament quan un flux el força per un camí ineficient encara que cada element individual sigui «conforme».

Un desenvolupador vident que prova per primera vegada tendeix a verificar la presència — «el botó s’anuncia» — mentre que un usuari expert avalua l’experiència — «el botó s’anuncia, però l’etiqueta és ambigua, la confirmació no es llegeix, i arribar fins aquí ha calgut dotze lliscaments addicionals». Aquestes troballes d’usabilitat rarament apareixen en una llista de verificació de conformitat, però són exactament el que determina si algú pot completar realment una tasca. Per això QualiBooth combina el programari de cerca d’accessibilitat automatitzat i el nostre kit d’eines d’accessibilitat amb auditories per part de persones amb discapacitats: les eines troben l’obvi, els experts troben el que realment trenca l’experiència. Per a productes que canvien sovint, les auditories d’accessibilitat recurrents eviten que aquesta cobertura es desviï entre versions.

On encaixen les proves amb lectors de pantalla al teu programa

Les proves amb lectors de pantalla són una disciplina dins d’una pràctica més àmplia. S’aparellen naturalment amb les proves només de teclat i amb les eines web adaptatives en què confien els teus usuaris, i produeixen el tipus d’evidència que dona suport a obligacions legals sota l’EAA, l’ADA i la Section 508. Les troballes també alimenten directament la documentació: el nostre equip tradueix els resultats lector per lector en informes VPAT i en els plans de correcció prioritzats que lliurem mitjançant la consultoria d’accessibilitat. Si estàs construint un programa a llarg termini en lloc d’una comprovació puntual, aquesta integració és el que evita que l’accessibilitat retrocedeixi.

Conclusió

Els lectors de pantalla no són intercanviables, i un informe automatitzat net no és un producte utilitzable. NVDA, JAWS, VoiceOver i TalkBack interpreten cadascun el teu marcatge de manera diferent, s’aparellen amb navegadors diferents i revelen defectes diferents — així que provar les combinacions reals que utilitza el teu públic és l’única manera d’estar segur. Estructura les teves proves al voltant dels anuncis, els rols i estats, l’enfocament, l’ordre de lectura, les regions actives i els ginys personalitzats; prefereix la semàntica nativa als pegats d’ARIA; ignora les superposicions; i, sempre que sigui possible, deixa que les persones que utilitzen aquestes eines cada dia et diguin què funciona realment.

Quan vulguis aquesta certesa verificada per especialistes, l’avaluació de lectors de pantalla de QualiBooth prova tots els lectors principals i retorna troballes amb correccions de marcatge exactes. També pots començar amb una cerca gratuïta o sol·licitar una demostració per veure on es troba la teva interfície avui.

Preguntes freqüents

Quants lectors de pantalla necessito provar realment?

Com a mínim, prova NVDA, JAWS i VoiceOver a l’escriptori, més VoiceOver a iOS i TalkBack a Android si ofereixes una experiència mòbil. Provar-ne menys deixa punts cecs perquè els lectors divergeixen en com gestionen ARIA i el contingut dinàmic.

Les eines automatitzades poden substituir les proves amb lectors de pantalla?

No. Les eines automatitzades detecten de manera fiable només una part dels problemes — text alternatiu absent, alguns problemes de contrast, certs errors estructurals — però no poden jutjar si un anunci és clar, si l’enfocament es mou sensatament o si una tasca és realment completable només amb àudio. Això requereix un lector real i, idealment, un usuari real.

Els ginys de superposició o d’«accessibilitat amb IA» eliminen la necessitat de provar?

No. Les superposicions no produeixen una experiència fiable de lector de pantalla i sovint introdueixen nous problemes. La solució duradora és un marcatge accessible confirmat mitjançant proves reals amb lectors, que és el que ofereix el nostre servei d’avaluació de lectors de pantalla.

Quins criteris WCAG cobreixen les proves amb lectors de pantalla?

Donen suport directament a 1.3.1 (Informació i relacions), 2.4.3 (Ordre d’enfocament), 4.1.2 (Nom, rol, valor) i 4.1.3 (Missatges d’estat), entre d’altres. Cada troballa d’una avaluació estructurada es pot assignar al criteri d’èxit WCAG 2.2 corresponent.