Um site criado por IA pode parecer completo e ainda impedir que parte do público leia, navegue ou conclua a ação principal. Um botão sem nome claro, foco invisível, contraste fraco ou formulário sem rótulos não costuma aparecer em uma revisão feita apenas com o mouse e uma tela grande.

A acessibilidade precisa entrar no fluxo como critério de aceite: revisar a fonte, testar a experiência, publicar e repetir os caminhos essenciais na URL real. O agente ajuda a localizar padrões problemáticos e executar checks, mas não transforma uma nota automática em prova de conformidade.

Este checklist organiza uma primeira auditoria prática para landing pages e sites estáticos criados com IA. Ele não substitui uma avaliação formal nem testes com pessoas com deficiência.

Use WCAG 2.2 como referência, não como selo automático

A WCAG 2.2 organiza os requisitos em quatro princípios:

Princípio Pergunta para a revisão
perceptível o conteúdo chega por mais de uma forma quando necessário?
operável todas as ações funcionam sem depender de um único dispositivo?
compreensível conteúdo, navegação e erros podem ser entendidos?
robusto o código comunica estrutura e estado a diferentes tecnologias?

Os critérios são classificados nos níveis A, AA e AAA. Para uma auditoria de conformidade, defina versão, nível, páginas incluídas e método de avaliação. Não declare que o site “é WCAG” porque uma extensão mostrou zero erros.

A própria W3C explica que ferramentas de avaliação não verificam todos os aspectos. Elas encontram problemas e apoiam a revisão manual; não determinam sozinhas se um site é acessível.

Comece pelo escopo e pela tarefa principal

Antes de abrir uma ferramenta, registre:

URL ou build revisado:
versão ou commit:
páginas incluídas:
tarefa principal:
nível de referência:
navegadores e larguras:
tecnologias assistivas previstas:
responsável pela liberação:

Em uma landing page, a tarefa principal pode ser entender a oferta e enviar um formulário. Em um site de documentação, pode ser localizar e ler uma orientação. Esse caminho orienta a prioridade: uma falha que bloqueia a conversão ou o acesso ao conteúdo principal é mais urgente que um detalhe isolado em uma área secundária.

Separe também três tipos de resultado:

  • falha confirmada: existe evidência reproduzível de barreira;
  • alerta para revisão: a ferramenta encontrou um padrão que exige contexto humano;
  • decisão editorial: texto, ordem ou descrição precisam de quem conhece a mensagem.

O agente pode organizar os três grupos, mas não deve encerrar alertas ambíguos como se fossem aprovados.

Check 1: estrutura e significado

Comece sem olhar para o acabamento visual. A página precisa continuar compreensível quando sua estrutura é interpretada por um leitor de tela, modo de leitura ou navegação por headings.

Verifique:

  • o documento informa o idioma correto;
  • existe um H1 que identifica a página;
  • headings seguem uma hierarquia coerente, sem serem escolhidos apenas pelo tamanho;
  • regiões como navegação, conteúdo principal e rodapé usam elementos adequados;
  • listas, tabelas e botões são elementos reais, não blocos genéricos estilizados;
  • o título da página é específico;
  • links descrevem o destino fora do contexto;
  • a ordem do DOM acompanha a ordem visual e de leitura.

Peça ao agente para mostrar o elemento e a causa, não apenas recomendar mais ARIA. HTML semântico costuma comunicar melhor que uma camada de atributos aplicada sobre componentes incorretos. ARIA não corrige um div clicável que deveria ser um botão.

Check 2: imagens, ícones e conteúdo visual

Toda imagem precisa de uma decisão, não necessariamente de uma descrição longa.

  • imagens informativas recebem alternativa que transmite sua função ou conteúdo;
  • imagens decorativas são ignoradas por tecnologias assistivas;
  • ícones usados como controles têm nome acessível;
  • gráficos têm a informação essencial disponível em texto ou tabela;
  • texto importante não está preso dentro de uma imagem;
  • legenda, alternativa e texto próximo não repetem a mesma frase sem necessidade.

Uma descrição útil depende do contexto. “Foto de pessoas” diz pouco em uma seção de prova social; “Equipe da cliente reunida no lançamento” pode ser relevante se essa informação sustenta o conteúdo. Para uma textura de fundo, nenhuma narração é melhor que ruído repetitivo.

Imagens geradas por IA também precisam de revisão editorial: confirme se representam o assunto sem inventar interface, dado, cliente ou resultado.

Check 3: contraste, cor e legibilidade

Teste texto, controles e estados, não apenas a combinação principal da marca.

Revise:

  • contraste de texto normal e grande;
  • bordas e ícones necessários para entender ou operar um controle;
  • foco visível sobre fundos claros e escuros;
  • erros, sucesso e seleção comunicados por algo além de cor;
  • zoom e aumento de texto sem corte ou sobreposição;
  • comprimento de linha, espaçamento e tamanho de fonte adequados à leitura;
  • conteúdo que continua utilizável em larguras pequenas.

Um agente pode calcular relações de contraste a partir das cores encontradas no código. Ainda assim, compare com a versão renderizada: transparência, imagem de fundo, gradiente e estados interativos podem produzir uma combinação diferente da variável CSS isolada.

Check 4: teclado e foco

Percorra a página usando Tab, Shift+Tab, Enter, Espaço e Esc quando aplicável. A introdução da W3C aos princípios de acessibilidade reforça que funcionalidades disponíveis pelo mouse também precisam estar disponíveis pelo teclado.

