Uma landing page criada por IA pode funcionar perfeitamente com o mouse e falhar assim que alguém pressiona Tab. O foco desaparece, o menu não abre, um modal prende a navegação ou o CTA entra na sequência em uma ordem diferente da tela.

O teste de teclado encontra barreiras que screenshots e scanners não conseguem confirmar. Ele também revela problemas de estrutura: controles simulados com div, ordem do DOM incompatível com o layout e estados visuais sem equivalente programático.

Este guia organiza um roteiro manual, evidências para o handoff e um ciclo de correção e reteste na URL publicada.

Por que testar sem mouse

A W3C explica que toda funcionalidade disponível pelo mouse também deve estar disponível pelo teclado. Isso atende pessoas que usam teclado, teclado virtual, dispositivo de acionamento ou outras formas de entrada.

Na WCAG 2.2, a revisão conversa com vários critérios:

  • operação por teclado;
  • ausência de armadilha de teclado;
  • ordem de foco compreensível;
  • foco visível;
  • foco não totalmente encoberto;
  • mecanismo para pular blocos repetidos.

O texto normativo da WCAG 2.2 define os critérios. Um teste curto não declara conformidade com todos eles, mas produz evidência concreta sobre a tarefa principal.

Prepare um roteiro reproduzível

Registre:

URL ou build:
versão:
navegador e sistema:
largura da janela:
página inicial do teste:
tarefa principal:
componentes especiais:
resultado esperado:

Exemplo de tarefa:

Abrir o menu, chegar à seção de planos, abrir o modal do plano Pro,
fechar o modal, preencher o formulário e chegar ao botão de envio.

Teste primeiro em uma largura grande e depois em uma largura pequena. Menus, headers fixos, banners e componentes responsivos costumam mudar a sequência e a visibilidade do foco.

Não comece clicando dentro da página. Recarregue e use o teclado desde o início para observar a ordem real.

Conheça as teclas que entram no teste

Na página:

  • Tab: avança entre elementos focáveis;
  • Shift+Tab: retorna;
  • Enter: ativa links, botões e alguns controles;
  • Espaço: ativa botões e alterna certos controles nativos;
  • Esc: fecha componentes que adotam esse comportamento, como modais;
  • setas: navegam dentro de widgets que seguem um padrão específico.

Não imponha setas a todo menu de links. A interação esperada depende do componente. A ARIA Authoring Practices Guide documenta padrões para widgets como dialogs, tabs, accordions e menus, mas a própria W3C trata o APG como orientação informativa, não como um design system pronto.

Check 1: percorra a ordem de foco

Pressione Tab lentamente e anote cada parada.

A sequência deve:

  • começar em um ponto previsível;
  • acompanhar uma ordem que permita entender e operar a página;
  • incluir todos os controles necessários;
  • evitar elementos invisíveis ou desativados;
  • não focar conteúdo puramente decorativo;
  • permitir retorno com Shift+Tab;
  • chegar ao CTA e ao formulário sem saltos ilógicos.

A ordem não precisa reproduzir cada centímetro do layout, mas não pode criar confusão. A explicação da W3C sobre ordem de foco admite diferenças em relação à ordem de leitura desde que a página continue compreensível e operável.

Desconfie de:

tabindex="1"
tabindex="2"
tabindex="99"

Valores positivos criam uma sequência paralela difícil de manter. Prefira a ordem natural do DOM e ajuste a estrutura.

Check 2: confirme que o foco é visível

Em cada parada, responda: “eu consigo dizer imediatamente onde estou?”

O indicador precisa:

  • aparecer em todos os controles focáveis;
  • permanecer enquanto o elemento está focado;
  • ser distinguível do estado normal;
  • funcionar em fundos claros, escuros e com imagem;
  • não depender apenas de uma mudança sutil de cor;
  • acompanhar controles que recebem foco por script.

Não remova outline sem oferecer um indicador equivalente. A W3C destaca que foco visível permite que a pessoa saiba qual elemento receberá a interação.

