En 2026, el panorama comprende cinco lectores de pantalla principales —NVDA, JAWS, VoiceOver, TalkBack y Narrator— más una capa en maduración de drivers de automatización (Playwright AT-driver, inspectores basados en AccTree, servicios de grabación en la nube) que permiten trasladar parte de este trabajo a integración continua. Ninguno de ellos sustituye a ejecutar el software real sobre el producto real. Sí permiten detectar las regresiones evidentes antes de que lleguen a un tester humano.

Esta guía cubre los cinco lectores de pantalla que merece la pena probar, una matriz de pruebas mínima viable, qué buscar, la capa de automatización en la que vale la pena invertir y una lista de verificación inicial para el proceso de publicación.

Cinco productos dominan el mercado de lectores de pantalla en 2026: dos en escritorio Windows, uno multiplataforma Apple, uno para Android y el de Microsoft incluido por defecto. La cuota aproximada, la banda de coste y la fidelidad de prueba que ofrece cada uno se resumen en las tarjetas siguientes; el texto bajo cada tarjeta añade los puntos fuertes y las advertencias.

NVDA — Windows, gratuito, código abierto. Mantenido por NV Access. Aproximadamente el 35-40 % de los encuestados de WebAIM lo usan como lector de pantalla principal, lo que lo convierte en la herramienta individual de mayor impacto para instalar. Gratuito, código abierto, ligero, se combina limpiamente con Firefox y Chrome. Punto fuerte: compatibilidad estricta con ARIA y un ciclo de desarrollo rápido. Advertencia: los valores predeterminados de configuración difieren entre versiones, por lo que conviene documentar la versión exacta y los ajustes con los que trabaja el equipo.

JAWS — Windows, comercial. El producto estrella de Freedom Scientific. La licencia doméstica es de aproximadamente 95 dólares al año; las licencias corporativas son considerablemente más caras. Históricamente el estándar empresarial y del gobierno federal de EE. UU., sigue siendo la referencia en administración pública, finanzas y sanidad. Punto fuerte: conjunto de funciones completo y una larga compatibilidad con aplicaciones empresariales antiguas. Advertencia: el coste de licencia y la tendencia a enmascarar errores de marcado que NVDA sí expone.

VoiceOver — macOS e iOS, integrado. Se incluye en todos los dispositivos Apple. En móvil, VoiceOver representa aproximadamente el 70 % de los usuarios globales de lector de pantalla, lo que lo convierte en el objetivo móvil más importante con diferencia. Punto fuerte: instalación cero, integración profunda con el sistema operativo, el modelo de gestos es la convención móvil de facto. Advertencia: VoiceOver para macOS y VoiceOver para iOS se comportan de forma diferente; probar uno no cubre al otro.

TalkBack — Android, integrado. El lector de pantalla integrado de Android de Google. El lector de pantalla móvil con mayor base instalada en términos absolutos, aunque una parte significativa de los usuarios de Android lo tiene desactivado. Punto fuerte: viene en todas partes; se combina con Chrome. Advertencia: el comportamiento varía entre las diferentes capas de Android (Samsung One UI, Pixel, MIUI), y la paridad con VoiceOver es imperfecta.

Narrator — Windows, integrado. El lector de pantalla incluido de Microsoft. Un lejano quinto entre los usuarios reales (WebAIM lo sitúa en menos del 1 % como herramienta principal), pero importa en entornos corporativos con restricciones de TI donde los usuarios no pueden instalar NVDA. Punto fuerte: instalación cero en Windows. Advertencia: menor fidelidad que NVDA o JAWS; la mayoría de los usuarios que dependen de un lector de pantalla lo han abandonado.

La respuesta honesta a «¿con qué lectores de pantalla debo probar?» es: con tantos como los que realmente usa el público objetivo, no más. La mayoría de los equipos se quedan cortos de presupuesto y acaban haciendo dos lectores de pantalla de forma deficiente en lugar de uno bien.

