Um site criado por IA pode parecer organizado na tela e continuar sendo apenas uma pilha de divs. O visitante que usa mouse talvez conclua a tarefa. Já o navegador, um leitor de tela, um modo de leitura ou uma automação de QA recebe pouca informação sobre o que é navegação, conteúdo principal, botão, lista ou formulário.

Revisar HTML semântico não significa trocar todas as tags por elementos “mais bonitos”. Significa verificar se a estrutura programática descreve a mesma página que a interface visual apresenta.

Este guia mostra como inspecionar o HTML gerado, priorizar falhas e corrigir a fonte antes de publicar. Depois, a revisão continua na URL real, porque o arquivo certo ainda pode ser substituído por uma build antiga ou chegar incompleto ao pacote.

O que HTML semântico resolve

HTML semântico usa o elemento que representa a função real do conteúdo. Um link navega. Um botão executa uma ação. Uma lista agrupa itens relacionados. Um heading nomeia uma seção. header, nav, main, aside e footer identificam regiões da página.

A orientação da MDN sobre HTML e acessibilidade resume a ideia como usar o elemento certo para o trabalho. Elementos nativos já carregam comportamentos, significado e suporte de teclado que precisam ser reconstruídos quando tudo vira um componente genérico.

A W3C recomenda identificar as regiões da página para que navegadores e tecnologias assistivas reconheçam navegação, conteúdo principal e áreas complementares. Isso também torna a fonte mais legível para quem mantém o site.

Semântica não garante sozinha acessibilidade, SEO ou conversão. Ela cria uma base programática coerente sobre a qual esses trabalhos podem ser avaliados.

Defina o escopo antes de trocar tags

Comece registrando:

fonte e versão:
build ou arquivo revisado:
páginas incluídas:
tarefa principal:
componentes interativos:
framework e limites do projeto:
responsável pela aprovação:

Não autorize uma reescrita ampla a partir de um alerta genérico. Uma troca de elemento pode alterar estilo, evento, formulário ou comportamento de navegação. Peça primeiro um inventário com elemento, função observada, impacto e menor correção possível.

Classifique cada achado:

Severidade Exemplo Decisão
bloqueante CTA visual não pode ser acionado como controle corrigir antes de publicar
alta página sem main, formulário sem rótulos, ordem incoerente corrigir na versão atual
média lista visual criada como sequência de blocos genéricos corrigir com o componente responsável
baixa região complementar sem marcação, mas ainda compreensível registrar se não couber na entrega atual

Se a troca exige escolher outro destino, texto ou comportamento comercial, pare. Isso é decisão de produto ou conteúdo, não correção semântica.

Check 1: identifique as regiões da página

Uma landing page costuma ter:

  • um cabeçalho global;
  • uma navegação;
  • um conteúdo principal;
  • seções temáticas;
  • conteúdo complementar, quando existir;
  • um rodapé.

No HTML, espere uma estrutura próxima desta:

<header>
  <nav aria-label="Principal">...</nav>
</header>


<main id="conteudo">
  <h1>...</h1>
  <section aria-labelledby="beneficios">...</section>
</main>


<footer>...</footer>

Não adicione role="main" a um <main> apenas para repetir o significado nativo. A técnica H101 da W3C explica que navegadores modernos expõem os landmarks relacionados aos elementos semânticos sem exigir um papel redundante.

Quando houver mais de uma navegação, diferencie cada uma com nome acessível, como “Principal”, “Rodapé” ou “Neste artigo”. Um conjunto de links não precisa virar nav se não representa uma área de navegação relevante.

Também não use section como substituto universal de div. A W3C descreve section como um agrupamento temático, normalmente identificado por um heading. Agrupamentos puramente visuais continuam podendo usar um contêiner genérico.

Check 2: revise headings como um sumário

Extraia H1, H2 e H3 e leia apenas essa sequência. Ela deve explicar a estrutura da página.

Confirme:

  • o H1 identifica o assunto principal;
  • cada seção relevante tem um heading descritivo;
  • a hierarquia representa relação, não tamanho de fonte;
  • headings não são usados para frases decorativas;
  • texto visualmente grande não ficou sem significado quando realmente abre uma seção;
  • componentes repetidos não criam dezenas de headings sem utilidade.

Não existe benefício em inserir palavras-chave em toda heading. O objetivo é orientação. A aparência pertence ao CSS; o nível pertence à estrutura.

Uma auditoria automática consegue contar headings e detectar saltos. Ela não decide se “Resultados” descreve aquela seção ou se dois blocos pertencem ao mesmo assunto.

Use:

  • <a href="..."> quando a ação leva a outro endereço ou ponto da página;
  • <button type="button"> quando a ação altera a interface;
  • <button type="submit"> quando envia um formulário.

Evite:

<div class="botao" onclick="abrirModal()">Ver planos</div>

Prefira:

<button type="button" class="botao" aria-haspopup="dialog">Ver planos</button>

O elemento nativo recebe foco e comportamento de teclado esperado. Ainda é necessário implementar o modal corretamente, mas a base não começa simulando um botão.

Não converta automaticamente todo CTA em link. “Baixar o guia” pode iniciar um download, navegar para um arquivo ou abrir um formulário; confirme o comportamento aprovado antes de escolher o elemento.

Revise também o texto dos links. “Clique aqui” repetido perde sentido fora do parágrafo. O nome deve indicar o destino ou a ação.

Check 4: marque listas, tabelas e citações pelo significado

Cards podem formar uma lista mesmo quando aparecem em grid. Passos de um processo podem formar uma lista ordenada. Recursos sem ordem podem usar uma lista não ordenada. Perguntas e respostas não viram tabela apenas porque têm duas colunas.

