Como testar uma landing page criada por IA com leitor de tela

Uma landing page criada por IA pode ter headings, alt e ARIA suficientes para um scanner e ainda ser difícil de usar com leitor de tela. O menu repete links, o CTA é anunciado sem contexto, o formulário não explica o erro e a mensagem de sucesso aparece sem ser lida.

O teste manual encontra a distância entre marcação e experiência. Ele não pede que você percorra cada nó do DOM nem que decore todos os comandos do leitor. Comece pela tarefa principal, use modos de navegação que pessoas reais usam e registre a barreira com contexto.

Este roteiro cobre uma página de marketing com navegação, conteúdo, formulário e resposta dinâmica. Adapte os passos ao navegador, sistema e leitor de tela que fazem parte do suporte do projeto.

Escolha uma combinação real de navegador e leitor

Leitores de tela dependem das APIs de acessibilidade do sistema e do navegador. O mesmo código pode produzir anúncios diferentes em combinações distintas.

Comece com uma configuração que você consegue repetir:

Essa tabela é um ponto de partida, não uma matriz universal de suporte. Registre as versões usadas e acrescente outras combinações quando o público, o risco ou um bug exigir.

No Mac, a documentação da Apple mostra como o VoiceOver navega páginas pelo DOM ou por grupos e como o rotor reúne headings, links, landmarks e outros itens. No Windows, consulte o guia do NVDA para Browse Mode, Focus Mode e navegação rápida.

Não ligue dois leitores de tela ao mesmo tempo. Feche extensões que alteram a página e mantenha o áudio ou visualizador de fala disponível para registrar o que foi anunciado.

Defina a tarefa e a evidência

Antes de iniciar, escreva um caminho curto:

URL ou build:
versão:
sistema, navegador e leitor:
viewport:
tarefa principal:
resultado esperado:
dados de teste autorizados:

Exemplo:

Entender a oferta, comparar os planos, abrir o formulário,
preencher nome e email, provocar um erro e concluir o envio.

Para cada falha, guarde:

• passo e comando usado;
• elemento visível;
• anúncio ouvido;
• anúncio ou comportamento esperado;
• impacto na tarefa;
• trecho de HTML ou componente responsável;
• captura, gravação curta ou transcrição;
• combinação e versão testadas.

“Leitor de tela não funciona” não ajuda quem vai corrigir. “Após Enviar, o texto de erro aparece abaixo do email, mas NVDA não anuncia a mensagem e o foco continua no botão” é reproduzível.

Faça uma primeira leitura sem interagir

Carregue a página do início e ouça título, idioma, conteúdo inicial e ordem de leitura. Depois percorra o conteúdo em sequência.

Pergunte:

• o título identifica a página e muda entre rotas?
• o idioma faz o leitor usar a pronúncia correta?
• navegação, conteúdo principal e rodapé aparecem em ordem compreensível?
• texto visualmente oculto acrescenta contexto ou cria ruído?
• imagens decorativas são ignoradas?
• imagens informativas têm uma alternativa que cumpre a mesma função?
• conteúdo repetido ou escondido é anunciado?

A ordem do leitor costuma seguir o DOM. Layouts que reposicionam blocos apenas com CSS podem contar uma história diferente da tela. O guia sobre HTML semântico ajuda a corrigir a estrutura em vez de adicionar ARIA sobre elementos genéricos.

Navegue por headings e landmarks

Pessoas que usam leitor de tela não precisam ouvir a página inteira para encontrar uma seção. Teste a lista de headings e a lista de landmarks no rotor do VoiceOver ou na navegação rápida do NVDA.

Confirme:

• existe um heading principal que descreve a página;
• os headings nomeiam as seções com clareza;
• a hierarquia representa a estrutura, sem níveis escolhidos pelo tamanho visual;
• main, navegação e outras regiões úteis podem ser encontradas;
• landmarks repetidos recebem nomes que os distinguem;
• não há dezenas de regiões que transformam a lista em ruído.

A W3C explica que headings e labels devem descrever o tópico ou a finalidade. Uma lista tecnicamente completa continua ruim se todos os headings dizem “Saiba mais”.

Use a navegação por heading para chegar a preços, perguntas frequentes e formulário. Depois use landmarks para saltar ao conteúdo principal. Se esses caminhos não encontram a tarefa, revise a estrutura antes de criar atalhos exclusivos para o leitor.

Revise links e botões fora do contexto visual

Abra a lista de links. Nomes repetidos como “clique aqui”, “ver mais” ou “saiba mais” perdem o contexto do card que a pessoa vidente enxerga.

Em cada controle importante, confirme o que a tecnologia assistiva expõe:

• nome;
• papel, como link, botão ou checkbox;
• estado, como expandido, pressionado ou selecionado;
• valor quando aplicável;
• disponibilidade e foco.

O critério Name, Role, Value exige que tecnologias assistivas obtenham essas informações e acompanhem mudanças. HTML nativo já fornece boa parte do contrato quando usado corretamente.

Compare nome visível e nome anunciado. Um botão que mostra “Publicar site” e anuncia “Enviar” cria dúvida. Um ícone sem nome pode ser anunciado pelo nome do arquivo ou apenas como “botão”.

Ative CTA, menu, accordion e modal com o teclado. O resultado precisa ser o mesmo caminho funcional testado com mouse. O roteiro de navegação por teclado cobre ordem, foco e armadilhas com mais detalhe.

Teste o formulário como uma conversa

