Breadcrumbs parecem apenas uma fileira de links separados por barras. Quando a hierarquia vem de uma rota gerada, porém, é comum encontrar nomes repetidos, página atual apontando para si mesma, separadores anunciados pelo leitor de tela e caminhos que mudam entre desktop e celular.

Uma trilha acessível mostra onde a página está na estrutura do site e permite subir pelos níveis reais. Ela não registra cada clique da sessão e não substitui o menu principal. Este guia mostra como modelar a hierarquia, escrever o HTML e validar as rotas depois da publicação.

Modele a hierarquia antes do componente

O padrão de breadcrumb da W3C descreve uma lista de links para as páginas ancestrais, em ordem hierárquica, seguida pela localização atual.

Isso é diferente do histórico do navegador. Se uma pessoa chegou por busca, campanha ou link direto, o breadcrumb deve mostrar a mesma posição na arquitetura. Não monte a trilha com os últimos cliques da sessão.

Antes de escrever o componente, registre para cada tipo de página:

  • qual é a raiz relevante;
  • quais níveis têm página e URL próprias;
  • qual rótulo humano representa cada segmento;
  • o que acontece com categorias removidas ou renomeadas;
  • como a trilha muda em sites com mais de um caminho possível.

Um slug não é um rótulo pronto. guias-acessibilidade pode virar “Guias de acessibilidade”, com acentos e capitalização editorial. Busque esse nome na mesma fonte usada pelo título da página, em vez de transformar a URL por substituição de hífens.

Uma estrutura curta resolve a maior parte do contrato:

<nav aria-label="Breadcrumb">
<ol>
<li><a href="/">Início</a></li>
<li><a href="/guias/">Guias</a></li>
<li><span aria-current="page">Acessibilidade</span></li>
</ol>
</nav>

nav cria uma região de navegação. O rótulo permite distingui-la do menu principal, do sumário e do rodapé. A lista ordenada comunica a sequência. Os ancestrais são links normais, com destinos que funcionam sem JavaScript.

Se o nome “Breadcrumb” não fizer sentido para o público do produto, use “Caminho da página” ou outro rótulo curto e consistente. Evite incluir a palavra “navegação” no nome, pois a tecnologia assistiva já anuncia o tipo da região.

O guia sobre títulos e regiões ajuda a conferir se todas as navegações da página têm nomes distintos.

O último item representa a página aberta. Quando ele é texto, aria-current="page" é opcional segundo o padrão da W3C, mas pode tornar o estado explícito. Quando ele continua sendo um link, use aria-current="page".

Prefira texto sem link quando clicar no item apenas recarregaria a mesma URL. Se o produto tem uma razão concreta para manter o link, preserve o destino canônico e marque o estado atual.

Use apenas um item atual na trilha. Não aplique aria-current em todos os ancestrais nem troque o valor por true sem necessidade. O valor page informa exatamente o tipo de estado.

O texto final deve combinar com o h1 ou ser uma versão curta e inequívoca. Se o título diz “Como testar uma landing page com leitor de tela”, um item chamado apenas “Artigo” não orienta ninguém.

Esconda separadores da árvore de acessibilidade

Barras, setas e chevrons explicam visualmente a passagem entre níveis. A estrutura da lista já comunica essa relação para tecnologia assistiva. Anunciar “Início, barra, Guias, barra, Acessibilidade” acrescenta ruído.

Gere separadores com CSS ou marque o elemento decorativo como aria-hidden="true":

<li>
<a href="/guias/">Guias</a>
<span aria-hidden="true">/</span>
</li>

Não coloque o separador dentro do nome do link. Não use uma imagem com texto alternativo “seta”. Se a direção visual muda em idiomas da direita para a esquerda, trate isso no estilo, sem mudar a ordem lógica dos itens.

Confirme contraste e visibilidade do estado atual sem depender só de cor. O item pode usar peso, sublinhado, fundo ou outra diferença que continue perceptível em alto contraste.

Preserve nomes, URLs e barras finais

Breadcrumbs gerados por rota quebram quando o componente confunde caminho técnico com arquitetura editorial. Um segmento pode ser um ID, um filtro, uma localização ou uma etapa sem página própria.

Cada item precisa vir de dados que relacionem nome e URL. Evite:

  • criar link para um nível que retorna 404;
  • expor UUID, slug interno ou parâmetro de campanha;
  • duplicar o mesmo item por causa de barra final;
  • apontar o ancestral para uma URL redirecionada;
  • incluir filtros temporários como se fossem categorias permanentes;
  • misturar domínios ou idiomas sem indicar a mudança.

