Teclado e foco

O problema

Tem muita interface que parece pronta e ainda assim falha no primeiro teste honesto:

• navegar só com teclado
• enxergar claramente onde o foco está
• abrir e fechar componentes sem se perder

Quando isso quebra, a experiência não fica só “menos acessível”.

Ela fica confusa.

O usuário aperta Tab e o foco some. Abre um modal e continua navegando nos botões do fundo. Fecha a sobreposição e cai em um ponto aleatório da tela. Tudo isso passa sensação de produto desorganizado, mesmo quando o visual está impecável.

Modelo mental

Pensa assim:

foco é o cursor de navegação da interface para quem não está usando mouse.

Se esse cursor está invisível, desordenado ou preso no lugar errado, a pessoa perde orientação.

Teclado e foco não são um complemento da navegação. Em muitos fluxos, eles são a navegação.

Então a pergunta certa não é:

• “essa tela funciona com teclado?”

A pergunta melhor é:

• “essa tela continua previsível quando o teclado vira o principal jeito de andar nela?”

Quebrando o problema

Ordem de foco precisa seguir a lógica da tela

O foco deveria caminhar de um jeito que pareça natural.

Na prática, isso costuma significar:

• seguir a ordem visual e estrutural da interface
• não saltar para áreas sem contexto
• não obrigar a pessoa a atravessar elementos irrelevantes para chegar ao que importa

Quando a ordem do DOM e a ordem da experiência brigam, o teclado denuncia isso rápido.

Foco visível não é detalhe estético

Tem time que remove outline porque acha feio.

Isso é quase sempre um erro.

Se você não quer usar o estilo padrão do navegador, tudo bem. Mas precisa substituir por outro indicador forte, visível e consistente.

Sem isso, a pessoa navega no escuro.

Componentes sobrepostos precisam governar o foco

Modal, drawer, menu e popover mudam o contexto da interação.

Então eles também precisam cuidar do foco:

• ao abrir, o foco precisa entrar no contexto novo
• enquanto estiver aberto, a navegação deve ficar dentro dele quando isso fizer sentido
• ao fechar, o foco deveria voltar para quem iniciou a ação

Se você ignora esse ciclo, a interface fica parecendo quebrada por baixo.

Elemento nativo resolve metade do problema antes do JavaScript

Isso conecta com semântica.

Botão de verdade já recebe foco, responde a teclado e participa da navegação como esperado.

div estilizada como botão não faz isso sozinha.

Quando o time começa com o elemento errado, acaba tentando reconstruir comportamento básico com remendo.

Exemplo simples

Imagina um botão “Excluir” que abre um modal de confirmação.

Fluxo ruim:

1. a pessoa aperta Enter no botão
2. o modal abre visualmente
3. o foco continua no botão de trás ou some
4. Tab começa a passear por elementos fora do modal
5. ao fechar, o foco volta para um ponto imprevisível

Fluxo saudável:

1. a pessoa aperta Enter no botão
2. o modal abre
3. o foco vai para o primeiro elemento útil do modal
4. Tab navega dentro do contexto do modal
5. Esc ou o botão de fechar encerram a interação
6. o foco volta para o botão “Excluir”

Esse segundo fluxo não é capricho.

É o que faz a interface continuar compreensível durante a troca de contexto.

Erros comuns

• Remover outline e não colocar nada no lugar.
• Testar componente interativo só no mouse.
• Abrir modal sem mover o foco para dentro dele.
• Fechar modal sem devolver o foco para a origem.
• Criar botão com div e depois tentar corrigir no onKeyDown.
• Usar tabIndex como atalho para consertar estrutura ruim em vez de corrigir a base.

Como um senior pensa

Quem tem mais experiência olha para teclado e foco como parte do contrato da interface.

Não como ajuste fino.

A pergunta muda de:

• “depois a gente vê acessibilidade”

para:

• “qual é a trajetória de navegação dessa tela quando o usuário não usa mouse?”

Isso muda o jeito de construir componente, revisar PR e testar fluxo.

Um senior também sabe que foco ruim gera bug difícil de perceber para quem desenvolve no próprio contexto, mas muito óbvio para quem depende de navegação por teclado. Por isso ele valida cedo, usa elementos nativos sempre que possível e trata mudança de contexto com mais rigor.

O que o entrevistador quer ver

Quando esse tema aparece em entrevista, o avaliador geralmente não quer ouvir uma lista decorada de atributos.

Ele quer perceber se você entende:

• que navegação por teclado é fluxo principal
• que foco precisa ser visível e previsível
• que componentes sobrepostos precisam controlar entrada e saída de foco
• que semântica correta reduz muito do problema antes de qualquer remendo

Uma resposta forte costuma soar assim:

Eu penso em foco como a posição atual da navegação. Se ela fica invisível ou vai para lugares sem lógica, a interface já perdeu previsibilidade. Em modal, menu e drawer, eu cuido explicitamente de onde o foco entra, como ele circula e para onde volta quando o contexto fecha.

Interface boa não funciona só no clique. Ela continua fazendo sentido quando o teclado assume a direção.

Quando o foco se comporta bem, a interface parece sólida. Quando se comporta mal, ela parece quebrada mesmo sem erro visual.