Navegação por teclado: teste menus e controles do seu site
Resposta direta: teste cada fluxo importante do site sem mouse: use Tab e Shift+Tab para percorrer links e controles, Enter ou Espaço para ativá-los conforme o elemento, e setas quando o componente usar navegação própria. A ordem deve fazer sentido, o foco precisa ficar visível e nenhuma interação pode prender a pessoa em um menu, modal ou widget. Esse teste manual simples encontra barreiras que uma inspeção visual ou ferramenta automática pode não revelar.
Teclado é uma forma de entrada essencial para pessoas que não usam mouse, incluindo algumas pessoas com deficiência motora ou visual, usuários de leitores de tela, quem prefere atalhos e quem está temporariamente impossibilitado de usar um dispositivo apontador. Um site que só funciona ao clicar pode esconder opções, tornar um formulário impossível de concluir ou interromper a jornada exatamente antes do contato.
As Web Content Accessibility Guidelines (WCAG) 2.2 descrevem critérios para que funcionalidades sejam operáveis por teclado, para que o foco seja visível e para que a sequência preserve sentido e operação. Usar estas diretrizes é um processo de avaliação, não uma certificação automática. A conformidade depende de todos os requisitos aplicáveis e das páginas e fluxos considerados.
Na criação de sites da Open Leads, navegação previsível faz parte de uma experiência utilizável. A seguir, veja um método para mapear o percurso, testar componentes e corrigir problemas comuns. Explore os serviços de criação de sites e outros conteúdos no blog da Open Leads.
Prepare um teste sem mouse
Abra a página em um navegador comum, coloque o cursor fora dos controles e use o teclado. Tab costuma mover o foco adiante; Shift+Tab retorna. Enter ativa muitos links e botões; Espaço é comum para botões e caixas de seleção. As teclas de seta podem mover-se dentro de menus, listas e outros widgets, conforme o padrão adotado. Não assuma que toda tecla opera todos os elementos da mesma forma.
Teste um percurso representativo, não somente a página inicial. Inclua menu, conteúdo, âncoras, controles de expansão, modal, formulário, confirmação, mensagens de erro, busca e ações de contato. Em sites de serviço, verifique o caminho desde a navegação até a página de serviço e o próximo passo. Repita em resoluções diferentes se o menu muda para uma versão móvel ou abre um painel lateral.
Observe o indicador de foco
Em cada passo, identifique claramente qual elemento está ativo. A diretriz WCAG 2.4.7 exige que uma interface operável por teclado ofereça um modo em que o foco seja visível. Um contorno pode cumprir esse papel quando tem contraste suficiente e não é recortado, coberto por cabeçalho fixo ou confundido com o estado de seleção. Remover o outline sem alternativa clara deixa a pessoa sem orientação.
Ordem de foco é parte da hierarquia
A sequência não precisa reproduzir cada detalhe visual da página, mas precisa preservar significado e operação. Em um cabeçalho, pode fazer sentido visitar o link para pular ao conteúdo, a marca, a navegação e os controles principais em ordem coerente. Se a apresentação usa colunas, o caminho não deve alternar de modo imprevisível entre blocos distantes. A pessoa deve conseguir prever onde estará depois.
Evite usar valores positivos de tabindex para forçar uma sequência artificial. Em geral, uma ordem natural do documento e elementos semânticos nativos são mais robustos. Uma div transformada em botão pode exigir nome, papel, estado, ativação por teclado e gerenciamento de foco; um botão HTML nativo já oferece muitas dessas funções. Use elementos com semântica correta, e só construa comportamento customizado quando a interação realmente exigir.
Não deixe ninguém preso
Menus, diálogos e widgets podem usar padrões próprios, mas a pessoa precisa compreender como entrar, navegar e sair. Um modal deve mover ou gerenciar o foco com coerência, oferecer um meio claro de fechar e não deixar o foco escapar para controles ocultos atrás dele. Um menu aberto não deve roubar o foco de forma inesperada nem deixar a tecla Escape sem efeito quando esse é o comportamento definido pelo componente.
WCAG 2.1.2 proíbe uma armadilha de teclado: se o foco entra em um componente, deve haver um caminho padrão para sair ou uma instrução clara sobre como fazê-lo. Confira widgets de terceiros, players, mapas, calendários e ferramentas incorporadas; a equipe pode não controlar o código, mas continua responsável por avaliar o uso dentro de sua experiência.
Links, botões e controles devem explicar sua função
Um link deve conduzir a um destino; um botão realiza uma ação. O texto precisa permitir que a pessoa entenda o propósito em contexto. Evite uma página cheia de links genéricos “saiba mais” sem identificação ao redor, ou controles sem rótulo perceptível. O critério de propósito de link da WCAG considera o texto do link sozinho ou junto ao contexto programaticamente determinado.
Confira se o foco visual cobre o elemento interativo correto, se há um nome acessível e se o estado é anunciado de forma apropriada. Uma seta decorativa pode não precisar receber foco; uma seta que abre um submenu precisa ser operável e informar o que faz. A cor, sozinha, não deve ser o único indicador de foco ou erro. Teclado manual não substitui teste com leitor de tela, mas ajuda a localizar problemas básicos.
Como corrigir problemas frequentes
- Restaurar ou desenhar um contorno de foco visível em todos os componentes relevantes.
- Usar links e botões semânticos em vez de elementos genéricos com clique no mouse.
- Remover tabindex positivo e revisar ordem do DOM e da navegação.
- Corrigir menus para que abertura, seleção e saída funcionem sem mouse.
- Gerenciar o foco ao abrir e fechar diálogos, menus móveis e avisos.
- Verificar se cabeçalhos fixos ou banners não escondem o elemento focado.
- Dar nomes claros a ícones interativos e ocultar do foco ícones decorativos.
Faça uma correção por componente reutilizado e teste em diferentes páginas. Um menu global pode ser acessível em uma página e falhar em outra se houver sobreposição de script ou conteúdo. Depois de corrigir, repita o percurso completo e teste estados de erro, carregamento e confirmação. A acessibilidade precisa persistir quando o componente muda de estado, e não apenas no estado inicial.
Exemplo prático: menu de serviços e pedido de contato
Uma empresa tem um menu suspenso de serviços que abre apenas ao passar o mouse. No computador, o conteúdo parece funcionar, mas ao pressionar Tab, o menu nunca aparece. O teste encontra que os links estão escondidos e o foco pula direto para o rodapé. A equipe implementa uma ativação de teclado coerente e mantém o estado aberto visível.
Na sequência, o foco chega ao botão de contato, mas o contorno fica sob uma barra fixa. A equipe ajusta rolagem e posicionamento para revelar o controle. Dentro do formulário, a confirmação de envio aparece sem que a pessoa saiba se o foco mudou ou se houve sucesso. A equipe revisa a mensagem de status e a ordem. Esse processo testa a jornada inteira, não apenas o menu isolado.
Uma revisão inicial pode ser feita com Tab e Shift+Tab, mas não substitui avaliação especializada ou verificação integral da WCAG. Use ferramentas automáticas como apoio e consulte as soluções digitais da Open Leads para discutir estrutura e experiência do site.
Ao testar, procure ainda controles que surgem apenas após uma ação. Um submenu pode aparecer ao focar um item e desaparecer ao tentar alcançá-lo; um aviso pode deslocar o conteúdo sob um cabeçalho fixo; uma faixa de consentimento pode bloquear a ação principal e não oferecer um botão de fechar acessível. Inclua esses estados na inspeção, pois a operação com teclado muda quando um componente abre ou fecha. Guarde uma lista de páginas verificadas e repita o teste sempre que o tema, menu ou plugin de interface for atualizado.
Checklist de navegação por teclado
- Consigo percorrer todas as ações importantes sem mouse.
- O foco aparece em links, botões, campos e controles customizados.
- A ordem de foco acompanha o sentido e a operação do conteúdo.
- Menus, modais e widgets podem ser abertos, operados e fechados.
- Não há componente que prenda o teclado ou esconda o foco.
- Links levam a destinos; botões executam ações.
- Os nomes e rótulos dos controles explicam a finalidade.
- O foco não fica coberto por cabeçalhos, avisos ou painéis fixos.
- Testei estados de erro, sucesso, carregamento e navegação móvel.
- Usei WCAG como referência, sem declarar conformidade com base em um teste superficial.
Perguntas frequentes
Qual tecla uso para testar a navegação?
Tab e Shift+Tab percorrem componentes focáveis em muitos navegadores. Enter, Espaço e setas podem ativar ou mover-se dentro de controles, dependendo do elemento e do padrão implementado.
Todo conteúdo precisa receber foco?
Não. O foco deve alcançar controles interativos e caminhos de navegação necessários. Texto estático normalmente é lido na ordem do documento, sem precisar virar um controle focável.
Posso remover o contorno padrão do navegador?
Somente se houver um indicador de foco alternativo, visível e consistente. Sem indicador, a pessoa que navega pelo teclado pode não saber onde está.
Um menu acessível só com teclado também funciona para leitores de tela?
O teste de teclado encontra barreiras importantes, mas não comprova sozinho a experiência com leitor de tela. Avalie semântica, nomes, estados e anúncios com tecnologias assistivas.
Tab deve seguir exatamente a posição visual dos elementos?
Não necessariamente. A sequência precisa preservar significado e operação. Uma ordem lógica pode diferir de detalhes do layout, mas não deve desorientar nem tornar ações inacessíveis.
Quer transformar tráfego em oportunidades reais? A Open Leads integra mídia paga, mensuração e criação de sites focados em conversão. Conheça os serviços da Open Leads.
Fontes consultadas
Consulte os materiais originais usados na pesquisa deste artigo.
Tags
Escrito por
Equipe Open Leads
