Botões devem ter ícone e texto?

Combine ícone e texto quando a ação precisar de clareza. Use apenas ícone quando o significado for reconhecível, consistente e acessível.

Ilustração minimalista comparando um botão com ícone e rótulo visual a um botão compacto somente com ícone
Nível de impácto
Alto
Status
Usar com atenção
Nível de evidênica
Evidência moderada

Contexto

Ícones podem acelerar o reconhecimento de uma ação, mas não são uma linguagem universal. O texto torna a intenção mais explícita, ajuda pessoas que usam comando de voz e reduz a dependência de memória ou interpretação visual.

Por isso, não existe uma regra universal dizendo que todo botão deve ter ícone ou que todo botão deve exibir apenas texto. A decisão depende da familiaridade da ação, do contexto, do espaço disponível, do público e do risco associado.

Use texto junto ao ícone quando a ação for pouco familiar, importante, destrutiva, complexa ou sujeita a interpretações diferentes.

Use apenas ícone em ações muito conhecidas, recorrentes e compactas, desde que o botão tenha nome acessível, foco visível e comportamento compreensível.

Escolha primeiro o nome da ação. O ícone deve reforçar o significado, não substituir um rótulo necessário.

Mantenha a mesma função com o mesmo nome e padrão visual em toda a interface.

Documentação do Design System GOV.BR mostrando o componente Button, suas variações e orientações de uso.
Exemplo real: o Design System GOV.BR documenta o Button com variações de botões com rótulo e circulares e orienta nome acessível para botões apenas com ícone, foco visível e teclado. Isso mostra que a forma depende do contexto, mas a função precisa continuar identificável. Fonte: Padrão Digital de Governo — Button: https://www.gov.br/ds/components/button

Porque isso importa?

Um botão precisa comunicar o que acontecerá após sua ativação. A pesquisa aplicada da Baymard destaca a importância de microcopy descritiva, consistência e diferenciação visual para que as pessoas compreendam a intenção dos botões. Seus resultados são especialmente contextualizados para e-commerce.

Para acessibilidade, o botão precisa ter nome, função e estado identificáveis programaticamente. A WCAG 2.2 exige que essas informações estejam disponíveis para tecnologias assistivas.

Quando existe texto visível, o nome acessível deve conter esse texto. Isso permite que pessoas que usam comando de voz acionem o botão pelo rótulo que enxergam.

Use ícone e texto quando a ação não for imediatamente reconhecível, quando o botão estiver em uma tela pública ou para públicos variados, quando a ação tiver consequência importante, quando houver várias ações próximas ou quando o ícone puder ter interpretações diferentes.

O texto também é preferível quando a interface precisa funcionar sem depender de tooltip ou quando o rótulo ajuda na tradução e na compreensão do fluxo.

Considere usar apenas o ícone quando a ação for muito familiar, o contexto tornar a função evidente, o padrão for repetido em uma barra de ferramentas e o espaço for realmente limitado.

Mesmo nesses casos, o botão precisa ter nome acessível, foco visível e comportamento testado com pessoas do público.

Evite o botão somente com ícone quando a pessoa precisar passar o mouse para descobrir sua função, quando o símbolo for ambíguo ou quando a ação envolver perda de dados, dinheiro, privacidade ou acesso.

Página de acessibilidade do Primer diferenciando links e botões e mostrando orientação para controles com ícone.
Exemplo real: o GitHub Primer orienta que botões tenham rótulos claros e que ícones auxiliares não substituam a finalidade da ação. Para botões somente com ícone, o nome acessível deve comunicar a mesma função. Fonte: Primer — Button Accessibility: https://primer.style/product/components/button/accessibility/

Recomendações

Faça

Práticas recomendadas
  • Escreva a ação.
  • Use o ícone como apoio.
  • Mantenha nomes consistentes.
  • Garanta nome acessível.
  • Teste compreensão.
  • Considere tradução.
Wireframe minimalista de um botão principal com ícone e rótulo visual e um controle compacto de ícone em uma barra contextual
Exemplo correto: o texto acompanha o ícone na ação principal, enquanto o ícone isolado aparece apenas em um contexto compacto e reconhecível. Ilustração didática da CamaraUX.

Evite

Práticas a evitar
  • Não use ícone ambíguo.
  • Não dependa só de tooltip.
  • Não troque o nome da ação.
  • Não misture padrões sem motivo.
  • Não esconda o foco.
  • Não trate ícone como decoração.
Wireframe minimalista de uma interface com vários botões somente com ícones ambíguos e sem hierarquia clara
Exemplo incorreto: várias ações dependem de ícones ambíguos, sem rótulo visível, sem contexto suficiente e sem hierarquia clara. Ilustração didática da CamaraUX.
Página Buttons das Apple Human Interface Guidelines explicando como comunicar a função de botões com símbolos e rótulos.
Exemplo real: as Apple Human Interface Guidelines apresentam o botão como controle que pode comunicar sua função com símbolo, rótulo ou ambos. A referência reforça que a escolha depende do contexto e da reconhecibilidade da ação. Fonte: Apple HIG — Buttons: https://developer.apple.com/design/human-interface-guidelines/buttons

Acessibilidade

Prefira o elemento HTML nativo <button>.

Quando o botão tiver texto visível, use esse texto como nome acessível e trate o ícone como decoração quando ele não acrescentar informação.

Quando o botão for somente um ícone, forneça um nome acessível que descreva a ação, como “Fechar”, e não o símbolo “X”. O nome deve comunicar a função, não a aparência do ícone.

O botão deve funcionar com teclado, incluindo Tab, Enter e Espaço. Não dependa apenas de hover. O rótulo e a orientação precisam funcionar também com foco de teclado, toque, leitor de tela e comando de voz.

Checklist

  • A ação está clara antes da escolha do ícone?
  • O ícone reforça o significado do texto?
  • O botão precisa de texto para este público?
  • O ícone sozinho é reconhecível neste contexto?
  • O nome acessível descreve a ação?
  • O nome acessível contém o texto visível?
  • O comportamento funciona sem hover?
  • A função usa o mesmo nome em toda a interface?
  • O botão continua compreensível em telas estreitas?
  • O padrão foi testado com teclado, voz e leitor de tela?

Referências

W3C. Label in Name. Explica que o nome acessível deve conter o texto visível do controle, favorecendo especialmente o uso por comando de voz. Consultar a fonte.

W3C. Name, Role, Value. Define que o nome, a função e o estado dos componentes devem ser determinados programaticamente para tecnologias assistivas. Consultar a fonte.

W3C ARIA Authoring Practices Guide. Names and Descriptions. Recomenda preferir texto visível, nomes concisos e a descrição da função em vez da aparência de um ícone. Consultar a fonte.

W3C ARIA Authoring Practices Guide. Button Pattern. Documenta o nome acessível de botões, o uso do elemento nativo e a operação por teclado. Consultar a fonte.

Baymard Institute. Button Design. Reúne pesquisa aplicada e benchmarking de e-commerce sobre intenção, microcopy, consistência e diferenciação de botões. É uma referência contextual para produtos digitais, não uma regra universal para todos os setores. Consultar a fonte.

IBM Carbon Design System. Button Accessibility. Mostra como um design system documenta rótulos, foco, hover e operação por teclado em botões somente com ícone. É um exemplo de implementação, não evidência independente de usabilidade. Consultar a fonte.

GitHub Primer. Button Accessibility. Recomenda rótulos claros e descritivos, sem depender excessivamente de ícones ou pistas visuais, e orienta a manutenção do nome acessível. É uma referência de implementação de produto. Consultar a fonte.

Veja também

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