Guía completa de accesibilidad para lectores de pantalla y entornos de lectura en voz alta: construye una UI que “transmita correctamente” mediante encabezados, etiquetas, orden de lectura, live regions y tecnologías de asistencia (WCAG 2.1 AA)

Resumen general (puntos clave primero)

• El soporte para lectores de pantalla no consiste simplemente en “hacer que el contenido pueda leerse en voz alta”, sino en transmitir correctamente la estructura, el significado, el estado y el orden.
• Los seis elementos esenciales son (1) encabezados y landmarks, (2) nombres de enlaces y botones, (3) etiquetas y errores de formularios, (4) alternativas para imágenes, (5) relaciones en tablas y (6) anunciar cambios de estado con live regions.
• Las personas que usan lectores de pantalla no “ven toda la pantalla” de una sola vez. En cambio, exploran de forma eficiente mediante listas de encabezados, listas de enlaces, listas de formularios y navegación por landmarks. Por eso, el acabado visual por sí solo nunca es suficiente.
• “Es visible, así que es comprensible” no funciona. El núcleo de la accesibilidad para lectores de pantalla es traducir la información a una estructura que pueda entenderse sin visión.
• Este artículo incluye errores comunes de implementación, ejemplos seguros de HTML/ARIA, puntos de vista para pruebas con lectores de pantalla y una smoke test de 5 minutos para la práctica real.

Lectores previstos (específicamente): ingenieros front-end, diseñadores UI/UX, editores, QA/testers, equipos de design systems, equipos de sitios web del sector público/gobierno, y desarrolladores de SaaS y sistemas empresariales
Objetivo de accesibilidad: cumplimiento de WCAG 2.1 AA (relacionado con 1.1.1, 1.3.1, 2.4.x, 3.3.x, 4.1.2 y más)

1. Introducción: el soporte para lectores de pantalla no es “conversión a audio”, sino “estructuración de la información”

Cuando la gente oye el término “lector de pantalla”, suele entenderlo como “algo que lee en voz alta lo que hay en la pantalla”. Por supuesto, eso es cierto, pero en la práctica necesitamos pensar un paso más allá.
Eso se debe a que un lector de pantalla no simplemente “lee tal cual lo que se muestra visualmente”. En cambio, interpreta la página en función de la estructura, los roles y los estados derivados de HTML y ARIA.
En otras palabras, aunque el diseño se vea bonito, si la estructura está rota, entonces en la experiencia de lectura en voz alta ocurrirá esto:

• No queda claro qué es un encabezado
• No queda claro si algo es un botón o un enlace
• No queda claro dónde ocurrió un error
• No queda claro qué cambió hace un momento

Esto es lo que sucede.
En este artículo, teniendo en cuenta cómo exploran realmente las páginas las personas usuarias de lectores de pantalla y dónde es más probable que tengan dificultades, organizaremos cómo construir una UI que tenga sentido cuando se lea en voz alta.

2. Entender cómo “leen” las personas usuarias de lectores de pantalla: no recorren todo de arriba abajo

Cuando miramos una página visualmente, captamos instantáneamente su estructura general mediante cabeceras, encabezados, espacios y énfasis visuales como el color. Pero las personas usuarias de lectores de pantalla hacen esto solo mediante audio. Por eso, muchas de ellas no escuchan toda la página de principio a fin, sino que usan listas y atajos para saltar directamente a lo que necesitan.

2.1 Métodos de navegación comunes

• Lista de encabezados: para entender la estructura de la página
• Navegación por landmarks: para moverse entre nav, main, search, footer y otras regiones principales
• Lista de enlaces: para encontrar el destino que buscan
• Lista de formularios: para revisar campos de entrada
• Navegación por tablas: para entender las relaciones entre filas y columnas

Por eso, en la accesibilidad para lectores de pantalla, importa no solo el “texto del cuerpo que se lee”, sino también si el significado se conserva cuando el contenido se presenta en forma de lista.

2.2 Por eso ocurren estos fallos

• Todos los enlaces dicen “aquí” o “detalles”
• Todos los encabezados dicen “resumen”, “detalles” u “otros”
• Los nombres de los botones son solo “icono” o “botón”
• Los campos del formulario no tienen etiquetas

Cuando esto ocurre, el significado se derrumba en las vistas de lista.

3. Encabezados y landmarks: ofrece un “mapa” para las personas usuarias de lectores de pantalla

Para quienes usan lectores de pantalla, los encabezados y los landmarks son el propio mapa. Cuando están bien estructurados, incluso una página larga se vuelve mucho menos confusa.

3.1 Lo básico sobre encabezados

• h1 normalmente debería usarse una sola vez para el tema principal de la página
• h2 para secciones, h3 para subsecciones
• Aunque algo solo parezca un encabezado visualmente, usa un elemento de encabezado real en lugar de solo estilo

