Lectores de pantalla explicados: cómo las personas ciegas navegan por la web

Se estima que hay 36 millones de personas ciegas en todo el mundo, y aproximadamente 217 millones más viven con discapacidad visual moderada a grave. Sin embargo, en 2025, más del 96% de los sitios web siguen teniendo al menos una falla de accesibilidad detectable. Para una persona ciega que depende de un lector de pantalla, una sola etiqueta ausente, una jerarquía de encabezados rota o un CAPTCHA inaccesible puede marcar la diferencia entre completar una tarea de forma independiente y abandonar por completo tu sitio. Entender cómo funcionan realmente los lectores de pantalla —no solo en teoría, sino en la práctica— es la base para construir una web accesible.

¿Qué es un lector de pantalla y quién lo usa?

Un lector de pantalla es un software de tecnología de apoyo que convierte el contenido en pantalla en voz sintetizada o en salida braille refrescable. En lugar de simplemente leer el texto en voz alta, los lectores de pantalla interpretan la estructura, los roles, los estados y las relaciones de los elementos de la interfaz, proporcionando a las personas usuarias una comprensión completa de una página web sin depender de la presentación visual. Piénsalo menos como un narrador y más como un intérprete inteligente que traduce toda tu interfaz visual en un flujo de información auditivo o táctil.

Los lectores de pantalla son utilizados principalmente por personas ciegas o con baja visión, pero también dan soporte a personas con ciertas discapacidades cognitivas o de lectura. Según la 10.ª encuesta de usuarios de lectores de pantalla de WebAIM —realizada a finales de 2023 y publicada en febrero de 2024— casi el 77% de las personas usuarias de lectores de pantalla son personas con ceguera, seguidas por personas con baja visión u otras discapacidades visuales con casi un 20%. La pérdida de audición, las discapacidades cognitivas y las discapacidades motoras representan el resto. No se trata de una audiencia de nicho: el 4,9% de las personas adultas en EE. UU. tiene una discapacidad visual con ceguera o dificultad grave para ver, y la cifra global de personas usuarias con discapacidad visual se cuenta por cientos de millones.

También vale la pena señalar que las personas usuarias de lectores de pantalla no son un grupo monolítico. La investigación muestra de forma consistente una amplia variación en habilidades, preferencias, estrategias de navegación y enfoques de resolución de problemas. Una persona que es ciega desde el nacimiento y ha usado JAWS durante veinte años navega de manera muy diferente a alguien que perdió la vista recientemente y aún está aprendiendo tecnología de apoyo. Incluso los sitios web técnicamente accesibles pueden presentar desafíos significativos cuando los modelos mentales que requieren no coinciden con las expectativas de la persona usuaria. Diseñadores y desarrolladores deben resistir la tentación de imaginar a una única persona usuaria arquetípica de lector de pantalla.

Cómo funcionan realmente los lectores de pantalla: el árbol de accesibilidad

Para entender de verdad los lectores de pantalla, necesitas entender qué leen —y no es tu diseño visual. Los lectores de pantalla funcionan accediendo al árbol de accesibilidad, una representación estructurada de la página que el navegador construye a partir del DOM HTML. El navegador expone este árbol a través de APIs de accesibilidad específicas de la plataforma: UI Automation en Windows, NSAccessibility en macOS y AccessibilityService en Android. El lector de pantalla consulta esta API, recibe información semántica sobre cada elemento y la convierte en salida de voz o braille.

Esto tiene una implicación crucial: lo que ves en pantalla y lo que percibe un lector de pantalla puede ser radicalmente diferente. Si tu diseño visual usa un <div> con estilo de botón, un lector de pantalla no lo anunciará como botón, porque no tiene un rol de botón en el árbol de accesibilidad. El lector de pantalla anuncia lo que dice el código, no lo que muestran los píxeles. Los elementos HTML semánticos como <button>, <nav>, <h1> y <form> llevan roles integrados que se exponen automáticamente al árbol de accesibilidad. Cuando las personas desarrolladoras omiten estos en favor de elementos genéricos parcheados con roles ARIA, crean una complejidad innecesaria y con frecuencia introducen nuevos errores.

Los lectores de pantalla también proporcionan contexto que no es visible en pantalla. Cuando una persona usuaria se encuentra con una lista, el lector de pantalla anuncia cuántos elementos contiene. Cuando se llega a una tabla, anuncia el número de filas y columnas. Cuando el foco se mueve a un campo de formulario, lee la etiqueta del campo, su tipo y su estado actual. Estos metadatos contextuales dependen por completo de un HTML bien estructurado y semántico. Si los eliminas, eliminas la capacidad de la persona usuaria de entender con qué está interactuando.

