Comece pelas tarefas e uma arquitetura de informação enxuta
Arquitetura de informação é como conteúdos e funções são agrupados, nomeados e conectados. Liste tarefas de visitantes e mapeie a página de início, a próxima página e o estado final bem‑sucedido para cada tarefa. Isso mostra se um item de menu é útil ou um rótulo interno que visitantes precisam decodificar. Mantenha a navegação primária focada nas seções que iniciam essas tarefas.
Navegação não é um mapa do site. GOV.UK recomenda listar seções de alto nível úteis em vez de cada parte de um serviço. Quando uma jornada exige uma ordem obrigatória, mostre‑a no conteúdo ou em uma lista de tarefas em vez de fazer as pessoas inferirem pela navegação global.
Coloque páginas juntas quando visitantes esperam a mesma resposta ou tarefa, não porque uma equipe seja dona delas.
Use páginas de entrada e links contextuais para detalhes em vez de um cabeçalho denso.
Use rótulos que prevejam o destino
Um rótulo é uma promessa sobre o que vem a seguir. Prefira nomes familiares como “Preços”, “Documentação”, “Obter suporte” ou “Gerenciar conta” quando corresponderem ao destino. Evite rótulos vagos como “Recursos” ou “Explorar”, salvo quando visitantes puderem prever o conteúdo. Mantenha redação e ordem consistentes.
O Google aconselha texto de link conciso e relevante, compreensível fora de contexto. “Clique aqui” genérico e links recheados de palavras‑chave não ajudam. Dê a um controle somente com ícone um nome acessível que descreva sua ação.
Use “Ver planos” em vez de “Saiba mais” quando o destino for planos.
Marque o destino ativo visualmente e programaticamente; a W3C descreve aria-current=page para a página exibida.
Torne os destinos rastreáveis e estruturalmente claros
Um destino de navegação normalmente deve ser uma âncora HTML com um href que resolva para um endereço web real. O Google diz que geralmente consegue rastrear esse formato, inclusive âncoras inseridas dinamicamente quando o markup renderizado mantém essa estrutura. Um manipulador de clique ou atributo customizado sozinho não é substituto confiável. Inspecione o resultado renderizado, não só o código da framework.
Use estrutura semântica ao redor da navegação principal. A W3C recomenda um elemento nav e, para navegação comum do site, uma lista. Se uma página tem várias regiões de navegação, rotule cada uma para que um usuário de leitor de tela possa distinguir navegação primária de rodapé ou navegação local.
Confirme que destinos importantes em desktop e mobile têm âncoras e valores href após a renderização do cliente.
A Inspeção de URL fornece informação de rastreio, indexação e entrega pelo Google; não prova que visitantes conseguem encontrar uma página.
Projete o menu móvel como uma interação completa
Navegação responsiva pode colapsar, mas os destinos que permanecem devem conservar mesma redação, ordem e destino entre tamanhos de tela. A W3C permite colapsar ou ocultar itens de subnavegação enquanto pede consistência. Não torne uma rota crítica exclusiva para desktop porque o cabeçalho está lotado; realoque material de baixa prioridade ou reconsidere a hierarquia.
Para um menu que mostra/oculta, use um botão para controlar o grupo de links e comunique se ele está aberto. O exemplo disclosure-navigation da W3C usa aria-expanded e aria-controls e documenta Tab, Shift+Tab e Escape. É instrucional, então teste seu componente com as combinações que seu público usa.
Quando uma página pai e seus links filhos forem ambos necessários, distinga o link da página do controle que o expande.
Qualquer coisa revelada por hover do ponteiro deve ser descobrível com foco do teclado e por toque.
Suporte orientação e navegação por teclado
Acesso por teclado não é um detalhe final. O WCAG 2.1 Success Criterion 2.1.1 exige que funcionalidade seja operável via interface de teclado, exceto para entrada dependente de caminho. Em um cabeçalho, visitantes devem poder Tabular pelos controles, ver o foco, ativar links e botões, e sair sem ficar presos.
Links repetidos no cabeçalho podem tornar páginas lentas de percorrer. Um link de pular (skip link) próximo ao início dá aos usuários de teclado uma rota até o conteúdo principal. GOV.UK explica que ele fica visualmente oculto até ser ativado pelo teclado. Teste se ele aterrissa em um destino significativo.
Não remova o indicador de foco do navegador sem uma alternativa clara que permaneça visível ao aumentar o zoom.
Use Tab, Shift+Tab, Enter, Space e Escape do cabeçalho até a página de destino.
Teste encontrabilidade antes e depois da publicação
Peça a pessoas representativas que completem uma tarefa realista, como encontrar orientações de cancelamento ou comparar planos. Observe onde esperam ir, quais rótulos interpretam errado e se recorrem à busca porque a navegação falhou. Não conduza até o rótulo pretendido. Registre cada barreira e a menor mudança provável para removê‑la.
Emparelhe testes de tarefa com verificações técnicas. As Easy Checks da W3C recomendam testar sem mouse, incluindo visibilidade do foco, ordem de tabulação, armadilhas de teclado e dropdowns. Repita tarefas principais em larguras estreitas e tamanhos de texto maiores. Verificações automatizadas podem sinalizar problemas de marcação, mas não estabelecem que um rótulo faça sentido.
Registre o endpoint pretendido e o dispositivo ou método de entrada suportado antes do teste.
Teste a rota antiga e a nova com as mesmas tarefas em vez de confiar na preferência de stakeholders.
Trate mudanças de navegação como releases sensíveis à disponibilidade
Um cabeçalho pode carregar enquanto um caminho crítico está efetivamente indisponível: checkout, login, rota de suporte ou página de documentação pode estar atrás de um estado quebrado, link desatualizado ou redirecionamento errado. Antes da publicação, inventarie destinos críticos, teste rotas em desktop e mobile e confirme que links renderizados alcançam a página pretendida. Use ambientes autorizados para caminhos autenticados ou regionais.
O papel do SIU é remediação proativa: execute um pré‑voo, verifique caminhos essenciais após a implantação e torne a correção reversível. Mantenha uma configuração de menu versionada, nomeie a pessoa que pode restaurá‑la e valide caminhos restaurados. Isso limita o impacto do release; não substitui pesquisa de usabilidade ou monitoramento de status ao vivo.
Bloqueie a publicação quando um destino crítico estiver ausente, errado ou inacessível por teclado e toque.
Documente a configuração anterior, o responsável, o gatilho e os passos de validação antes de reestruturar.