:focus-visible pode diferenciar a apresentação usada em navegação por teclado sem esconder o estado necessário. Teste no navegador em vez de confiar apenas na regra CSS.

Check 3: verifique foco encoberto

Headers fixos, banners de cookies, chat flutuante e rodapés persistentes podem cobrir o elemento focado.

Teste:

  • início e fim da página;
  • campos próximos ao rodapé;
  • CTA sob header fixo;
  • conteúdo depois de abrir um menu;
  • largura mobile;
  • zoom ou texto ampliado.

A WCAG 2.2 adicionou o critério de foco não encoberto no nível mínimo: um componente focado não pode ficar totalmente escondido por conteúdo criado pela página.

Não corrija apenas rolando a tela por script a cada Tab. Primeiro identifique por que o layout cobre a área e se o componente persistente realmente precisa ocupar aquele espaço.

Check 4: compare mouse, Enter e Espaço

Para cada CTA ou controle:

  1. ative com mouse;
  2. recarregue;
  3. ative com teclado;
  4. compare resultado, estado e mensagem.

Um link nativo costuma responder a Enter. Um botão nativo responde a Enter e Espaço. Quando um div recebe apenas onclick, o mouse funciona e o teclado não.

O guia sobre como revisar HTML semântico em sites criados por IA aprofunda a escolha entre link, botão e elemento genérico. Corrija a raiz antes de adicionar manipuladores de teclado duplicados.

Check 5: teste menu e navegação responsiva

Em um menu mobile:

  • o botão de abertura recebe foco;
  • o nome acessível descreve a ação;
  • Enter ou Espaço abre;
  • o estado aberto é comunicado;
  • os links ficam disponíveis numa ordem lógica;
  • Esc, quando adotado, fecha;
  • o foco retorna ao botão ou segue para um lugar previsível;
  • itens invisíveis não permanecem na sequência quando o menu fecha.

Depois redimensione a janela. Confirme que o componente não mantém um estado intermediário: menu visualmente fechado com links ainda focáveis, botão duplicado ou foco perdido.

Check 6: teste modais sem criar uma armadilha

Um modal exige gerenciamento deliberado.

Segundo o padrão de dialog modal da W3C:

  • ao abrir, o foco vai para dentro do dialog;
  • Tab e Shift+Tab percorrem os elementos internos;
  • Esc fecha;
  • ao fechar, o foco normalmente retorna ao controle que abriu;
  • o conteúdo fora do modal fica indisponível enquanto ele está ativo.

Conter o foco dentro de um modal aberto é comportamento esperado. Impedir que a pessoa saia de um componente que não pode ser fechado é armadilha.

Teste também:

  • título e nome acessível;
  • botão visível de fechar;
  • conteúdo longo sem esconder o início;
  • mensagem de erro dentro do modal;
  • reabertura após fechar;
  • modal sobre outro componente responsivo.

Não copie um padrão complexo sem validar a implementação no framework e nas tecnologias assistivas previstas.

Check 7: percorra formulários e mensagens

No formulário:

  • a ordem acompanha os rótulos e grupos;
  • cada campo focado tem identificação visível;
  • checkbox e radio podem ser alterados por teclado;
  • seletores personalizados seguem um padrão conhecido;
  • erro não apaga os dados sem necessidade;
  • o foco chega à mensagem ou ao primeiro campo inválido de forma útil;
  • sucesso é percebido sem depender de cor;
  • envio não acontece apenas porque um campo recebeu foco.

Execute o caminho feliz e pelo menos um erro relevante. O guia de teste de formulários em landing pages com IA cobre também rede, integração e destino dos dados.

Check 8: procure armadilhas e mudanças inesperadas

Uma armadilha ocorre quando o foco entra em uma área e não consegue sair com métodos esperados.

Procure em:

  • players e embeds;
  • carrosséis;
  • editores ou widgets de terceiros;
  • menus personalizados;
  • modais;
  • captchas;
  • iframes;
  • componentes que interceptam teclas.