Los principales lectores de pantalla: JAWS, NVDA, VoiceOver y TalkBack

El mercado de lectores de pantalla está dominado por unas pocas herramientas, cada una con características distintas. Entender qué herramientas es probable que usen tus personas usuarias informa directamente cómo deberías probar tu sitio.

JAWS (Job Access With Speech), desarrollado por Freedom Scientific y lanzado por primera vez en 1995, ha sido considerado durante mucho tiempo el estándar de oro del sector, especialmente para uso empresarial. En la encuesta de WebAIM de 2024, JAWS era el lector de pantalla principal para aproximadamente el 41% de las personas encuestadas. Es un producto comercial con costos de licencia que van desde $90 hasta más de $1.400 al año. JAWS ofrece una amplia personalización, compatibilidad robusta con flujos de trabajo complejos en Microsoft Office y aplicaciones profesionales, y un "Browse Mode" que transforma la página en un entorno lineal navegable que permite a las personas usuarias saltar por encabezados, regiones y campos de formulario usando combinaciones de teclas intuitivas.

NVDA (NonVisual Desktop Access), desarrollado por NV Access e introducido en 2006, es un lector de pantalla gratuito y de código abierto para Windows. Fue el lector de pantalla principal para aproximadamente el 38% de las personas encuestadas por WebAIM en 2024, casi idéntico a JAWS. NVDA ha ganado una popularidad significativa debido a su modelo sin costo, sus actualizaciones frecuentes y su rendimiento robusto. En 2025, NVDA introdujo una gestión mejorada del foco en aplicaciones de una sola página, ayudando a las personas usuarias a entender cuándo ha cambiado el contenido y adónde se ha movido el foco. Su combinación de navegador recomendada es Firefox, aunque el soporte para Chrome también es sólido.

VoiceOver es el lector de pantalla integrado de Apple, disponible en macOS, iOS y iPadOS, sin necesidad de instalación. En escritorio, utiliza atajos de teclado con el modificador VO (Control + Opción), mientras que en iOS se basa en gestos táctiles como deslizar, doble toque y el rotor. En dispositivos móviles, VoiceOver es el lector de pantalla más utilizado, con un 70,6% de las personas usuarias de lectores de pantalla móviles dependiendo de él. Funciona mejor combinado con Safari, que es el único navegador que expone completamente las APIs de accesibilidad de macOS/iOS a VoiceOver.

TalkBack es el lector de pantalla integrado de Android, que ofrece retroalimentación hablada y vibraciones para ayudar a las personas usuarias a navegar por sus dispositivos. Es la herramienta estándar para pruebas móviles en Android y se combina mejor con Chrome. Windows también incluye Narrator, un lector de pantalla integrado que ha mejorado de forma constante pero aún carece de algunas funciones de JAWS y NVDA. Cada una de estas herramientas se comporta de forma algo diferente —un patrón que funciona correctamente en NVDA puede fallar en JAWS—, por lo que probar con varios lectores de pantalla es esencial para cualquier programa serio de accesibilidad.

Cómo navegan realmente las personas ciegas: el modelo mental que lo cambia todo

Este es el hallazgo que más profundamente debería cambiar la forma en que las personas desarrolladoras piensan sobre su trabajo: las personas usuarias de lectores de pantalla no leen las páginas de forma lineal de arriba abajo. Utilizan un conjunto sofisticado de estrategias de navegación para escanear y saltar por el contenido de forma eficiente, de manera muy similar a como una persona vidente hojea visualmente. Si no se apoyan estas estrategias, incluso una página técnicamente accesible se convierte en una experiencia agotadora e inutilizable.

La estrategia de navegación más extendida es la navegación por encabezados. El uso de encabezados para encontrar información ha aumentado con el tiempo y sigue siendo el método predominante: el 88,8% de las personas encuestadas considera que los niveles de encabezado son muy o algo útiles. Las personas usuarias avanzadas tienen muchas más probabilidades de navegar por encabezados que las principiantes. En la práctica, esto significa que una persona usuaria pulsa la tecla H en JAWS o NVDA para saltar al siguiente encabezado de la página, escaneando rápidamente la estructura. Pulsar 1 a 6 salta directamente a un encabezado de ese nivel. Si tu página no tiene encabezados, o usa encabezados elegidos por su tamaño visual en lugar de por la estructura del documento, las personas ciegas no tienen puntos de referencia entre los que saltar: se ven obligadas a escuchar la página completa desde el principio.