Se uma categoria não tem página, decida se ela deve aparecer como texto ou sair da trilha. Não invente um href="#". O artigo sobre links quebrados traz um roteiro para testar cada destino servido.

Trate telas estreitas sem apagar o contexto

Uma trilha longa pode ultrapassar a largura disponível. Não reduza a fonte e os alvos até caber. Também não esconda todos os ancestrais no celular e deixe apenas o título atual, pois isso remove a função de orientação.

Algumas opções são:

  • permitir quebra em mais de uma linha;
  • oferecer rolagem horizontal com foco sempre visível;
  • abreviar níveis intermediários com um controle que os revela;
  • mostrar a raiz, o ancestral imediato e a página atual;
  • encurtar rótulos sem torná-los ambíguos.

Se usar um controle para revelar itens, ele precisa de nome, estado expandido e comportamento de teclado. Os itens escondidos devem sair da leitura e da ordem de foco até a abertura.

Teste zoom de 200% e 400%, largura equivalente a 320 pixels CSS e títulos reais. O roteiro de zoom e reflow ajuda a encontrar corte, sobreposição e rolagem em duas dimensões.

Não confunda HTML visível com dados estruturados

O breadcrumb visível orienta pessoas e oferece links. BreadcrumbList descreve a hierarquia para mecanismos de busca. Um não substitui o outro.

A documentação do Google sobre BreadcrumbList orienta adicionar as propriedades exigidas, validar o resultado e testar algumas URLs publicadas. Os dados estruturados precisam representar a mesma hierarquia que aparece na página.

Não marque uma trilha diferente na esperança de controlar o resultado de busca. Também não prometa exibição especial. O Google deixa claro que dados válidos não garantem um recurso visual nos resultados.

Se o site já gera JSON-LD por layout, atualize a fonte compartilhada em vez de colar blocos diferentes em cada página. Depois valide uma rota de cada modelo com o Rich Results Test e confira o HTML servido.

Teste a trilha em todos os modelos de página

Uma rota correta não prova o componente. Monte uma matriz:

Situação Evidência esperada
página de primeiro nível trilha curta, sem item vazio ou duplicado
página profunda todos os ancestrais reais aparecem na ordem correta
página atual último item tem nome coerente e estado identificável
teclado cada link recebe foco visível na ordem da lista
leitor de tela região, lista, links e página atual são compreensíveis
tela estreita e zoom nenhum item ou foco fica cortado
categoria removida trilha não aponta para 404
rota com parâmetro ou locale rótulos e destinos continuam canônicos

Percorra os links e compare a trilha com menu, URL, h1, canonical e dados estruturados. A inconsistência costuma aparecer quando esses elementos usam fontes diferentes.

Dê ao agente uma fonte de verdade

Revise os breadcrumbs deste site sem publicar ainda.
Escopo:
- fonte e commit: [referência]
- modelos de página: [lista]
- mapa de nomes e URLs: [fonte]
Para cada modelo:
1. Derive a trilha da hierarquia editorial, não do histórico de cliques.
2. Use nav com nome distinto, lista ordenada e links reais para ancestrais.
3. Marque a página atual e alinhe seu rótulo ao h1.
4. Remova separadores decorativos da árvore de acessibilidade.
5. Valide URLs, barras finais, redirects, locales e categorias removidas.
6. Sincronize HTML visível e BreadcrumbList quando houver dados estruturados.
7. Teste teclado, leitor de tela, zoom e telas estreitas.
8. Preserve analytics, canonical e regras de roteamento.
Entregue a matriz de rotas, o diff e as evidências antes de publicar.

O mapa impede que o agente invente nomes a partir de slugs ou transforme todo segmento técnico em link.

Reteste a versão publicada

Depois da aprovação, siga a documentação de Publicação: publique uma nova Version, acompanhe o deploy e abra uma URL de cada modelo. Percorra todos os ancestrais no HTML servido.

Confira também redirects, canonical, locale, dados estruturados e comportamento depois da hidratação. Se a build criar uma trilha diferente da fonte ou a URL final mudar um ancestral, corrija a origem e republique o mesmo Site. O breadcrumb está pronto quando orienta, navega e descreve a mesma hierarquia em todas as rotas.