Use tabelas somente para dados que dependem da relação entre linhas e colunas. Inclua cabeçalhos apropriados e preserve leitura em telas pequenas.

Para depoimentos ou citações, diferencie:

  • a fala citada;
  • a pessoa ou fonte;
  • o contexto autorizado.

Semântica não valida a veracidade do depoimento. O checklist de QA para landing pages criadas com IA cobre prova, autorização e aderência ao briefing.

Check 5: trate imagens e ícones como conteúdo ou decoração

Uma tag correta ainda pode carregar um nome ruim.

  • imagem informativa: alt comunica a informação relevante;
  • imagem decorativa: alternativa vazia evita repetição;
  • ícone dentro de botão: o controle recebe um nome acessível;
  • imagem com legenda: use uma relação coerente entre figura e texto;
  • logo com link para a home: o nome deve permitir entender o destino.

Não copie o nome do arquivo para o alt. Também não transforme o texto alternativo em lista de palavras-chave.

O guia sobre otimização de imagens antes da publicação complementa esta revisão com dimensões, formato, compressão, carregamento e caminhos no pacote.

Check 6: revise formulários na estrutura e no fluxo

Para cada campo, confira:

  • rótulo associado programaticamente;
  • tipo de input coerente;
  • nome e propósito compreensíveis;
  • instruções próximas;
  • obrigatoriedade comunicada além da cor;
  • mensagem de erro ligada ao campo;
  • agrupamentos relacionados com estrutura adequada;
  • botão de envio real.

Placeholder não substitui rótulo. Ele desaparece durante o preenchimento e pode mostrar exemplo sem nomear o campo.

Depois da estrutura, execute o fluxo completo. O artigo sobre como testar formulários de landing pages criadas por IA cobre validação, falha de rede, sucesso, destino dos dados e reteste na URL.

Check 7: use ARIA para completar, não para disfarçar

ARIA comunica nomes, estados e relações que o HTML nativo não expressa sozinho. Não deve transformar um componente incompleto em uma promessa falsa para tecnologias assistivas.

Antes de adicionar um atributo, responda:

  1. existe um elemento HTML nativo com essa função?
  2. o comportamento de teclado foi implementado?
  3. o estado visual acompanha o estado programático?
  4. o nome acessível corresponde ao texto visível?
  5. o componente foi testado no navegador?

Um div role="button" ainda precisa de foco e ativação por teclado. Um aria-expanded="true" precisa mudar quando a região fecha. Um modal marcado como modal precisa gerenciar foco e impedir interação com o fundo conforme o padrão escolhido.

Evite adicionar ARIA em massa porque um scanner sugeriu. Corrija primeiro o elemento e o comportamento.

Audite a fonte e o HTML produzido

Em projetos com framework, o componente-fonte não é necessariamente o documento final. Faça duas leituras:

  1. fonte: encontra a origem e permite uma correção sustentável;
  2. HTML gerado: confirma o que o navegador realmente recebe.

Procure padrões como:

div ou span com onclick
elementos com tabindex positivo
outline removido sem substituição
headings escolhidos por estilo
inputs sem label associado
navs sem nome quando existem vários
ARIA com estado fixo
listas visuais sem elemento de lista

Depois abra a página e confira árvore de acessibilidade, ordem de leitura e comportamento. Um lint verde não prova que o componente comunica a intenção correta.

Corrija em lotes pequenos

Uma sequência segura:

  1. landmarks e conteúdo principal;
  2. headings;
  3. links, botões e CTAs;
  4. formulários;
  5. listas, tabelas e conteúdo estruturado;
  6. nomes e estados acessíveis;
  7. regressão visual e de teclado.

Para cada lote:

  • preserve copy, destino, tracking e estilo aprovado;
  • execute os checks do projeto;
  • compare o HTML gerado;
  • percorra a tarefa principal;
  • revise o diff antes de avançar.

Não aceite uma “limpeza semântica” que muda dezenas de componentes sem evidência de regressão.

Prompt copiável para o agente

Revise o HTML semântico deste site antes da publicação.


Escopo:
- fonte e versão: [repositório, branch e commit]
- build ou arquivo: [caminho]
- páginas: [lista]
- tarefa principal: [objetivo]


1. Inventarie landmarks, headings, links, botões, listas, imagens e formulários.
2. Compare a função visual e interativa com o elemento HTML usado.
3. Classifique achados por severidade e informe arquivo, elemento, impacto
   e menor correção possível.
4. Prefira HTML nativo; não adicione ARIA redundante ou sem comportamento.
5. Preserve copy, estilo, tracking, destinos e regras comerciais.
6. Não edite ainda. Mostre o plano e os pontos que exigem decisão humana.

Depois da aprovação, peça correções por lote, checks do projeto, diff e teste da tarefa principal. Complete com o guia de navegação por teclado para verificar a operação real dos controles.

Publique e valide a URL real

O contrato de Publicação serve os arquivos dentro de public/. Antes do deploy, confirme que o HTML revisado pertence à Version atual e que todos os assets referenciados existem.

Depois do deploy:

  1. abra a URL final;
  2. confirme título, idioma, H1 e conteúdo principal;
  3. inspecione landmarks e headings no HTML servido;
  4. teste CTA, links e formulário;
  5. percorra a página com teclado;
  6. registre versão, checks e exceções.

Se houver correção, preserve o Site e publique outra versão no mesmo endereço. O guia de republicação com agente de IA mostra como manter Site ID, slug e URL.

HTML semântico é uma correspondência entre significado, código e comportamento. Quando essa correspondência existe, o site fica mais previsível para pessoas, navegadores e ferramentas. O agente acelera o inventário e as mudanças; a revisão humana continua necessária para confirmar que a estrutura descreve a página real.