Ejemplo

<h1>Fundamentos del soporte para lectores de pantalla</h1>

<h2>Encabezados y landmarks</h2>
<h3>Cómo escribir encabezados</h3>
<h3>Cómo usar landmarks</h3>

<h2>Lectura de formularios en voz alta</h2>
<h3>Etiquetas</h3>
<h3>Anuncio de errores</h3>

3.2 Lo básico sobre landmarks

<header>…</header>
<nav aria-label="Navegación global">…</nav>
<main id="content">…</main>
<footer>…</footer>

Si hay varios elementos nav, diferéncialos con aria-label.
Por ejemplo:

• Navegación global
• Tabla de contenidos dentro de la página
• Navegación del pie de página

3.3 Skip links

Estos ayudan no solo a personas usuarias de lectores de pantalla, sino también a quienes usan teclado.

<a href="#content" class="skip-link">Saltar al contenido principal</a>
<main id="content" tabindex="-1">…</main>

4. Nombre, rol y estado: comunica correctamente qué son los enlaces, botones y formularios

4.1 Nombres para enlaces y botones

Las personas usuarias de lectores de pantalla suelen depender de listas de enlaces y listas de botones.
Por eso, los nombres deben seguir teniendo sentido cuando se ven en una lista.

• Mal: “aquí”, “detalles”, “abrir”
• Bien: “Ver tabla de precios”, “Abrir configuración de notificaciones”, “Confirmar pedido”

4.2 Preferir elementos nativos

• Navegación: <a>
• Acciones: <button>
• Entradas: <input> / <select> / <textarea>

Implementaciones como div role="button" significan que debes manejar manualmente el comportamiento de teclado y la gestión del estado, lo que aumenta la probabilidad de problemas.

4.3 Exponer el estado

• Expandido/contraído: aria-expanded
• Seleccionado: aria-selected
• Deshabilitado: disabled o una explicación adecuada
• Estado de error: aria-invalid="true"

Ejemplo: botón desplegable

<button aria-expanded="false" aria-controls="faq1">
  Sobre el cambio de fecha de entrega
</button>
<div id="faq1" hidden>
  Puede cambiarse siempre que el envío no haya comenzado.
</div>

5. Formularios y lectores de pantalla: conecta correctamente etiquetas, ayudas y errores

Los formularios son una de las áreas donde la diferencia de calidad se vuelve más evidente para quienes usan lectores de pantalla.
La información que visualmente aparece “cerca” no llega a la persona en audio a menos que esté asociada explícitamente.

5.1 Las etiquetas deben ser visibles y conectadas con label for

<label for="email">Correo electrónico (obligatorio)</label>
<input id="email" type="email" autocomplete="email">

Un placeholder no sustituye a una etiqueta. Desaparece durante la escritura y a menudo tiene poco contraste.

5.2 Texto de apoyo con aria-describedby

<label for="postal">Código postal</label>
<input id="postal" aria-describedby="postal-hint">
<p id="postal-hint">Introduce 7 dígitos (ejemplo: 1000001)</p>

5.3 Los errores deben comunicar “dónde, por qué y cómo corregir”

<label for="email">Correo electrónico</label>
<input id="email" aria-invalid="true" aria-describedby="email-err">
<p id="email-err" role="alert">El formato del correo electrónico es incorrecto. Ejemplo: nombre@example.com</p>

5.4 Resumen de errores y movimiento del foco

Cuando un formulario tiene varios errores tras el envío, ayuda mostrar un resumen en la parte superior y mover el foco allí primero, para que las personas usuarias de lectores de pantalla puedan entender y corregir más fácilmente los problemas.

6. Imágenes, tablas y gráficos: proporciona la información visual como “significado”

6.1 Texto alternativo para imágenes

El texto alternativo no es solo “una descripción de la imagen”. Debe expresar el papel que cumple la imagen en ese contexto.

• Imagen decorativa: alt=""
• Imagen con significado: texto alternativo según su propósito
• Gráfico/diagrama complejo: texto alternativo breve más un resumen en el contenido principal

6.2 Tablas

Si una tabla no está estructurada correctamente, un lector de pantalla puede presentarla como una simple secuencia de números.

<table>
  <caption>Ventas trimestrales de 2025</caption>
  <thead>
    <tr>
      <th scope="col">Producto</th>
      <th scope="col">T1</th>
      <th scope="col">T2</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <th scope="row">A</th>
      <td>120</td>
      <td>140</td>
    </tr>
  </tbody>
</table>

6.3 Gráficos y diagramas

Los gráficos son excelentes resúmenes visuales, pero pueden ser muy difíciles de entender solo mediante audio.
Un enfoque seguro es proporcionar:

