Contenido dinámico, mensajes de estado y cambios de foco

Las páginas actuales cambian sin recargarse: se añade un producto al carrito, se aplica un filtro, se valida un formulario, se cargan más resultados, aparece un aviso de sesión a punto de caducar. Quien ve la pantalla percibe el cambio al instante; quien usa un lector de pantalla solo se entera si el foco se mueve al contenido nuevo o si el cambio se anuncia mediante una región activa. Esta lección te enseña a evaluar esos momentos con tecnologías de apoyo, que es donde fallan muchas aplicaciones web que superan sin problemas una revisión estática.

Las tres preguntas ante cada cambio

Para cada acción que modifica la página sin recargarla, detente justo después de ejecutarla, no muevas el cursor y responde a tres preguntas:

1. ¿Dónde está el foco ahora? Con NVDA, NVDA+Tab lee el elemento que tiene el foco. Si responde con el nombre de la página o con nada, el foco se ha perdido.
2. ¿Qué se ha anunciado? Consulta el visor de voz: es la prueba objetiva de lo que oyó la persona usuaria.
3. ¿Puedo llegar al contenido nuevo y entenderlo? Navega desde la posición actual: ¿el contenido añadido está en un lugar lógico del DOM, cerca de donde se produjo la acción, o al final de la página?

Mensajes de estado (4.1.3) en la práctica

WCAG 2.2 define un mensaje de estado como un cambio de contenido que no es un cambio de contexto y que informa del éxito o el resultado de una acción, del estado de espera de una aplicación, del progreso de un proceso o de la existencia de errores. El criterio 4.1.3 Mensajes de estado (AA) exige que esos mensajes puedan determinarse mediante un rol o unas propiedades, de modo que las tecnologías de apoyo los presenten sin que reciban el foco. De ahí un matiz importante: si el mensaje recibe el foco, 4.1.3 no se aplica, porque el propio movimiento del foco lo comunica.

Ejemplos típicos: «3 artículos en el carrito», «Buscando…», «Se han encontrado 24 resultados», «Borrador guardado», «Paso 2 de 4 completado», «Hay 2 errores en el formulario».

Cómo probarlo

• Ejecuta la acción con el lector activo y quédate quieto. Escucha y revisa el visor de voz.
• Si no se anuncia nada, busca en el inspector del navegador una región activa: role="status" (anuncio educado, espera a que el lector termine), role="alert" (anuncio inmediato, interrumpe), role="log", aria-live o el elemento <output>, que tiene rol de estado implícito.
• Repite en otra combinación de la línea base: el anuncio de regiones activas es una de las áreas con más diferencias entre lectores, como viste en la lección de VoiceOver y TalkBack.
• Valora también el exceso: un role="alert" que interrumpe a cada pulsación de tecla no incumple 4.1.3, pero hace la página inutilizable en la práctica y merece una observación.

Errores de implementación y su síntoma

• La región se crea a la vez que su contenido. Muchos lectores solo anuncian cambios en regiones que ya existían en la página: insertar de golpe un div con rol y texto suele producir silencio.
• El framework sustituye el nodo entero. Si la región se vuelve a renderizar como elemento nuevo, el efecto es el mismo que en el caso anterior: anuncios irregulares o ausentes.
• La región está oculta con display: none o dentro de un contenedor con aria-hidden="true": no se anuncia.
• El aviso es solo visual, un mensaje emergente (toast) que desaparece en tres segundos sin rol ni propiedad: fallo de 4.1.3.

Implementación que suele quedarse en silencio:

const aviso = document.createElement('div');
aviso.setAttribute('role', 'status');
aviso.textContent = 'Producto añadido al carrito';
document.body.append(aviso);

Implementación robusta: la región está en el HTML inicial, vacía, y el script solo cambia su texto.

<!-- En el HTML de la página, desde la carga -->
<div id="estado-carrito" role="status"></div>

// Al añadir el producto
document.getElementById('estado-carrito').textContent =
  'Producto añadido. Carrito: 3 artículos';

El foco tras las acciones y en las aplicaciones de una sola página

En una SPA (single page application, aplicación de una sola página), pulsar un enlace cambia la vista sin cargar una página nueva. El lector no detecta que ha cambiado nada: si el título no se actualiza y el foco se queda en el enlace pulsado o se pierde, la persona usuaria no sabe dónde está. Prueba así: activa el enlace con NVDA, pulsa NVDA+T (¿ha cambiado el título?), NVDA+Tab (¿dónde está el foco?) y Flecha abajo (¿la lectura continúa en el contenido nuevo o en el antiguo?). Lo esperable es que el foco vaya al encabezado principal de la nueva vista o a su contenedor.

El foco también se pierde cuando se elimina el elemento que lo tenía: borrar una fila de una lista, cerrar una etiqueta de filtro, sustituir un panel entero. El navegador lo devuelve al inicio del documento y la siguiente pulsación de Tab empieza desde la cabecera. Con botones de «Cargar más», comprueba que el foco se queda en el botón o pasa al primer resultado nuevo, y que el número de resultados añadidos se anuncia.

Tiempo y procesos asíncronos

El criterio 2.2.1 Tiempo ajustable (A) exige que, si hay un límite de tiempo, la persona usuaria pueda desactivarlo, ajustarlo o ampliarlo; en el caso de ampliarlo, que se le avise antes de que expire, que disponga de al menos 20 segundos para ampliarlo con una acción simple y que pueda hacerlo al menos diez veces. Hay excepciones (tiempo real, límites esenciales y límites de más de 20 horas). Con tecnologías de apoyo la pregunta clave es si el aviso llega: un banner visual sin rol ni movimiento del foco no existe para quien usa un lector, y un botón de «Ampliar sesión» situado al final del DOM puede ser inalcanzable en los segundos disponibles.

Las sedes electrónicas y la banca en línea suelen cerrar la sesión tras unos minutos de inactividad. Para no esperar durante la auditoría, pide al cliente un entorno de preproducción con el tiempo de sesión reducido. Comprueba también los estados de espera: un indicador de carga que gira sin texto ni región de estado deja a la persona usuaria sin saber si la acción se está procesando, y la espera forma parte de la definición de mensaje de estado.

Resumen

• Ante cada cambio sin recarga, responde a tres preguntas: dónde está el foco, qué se ha anunciado y si se puede llegar al contenido nuevo.
• 4.1.3 Mensajes de estado se aplica a mensajes que no reciben el foco; se evalúa ejecutando la acción con el lector y revisando el visor de voz.
• Las regiones activas deben existir antes de recibir el texto; crearlas a la vez que su contenido o renderizarlas de nuevo suele producir silencio.
• En SPA y al eliminar elementos, comprueba título, posición del foco y continuidad de la lectura (2.4.2, 2.4.3).
• Los avisos de tiempo deben llegar a quien usa tecnologías de apoyo y permitir ampliar la sesión (2.2.1); provoca los estados dinámicos para poder evaluarlos.