Como revisar títulos e regiões de uma landing page criada por IA

Uma landing page criada por IA pode parecer organizada e ainda chegar ao navegador como uma sequência de div. O título principal é um parágrafo grande, cada card usa h4 porque esse tamanho combinou com o layout, e três áreas diferentes se chamam “Navegação”. Quem enxerga a composição deduz a hierarquia pela posição e pelo tamanho. Quem navega por títulos ou regiões recebe outra página.

Títulos e landmarks formam um mapa do documento. Eles ajudam uma pessoa a saltar para o conteúdo principal, percorrer as seções e distinguir a navegação do topo daquela que aparece no rodapé. Este guia mostra como extrair esse mapa, corrigir a estrutura sem alterar a aparência e testar a versão publicada.

O mapa precisa existir no HTML

A orientação da W3C sobre estrutura de página recomenda títulos aninhados de acordo com a relação entre as seções e regiões identificadas com HTML ou WAI-ARIA. Isso atende necessidades diferentes:

• títulos descrevem a hierarquia do conteúdo;
• regiões identificam áreas recorrentes ou importantes da interface;
• um link de salto oferece um caminho curto até o conteúdo principal.

Na WCAG 2.2, essas decisões se relacionam com Informações e relações, Ignorar blocos e Cabeçalhos e rótulos.

Não basta aplicar fonte grande e peso alto a um texto. A relação precisa estar disponível no HTML que o navegador entrega.

Comece com dois inventários

Abra a rota principal e registre a lista de títulos na ordem do DOM. Depois registre as regiões expostas na árvore de acessibilidade.

Uma tabela curta já revela boa parte dos problemas:

Faça o inventário no HTML produzido pela build em vez de se limitar ao componente. Slots, layouts e bibliotecas podem mudar a ordem ou adicionar títulos que não aparecem no arquivo da página.

O guia de HTML semântico ajuda a revisar elementos além da estrutura de navegação. Para ouvir o resultado completo, use também o roteiro de teste com leitor de tela.

Check 1: dê à página um título principal claro

O h1 deve identificar o assunto daquela rota. Em uma landing page de produto, ele costuma corresponder à promessa principal, não ao nome genérico da empresa nem a uma frase oculta criada só para satisfazer um scanner.

<main id="conteudo">
  <h1>Envie propostas comerciais sem montar PDFs à mão</h1>
  <p>Crie, aprove e acompanhe cada proposta no mesmo fluxo.</p>
</main>

Confira se o texto ainda faz sentido quando aparece sozinho numa lista de títulos. “A solução completa” diz pouco sem o parágrafo seguinte. “Envie propostas comerciais sem montar PDFs à mão” identifica a página e antecipa o resultado.

Mais de um h1 não é automaticamente uma falha de conformidade, mas costuma piorar o mapa de uma landing page curta. Prefira um título principal inequívoco, salvo quando a arquitetura do produto tem uma razão testada para outro modelo.

Check 2: aninhe pela relação, não pelo tamanho

A orientação da W3C sobre headings recomenda níveis que representem a organização. Um h3 abre uma subseção do h2 anterior. Ele não deve aparecer porque o estilo padrão do h2 ficou grande demais.

<h1>Gestão de propostas comerciais</h1>

<h2>Como funciona</h2>
<h3>Criação</h3>
<h3>Aprovação</h3>

<h2>Planos</h2>

É normal voltar de h3 para h2 quando uma subseção termina. O problema é avançar de h2 para h4 sem que exista um nível intermediário coerente.

Corrija a apresentação no CSS. Não troque o elemento para obter um tamanho visual:

.section-title {
  font-size: clamp(1.75rem, 4vw, 3rem);
}

Depois da mudança, confira a hierarquia em desktop e mobile. Reordenar blocos só com CSS pode criar uma sequência visual diferente da ordem do DOM. O guia de zoom e reflow cobre essa comparação em largura estreita.

Check 3: use regiões nativas antes de adicionar roles

Elementos como header, nav, main, aside e footer podem expor landmarks quando usados no contexto correto. A orientação da W3C sobre regiões mostra como essas áreas dão pontos de navegação para tecnologias assistivas.

Uma estrutura básica pode ser simples:

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

<main id="conteudo">...</main>

<footer>
  <nav aria-label="Rodapé">...</nav>
</footer>

Não duplique a semântica sem necessidade. <nav role="navigation"> repete uma função que o elemento já possui. <main role="main"> faz o mesmo. O excesso não melhora a navegação e aumenta a chance de um atributo ficar incompatível com o elemento.

Também evite transformar cada bloco visual em região. Uma página com dezenas de landmarks deixa de oferecer atalhos e vira outra lista longa. Reserve regiões para áreas que merecem identificação e acesso direto.

