Accesibilidad en interfaces de IA: respuestas en streaming y lectores de pantalla

¿Por qué el streaming rompe la lectura de pantalla?

Los modelos generan texto en fragmentos, y muchas interfaces los muestran uno tras otro. Visualmente, es cómodo. Para un lector de pantalla, cada cambio en el contenido puede disparar un anuncio. Un artículo técnico de 2026 sobre el tema describe los dos fallos típicos:

• Si el contenedor de la respuesta se marca como atómico, el lector vuelve a leer todo el mensaje acumulado en cada token.
• Si no es atómico y los cambios llegan muy seguido, algunos fragmentos se saltan y el usuario escucha frases incompletas (Tianpan, abril de 2026).

La solución no es quitar el streaming, sino separar el estado de la respuesta. Lo que se anuncia en vivo debe ser corto.

¿Qué rol y atributos usar?

Un chat es un historial donde se añaden mensajes. Para eso existe el rol log. La técnica ARIA23 del W3C lo describe así: tiene aria-live="polite" implícito y aria-atomic="false", de modo que las entradas nuevas se leen sin mover el foco. Su ejemplo es un contenedor de historial de chat con un título asociado y mensajes añadidos a una lista (W3C, ARIA23).

Sobre esa base, el mismo artículo técnico de 2026 propone algunos ajustes que conviene probar, aunque no son estándar:

Un detalle que se pasa por alto: la región en vivo debe existir vacía en el DOM antes de que llegue el contenido, para que el lector la registre. El mismo artículo sugiere esperar unos segundos antes de insertar el primer texto.

¿Cómo se anuncia el estado?

El criterio 4.1.3 Status Messages de WCAG 2.2, de nivel AA, pide que los mensajes de estado se puedan determinar por programa, mediante un rol o una propiedad, para que las tecnologías de apoyo los presenten sin recibir el foco. No obliga a crear mensajes de estado nuevos, pero los que se muestren deben llegar al lector. Para una interfaz de IA, eso significa tres estados claros, en texto:

1. Generando. “Generando respuesta…” en un elemento de estado separado, no dentro de la respuesta.
2. Completa. Un aviso breve al terminar, por ejemplo “Respuesta completa, 4 párrafos”, para que el usuario sepa que puede leer.
3. Cancelada o con error. “Generación cancelada” o “No se pudo generar la respuesta, reintentar”, con foco disponible para actuar.

Evita anunciar cada palabra, y evita los indicadores de “escribiendo…” de forma insistente: son ruido constante para quien escucha.

¿Qué hacer con el texto final?

Una estrategia práctica es que el texto parcial no se anuncie, y que la respuesta completa se publique una vez al final, dentro del historial log. Así el lector escucha la respuesta una sola vez y sin cortes. Si la respuesta es larga, ayuda empezar con un resumen breve de una a tres frases, como recomienda el mismo artículo, y usar encabezados, listas y tablas para que el lector pueda navegar por la estructura.

El diseño también importa en lo visual. Si un bloque de código o una tabla llega a mitad del streaming, el contenido debe mantener su estructura semántica (encabezado, lista, celda) y no convertirse en texto plano.

¿Cómo se prueba?

• Revisión de código. El contenedor tiene rol log, nombre accesible y arranca vacío.
• Prueba automatizada. Un chequeo que confirme que la región existe y que aria-busy cambia al terminar. Las herramientas automáticas no detectan si la conversación tiene sentido al escucharla.
• Prueba manual con lectores. Al menos dos lectores de pantalla, por ejemplo NVDA, JAWS o VoiceOver, porque se comportan de forma muy distinta con cambios frecuentes, como señala el mismo artículo. Incluye el caso de respuesta cancelada.

Ejemplo

Ejemplo ilustrativo: un asistente de un banco responde preguntas de productos. Al enviar una pregunta, un texto de estado sale en el aviso: “Generando respuesta”. La respuesta se escribe en pantalla, pero el lector no la anuncia mientras avanza. Al terminar, el historial añade el mensaje completo y el estado cambia a “Respuesta completa”. Si el usuario presiona Escape, el estado dice “Generación cancelada” y el campo de entrada recupera el foco.

Cómo aplicarlo mañana

1. Activa un lector de pantalla en tu equipo y haz una consulta completa en tu prototipo con los ojos cerrados. Anota cada anuncio que te sobra o que te falta.
2. Pide a ingeniería que muestre el contenedor de respuestas en el código: rol, nombre accesible y estado inicial vacío.
3. Añade tres estados textuales a la interfaz: generando, completa y cancelada. Revisa que cada uno tenga su texto y que no dependa solo de un icono.
4. Incluye la cancelación con teclado en tu lista de pruebas. Muchas interfaces de chat no permiten detener una respuesta sin usar el ratón.

Una regla útil: si el usuario no puede saber desde el teclado si la IA sigue trabajando, la interfaz no está terminada.

La accesibilidad de los estados de respuesta se conecta con la calibración de confianza, porque quien no puede ver si la respuesta es firme también necesita esa información. Para los mensajes de error, revisa errores de IA y cómo recuperarse, y para el tono del asistente, antropomorfización.

Errores comunes

• Marcar todo el contenedor de streaming con aria-live="assertive".
• Usar aria-atomic="true" en el historial completo, lo que relee toda la conversación.
• Poner el spinner como único indicador de actividad.
• Confiar solo en una auditoría automática y no probar con un lector de pantalla.
• Mover el foco al final de cada respuesta mientras el usuario escribe otra pregunta.
• Olvidar el estado de error y dejar al usuario sin saber si la generación falló.

Fuentes

• W3C, “ARIA23: Using the log role to identify a sequential update container” (WCAG 2.2 Techniques): https://w3.org/WAI/WCAG22/Techniques/aria/ARIA23.html
• Tianpan, “The Accessibility Gap in AI Interfaces Nobody Is Shipping Around” (abril de 2026): https://tianpan.co/blog/2026-04-17-ai-accessibility-streaming-screen-readers
• W3C, “Understanding Success Criterion 4.1.3: Status Messages” (WCAG 2.2): https://www.w3.org/WAI/WCAG22/Understanding/status-messages.html