Também registre mudanças inesperadas:

  • focar um campo envia o formulário;
  • focar uma opção navega para outra página;
  • abrir um componente move o foco para lugar desconhecido;
  • fechar remove o elemento focado sem definir continuação;
  • Esc fecha a página inteira ou perde dados.

O critério On Focus da WCAG orienta que receber foco não deve iniciar uma mudança de contexto.

Quando navegação, banners ou outros blocos se repetem, ofereça um caminho para chegar ao conteúdo principal.

Um skip link pode ficar visualmente oculto até receber foco, mas precisa:

  • ser uma das primeiras paradas;
  • ficar visível quando focado;
  • apontar para o conteúdo principal;
  • mover o foco ou a navegação de forma útil;
  • não ficar atrás do header.

Teste em todas as larguras. Um link presente no HTML, mas encoberto quando aparece, não cumpre sua função.

Automação ajuda, mas não percorre a experiência

Checks automáticos podem encontrar:

  • elementos clicáveis sem semântica;
  • tabindex suspeito;
  • foco removido por CSS;
  • nomes acessíveis ausentes;
  • atributos ARIA incompatíveis;
  • controles ocultos ainda focáveis.

Eles não confirmam:

  • se a ordem conta uma história coerente;
  • se o foco é fácil de perceber sobre a arte final;
  • se um modal devolve a pessoa ao lugar certo;
  • se a mensagem de erro ajuda;
  • se a tarefa pode ser concluída sem mouse.

Combine lint, scanner e teste manual. O checklist de acessibilidade para sites criados por IA amplia o escopo para contraste, conteúdo, imagens, movimento e tecnologias assistivas.

Registre cada falha com evidência

Evite “teclado não funciona”. Use um formato reproduzível:

página e versão:
largura e navegador:
passo inicial:
sequência de teclas:
elemento esperado:
resultado observado:
impacto:
severidade:
arquivo ou componente provável:

Exemplo:

Na largura de 390 px, abra o menu com Enter e pressione Tab quatro vezes.
O foco chega aos links escondidos atrás do banner antes do CTA visível.
Impacto: a ordem não corresponde ao menu apresentado.

Essa evidência permite corrigir um componente sem reescrever a página inteira.

Prompt copiável para o agente

Teste a navegação por teclado desta landing page.


Escopo:
- URL ou build: [origem]
- versão: [commit]
- navegador e larguras: [lista]
- tarefa principal: [objetivo]


1. Recarregue e percorra tudo sem mouse com Tab e Shift+Tab.
2. Teste Enter, Espaço, Esc e setas somente onde forem esperados.
3. Verifique ordem, foco visível, foco encoberto, skip link, menu,
   modais, formulário e retorno de foco.
4. Registre cada falha com passos, resultado observado, impacto,
   severidade e componente provável.
5. Separe falhas confirmadas de alertas que exigem revisão humana.
6. Não edite nem publique antes da aprovação.

Depois da aprovação, autorize a menor correção possível e peça regressão visual, teste de mouse e repetição do roteiro completo.

Reteste na URL publicada

O contrato de Publicação serve os arquivos dentro de public/. Confirme que a Version testada contém exatamente os arquivos revisados.

Depois do deploy:

  1. abra a URL final em uma sessão nova;
  2. registre a versão publicada;
  3. repita a tarefa sem mouse;
  4. teste desktop e mobile;
  5. confirme que scripts, fontes e componentes carregaram;
  6. registre falhas restantes e exceções aprovadas.

Se houver regressão, preserve Site ID, slug e URL e siga o fluxo de republicação do Site com agente de IA.

Uma landing page passa no teste de teclado quando a tarefa pode ser entendida e concluída sem depender do mouse, com foco perceptível e comportamento previsível. O agente pode executar checks, localizar componentes e documentar evidências. A validação manual continua essencial porque acessibilidade acontece no percurso, não apenas no código.