En las últimas semanas he estado analizando cómo se comportan distintos lectores de pantalla: NVDA, JAWS y VoiceOver frente a componentes concretos de interfaces web. Aunque todos comparten el mismo objetivo, hacer accesible la información para personas con discapacidad visual, la realidad es que cada uno interpreta, anuncia y navega los elementos de forma diferente. Aquí resumo las principales lecciones aprendidas que considero valiosas tanto para testers como para equipos de desarrollo.
El texto en pantalla no siempre coincide exactamente con lo que anuncia el lector
Una de las dudas más frecuentes es si la WCAG exige que el texto visible y el texto que anuncia el lector de pantalla coincidan palabra por palabra.
La respuesta es no: las pautas no exigen coincidencia literal, pero sí que la experiencia transmitida sea equivalente y comprensible para todos los usuarios.
Lección aprendida:
Lo importante no es la coincidencia textual, sino que el contenido anunciado transmita el mismo propósito e información. Esto deja espacio para adaptaciones útiles, como omitir símbolos irrelevantes o añadir contexto accesible mediante ARIA.
Las tabs pueden anunciarse como “documento” según el lector y el modo
Probando un componente de pestañas, observé que al seleccionar una tab JAWS anunciaba “documento”, algo que NVDA no hacía. Este comportamiento suele ocurrir cuando:
- JAWS interpreta el cambio de panel como una región diferente.
- El componente usa roles ARIA que JAWS traduce de forma más literal.
- El modo de navegación influye en qué información se anuncia.
Lección aprendida:
Aunque se siga exactamente la especificación WAI-ARIA, cada lector tiene su propia interpretación. Siempre es necesario validar la experiencia con al menos dos lectores, preferiblemente NVDA y JAWS en Windows, para evitar sorpresas.
Gráficos accesibles: NVDA suele funcionar mejor que JAWS dependiendo de cómo se etiqueten
En varias pruebas, un gráfico accesible funcionaba correctamente con NVDA, pero no era anunciado por JAWS. Las posibles causas incluyen:
- Diferencias en cómo cada lector maneja contenido dentro de <canvas> o SVG.
- Configuraciones internas del lector.
- La forma en que JAWS procesa descripciones longdesc, aria-describedby o contenido alternativo.
Lección aprendida:
La accesibilidad de gráficos no depende solo del código, sino del lector. NVDA suele ser más permisivo; JAWS es más estricto. Por eso, siempre conviene probar ambos y ofrecer descripciones textuales adecuadas.
El VoiceOver puede anunciar signos o símbolos como elementos separados
Al probar contenido con dos puntos “:”, VoiceOver los anunciaba de manera individual, mientras que NVDA y JAWS no. Esto pasa porque:
- VoiceOver tiene un tratamiento más granular de la puntuación.
- La configuración de verbosidad influye mucho más que en otros lectores.
Lección aprendida:
VoiceOver tiende a desglosar la información más que NVDA/JAWS. Es normal. No siempre significa un problema de accesibilidad.
NVDA, JAWS y VoiceOver no siguen exactamente las mismas reglas
Cada lector:
- Tiene un motor de accesibilidad distinto.
- Interpreta de forma diferente el mismo HTML/ARIA.
- Depende del navegador usado (NVDA y JAWS funcionan mejor con Firefox o Chrome; VoiceOver con Safari).
- Se comporta distinto según su modo de lectura.
Lección aprendida general:
Accesibilidad real no es que tu código pase un validador o funcione con un solo lector.
Accesibilidad real es probar con varios lectores, varios modos de interacción y varios navegadores.
Resumiendo:
Las diferencias entre NVDA, JAWS y VoiceOver no son fallos del código, sino parte natural del ecosistema accesible actual. Cada lector interpreta el contenido a su manera, lo que nos recuerda que:
La accesibilidad no es binaria, es contextual.
El objetivo siempre debe ser garantizar una experiencia usable, no idéntica.
Probar con varios lectores es tan importante como aplicar WCAG o WAI-ARIA.
Estas lecciones aprendidas refuerzan que la accesibilidad es una práctica continua, en la que la observación y las pruebas reales son tan importantes como el conocimiento técnico.
¿Te animas a compartirme tus experiencias y anécdotas con el uso de lectores de pantalla? ¡Te leo!