Una respuesta crece palabra a palabra. Para las personas videntes, esto parece progreso. Si cada fragmento se lee en voz alta de inmediato, la misma salida puede provocar interrupciones constantes. Por tanto, la cuestión no es si un cambio es técnicamente visible, sino qué información necesita una persona en ese momento.
En el criterio de conformidad 4.1.3, las WCAG 2.2 abordan los mensajes de estado, que deberían poder determinarse mediante programación sin un cambio de foco. La explicación del W3C menciona también evitar interrupciones innecesarias. Esto no implica una obligación general de anunciar individualmente cada palabra recién generada. En un chat de IA resulta especialmente útil separar el estado de trabajo del contenido de la respuesta.
Tres estados en lugar de un anuncio interminable
Nuestro propio modelo de demostración tiene tres situaciones comprensibles: solicitud recibida, respuesta en generación, respuesta completa. Proporcionan orientación sobre el proceso. El propio texto de la respuesta responde a la cuestión de fondo y después debería poder leerse al ritmo de cada persona.
Mientras espera, una persona puede volver a su propio campo de entrada o leer otras partes de la página. La interfaz no debería desplazar esta actividad solo porque haya llegado otro fragmento de texto. Una respuesta terminada tampoco tiene por qué apropiarse automáticamente del foco del teclado.
La respuesta adecuada depende del estado. Un proceso que sigue en marcha es algo distinto de un error que exige una nueva decisión. Si todos los mensajes se presentan como igual de urgentes, desaparece precisamente esta prioridad.
Un pequeño patrón de HTML separa contenido y estado
El siguiente fragmento es nuestro y no contiene ninguna conexión con IA. Solo muestra dos áreas con funciones distintas. El área de respuesta contiene el texto que puede leerse más tarde. La breve línea de estado transmite el estado actual.
<section aria-labelledby="answer-title">
<h2 id="answer-title">Answer</h2>
<div id="answer"></div>
</section>
<p id="answer-status" role="status" aria-atomic="true"></p>La técnica ARIA22 del W3C describe role=status con una región activa cortés y el anuncio del contenido de estado completo. Nuestro aria-atomic explícito hace visible esta intención en el fragmento didáctico. No es motivo para meter todo el texto de la respuesta, que crece constantemente, en el mismo mensaje de estado breve.
Una implementación real actualizaría la línea de estado en transiciones significativas, por ejemplo una vez al inicio y otra vez tras completarse del todo. La frecuencia con la que un mensaje de progreso intermedio ayuda realmente tiene que probarse con el flujo concreto y con tecnología de apoyo.
Al comprobarlo de oído, piensa también en una persona que ya está leyendo en otro lugar mientras se genera la respuesta. ¿Tiene que volver a empezar su frase una y otra vez? ¿Puede encontrar la respuesta terminada de forma deliberada más tarde? Estas observaciones comprueban cómo se usa el patrón con más precisión que limitarse a constatar que se oye un anuncio en algún sitio.
La cancelación y los errores necesitan sus propias palabras
Si la salida se interrumpe, «listo» no debe significar simplemente que ya no llegan más caracteres. Un texto detenido deliberadamente puede estar incompleto. Un error técnico puede significar que no se ha producido ningún resultado utilizable. Estas diferencias deben reflejarse en el lenguaje de la interfaz.
Para una primera comprobación, puedes usar tres textos de muestra fijos y activar las transiciones a mano. Observa qué se anuncia mientras sigues leyendo, si el foco permanece donde está y cómo llegas al texto terminado. Es un ejercicio que puedes realizar, pero aquí no se presenta como una prueba con lector de pantalla superada.
Si preparas tu propio HTML y JavaScript en una página de KENJTEC, el modo de desarrollador de KENJTEC WebSiteBuilder ai está disponible para ello, con una vista previa aislada y la publicación de tu propio código. Tú mismo trasladas el componente; esto no crea ningún servicio de chat de IA adicional e integrado.
Lo que decide es la experiencia de escucha real
Una captura de pantalla no puede demostrar ni una interrupción ni un anuncio inesperado. Por eso, las pruebas necesitan un teclado y tecnología de apoyo real. Anota el dispositivo, el navegador y el lector de pantalla utilizados si más adelante informas sobre un resultado concreto.
Ni siquiera un buen patrón de estado cumple automáticamente todos los requisitos de un chat accesible. Responde a una pregunta limitada: ¿cómo se vuelve comprensible el estado de trabajo sin imponerle a alguien el contenido palabra a palabra? Una buena solución conserva ambas cosas: una orientación fiable y el control de la persona sobre su propio ritmo de lectura.
Fuentes y estado
Investigación y documentación a fecha de 25 de octubre de 2026. Understanding SC 4.1.3: Status Messages · ARIA22: Using role=status to present status messages.
