Link ou botão: qual usar?

Link navega para um destino; botão executa uma ação. Veja como escolher o elemento certo, preservar acessibilidade e evitar interfaces com semântica enganosa.

Ilustração minimalista mostrando a decisão entre um link que leva a outro destino e um botão que executa uma ação local.
Nível de impácto
Alto
Status
Recomendado
Nível de evidênica
Forte evidência

Contexto

Links e botões podem receber estilos parecidos, especialmente em chamadas para ação, cards e interfaces de aplicações. A aparência, porém, não define o comportamento do controle. Um link representa navegação para um destino; um botão representa uma ação executada na página, em um formulário ou sobre outro componente.

Quando a semântica é trocada apenas para facilitar o estilo ou o JavaScript, a interface pode perder comportamentos esperados: abrir o destino em outra aba, copiar ou salvar o endereço, usar o menu de contexto, responder às teclas corretas e ser anunciada com o papel adequado por tecnologias assistivas.

Classifique a intenção da interação antes de escolher o componente. Se existe um destino que pode ser representado por uma URL, use um link. Se a interação modifica o estado atual ou dispara uma operação, use um botão.

Use um link para navegação, preferindo <a href="..."> para abrir outra página, outra área do site, uma posição na mesma página, um documento, um download ou um endereço de e-mail e telefone.

Use um botão para ações da própria interface, como enviar formulário, salvar, excluir, abrir modal, abrir menu, expandir conteúdo, alternar estado ou executar uma operação sem mudar o destino.

Separe semântica de aparência. Um link pode receber aparência de botão quando a navegação for a chamada principal. Um botão pode receber aparência mais discreta quando a ação for secundária. O HTML deve continuar refletindo a intenção.

Preserve os comportamentos nativos. Não substitua um link por um elemento genérico com JavaScript nem transforme um link em botão com href="#". Também não use um botão com onclick para simular navegação quando existe uma URL.

Escolha o tipo correto do botão. Dentro de um formulário, use type="submit" para enviar e type="button" para uma ação que não deve submeter os dados. Use type="reset" somente quando o reset for realmente compreensível e necessário.

Escreva um nome claro. O texto deve indicar o destino do link ou o resultado da ação do botão. Evite “clique aqui”, “saiba mais”, “enviar” sem contexto e rótulos que dependam apenas de um ícone.

Teste a interação real verificando mouse, teclado, leitor de tela, menu de contexto, copiar endereço, abrir em nova aba, foco, estados e comportamento sem JavaScript quando aplicável.

Regra prática

Se a pessoa vai para algum lugar, use link. Se algo acontece onde ela está, use botão. Se um componente visual aceita uma URL, ele deve renderizar um link por baixo; se dispara uma ação, deve renderizar um botão.

Base da recomendação

O HTML e o WAI-ARIA APG distinguem a navegação de um link da ação de um controle. MDN documenta que um <a> com href cria um hiperlink e que links falsos com # ou javascript:void(0) devem ser substituídos por <button>. Primer reforça a mesma distinção e alerta que aparência de link ou botão não deve substituir a semântica correta. Spectrum e GOV.BR mostram como sistemas de design aplicam essa separação em componentes e estados. A recomendação é forte para a escolha semântica, mas o estilo, o texto e a hierarquia visual dependem do contexto do produto.

Página de acessibilidade do Primer orientando quando usar links e botões.
Exemplo real: o Primer separa links, que navegam para um destino, de botões, que executam ações, e recomenda elementos nativos. A captura mostra a orientação de acessibilidade que sustenta a escolha semântica antes da aparência. Fonte: Primer — Links and buttons: https://www.primer.style/accessibility/design-guidance/links-and-buttons/

Porque isso importa?

O elemento escolhido informa ao navegador, às tecnologias assistivas e a outros mecanismos de interação o que a pessoa pode esperar. Um link nativo oferece recursos de navegação, como copiar o destino, abrir em outra aba e usar o histórico. Um botão nativo comunica uma ação e participa de formulários e controles de estado.

Quando um botão é usado para navegar, a pessoa pode perder recursos do navegador e encontrar um comportamento diferente do esperado. Quando um link é usado para abrir um modal, salvar ou alternar um painel, o papel, as teclas, o menu de contexto e o anúncio para leitor de tela podem ficar inconsistentes.

  • Use link para outra página ou tela com URL própria.
  • Use link para uma seção da mesma página.
  • Use link para documento, download, e-mail ou telefone.
  • Use botão para enviar, salvar, excluir ou atualizar dados.
  • Use botão para abrir modal, menu, popover ou painel.
  • Use botão para expandir, recolher ou alternar um estado.
  • Evite botão com JavaScript para substituir uma URL.
  • Evite link com href="#" para executar uma ação.
  • Evite role="button" ou role="link" como primeira opção.
  • Evite decidir pelo formato visual antes da semântica.
  • Evite “clique aqui” sem destino ou ação explícita.
  • Evite remover o foco para esconder a diferença entre controles.