Una línea de base de dos filas (NVDA + Firefox en Windows, VoiceOver + Safari en iOS) detecta la mayoría de los problemas del mundo real para un producto de consumo típico. Conviene añadir JAWS en cuanto entre en escena un sector regulado. Añadir TalkBack cuando la cuota de Android no sea trivial. Tratar Narrator como una comprobación anual de cordura, no como una herramienta de control. Conviene registrar la matriz elegida en la lista de verificación de publicación para que no pueda omitirse silenciosamente.

Más allá de «¿lo lee?», la prueba real es estructural. Al sentarse con NVDA o VoiceOver, se comprueba la página por los mismos ejes que un usuario ciego:

• Estructura de la página — ¿el lector de pantalla anuncia los encabezados en una jerarquía coherente? ¿Se puede navegar por atajos de encabezado (tecla H en NVDA, rotor en VoiceOver) y llegar a los lugares correctos? ¿Funciona el enlace de salto: Tab, escucharlo, Enter, el foco se mueve al landmark principal?
• Etiquetas de formulario — cada campo de entrada anuncia un nombre. Los campos obligatorios anuncian «obligatorio». Los tipos de campo son correctos (email, tel, number). Los mensajes de error están asociados mediante aria-describedby y se anuncian al fallar la validación, en lugar de aparecer silenciosamente por encima del formulario.
• Contenido dinámico — al plegar un panel, enviar un formulario o aplicar un filtro, ¿se activa una actualización de regiones aria-live? ¿O el lector de pantalla no dice nada mientras la interfaz visible cambia? Las actualizaciones silenciosas son el error de contenido dinámico más frecuente.
• Gestión del foco — cuando se abre un modal, ¿el foco se mueve hacia él y queda atrapado allí? Cuando se cierra, ¿vuelve el foco al elemento que lo activó? La mayoría de las bibliotecas de componentes accesibles comerciales gestionan esto correctamente; los componentes internos frecuentemente no lo hacen.
• Orden de lectura — ¿el contenido se lee en el orden en que aparece visualmente? ¿O el CSS order, el posicionamiento absoluto o el reordenamiento flex dejan el DOM en una secuencia diferente a la disposición visual?
• Calidad del texto alternativo — ¿el texto alternativo es realmente útil, o es Image_47.png? ¿Las imágenes decorativas están en silencio (alt="")? ¿El texto alternativo describe lo que la imagen comunica en su contexto?
• Texto del enlace — «haga clic aquí» y «leer más» suenan pésimo fuera de contexto. Los usuarios de lector de pantalla a menudo navegan abriendo una lista de enlaces; si todos los enlaces dicen «Leer más», esa lista es inútil.

Estos aspectos se corresponden con criterios de conformidad de WCAG 2.2 —en particular 1.3.1, 2.4.3, 3.3.1 y 4.1.3—, pero la prueba es más rápida y más honesta con el lector de pantalla funcionando que solo con una lista de verificación.

Las pruebas automatizadas al estilo del lector de pantalla han mejorado significativamente en los últimos dos años. Todavía no sustituyen a un ser humano escuchando NVDA, pero detectan una parte real de las regresiones antes de que se publiquen. Conviene conocer tres enfoques.

Playwright AT-driver y Selenium ChromeDriver “force-text”. Tanto Playwright como Selenium pueden ahora controlar un navegador y afirmar lo que se anunciaría a nivel del árbol de accesibilidad: nombre, rol, estado, valor. Esto es más sólido que getByRole/getByLabel: esos localizadores leen el árbol AT para encontrar un elemento, pero force-text recorre el árbol como lo haría un lector de pantalla. No equivale a ejecutar NVDA contra la página, pero detecta regresiones de nombre + rol + estado de forma barata y determinista. La mayoría de los grandes equipos de producto disponen ahora de al menos una suite de smoke de pruebas AT-driver en páginas críticas: registro, proceso de compra, configuración de cuenta.

Inspectores basados en AccTree — axe DevTools, axe Linter, eslint-plugin-jsx-a11y. Análisis estático de código y DOM. Detecta etiquetas faltantes, ARIA inválida, discrepancias entre etiqueta y contenido, fallos de contraste y problemas estructurales. Barato de ejecutar en cada commit. El escáner de accesibilidad gratuito de este sitio usa la misma familia de reglas. Nivel de suelo: indica cuándo algo está definitivamente roto, no cuándo algo está sutilmente mal.

