Link ou botão no site: escolha pela função e teste o resultado

Use um link para levar a pessoa a um recurso ou destino; use um botão para executar uma ação, como mostrar filtros ou enviar um formulário. A escolha começa pelo comportamento esperado. Um link pode receber destaque com aparência de botão sem deixar de ser uma navegação. Cor, borda e tamanho não definem sozinhos a função do elemento.

O guia de call to action explica como relacionar convite, oferta e próximo passo. Aqui, vamos aprofundar a escolha entre link e botão, com um catálogo fictício e um roteiro de conferência. O objetivo é permitir que conteúdo, design e implementação descrevam a mesma interação antes de publicar uma chamada.

Descreva o que acontecerá antes de escolher a aparência

Complete a frase: ao acionar esta chamada, a pessoa vai encontrar um destino ou executar qual ação? “Ver modelos urbanos” pode levar a uma página com bicicletas dessa categoria. “Mostrar filtros” pode revelar opções na página atual. São tarefas diferentes, mesmo que as duas chamadas usem o laranja da marca.

No padrão de link da W3C WAI, o destino pode estar fora ou dentro da página ou aplicação. Portanto, navegar até uma seção do próprio conteúdo também pode ser função de link. O guia recomenda usar o elemento de link nativo com endereço, preservando os comportamentos que o navegador oferece.

O padrão de botão da W3C WAI descreve ações como abrir um diálogo ou enviar um formulário. Para revisar a página, registre a tarefa concreta e o resultado esperado. “Abrir” é insuficiente se a equipe não sabe se a chamada abre outra página, um painel de opções ou uma janela de diálogo.

Exemplo fictício: consultar modelos e mostrar filtros

Exemplo fictício: uma equipe prepara um catálogo de bicicletas. Na proposta, “Ver modelos urbanos” leva à página dessa categoria. “Mostrar filtros” revela opções dentro do catálogo atual. Não há loja, estoque, preço ou catálogo funcional anunciado neste exercício; o desenho compara comportamentos previstos, sem teste de uso realizado.

Contexto do exemplo fictício

Catálogo de bicicletas com duas chamadas que atendem a tarefas diferentes. A aparência não define sozinha a função.

Link · Ver modelos urbanos

Leva à página da categoria urbana. Confira se o conteúdo encontrado corresponde ao rótulo.

Botão · Mostrar filtros

Revela opções no catálogo atual. Confira se aparecem e podem ser usadas, com estado compreensível.

Resultado que precisa ser distinguido

Mostrar opções de filtro não equivale a escolher ou aplicar um filtro.

Limite da leitura

Desenho estático e catálogo fictício. Sem controles funcionais, teste de uso, filtro aplicado ou resultado comercial.

Descrição da figura

A figura compara dois comportamentos previstos num catálogo fictício de bicicletas. Ver modelos urbanos é um link que leva à página da categoria urbana. A conferência deve verificar se o conteúdo encontrado corresponde ao rótulo. Mostrar filtros é um botão que revela opções no catálogo atual. Mostrar opções não significa que a pessoa escolheu ou aplicou um filtro. As chamadas recebem desenhos de destaque semelhantes para mostrar que a aparência não define sozinha a função. São elementos estáticos, sem controles funcionais, catálogo real, teste de uso ou resultado comercial.

O primeiro caminho termina quando a categoria correta pode ser consultada. O segundo apenas mostra controles para continuar a busca. Revelar os filtros não significa que um filtro já foi escolhido ou aplicado. A implementação deve deixar essa sequência compreensível, incluindo como alterar ou retirar uma escolha quando esse recurso existir.

Se a equipe mudar o projeto e fizer “Mostrar filtros” levar a uma página específica de busca, reveja o rótulo e a função. O componente precisa acompanhar o comportamento final, em vez de manter uma escolha técnica feita para uma versão anterior do desenho.

Contexto: catálogo ilustrativo de bicicletas.
Chamada 1: Ver modelos urbanos.
Função prevista: navegar para a página da categoria urbana.
Conferência prevista: categoria e conteúdo correspondem ao rótulo.
Chamada 2: Mostrar filtros.
Função prevista: revelar opções no catálogo atual.
Conferência prevista: opções visíveis, operáveis e com estado compreensível.
Limite: mostrar opções não equivale a escolher ou aplicar um filtro.
Estado do exercício: proposta sem catálogo funcional, teste de uso ou resultado comercial.

Faça o rótulo antecipar o resultado

“Saiba mais” pode deixar o próximo passo ambíguo quando várias chamadas aparecem próximas. Nomeie o objeto da consulta ou da ação: ver uma categoria, consultar condições ou enviar uma solicitação. O rótulo não precisa explicar todo o processo, mas deve combinar com a informação que a pessoa receberá.

Não use a aparência para sugerir uma confirmação inexistente. Abrir a página de inscrição, abrir um formulário e enviar uma inscrição são etapas distintas. Se a chamada apenas leva ao formulário, descreva esse caminho; a confirmação do envio precisa ocorrer no momento correspondente.

A distinção entre função e prioridade também ajuda. O guia de CTA principal e secundário organiza o destaque entre duas chamadas. Uma opção pode ser prioritária e continuar sendo um link, enquanto um botão pode executar uma ação secundária. A hierarquia não substitui a definição do comportamento.