Documentação do Adobe Spectrum mostrando um link em texto corrido e orientações para chamadas de ação.
Exemplo real: o Adobe Spectrum mostra o link integrado ao texto corrido e orienta considerar outro componente quando a intenção for uma chamada para ação mais proeminente. A captura demonstra a relação entre semântica, contexto e tratamento visual. Fonte: Adobe Spectrum — Link: https://spectrum.adobe.com/page/link/

Recomendações

Faça

Práticas recomendadas
  • Defina primeiro: destino ou ação.
  • Use <a href> para navegar.
  • Use <button> para agir.
  • Escolha a aparência depois.
  • Escreva destino ou resultado.
  • Preserve foco e teclado.
Wireframe minimalista mostrando um link levando a outra página e um botão alterando o estado da interface.
Exemplo correto: o link leva a outro destino e o botão executa uma ação local, preservando a semântica de cada elemento.

Evite

Práticas a evitar
  • Usar botão como link.
  • Usar link como botão.
  • Depender de href="#".
  • Depender só de JavaScript.
  • Confiar apenas na aparência.
  • Esconder o nome da interação.
Wireframe minimalista mostrando um botão usado para navegar e um link usado para alterar o estado local da interface.
Exemplo incorreto: a aparência troca a semântica, usando botão para navegação e link para uma ação local.
Documentação do Design System GOV.BR mostrando uso, rótulo e acessibilidade do componente Button.
Exemplo real: o Design System GOV.BR documenta o botão como componente de ação, orienta rótulos claros e descreve Tab, Space, Enter, foco e o uso semântico do elemento button nativo. A captura demonstra a implementação contextual de um controle de ação. Fonte: Padrão Digital de Governo — Button: https://www.gov.br/ds/components/button

Acessibilidade

Prefira os elementos nativos <a href> e <button>. Eles já expõem papéis e comportamentos esperados para navegadores e tecnologias assistivas. Um link nativo é ativado por Enter; um botão precisa funcionar com Enter e Space. Não reproduza esses comportamentos com um div ou span se um elemento HTML adequado existir.

O nome precisa comunicar o destino do link ou o resultado da ação. Em botões somente com ícone, forneça nome acessível e, quando necessário, um rótulo visível. Em links, escreva texto que continue compreensível fora do parágrafo, inclusive na lista de links de um leitor de tela.

Preserve foco visível, ordem de navegação, contraste, tamanho de toque e estados de carregamento, erro, desativação e expansão. Não dependa apenas de cor, formato ou posição para diferenciar a ação. Se um controle customizado for inevitável, documente e teste nome, papel, estado, teclas e comportamento com tecnologias assistivas.

Checklist

  • A interação leva a pessoa para um destino ou executa uma ação?
  • O elemento HTML corresponde a essa intenção?
  • O link possui href e destino real?
  • O botão possui o type correto?
  • O texto informa o destino ou o resultado da ação?
  • O controle funciona com teclado?
  • O link mantém copiar, abrir em nova aba e menu de contexto?
  • O botão mantém foco, estados e feedback da ação?
  • O nome é compreensível em uma lista de links ou botões?
  • A aparência não contradiz a semântica?
  • O foco permanece visível?
  • A interação foi testada com leitor de tela e zoom?

Referências

MDN Web Docs: elemento <a>. Documenta que um link com href cria um hiperlink, que o texto deve indicar o destino e que links falsos com # ou javascript:void(0) devem ser substituídos por um botão. Consultar o elemento a.

MDN Web Docs: elemento <button>. Documenta botões para ações, envio de formulários, controles de diálogo e o uso de type para definir o comportamento. Consultar o elemento button.

W3C WAI-ARIA APG: Link Pattern. Recomenda o elemento nativo <a> com href e explica que aplicar role="link" não adiciona automaticamente navegação, menu de contexto ou outros comportamentos nativos. Consultar o padrão Link.

W3C WAI: técnica H91. Explica como controles HTML e links nativos expõem nome, papel, estado e operação de teclado para navegadores e tecnologias assistivas. Consultar a técnica H91.

GitHub Primer: Links and buttons. Diferencia navegação de ação, recomenda elementos nativos e explica que um link pode receber aparência de botão quando continua sendo um link semântico. Consultar Links and buttons.

Adobe Spectrum: Link. Orienta usar links em texto corrido e considerar outro componente quando a intenção for uma chamada para ação maior ou mais proeminente. Consultar o componente Link.

Adobe Spectrum: Button. Documenta botões para ações, rótulos, foco, estados e hierarquia visual. A página é usada como referência contextual de implementação. Consultar o componente Button.

Padrão Digital GOV.BR: Button. Documenta rótulos de ação, teclado, foco, área de toque e o uso da tag <button> como marcação semântica. Consultar o componente Button do GOV.BR.

Veja também

Esta recomendação foi útil para você?