La segunda gran estrategia es la navegación por regiones (landmarks). Los elementos de región HTML5 —<main>, <nav>, <header>, <footer>, <aside> y <section> con una etiqueta— crean zonas con nombre a las que las personas usuarias de lectores de pantalla pueden saltar usando su rotor o teclas rápidas de regiones. En 2025, la adopción de regiones ARIA ha aumentado ligeramente, impulsada por el creciente uso del elemento nativo <main>, ahora presente en el 47% de las páginas. Aunque el 31,7% de las personas encuestadas indica que siempre o a menudo usa regiones cuando están presentes, solo el 3,7% las usa como su método principal de navegación, lo que sugiere que las regiones son una herramienta secundaria, pero importante para la orientación.

Las personas usuarias también navegan por enlaces, campos de formulario y botones usando atajos de una sola tecla, y con frecuencia abren listas de elementos —un cuadro de diálogo que muestra todos los encabezados, todos los enlaces o todos los campos de formulario de la página a la vez— para escanear y saltar directamente a lo que necesitan. Este comportamiento tiene enormes implicaciones para el texto de los enlaces. Una lista de enlaces que dice "Leer más, Leer más, Leer más" no proporciona ningún valor de navegación. Cada enlace y botón debe tener un nombre accesible descriptivo y único que tenga sentido fuera de contexto.

En dispositivos móviles, el paradigma cambia a los gestos táctiles. Las personas usuarias de VoiceOver y TalkBack deslizan hacia la derecha para pasar al siguiente elemento, hacen doble toque para activarlo y usan gestos de rotor para cambiar entre modos de navegación. La preferencia por el uso de aplicaciones móviles ha aumentado al 58% en 2024, frente al 51,8% en 2021. Esto significa que tu diseño responsive y tu accesibilidad móvil no son complementos opcionales: son casos de uso principales para un gran segmento de personas usuarias de lectores de pantalla.

Las barreras más problemáticas en la web hoy

La encuesta de WebAIM pidió a las personas encuestadas que identificaran los elementos más problemáticos que encuentran. Los resultados son notablemente consistentes a lo largo de más de una década de encuestas, y constituyen una lista directa de lo que tu sitio debe hacer bien.

• CAPTCHA es, con diferencia, la principal queja. Las personas usuarias de lectores de pantalla coinciden en que CAPTCHA ha sido el elemento más problemático durante más de catorce años seguidos. El uso de un CAPTCHA tradicional es obviamente problemático para las personas ciegas, ya que los lectores de pantalla de los que dependen no pueden procesar la imagen, impidiéndoles descubrir la información que requiere el formulario. Incluso los CAPTCHA de audio fallan a muchas personas: la distorsión intencional los vuelve ininteligibles. La recomendación práctica: utiliza verificación invisible basada en el comportamiento, como reCAPTCHA v3 o técnicas de honeypot siempre que sea posible.
• Elementos interactivos con comportamiento inesperado —menús, pestañas, ventanas de diálogo y widgets personalizados que no siguen patrones establecidos de interacción con teclado— están muy cerca de CAPTCHA. Estos elementos suelen construirse con atributos ARIA excesivos y presentan comportamientos de interacción irregulares y problemas de compatibilidad entre navegadores y lectores de pantalla.
• Enlaces y botones ambiguos frustran constantemente a las personas usuarias. Frases como "haz clic aquí", "más información" o "leer más" no ofrecen ninguna pista sobre el destino o la acción cuando se escuchan aisladas en una lista de enlaces.
• Cambios inesperados en la pantalla —actualizaciones de contenido dinámico que se producen sin aviso— desorientan a las personas ciegas, que no tienen una señal visual de que algo ha cambiado. Esto es especialmente agudo en aplicaciones de una sola página construidas con React, Vue o Angular, donde el contenido puede cambiar sin recargar la página.
• Jerarquías de encabezados rotas socavan la estrategia de navegación principal de la mayoría de las personas usuarias avanzadas. Alrededor del 39% de los sitios web tienen jerarquías de encabezados rotas, lo que dificulta que las personas usuarias de lectores de pantalla naveguen correctamente por el contenido.
• Texto alternativo ausente o inadecuado en las imágenes. Cuando falta el texto alternativo, un lector de pantalla puede indicar únicamente la presencia de una imagen sin describir su contenido o, peor aún, leer un nombre de archivo sin sentido como "IMG_4823.jpg".