Grabación en vivo con lector de pantalla — Assistiv Labs, BrowserStack Accessibility. Servicios en la nube que ejecutan NVDA, JAWS o VoiceOver reales contra la URL del proyecto y permiten observar y escuchar sin instalar nada localmente. Lo más cercano a «probar con lo real» sin disponer del hardware. Útil para comprobaciones puntuales, para equipos que usan el sistema operativo incorrecto y para compartir grabaciones con partes interesadas que de otro modo nunca escucharían cómo suena una página con errores.

El patrón al que converge la mayoría de los equipos en 2026: análisis basado en AccTree en cada PR, pruebas AT-driver en un conjunto representativo de páginas en CI, pruebas manuales con lector de pantalla en una cadencia de sprint, y una auditoría manual por testers con discapacidad trimestral o anualmente. La capa de automatización es el suelo; la capa manual es donde se mide la experiencia real del usuario.

Puede incorporarse esta lista a la lista de verificación de publicación o a la plantilla de control de calidad:

NVDA en Windows. Es gratuito, de código abierto, mantenido activamente por NV Access y utilizado por aproximadamente el 35-40 % de los encuestados de WebAIM como lector de pantalla principal. Si solo se va a instalar una pieza de tecnología de apoyo para probar, instálese NVDA con Firefox o Chrome en una máquina o VM con Windows.

Dos bien probados superan a cinco probados superficialmente. El mínimo realista es NVDA en Windows para escritorio y VoiceOver en iOS para móvil: entre ambos cubren la mayor parte de los usuarios reales. Conviene añadir JAWS si el público objetivo es el sector gubernamental, financiero o sanitario, y TalkBack en Android si el tráfico móvil se inclina hacia Android.

No. Las herramientas automatizadas detectan aproximadamente el 30-40 % de los problemas de WCAG: atributos alt ausentes, ARIA inválida, etiquetas faltantes. No pueden juzgar si el texto alternativo es útil, si el contenido dinámico realmente anuncia o si la gestión del foco se percibe correcta. Debe usarse la automatización como suelo, no como techo, y combinarse con pruebas humanas periódicas en el lector de pantalla real.

Sí para pruebas locales: VoiceOver solo funciona en macOS e iOS. Si el equipo usa exclusivamente Windows, servicios en la nube como Assistiv Labs y BrowserStack Accessibility ofrecen sesiones remotas de VoiceOver sobre la URL del proyecto. Para comprobaciones ocasionales eso es suficiente; para trabajo serio en iOS, conviene disponer de un Mac o un iPhone.

Ambos son lectores de pantalla para Windows y ambos funcionan con todos los navegadores principales. NVDA es gratuito, de código abierto, más ligero y tiende a ser ligeramente más estricto respecto a la conformidad con ARIA. JAWS es comercial (alrededor de 95 dólares al año para una licencia doméstica), más completo en funciones, tiene una larga trayectoria en despliegues empresariales y del gobierno federal de EE. UU., y a veces es más tolerante con el marcado imperfecto. Si una página funciona en NVDA, generalmente funciona en JAWS; la inversa no siempre es cierta.

Las comprobaciones de nivel de automatización (axe, eslint-plugin-jsx-a11y, pruebas AT-driver) deben ejecutarse en cada solicitud de incorporación de cambios. Los pases manuales con lector de pantalla en recorridos de usuario clave pertenecen a la lista de verificación de publicación: normalmente cada sprint o cada versión. Una auditoría manual completa por testers con discapacidad tiene sentido trimestral o anualmente según cuánto cambie el producto.

Si todavía no se ha ejecutado un pase automatizado, conviene empezar con el escáner de accesibilidad gratuito: pondrá de manifiesto los problemas más evidentes que también detectaría un lector de pantalla, en segundos en lugar de horas. Una vez establecido ese suelo, conviene planificar una auditoría manual por testers con discapacidad sobre los recorridos de usuario que más importan al negocio. Y si la accesibilidad es un problema continuo más que un proyecto puntual, la guía de compra de monitorización compara las herramientas que vigilan la producción en busca de regresiones entre auditorías manuales.