• un resumen alternativo conciso,
• un breve resumen en texto de tendencias y excepciones notables,
• y, si es necesario, los datos fuente en forma de tabla.

7. Live regions: comunica los cambios que ocurren después de que la página se ha cargado

Los lectores de pantalla no anuncian automáticamente todos los cambios que aparecen en la pantalla.
Eventos como confirmaciones de guardado, resultados de búsqueda actualizados y nuevos mensajes de error son todos cambios que ocurren más tarde, así que deben comunicarse con live regions.

7.1 Mensajes de éxito o informativos: role="status"

<div id="status" role="status" aria-atomic="true" class="sr-only"></div>

document.getElementById('status').textContent = 'Se ha guardado correctamente.';

7.2 Errores o advertencias urgentes: role="alert"

<div id="alert" role="alert" aria-atomic="true"></div>

7.3 No abusar de ellos

Si todo es un alert, el lector de pantalla se llena de interrupciones constantes y se vuelve agotador de usar.
Una buena regla es:

• Éxito: anunciar discretamente
• Fallo: anunciar de forma clara y fiable

8. Anti-patrones comunes: UI que se ve bien, pero no puede entenderse al leerla en voz alta

9. Smoke test de 5 minutos: comprobaciones mínimas pensando en lectores de pantalla

1. ¿La lista de encabezados refleja una estructura significativa de la página?
2. ¿Se puede navegar al contenido principal, a la navegación y al pie mediante landmarks?
3. ¿Las listas de enlaces tienen sentido, o están llenas de etiquetas vagas como “aquí”?
4. ¿Los nombres de los botones son específicos, y se transmiten los estados expandido/seleccionado?
5. En los formularios, ¿se anuncian correctamente las etiquetas, el carácter obligatorio, las ayudas y los errores?
6. ¿El texto alternativo coincide con el contexto y el propósito de las imágenes?
7. ¿Se anuncian las actualizaciones como guardados o fallos mediante status / alert?
8. En modales y menús, ¿el foco permanece controlado en lugar de perderse?

10. Valor para cada tipo de lector (específicamente)

• Personas usuarias de lectores de pantalla: cuando la estructura es correcta, resulta muchísimo más fácil encontrar, entender y operar el contenido.
• Personas usuarias de teclado: los encabezados, landmarks y la gestión del foco reducen la carga de navegación.
• Personas con diferencias cognitivas: los estados y errores expresados con claridad facilitan la comprensión y la corrección.
• Personas mayores y usuarias de ampliación: una buena estructura les ayuda a seguir dónde están y a volver al lugar correcto con más facilidad.
• Equipos de desarrollo y operaciones: una vez que estructuras para lectores de pantalla, toda la arquitectura de la información queda mejor organizada, y la calidad se vuelve más estable.

11. Evaluación del nivel de accesibilidad (a lo que apunta este artículo)

• Principales criterios relacionados de WCAG 2.1 AA

  • 1.1.1 Contenido no textual: alternativas para imágenes
  • 1.3.1 Información y relaciones: encabezados, tablas, etiquetas, landmarks
  • 2.4.1 Saltar bloques / 2.4.6 Encabezados y etiquetas: mejor descubribilidad
  • 2.4.7 Foco visible: posición actual tanto para quienes usan teclado como para quienes usan lectura en voz alta
  • 3.3.1 Identificación de errores / 3.3.3 Sugerencia ante errores: apoyo para corregir formularios
  • 4.1.2 Nombre, rol, valor: botones, estados, live regions

• El soporte para lectores de pantalla no es solo un punto de control AA. Es una práctica central que eleva la calidad en múltiples criterios al mismo tiempo.

12. Conclusión: el soporte para lectores de pantalla significa transmitir la información como “significado”

1. Las personas usuarias de lectores de pantalla exploran mediante encabezados, landmarks y listas.
2. Por eso, la estructura, las etiquetas y el estado importan tanto como la apariencia.
3. Los formularios deben conectar explícitamente etiquetas, ayudas y errores.
4. Las imágenes, tablas y gráficos no deben seguir dependiendo de lo visual; su significado debe apoyarse en texto.
5. Los cambios en la página deben anunciarse con live regions para que no se pierdan.
6. Haz de la smoke test de 5 minutos un hábito, y mantén en el tiempo la accesibilidad “legible” funcionando.

El soporte para lectores de pantalla no es una función extra para un grupo especial de personas usuarias.
Es la práctica de respetar cuidadosamente los fundamentos de la web: estructurar la información y transmitir el significado con honestidad.
Ojalá tu UI se convierta en un lugar que pueda entenderse igual de bien viendo que escuchando. Te animo de todo corazón.