Navegue campo por campo, primeiro em modo de leitura e depois em modo de formulário ou foco quando o leitor alternar.

Verifique:

• nome acessível corresponde ao rótulo visível;
• obrigatoriedade é anunciada;
• instrução de formato aparece antes do erro;
• grupos de radio e checkbox têm contexto;
• autocomplete e tipo de campo não produzem anúncio enganoso;
• descrição adicional está associada ao campo certo;
• placeholder não substitui o rótulo;
• botão de envio tem nome e estado compreensíveis.

Provoque erros reais com dados de teste. Descubra como a pessoa percebe que algo falhou, encontra a mensagem, identifica o campo e volta para corrigir.

Não mova foco automaticamente para todo texto novo. Um resumo de erros pode receber foco quando inicia uma etapa de correção. Uma mensagem curta que aparece sem mudança de contexto pode usar um mecanismo de status. A decisão depende do fluxo.

O guia de teste de formulários amplia a revisão para envio, rede, integração e destino dos dados.

Confirme mensagens e mudanças dinâmicas

Landing pages modernas atualizam conteúdo sem recarregar. Teste:

• abertura e fechamento do menu;
• expansão de perguntas frequentes;
• seleção de plano ou período;
• validação enquanto a pessoa digita;
• carregamento, sucesso e erro do envio;
• modal de confirmação;
• conteúdo inserido depois de uma ação.

A WCAG 2.2 define que mensagens de status precisam ser determinadas por software para que tecnologias assistivas as anunciem sem receber foco. Isso cobre mensagens sobre resultado, espera, progresso e erro quando não há mudança de contexto.

Evite transformar toda atualização em role="alert". Avisos assertivos interrompem a fala e devem ficar restritos ao que realmente exige atenção imediata. Também não esconda uma correção de foco atrás de uma live region. Se um modal abriu, o foco precisa entrar no componente conforme o padrão adotado.

Procure excesso de ARIA e conteúdo duplicado

ARIA pode preencher uma lacuna de semântica. Também pode sobrescrever um nome correto, criar landmarks repetidos ou anunciar estado que o componente não mantém.

Desconfie de:

• aria-label diferente do texto visível;
• papel de botão em um div sem comportamento completo;
• aria-hidden="true" em ancestral de conteúdo focável;
• duas versões responsivas presentes na árvore de acessibilidade;
• heading escondido criado apenas para manipular a lista;
• live region que repete cada tecla digitada;
• descrição longa aplicada a todos os controles de um grupo;
• atributo de estado que não muda quando a interface muda.

Remova ARIA redundante antes de empilhar mais atributos. Se existe um elemento HTML que comunica papel e comportamento, ele costuma ser a correção menor e mais resistente.

Compare leitura, exploração e tarefa completa

Faça três passagens curtas:

1. leitura sequencial para ordem, idioma, imagens e conteúdo repetido;
2. navegação estrutural por headings, landmarks, links e campos;
3. execução da tarefa principal com estados de erro e sucesso.

Cada passagem encontra um tipo de barreira. Testar apenas Tab não é teste de leitor de tela. Ouvir apenas a página do início ao fim também não mostra se a pessoa consegue saltar para o preço ou corrigir um campo.

Se possível, repita a tarefa sem olhar para a tela. Isso expõe dependências de posição, cor e animação. Ainda assim, não trate essa simulação como experiência equivalente à de uma pessoa que usa leitor de tela todos os dias. Inclua pessoas com deficiência quando a decisão, o risco ou a maturidade do produto exigir evidência de uso.

Corrija a causa e rode regressões

Agrupe os achados pela origem:

Corrija uma causa por vez e repita o passo exato. Rode também os testes automáticos e o scanner, porque uma troca de componente pode corrigir o anúncio e introduzir outro problema de HTML.

O checklist de acessibilidade para sites criados por IA ajuda a manter contraste, zoom, movimento e conteúdo visual no mesmo ciclo de QA.

Reteste a Version publicada

No Site no Ar:

1. chame get_context para confirmar Site, Session e última publicação;
2. altere os arquivos com as file tools;
3. teste a tarefa na versão de trabalho;
4. publique com deploy;
5. acompanhe deploy_status até um estado terminal;
6. abra a URL pública em uma sessão limpa;
7. repita as três passagens com a mesma combinação;
8. associe a evidência ao commit da Version publicada.

A documentação de Publicação descreve esse fluxo. O reteste público importa porque fontes, scripts, cache, caminhos e integrações podem mudar o que o navegador entrega à árvore de acessibilidade.

Prompt para organizar o teste

Prepare um teste manual desta landing page com leitor de tela.

Escopo:
- URL ou build: [origem]
- versão: [identificador]
- sistema, navegador e leitor: [combinação]
- tarefa principal: [passos]
- dados de teste: [restrições]

1. Liste os passos de leitura sequencial, navegação estrutural e tarefa.
2. Inclua headings, landmarks, links, botões, formulário e mensagens.
3. Para cada falha, registre passo, comando, anúncio, esperado e impacto.
4. Relacione o achado ao HTML ou componente responsável.
5. Diferencie falha confirmada de diferença entre combinações.
6. Proponha a menor correção e os checks de regressão.
7. Não declare conformidade e não publique antes da aprovação.

Depois da correção, outra pessoa deve conseguir repetir o roteiro com a mesma combinação e chegar ao mesmo resultado. Esse é o ganho do teste bem documentado: o anúncio deixa de ser uma impressão e vira evidência ligada a uma Version.