lector de pantalla

Qué es y cómo funciona

Un lector de pantalla es un programa que convierte en voz sintética o en braille lo que el sistema muestra, y que permite manejar el equipo sin ver la pantalla. No es una lupa ni un asistente: es la interfaz completa de la persona con el dispositivo.

Los más extendidos son NVDA y JAWS en Windows, VoiceOver en macOS e iOS, TalkBack en Android y Orca en Linux. Cada uno tiene sus atajos y sus rarezas, y un mismo marcado puede anunciarse de forma ligeramente distinta en cada combinación de lector y navegador.

La clave técnica es que el lector no lee el HTML directamente ni describe los píxeles. Lee el árbol de accesibilidad: la representación que el navegador construye a partir del marcado, donde cada elemento tiene un nombre (cómo se llama), un rol (qué es) y un estado (qué le pasa ahora). Todo el trabajo de accesibilidad consiste en que esos tres datos sean correctos para cada cosa con la que se puede interactuar.

Cómo se navega de verdad

Este es el punto donde casi todo el mundo se equivoca al imaginarlo. Nadie escucha una página entera de arriba abajo. Sería insoportable y lentísimo.

Quien usa un lector de pantalla con soltura navega saltando:

• Pide la lista de encabezados y se mueve entre ellos para hacerse un mapa de la página y localizar la sección que busca.
• Pide la lista de enlaces para ver qué se puede hacer.
• Salta entre regiones —cabecera, navegación, contenido principal, pie— si el marcado las declara.
• En un formulario, tabula de campo en campo, y en cada uno espera oír la etiqueta, el tipo, si es obligatorio y qué error tiene si lo tiene.
• En una tabla de datos, se mueve por celdas y espera que se le anuncie la cabecera de fila y de columna correspondiente.

De ahí salen consecuencias muy concretas para quien escribe el código. Los encabezados son el índice de la página, no un recurso de estilo: si el h2 es un h4 porque quedaba mejor de tamaño, el mapa que recibe la persona es falso. Los enlaces se escuchan fuera de contexto, así que catorce «leer más» seguidos son catorce destinos indistinguibles. Y si el contenido principal no está en un <main>, no hay forma de saltar el menú y hay que recorrerlo entero en cada página.

Qué necesita de tu web

En una revisión, esto es lo que compruebo por orden de impacto.

Una jerarquía de encabezados real. Un solo h1, y niveles que bajan de uno en uno reflejando la estructura del contenido.

Textos alternativos que digan lo que hay que decir. Descriptivos si la imagen aporta información; vacíos —alt=""— si es puramente decorativa, para que el lector la ignore en vez de anunciar el nombre del archivo.

Etiquetas asociadas a los campos. Un <label> unido a su campo. El marcador de posición no es una etiqueta: desaparece al escribir y muchos lectores no lo anuncian de forma fiable.

Errores enunciados y conectados. «Error: la fecha debe tener el formato día/mes/año» junto al campo y asociado a él, no un genérico «revise el formulario» en la parte de arriba.

Cambios dinámicos anunciados. Si el carrito suma un producto o el buscador devuelve resultados sin recargar, hay que comunicarlo por una región activa. Si no, para quien no ve la pantalla no ha pasado nada.

Un enlace para saltar al contenido, y que el foco se vea siempre.

Lo que veo cuando audito

El fallo más caro que encuentro no es el que uno esperaría. No es la imagen sin alternativa —eso lo detecta cualquier herramienta y se arregla en una tarde—, sino el componente interactivo mudo: el modal que se abre sin llevarse el foco, el desplegable que no dice si está abierto, el paso 3 de un checkout que carga por JavaScript sin avisar de que la página ha cambiado. La persona se queda sin saber dónde está, y una web en la que no sabes dónde estás es una web en la que no compras.

El segundo patrón es el contenido visual sin equivalente en texto: precios dentro de una imagen, un horario en una infografía, un organigrama en un PDF escaneado. Si el dato solo existe en píxeles, no existe.

Y el tercero, muy español: los PDF de condiciones y tarifas exportados sin estructura. Se anuncian como un bloque continuo sin encabezados por el que no hay manera de navegar.

Sobre este sitio quiero ser explícito, porque es justo el punto donde muchos mienten: se ha construido con HTML semántico y se ha verificado con teclado y con herramientas, y todo lo comprobado está listado en la declaración de accesibilidad. No se declara una prueba con lector de pantalla real, porque no se ha hecho. Prefiero que la declaración se quede corta y sea cierta.

Por qué le importa a un negocio

Porque decide si se cierra la venta. Los puntos donde el lector de pantalla sufre son el buscador, los filtros, el carrito y el pago. Ahí no se pierde comodidad: se pierde el pedido completo, sin que nadie te avise.

Porque la ley ya lo alcanza. El EAA se aplica desde el 28 de junio de 2025 al comercio electrónico y a otros servicios privados, y el RD 1112/2018 obliga desde 2018 al sector público y a sus proveedores. Ambos se apoyan en la EN 301 549, que remite a las WCAG en nivel AA, y buena parte de esos criterios existen literalmente para que un lector de pantalla pueda hacer su trabajo.

Porque un buscador está en la misma situación. Tampoco ve el diseño: lee estructura, encabezados, alternativas de imagen y textos de enlace. Lo que arreglas para que la página se entienda escuchándola lo arreglas también para que se entienda rastreándola, algo que trato en SEO y en accesibilidad.

Errores frecuentes

Escribir el texto alternativo pensando en el buscador. Meter palabras clave en el alt produce frases que se escuchan absurdas y que no describen la imagen. El texto alternativo se escribe para una persona que no ve la foto; punto.

Usar el marcador de posición como etiqueta. Se pierde al empezar a escribir, tiene poco contraste y no se anuncia de forma consistente. Es el fallo de formulario más repetido que me encuentro.

Poner aria-hidden="true" sobre contenido visible. No oculta a la vista: oculta al lector. Crea partes de la página que existen para unos usuarios y no para otros, y si dentro hay algo enfocable, se llega a ello con el tabulador sin que se anuncie nada.

Anunciar todo con regiones activas. Poner aria-live en media página convierte la navegación en un bombardeo de interrupciones. Se anuncia lo que la persona necesita saber en ese momento, y nada más.

Declarar que se ha probado con lector de pantalla sin haberlo hecho. Es el error que más caro sale, porque un problema técnico se puede corregir y una declaración falsa no. Si no se ha probado, se escribe que no se ha probado.