Check 4: diferencie regiões repetidas

Duas navegações precisam de nomes que expliquem sua finalidade. A W3C recomenda rótulos de região curtos e distintos quando há mais de uma região do mesmo tipo.

<nav aria-label="Principal">...</nav>
<nav aria-label="Documentação">...</nav>
<nav aria-label="Rodapé">...</nav>

Se uma região já tem um título visível, relacione os dois:

<aside aria-labelledby="artigos-relacionados">
  <h2 id="artigos-relacionados">Artigos relacionados</h2>
  ...
</aside>

Use aria-labelledby quando o texto visível é a melhor identificação. Isso evita manter duas copies separadas. O artigo sobre nomes acessíveis de links e botões aplica o mesmo princípio aos controles.

Check 5: ofereça um link de salto funcional

Um visitante que usa teclado não deveria atravessar logo, menu e todos os atalhos do header em cada rota antes de chegar ao conteúdo.

<a href="#conteudo" class="skip-link">Ir para o conteúdo</a>

<header>...</header>
<main id="conteudo">...</main>

O link pode ficar fora da tela até receber foco, mas precisa aparecer de forma legível quando a pessoa usa Tab. Teste se:

• o foco chega ao link no começo da página;
• o link fica visível sem ser cortado por overflow;
• a ativação leva foco ou leitura ao conteúdo principal;
• o destino tem ID único;
• um header fixo não cobre o primeiro título.

Não confunda tabindex="-1" no destino com uma regra universal. Alguns padrões e navegadores tratam o fragmento corretamente sem ele. Teste a combinação real de navegador e tecnologia assistiva antes de acrescentar gerenciamento de foco.

Check 6: não esconda títulos úteis para consertar o outline

Agentes às vezes inserem títulos invisíveis em todo section ou removem títulos do HTML para simplificar o visual. As duas respostas atacam o sintoma.

Um título visualmente oculto pode ser válido quando a região precisa de um nome que não cabe no desenho. Ele não deve repetir palavras genéricas, nem criar uma hierarquia paralela que só existe para leitores de tela.

Pergunte em cada caso:

• a seção precisa mesmo ser uma seção identificável?
• existe um título visível que já comunica o assunto?
• o rótulo oculto ajuda a escolher a região numa lista?
• a ordem continua lógica sem depender da posição visual?

Se a resposta for não, simplifique a estrutura em vez de acumular marcação.

Automação ajuda a encontrar, mas não avalia o mapa

Linters e scanners encontram ausência de main, níveis pulados, IDs duplicados e regiões sem nome. Eles não sabem se “Resultados” descreve métricas, depoimentos ou casos de clientes. Também não percebem que a ordem dos títulos conta uma história diferente da página visual.

Combine quatro verificações:

1. lista de títulos na ordem do DOM;
2. lista de landmarks na árvore de acessibilidade;
3. navegação somente por teclado;
4. leitura rápida da página sem estilos.

Se o mapa não deixa claro onde você está e qual seção vem depois, a estrutura ainda precisa de trabalho.

Prompt copiável para o agente

Revise a estrutura de títulos e regiões desta landing page sem publicar ainda.

Escopo:
- fonte e commit: [referência]
- rotas: [lista]
- tarefa principal de cada rota: [objetivo]

1. Extraia títulos na ordem do DOM, com nível e texto.
2. Extraia landmarks, nomes e elementos que os originam.
3. Marque títulos ausentes, níveis incoerentes, regiões duplicadas e rótulos genéricos.
4. Confirme um conteúdo principal e um link de salto funcional.
5. Prefira HTML nativo e preserve copy, layout, tracking e comportamento.
6. Mostre o inventário e o plano antes de alterar títulos aprovados.
7. Depois da correção, teste teclado, árvore de acessibilidade e build.

Peça que o agente entregue evidência antes e depois. Uma resposta dizendo apenas “sem problemas de acessibilidade” não informa quais títulos, regiões e caminhos foram examinados.

Publique e repita o teste na URL final

A documentação de Publicação separa arquivos salvos na Session da Version servida. Depois de aprovar as correções, o agente deve publicar, acompanhar o estado do deploy e abrir a URL resultante.

Na versão pública:

• percorra o link de salto e o menu por teclado;
• liste títulos e regiões novamente;
• confirme a ordem após scripts e hidratação;
• teste pelo menos uma largura estreita;
• compare o conteúdo com a Version aprovada.

Se o HTML servido divergir, corrija a fonte e republique o mesmo Site. A revisão termina quando o mapa da URL pública corresponde ao conteúdo que a pessoa vê.