Confira o elemento usado na implementação

Para a equipe técnica, o link em HTML costuma ser representado por um elemento <a> com href, que informa o destino. O botão nativo é representado por <button>. A escolha deve preservar a semântica, isto é, a função que o componente comunica ao navegador e às tecnologias assistivas.

A documentação do elemento button na MDN diferencia os tipos de botão. Um botão associado a um formulário pode submeter os dados por padrão quando o tipo não é definido adequadamente. Para uma ação que não deve enviar o formulário, a implementação precisa definir esse comportamento, normalmente com type="button", e implementar a ação prevista.

Essa conferência evita, por exemplo, que uma chamada para mostrar ajuda provoque um envio inesperado. O tipo sozinho também não cria a ajuda nem torna um painel funcional. Conteúdo, controle e comportamento precisam ser implementados e testados em conjunto.

Aplicar somente role="link" a outro elemento não adiciona navegação ou ações de menu de contexto, como alerta o padrão da W3C citado acima. Prefira os elementos nativos adequados e peça à equipe que justifique e teste uma implementação personalizada. Mudar uma declaração de função não substitui conferir a interação.

Teste teclado, foco e resultado como partes da mesma tarefa

Comece em uma condição conhecida da página e percorra os controles com o teclado. Observe se consegue reconhecer o foco, identificar a chamada e chegar ao resultado esperado. Uma interação que funciona apenas ao tocar na tela ainda precisa ser conferida com outros modos de entrada.

Os padrões da W3C indicam Enter para ativar um link e Enter ou Espaço para ativar um botão com foco. Use essa referência na conferência dos componentes comuns. Quando houver um componente mais complexo, como um diálogo, confira também seu padrão e a continuidade do foco, em vez de presumir que conseguir abrir basta.

No catálogo fictício, o teste previsto do link é chegar à categoria urbana correta. No botão, é revelar opções de filtro e conseguir continuar a tarefa. Se o resultado aparece fora da área visível ou o foco desaparece, documente o ponto exato em que a continuidade se perde para a equipe responsável investigar.

O comportamento depois da ativação depende da ação. Abrir um diálogo exige uma continuidade diferente de revelar controles no mesmo contexto. Não imponha uma única posição de foco a todas as interações. O resultado precisa permanecer compreensível e permitir a sequência e a saída pertinentes.

Para controles que enviam dados ou iniciam operações reais, prepare um cenário de teste autorizado e registros fictícios. Diferencie conferir o componente de enviar uma solicitação para atendimento ou concluir uma transação. A evidência precisa mostrar o que efetivamente ocorreu, sem tratar a abertura de uma página como envio confirmado.

No celular, confira o controle no contexto da página

Veja se o rótulo continua legível e se a área pode ser acionada sem alcançar outro controle por engano. Confira menus, avisos e elementos flutuantes próximos. O teste deve incluir o resultado da interação: mostrar opções não ajuda se elas ficam cobertas ou se a pessoa não encontra como continuar.

Quando uma chamada aparece em vários pontos, examine cada ocorrência. Rótulos iguais com comportamentos diferentes merecem revisão. Se uma chamada estiver indisponível, a apresentação e a explicação precisam corresponder a esse estado, sem parecer que o pedido foi executado.

A escolha correta de link ou botão é uma parte da qualidade da página. Ela não comprova, sozinha, acessibilidade completa, facilidade de uso ou aumento de conversões. Registre separadamente a conferência técnica, a observação com pessoas e os resultados medidos conforme cada método.

Página, seção e versão:
Tarefa que a pessoa precisa realizar:
Rótulo visível e contexto:
Destino ou ação prevista:
Função e elemento usados na implementação:
Resultado esperado e modo de reconhecê-lo:
Percurso por teclado e visibilidade do foco:
Resultado de Enter e, para botão comum, Espaço:
Continuidade, saída e retorno pertinentes:
Apresentação e uso no celular:
Envio ou operação real envolvidos e cenário autorizado de teste:
Problema encontrado, responsável e ajuste:
Nova conferência após a correção:
Limites do que foi testado:

Perguntas frequentes sobre link e botão no site

Um link pode ter aparência de botão?

Pode receber destaque visual, preservando a navegação e a função de link. A aparência deve ajudar a compreender a chamada sem substituir a escolha pelo comportamento.

Ir para uma seção da mesma página é função de link?

Pode ser. O destino de um link também pode estar no conteúdo atual. Confira se a seção existe, pode ser encontrada e corresponde ao rótulo.

Todo botão deve enviar um formulário?

Não. Botões também podem executar ações como mostrar opções. A implementação precisa definir o tipo e o comportamento corretos, evitando envio inesperado quando o botão está associado a um formulário.

Se funciona com o mouse, a interação está conferida?

Ainda falta verificar teclado, foco, resultado e apresentação nas condições pertinentes. Esses testes também não equivalem, por si sós, a uma auditoria completa de acessibilidade ou a um teste com usuários.

Se sua página apresenta chamadas com resultados pouco claros, converse conosco sobre conteúdo e percurso do visitante. Podemos ajudar a definir rótulos e expectativas. Implementação de componentes, testes técnicos e pesquisa com pessoas precisam de responsabilidades e escopos combinados.