O que são os três pontos na interface
Os três pontos são aquele botão ou ícone formado por três dotinhos verticais ou horizontais que aparecem em praticamente todo software moderno. O nome técnico é "kebab menu" quando os pontos ficam na vertical e "more options menu" quando ficam na horizontal. Serve para esconder funcionalidades que não precisam estar visíveis o tempo todo. Em vez de lotar a barra de ferramentas com dezesseis botões, o desenvolvedor agrupa o que é secundário dentro daquele menu e pronto. Achei que era só uma questão de estética quando comecei a mexer com design de interface, mas na prática é uma solução para um problema real: espaço de tela limitado. Eu trabalhava num projeto interno de logística anos atrás onde a tela tinha que caber em monitores de 10 polegadas rodando resolução 1024 por 768. Não dava para colocar todos os botões de ação visíveis. Aí entram os três pontos como contenção de complexidade.
Para que serve os tres pontos em diferentes contextos
No contexto de aplicativos mobile, os três pontos geralmente carregam ações como compartilhar, salvar, marcar como favorito, excluir ou ver detalhes. No contexto de desktop, o mesmo ícone pode abrir opções de configuração avançada, relatórios exportáveis ou integrações com outros serviços. Em ferramentas de desenvolvimento como editores de código, os três pontos costumam controlar extensões, temas e configurações do ambiente. O problema é que muita gente trata o ícone como sinônimo de "todas as opções". Isso é errado. O menu de três pontos deveria conter no máximo quatro a sete itens. Se você passa disso, o menu tá viciado em esconder informação demais e o usuário perde tempo procurando. Eu vi um sistema corporativo com quarenta e três itens dentro do kebab menu. Ninguém conseguia achar nada. A gente teve que redistribuir os itens mais usados para a barra principal e dividir os demais em submenus hierárquicos.
Uma coisa que pouca gente sabe é que o acessibilidade desses menus é um campo minado. O menu de três pontos precisa ser totalmente navegável por teclado. Se você abre com tab e fecha com esc, tudo certinho. Mas já vi tantos sistemas onde o menu só abre com clique do mouse que usuários com deficiência motora simplesmente não conseguem acessar metade das funcionalidades. O WAI-ARIA tem regras específicas para isso: aria-haspopup, aria-expanded, o foco precisa travar dentro do menu enquanto ele estiver aberto. Ignorar isso é negligência, não erro inocente.
Como implementar corretamente
Se você vai construir um desses menus do zero, comece pensando na estrutura semântica. Um botão que abre um menu dropdown com aria-haspopup="menu" e aria-expanded controlado via JavaScript. Os itens dentro devem ser links ou botões, nunca divs soltas. O primeiro item deve receber o foco automaticamente quando o menu abrir. O esc deve fechar e devolver o foco pro botão original. A parte visual é mais simples do que a lógica. Um botão com o caractere Unicode U+22EE para vertical ou U+22EF para horizontal. Não use três pontos de reticência normais (U+2026) repetidos três vezes. O resultado visual é levemente diferente e vai parecer amador. Use o caractere correto ou um SVG. Fontes de ícone como Material Icons, Feather ou Lucide já trazem a versão pronta.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Eu tive um problema específico com menus de três pontos em tablets Android. O touch alvo do botão era muito pequeno, menor que 48 por 48 pixels, e os usuários iam clicar por engano em elementos vizinhos. A solução foi aumentar o padding do botão pra 12 pixels em cada lado e adicionar um touch target invisível ao redor. Não resolveu só o clique acidental, melhorou a taxa de acerto geral porque o botão ficou mais fácil de apontar.
Pegadinhas e armadilhas comuns
Uma das piores coisas que eu já vi foi o menu de três pontos escondendo a ação de exclusão. Usuários reclamavam que não conseguiam deletar registros porque não encontravam o botão. Quando eu pedia pra mostrar a tela, o menu tava lá, mas com cor cinza claro sobre fundo branco. O contraste era 1.4 para 1. Isso é violação direta das normas WCAG 2.1 nível AA que exige contraste mínimo de 4.5 para 1 em texto normal. Outro erro frequente é usar os três pontos junto com outros ícones de ação na mesma linha. Quando você já tem botões visíveis de editar e compartilhar, colocar um terceiro ponto que abre mais opções cria redundância. O usuário não sabe se clica no ícone óbvio ou no menu secreto. A regra prática é: se a ação cabe num ícone reconhecível e em uma barra de ferramentas, use o ícone. Reserve os três pontos exclusivamente para agrupar ações que não têm ícone padrão ou que são contextuais.
Sites de notícias e blogs costmam abusar dos três pontos pra criar menus de navegação com dezenas de links. O resultado é que o menu vira um labirinto. Eu recomendo limitar a três níveis de profundidade no máximo. Se o usuário precisa fazer quatro cliques pra chegar numa funcionalidade, talvez aquela funcionalidade devesse ter um lugar mais óbvio ou ser removida. Se o seu caso é um produto com muitas opções mesmo assim, considere alternativas como uma barra lateral de configurações, um painel de propriedades ou um modal de advanced settings. O kebab menu não é bala de prata. Ele funciona bem para cinco a sete ações contextuais. Pra qualquer coisa além disso, ele vira um buraco negro de usabilidade.
Em resumo, os três pontos existem pra organizar o que não pode ficar na cara. O segredo é não abusar, garantir que sejam acessíveis e manter o menu enxuto. O resto é tentativa e erro com usuários reais testando.
