Sua IA também precisa ser acessível

*O problema não termina no modelo

Imagine um assistente que escreve uma orientação aos poucos. Para quem vê a tela, o texto crescendo indica atividade. Para quem usa leitor de tela, a experiência depende de como essas mudanças foram implementadas: a resposta pode passar despercebida ou produzir uma sequência cansativa de anúncios.*

Este é um exemplo hipotético de produto, não um caso de cliente. Ele mostra por que avaliar apenas a qualidade do texto deixa uma parte importante da experiência de fora.

Uma base pública, não uma novidade de lançamento

As WCAG 2.2, na versão de Recomendação de 12 de dezembro de 2024 consultada em 16 de outubro de 2026, oferecem uma base para avaliar acessibilidade web. Aqui, o recorte é a interface de conversação; o checklist não equivale a uma auditoria completa nem comprova conformidade.

Fonte: https://www.w3.org/TR/WCAG22/

Separe o estado da tarefa do conteúdo da resposta

O critério 4.1.3 trata de mensagens de status que podem ser identificadas por tecnologia assistiva sem receber foco. A explicação do W3C inclui estados de espera, progresso e resultado. Ela também alerta para o excesso de anúncios.

Aplicação proposta: modele estados como “Gerando resposta”, “Resposta concluída”, “Geração interrompida” e “Não foi possível concluir”. Evite depender apenas de um spinner que desaparece. A resposta longa e o aviso breve de conclusão cumprem papéis diferentes.

Fonte: https://www.w3.org/WAI/WCAG22/Understanding/status-messages.html

Streaming visual não precisa virar anúncio de cada fragmento

A documentação MDN explica que o papel ARIA log serve para atualizações sequenciais, com novos itens acrescentados ao fim. Seu comportamento implícito é aria-live polite, e a região precisa de um nome acessível. Isso pode ajudar a representar um histórico de conversa, mas não resolve sozinho a experiência de uma mensagem alterada repetidamente durante a geração.

Como hipótese de implementação, separe o texto visual em construção dos avisos de status. Avalie anunciar blocos coerentes ou apenas a disponibilidade da resposta concluída. Não imponha a mesma estratégia a todos: teste combinações de navegador e leitor de tela e considere uma preferência de leitura. Não use alertas urgentes para cada trecho de uma resposta comum.

Fonte: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Reference/Roles/log_role

Dê controle a quem está lendo

A proposta de produto é simples: a chegada de texto não deve retirar da pessoa o controle da conversa. Preserve o ponto de leitura quando ela consultar uma mensagem anterior. Ofereça uma ação clara para voltar à resposta mais recente.

Um botão “Interromper resposta” deve dizer o que realmente faz. Se ele apenas para a animação, mas a tarefa continua no servidor, a interface precisa distinguir esses estados. Uma resposta interrompida deve permanecer identificada como incompleta; não pode parecer uma conclusão validada.

Também vale revisar o básico: controles com nomes claros, navegação por teclado, foco perceptível, texto que possa ser ampliado e estrutura de títulos e listas na resposta final. Esses aspectos devem entrar na revisão da interface junto com a qualidade do modelo.

Um teste pequeno antes da próxima entrega

Escolha uma única jornada: enviar uma pergunta, acompanhar a geração, interromper, tentar novamente e reler o resultado. Execute-a com dados fictícios.

Primeiro, use apenas o teclado. Registre se é possível alcançar todas as ações e localizar o foco.

Depois, percorra a mesma jornada com leitor de tela. Anote o que é anunciado no começo, durante e no fim da geração.

Em seguida, simule uma resposta longa e uma falha de conexão. Verifique se o histórico permanece compreensível e se existe um próximo passo claro.

Por fim, peça a uma pessoa que usa tecnologia assistiva que realize a tarefa. Observe dificuldades sem presumir que uma ferramenta automática representa a experiência humana.

Defina antes o que será observado: conclusão da jornada, perdas de foco, anúncios duplicados e trechos inacessíveis. São critérios de teste sugeridos, não resultados obtidos. Corrija uma barreira por vez e repita a jornada.

A pergunta de produto que fica

Seu assistente consegue entregar uma resposta. A pessoa consegue percebê-la, controlá-la e utilizá-la? Colocar essa pergunta no planejamento evita tratar acessibilidade como acabamento de última hora.

Referências

W3C — Web Content Accessibility Guidelines (WCAG) 2.2, Recomendação de 12/12/2024.

https://www.w3.org/TR/WCAG22/

W3C WAI — Understanding Success Criterion 4.1.3: Status Messages, consultado em 16/10/2026.

https://www.w3.org/WAI/WCAG22/Understanding/status-messages.html

MDN — ARIA: log role, última modificação indicada em 23/06/2025, consultado em 16/10/2026.

https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Reference/Roles/log_role