La mayoría —el 67%— de las personas usuarias de lectores de pantalla nunca o rara vez contacta con las personas propietarias de sitios web sobre las barreras. Simplemente se van. No recibirás una queja. Simplemente perderás a una persona usuaria.

Escribir código que los lectores de pantalla puedan interpretar realmente

Entender los patrones de navegación de las personas usuarias hace que los requisitos técnicos sean mucho más concretos. Cada decisión que tomas en el marcado y en JavaScript tiene una consecuencia directa y audible para las personas ciegas. Estos son los principios que más importan.

El HTML semántico es tu primera y más poderosa herramienta. La primera regla de ARIA establece: "Si puedes usar un elemento o atributo HTML nativo con la semántica y el comportamiento que necesitas ya incorporados, en lugar de reutilizar un elemento y añadir un rol, estado o propiedad ARIA para hacerlo accesible, entonces hazlo." Elementos como <button>, <nav>, <header> y <form> vienen con accesibilidad integrada. Usar controles nativos garantiza compatibilidad con navegadores y tecnología de apoyo desde el primer momento, sin código adicional.

ARIA es un complemento, no un sustituto. ARIA (Accessible Rich Internet Applications) es un conjunto de atributos HTML diseñado para cubrir brechas de accesibilidad donde HTML por sí solo no puede expresar la semántica necesaria —por ejemplo, hacer accesible un control deslizante personalizado, anunciar cambios de contenido dinámico o indicar que un menú desplegable está actualmente expandido. El peligro está en el mal uso. Las páginas de inicio con ARIA presentan más del doble de errores de accesibilidad de media que las páginas sin ARIA. Más ARIA no significa más accesible: a menudo significa más errores. Las páginas que usaron ARIA de forma incorrecta mostraron un 70% más de errores detectables que las que no lo hicieron. Úsalo de forma quirúrgica, donde ningún elemento nativo pueda hacer el trabajo.

El siguiente ejemplo de código ilustra la diferencia entre un botón personalizado inaccesible y uno correctamente accesible:

<!-- Inaccesible: un div con manejador de clic, sin rol, sin soporte de teclado -->
<div class='btn' onclick='submitForm()'>Submit</div>

<!-- Accesible: botón nativo con rol integrado, soporte de teclado y foco -->
<button type='submit'>Submit</button>

<!-- Si debes usar un elemento que no es botón, añade rol, tabindex y evento de teclado -->
<div role='button' tabindex='0'
     aria-label='Submit the registration form'
     onkeydown='handleKey(event)'
     onclick='submitForm()'>
  Submit
</div>

Las regiones ARIA en vivo (ARIA live regions) son el mecanismo correcto para anunciar cambios de contenido dinámico. Cuando tu página actualiza contenido sin recargarla por completo —un mensaje de validación de formulario, un total del carrito, una notificación— ese cambio es silencioso para una persona usuaria de lector de pantalla a menos que uses una región en vivo. El atributo aria-live='polite' indica al lector de pantalla que anuncie el cambio después de que la actividad actual de la persona usuaria termine, mientras que aria-live='assertive' interrumpe de inmediato; usa este último con moderación, solo para alertas urgentes. En 2025, alrededor del 33% de los sitios usan el atributo aria-live, un 4% más que en 2024, pero la adopción sigue siendo demasiado baja dado el número de interfaces dinámicas que se despliegan.

La gestión del foco en componentes interactivos —ventanas modales, menús desplegables, acordeones— debe manejarse de forma explícita. Cuando se abre una ventana modal, el foco debe moverse dentro de ella. Cuando se cierra, el foco debe volver al elemento que la activó. Una persona usuaria de lector de pantalla que abre una modal y encuentra que el foco sigue en el botón que hay detrás queda, en la práctica, bloqueada fuera del contenido del cuadro de diálogo.

Probar tu sitio con un lector de pantalla

Los escáneres automáticos de accesibilidad son valiosos pero limitados. Las herramientas automatizadas detectan entre el 30% y el 40% de las violaciones de WCAG, pero las pruebas con tecnología de apoyo real revelan cómo las personas usuarias experimentan realmente tu sitio: contexto ausente, navegación confusa e interacciones que simplemente no funcionan. Ningún escáner te dirá que el encabezado de tu modal no tiene sentido sin el contexto visual que lo rodea, o que tu desplegable personalizado anuncia su estado de forma incorrecta en una combinación concreta de navegador y lector de pantalla pero no en otra.