Confirme:

  • todos os controles interativos recebem foco;
  • a ordem de foco acompanha a tarefa;
  • o indicador de foco é visível e não fica escondido;
  • nenhum componente prende o teclado;
  • menus, modais e accordions abrem e fecham com comportamento esperado;
  • o foco retorna a um lugar lógico depois que um modal fecha;
  • não existem áreas clicáveis acessíveis somente por hover;
  • um link de salto permite chegar ao conteúdo principal quando a navegação se repete.

WCAG 2.2 acrescenta critérios relacionados a foco não oculto e tamanho mínimo de alvo. Isso importa em páginas com headers fixos, banners e botões pequenos: o controle pode tecnicamente receber foco e ainda permanecer invisível ou difícil de acionar.

Check 5: formulários e mensagens

Formulários merecem teste completo, inclusive estados de falha.

  • cada campo tem rótulo associado;
  • instruções aparecem antes de serem necessárias;
  • obrigatoriedade não depende apenas de um asterisco;
  • tipos e atributos de autocomplete fazem sentido;
  • o erro identifica o campo, explica o problema e orienta a correção;
  • a mensagem de sucesso é percebida e corresponde ao envio real;
  • o foco vai para uma posição útil depois de um erro;
  • dados preenchidos não são apagados sem necessidade;
  • autenticação, quando existir, não depende apenas de uma tarefa cognitiva.

Não use placeholder como único rótulo. Ele desaparece durante a digitação e costuma ter contraste fraco. Também não aceite uma mensagem genérica como “algo deu errado” quando a pessoa precisa descobrir qual campo corrigir.

Se o formulário envia dados para um serviço externo, teste com uma conta e um registro autorizados. Acessibilidade da interface não prova que o lead chegou ao destino certo.

Check 6: movimento, tempo e mídia

Sites gerados por IA frequentemente recebem animações porque elas produzem impacto rápido. Revise se o efeito ajuda ou cria uma barreira.

  • respeite a preferência por movimento reduzido;
  • ofereça controle para conteúdo que inicia ou avança automaticamente;
  • não use flashes perigosos;
  • garanta tempo suficiente para ler e agir;
  • forneça alternativas para áudio e vídeo quando fizerem parte da mensagem;
  • evite carrosséis que mudam antes que o conteúdo possa ser entendido;
  • preserve a funcionalidade quando a animação for removida.

Uma correção de acessibilidade não precisa apagar toda expressão visual. Ela precisa separar decoração de informação e garantir que o movimento não controle a experiência contra a vontade da pessoa.

Combine automação com revisão humana

Organize a auditoria em camadas:

  1. checks estáticos: HTML, nomes acessíveis, atributos, landmarks e padrões de código;
  2. scanner no navegador: contraste, árvore de acessibilidade e regras automatizáveis;
  3. teste manual: teclado, foco, zoom, mensagens e fluxo completo;
  4. tecnologia assistiva: leitor de tela e outras ferramentas previstas no escopo;
  5. avaliação com pessoas: quando o risco e a maturidade do produto exigirem evidência real de uso.

Nenhuma camada substitui as outras. A W3C recomenda avaliar acessibilidade cedo e ao longo do desenvolvimento e ressalta que nenhuma ferramenta isolada determina conformidade.

O checklist de QA para landing pages criadas com IA cobre conteúdo, responsividade, pacote e destino. Use este artigo para aprofundar a parte de acessibilidade.

Valide novamente na URL publicada

O build local não reproduz necessariamente o que chegou ao visitante. Depois do deploy:

  1. abra a URL final;
  2. confirme título, idioma e conteúdo principal;
  3. percorra a tarefa principal com teclado;
  4. verifique foco, formulário e mensagens;
  5. confira imagens, fontes e scripts carregados;
  6. repita o scanner na página pública;
  7. registre versão, data, falhas e exceções.

Problemas de pacote, caminhos ou scripts externos podem aparecer somente no endereço público. A documentação de Publicação explica como preparar uma página isolada ou um pacote com múltiplos arquivos.

Quando houver correção, preserve o Site ID e publique uma nova versão no mesmo endereço. O guia de republicação com agente de IA mostra como manter slug e URL enquanto o pacote é atualizado.

Prompt para conduzir uma auditoria

Audite a acessibilidade desta página com WCAG 2.2 como referência.


Escopo:
- URL ou build: [origem]
- versão: [commit ou referência]
- páginas: [lista]
- tarefa principal: [objetivo]
- nível de referência: [A/AA/outro]


1. Execute os checks disponíveis no projeto.
2. Revise estrutura, idioma, headings, links, imagens, formulários e ARIA.
3. Teste teclado, ordem e visibilidade do foco, zoom e larguras pequenas.
4. Classifique cada achado como falha confirmada, alerta manual ou decisão editorial.
5. Para cada falha, informe elemento, critério relacionado, impacto,
   severidade e menor correção possível.
6. Não declare conformidade apenas pelo resultado automático.
7. Não edite nem publique antes de eu aprovar o plano.

Depois da correção, peça ao agente para executar os checks de regressão, gerar o pacote completo, republicar e repetir a tarefa principal na URL final.

Registre evidência e limites

Um relatório útil contém:

escopo e versão:
referência e nível:
checks automáticos:
testes manuais:
tecnologias assistivas:
falhas corrigidas:
alertas pendentes:
exceções aceitas e responsável:
URL retestada:
próxima revisão:

Não escreva “100% acessível” quando a avaliação cobriu apenas uma página, um navegador e um scanner. Declare o que foi testado e o que continua fora do escopo.

Acessibilidade em sites criados por IA melhora quando deixa de ser um pedido genérico no fim do prompt. Defina critérios, teste a tarefa real, corrija barreiras pequenas e verificáveis e mantenha a evidência junto da versão publicada. O agente acelera inspeção e correção; pessoas e padrões continuam definindo se a experiência atende quem precisa usá-la.