Uma resposta cresce palavra a palavra. Para pessoas que veem, isto parece progresso. Se cada fragmento for lido de imediato, o mesmo resultado pode levar a interrupções constantes. A questão não é, portanto, se uma alteração é tecnicamente visível, mas de que informação uma pessoa precisa nesse momento.
No critério de sucesso 4.1.3, as WCAG 2.2 abrangem as mensagens de estado, que devem ser determináveis programaticamente sem mudança de foco. A explicação do W3C menciona também evitar interrupções desnecessárias. Isto não implica uma obrigação geral de anunciar individualmente cada palavra recém-gerada. Num chat de IA, separar o estado de trabalho do conteúdo da resposta é particularmente útil.
Três estados em vez de um anúncio interminável
O nosso próprio modelo de demonstração tem três situações compreensíveis: pedido recebido, resposta a ser gerada, resposta concluída. Dão orientação sobre o processo. O próprio texto da resposta responde à questão de fundo e deve depois continuar legível ao ritmo da própria pessoa.
Enquanto espera, uma pessoa pode voltar ao seu próprio campo de introdução ou ler outras partes da página. A interface não deve afastar esta atividade só porque chegou mais um bloco de texto. Uma resposta concluída também não tem de assumir automaticamente o foco do teclado.
O feedback adequado depende do estado. Um processo ainda em curso é algo diferente de um erro que exige uma nova decisão. Se todas as mensagens forem apresentadas como igualmente urgentes, é precisamente esta prioridade que desaparece.
Um pequeno padrão HTML separa conteúdo e estado
O fragmento seguinte é nosso e não contém qualquer ligação a IA. Mostra apenas duas áreas com funções diferentes. A área da resposta contém o texto que pode ser lido mais tarde. A curta linha de estado transmite o estado atual.
<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>A técnica ARIA22 do W3C descreve role=status com uma região dinâmica cortês e o anúncio do conteúdo completo do estado. O nosso aria-atomic explícito torna esta intenção visível no fragmento didático. Não é motivo para colocar todo o texto da resposta, em constante crescimento, na mesma mensagem de estado curta.
Uma implementação real atualizaria a linha de estado em transições significativas, por exemplo uma vez no início e uma vez após a conclusão total. Com que frequência uma mensagem de progresso intermédia ajuda realmente tem de ser testado com o fluxo concreto e com tecnologia de apoio.
Ao verificares de ouvido, pensa também numa pessoa que já está a ler noutro sítio enquanto a resposta é gerada. Tem de recomeçar a frase constantemente? Consegue encontrar deliberadamente a resposta concluída mais tarde? Estas observações testam a utilização do padrão com mais precisão do que a mera constatação de que um anúncio é ouvido algures.
Cancelamentos e erros precisam de palavras próprias
Se a saída for interrompida, «concluído» não pode significar simplesmente que já não chegam mais caracteres. Um texto parado deliberadamente pode estar incompleto. Um erro técnico pode significar que não foi produzido qualquer resultado utilizável. Estas diferenças pertencem à linguagem da interface.
Para uma primeira verificação, podes usar três textos de exemplo fixos e acionar as transições manualmente. Observa o que é anunciado enquanto continuas a ler, se o foco permanece onde está e como chegas ao texto concluído. Este é um exercício que podes realizar, mas não é apresentado aqui como um teste com leitor de ecrã aprovado.
Se preparares o teu próprio HTML e JavaScript numa página KENJTEC, o modo de programador de KENJTEC WebSiteBuilder ai está disponível para isso, com uma pré-visualização em sandbox e a publicação do teu próprio código. Transferes tu próprio o componente; isto não cria um serviço de chat de IA adicional e integrado.
A experiência real de audição é que decide
Uma captura de ecrã não consegue provar nem uma interrupção nem um anúncio inesperado. Por isso, os testes precisam de um teclado e de tecnologia de apoio real. Regista o dispositivo, o navegador e o leitor de ecrã utilizados se mais tarde relatares um resultado específico.
Mesmo um bom padrão de estado não cumpre automaticamente todos os requisitos de um chat acessível. Responde a uma questão limitada: como se torna compreensível o estado de trabalho sem impor o conteúdo a alguém palavra a palavra? Uma boa solução preserva ambos: uma orientação fiável e o controlo da pessoa sobre o seu próprio ritmo de leitura.
Fontes e estado
Pesquisa e documentação à data de 25 de outubro de 2026. Compreender o SC 4.1.3: mensagens de estado · ARIA22: usar role=status para apresentar mensagens de estado.