El punto de partida práctico para la mayoría de los equipos es NVDA con Firefox: gratuito, ampliamente utilizado y eficaz para detectar la gran mayoría de problemas comunes. Añade VoiceOver con Safari para cubrir a las personas usuarias de macOS y iOS. Para contextos empresariales o clientes con altos requisitos de cumplimiento, incluye JAWS con Chrome o Edge. Cada lector de pantalla funciona mejor con una combinación específica de navegador; usar la combinación equivocada puede producir resultados de prueba engañosos.

Al hacer pruebas, adopta los patrones de navegación que emplean las personas usuarias reales. No uses ratón. Navega por encabezados usando la tecla H. Abre la lista de enlaces y confirma que cada enlace tiene sentido fuera de contexto. Recorre los campos de formulario con la tecla Tab y comprueba que se anuncie correctamente cada etiqueta. Abre ventanas modales y verifica que el foco se mueva dentro de ellas. Rellena formularios y envíalos, escuchando cada mensaje de validación. Apaga tu monitor e intenta completar una tarea representativa de la persona usuaria de principio a fin: esa experiencia, por incómoda que sea para una persona que ve, es la realidad cotidiana de tus personas usuarias ciegas.

También es importante probar con tecnología de apoyo real en lugar de emuladores o simuladores de navegador. Los paneles de accesibilidad de las herramientas de desarrollo del navegador te muestran el árbol de accesibilidad, lo cual es útil para depurar, pero no replican la experiencia auditiva ni revelan peculiaridades de interacción que solo emergen con software de lector de pantalla real.

El caso empresarial y legal que no puedes ignorar

Si el argumento moral a favor de la accesibilidad necesita reforzarse con la realidad comercial, las cifras son contundentes. Hay aproximadamente 7 millones de personas con discapacidad visual solo en Estados Unidos, lo que representa una base de consumidores significativa. A nivel global, el 26% de las personas adultas en EE. UU. tiene discapacidades, lo que representa una oportunidad de mercado estimada en $13 billones. Cuando un diseño inaccesible excluye a las personas ciegas de tu sitio, no solo estás fallando a una obligación moral: estás rechazando clientela y exponiendo a tu organización a riesgos legales.

WCAG 2.2 es ahora el estándar legal de referencia en miles de demandas bajo la ADA, y la Ley Europea de Accesibilidad, que entró plenamente en vigor para empresas del sector privado en junio de 2025, amplía los requisitos de cumplimiento en toda la UE. La mayoría de las personas usuarias de lectores de pantalla nunca contacta con las personas propietarias de sitios web sobre las barreras: simplemente se van y llevan su negocio a otra parte. El 67% de las personas que nunca reportan problemas no están satisfechas; están derrotadas. Integrar la compatibilidad con lectores de pantalla en tu proceso de desarrollo desde el principio evita costosas remediaciones, reduce la exposición legal y abre tus productos a una audiencia que está buscando activamente experiencias digitales que realmente pueda usar.

Conclusiones clave

• Los lectores de pantalla navegan por la estructura, no por lo visual. Consultan el árbol de accesibilidad del navegador a través de las APIs de accesibilidad de la plataforma. El HTML semántico —encabezados adecuados, regiones, controles nativos— es la inversión de mayor impacto que puedes hacer en compatibilidad con lectores de pantalla.
• Las personas ciegas navegan por encabezados, regiones y listas de elementos, no de forma lineal. Más del 88% de las personas usuarias de lectores de pantalla considera que los niveles de encabezado son muy o algo útiles para la navegación. Una jerarquía de encabezados rota o ausente es uno de los fallos de accesibilidad más comunes y dañinos en la web.
• ARIA amplifica tanto el buen como el mal marcado. Las páginas con ARIA presentan de media más del doble de errores de accesibilidad que las páginas sin ARIA. Usa ARIA solo donde el HTML nativo no pueda expresar la semántica necesaria y prueba siempre con tecnología de apoyo real después de implementarlo.
• CAPTCHA, enlaces ambiguos y cambios de contenido dinámico no anunciados son las principales barreras en el mundo real. Sustituir el CAPTCHA visual por verificación basada en el comportamiento, escribir textos descriptivos para enlaces y botones e implementar regiones ARIA en vivo para actualizaciones dinámicas tendrá un impacto inmediato y medible en la usabilidad para las personas ciegas.
• Prueba con lectores de pantalla reales en varias combinaciones de navegador. Los escáneres automáticos detectan solo entre el 30% y el 40% de las violaciones de WCAG. NVDA con Firefox y VoiceOver con Safari cubren a la mayoría de tu base de personas usuarias sin costo, y la experiencia de navegar por tu sitio sin ratón revela problemas que ninguna herramienta automatizada puede sacar a la luz.