Navegação por teclado é a capacidade de usar um site inteiro — menus, formulários, botões, links — sem tocar no mouse ou na tela, apenas com teclas como Tab, Shift+Tab, Enter, Espaço e as setas direcionais. Para quem usa mouse sem pensar duas vezes, pode parecer um recurso secundário. Para quem depende dele, é a única forma de usar o site.
Quem depende da navegação por teclado
Pessoas com deficiência motora que não conseguem controlar um mouse com precisão são o grupo mais óbvio, mas não o único. Pessoas cegas que usam leitor de tela navegam quase inteiramente por teclado, já que não há como "apontar e clicar" em algo que não se vê. Pessoas com tremores, lesões temporárias no braço ou na mão, e até usuários avançados que preferem atalhos de teclado por velocidade também dependem dessa forma de navegação, mesmo sem nenhuma deficiência.
Tecnologias assistivas alternativas, como dispositivos de rastreamento ocular ou de sopro (usados por pessoas com deficiências motoras severas, como esclerose lateral amiotrófica), também costumam simular navegação por teclado — o que significa que um site compatível com teclado é, na prática, compatível com uma gama bem maior de tecnologias assistivas do que aparenta.
O que quebra a navegação por teclado
Um problema muito comum é o "foco invisível": ao pressionar Tab, o navegador move o foco entre elementos, mas se o site remove o contorno visual padrão de foco (via CSS, com outline: none) sem colocar outro indicador visual no lugar, a pessoa não tem como saber em qual elemento está posicionada.
Outro problema é a "armadilha de foco" (focus trap), quando um menu ou modal abre e o foco fica preso dentro dele sem forma de sair usando teclado — obrigando a pessoa a recarregar a página inteira. Elementos interativos construídos com <div> ou <span> em vez de <button> ou <a> também costumam ficar fora da ordem de tabulação por padrão, tornando-os inacessíveis via teclado mesmo que pareçam clicáveis visualmente.
Como verificar se um site é navegável por teclado
O teste mais simples é literalmente guardar o mouse e tentar usar o site inteiro só com Tab, Shift+Tab e Enter: dá para abrir o menu? Preencher um formulário? Fechar um modal? Chegar ao botão de finalizar uma ação? Se em algum ponto o foco "desaparece" ou fica preso, ali está uma barreira real de acessibilidade.
Esse teste, apesar de simples, revela problemas que passam despercebidos em testes visuais tradicionais, porque quem está olhando a tela normalmente usa o mouse sem perceber que aquele caminho específico não existe via teclado.
Suporte sólido a teclado costuma ser um dos indicadores mais confiáveis da maturidade de acessibilidade de um site — é difícil ter um site verdadeiramente acessível sem isso funcionando bem.
A ordem de tabulação também importa
Não basta que todos os elementos sejam alcançáveis por teclado — a ordem em que o foco passa de um elemento para outro precisa fazer sentido lógico, seguindo a estrutura visual da página. Quando o código HTML está desorganizado, o foco pode "pular" de forma confusa, indo do topo da página para o rodapé e voltando ao meio, obrigando quem navega por teclado a memorizar um caminho que não corresponde ao que é mostrado na tela. Esse problema costuma aparecer em páginas construídas com muitos elementos posicionados via CSS de forma independente da ordem real do código-fonte, uma prática comum, mas que exige atenção redobrada para não comprometer a navegação por teclado.
Este conteúdo tem caráter informativo e não substitui uma auditoria técnica de acessibilidade feita por um especialista.
Pronto pra colocar o Barra de Acessibilidade pra trabalhar?
Crie sua conta na VEANET Plataforma e comece a usar o Barra de Acessibilidade em poucos minutos.
Quero o Barra de Acessibilidade →