Ícones sem texto: quando podem ser usados

Ícones sem texto podem economizar espaço, mas só funcionam quando a ação é reconhecível, nomeada para tecnologias assistivas e fácil de testar. Veja quando usar e quando manter um rótulo visível.

Ilustração minimalista comparando um controle com ícone familiar e uma ação que precisa de explicação contextual.
Nível de impácto
Alto
Status
Usar com atenção
Nível de evidênica
Forte evidência

Contexto

Ícones podem reduzir a densidade visual e acelerar a varredura de barras de ferramentas, ações recorrentes e controles compactos. Eles também podem ser interpretados de formas diferentes, perder significado fora de um contexto conhecido ou parecer decorativos quando a interface não explica sua função.

O problema não é usar um ícone sem texto em qualquer situação. O problema é retirar o rótulo visível sem verificar se a ação continua compreensível para as pessoas que usam a interface, incluindo quem não enxerga o ícone, quem amplia a tela, quem usa comando de voz ou quem acessa a interface em um dispositivo diferente.

Trate o botão só com ícone como uma decisão contextual, não como um padrão visual automático. Comece pela ação e escreva o verbo que a pessoa precisa entender, como pesquisar, fechar, excluir, compartilhar, filtrar ou salvar.

Use ícone sozinho apenas quando a convenção for forte. A ação deve ser reconhecível no produto e no contexto, como fechar uma janela, pesquisar ou reproduzir mídia.

Forneça um nome acessível. Use texto visível quando possível; quando o controle for realmente iconográfico, use um nome curto e específico com texto visualmente oculto, aria-label ou aria-labelledby, conforme a implementação.

Ofereça ajuda visual. Um tooltip ou outra indicação contextual pode explicar a ação para quem não reconhece o ícone, mas não substitui o nome acessível.

Garanta estados e interação mantendo foco visível, contraste, área de toque, estado pressionado ou selecionado e feedback após a ação.

Nomeie o objeto quando necessário. Em listas repetidas, use nomes como “Excluir relatório mensal”, não apenas “Excluir”.

Teste a compreensão verificando se as pessoas identificam a ação sem depender de explicação do designer e se a operação funciona com teclado, leitor de tela, zoom e toque.

Regra prática

Se o ícone precisa ser explicado antes de a pessoa agir, mantenha o rótulo visível. Se a ação é familiar, o contexto é claro e o controle continua nomeado e operável, o ícone sozinho pode ser adequado.

Base da recomendação

W3C exige nome acessível para controles interativos e recomenda priorizar texto visível quando ele puder nomear a ação. Baymard observa, em pesquisas de usabilidade de comércio eletrônico, que ícones acompanhados de texto reduzem ambiguidades e que botões precisam preservar intenção, foco e área de toque. Primer, Apple e GOV.BR documentam soluções contextuais para botões iconográficos: nome acessível, tooltip ou texto alternativo, foco e tamanho adequado. Essas fontes sustentam a acessibilidade e os critérios de decisão, mas não transformam nenhum ícone em universal.

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 e mostra variações com rótulo e formato circular. A orientação também exige nome acessível para botões só com ícone e recomenda tooltip, foco visível, teclado e área mínima de toque. Fonte: Padrão Digital de Governo — Button: https://www.gov.br/ds/components/button

Porque isso importa?

O ícone é percebido visualmente, mas a ação precisa continuar identificável por diferentes formas de acesso. Sem nome acessível, um botão pode ser anunciado apenas como “botão” ou com um nome vazio. Sem rótulo ou ajuda contextual, pessoas podem hesitar, errar a ação ou ignorar controles importantes.

O risco aumenta quando ícones semelhantes representam ações diferentes, quando o controle aparece fora do contexto em que foi aprendido, quando a ação é destrutiva ou quando há muitos controles compactos próximos. Um rótulo visível não é excesso quando evita interpretação, retrabalho ou perda de dados.

  • Use ícone sozinho para ações muito familiares no contexto.
  • Use em barras de ferramentas com pouco espaço e ações recorrentes.
  • Use quando o ícone tiver convenção consolidada no produto.
  • Use quando houver nome acessível e foco visível.
  • Use quando tooltip ou contexto próximo ajudar quem não reconhecer o ícone.
  • Use com aria-pressed ou outro estado quando o controle for alternável.
  • Evite ícone sozinho para ações novas ou pouco frequentes.
  • Evite em ações destrutivas sem confirmação ou identificação clara.
  • Evite quando o ícone tiver mais de uma interpretação plausível.
  • Evite depender apenas de tooltip para nomear o controle.
  • Evite controles pequenos, agrupados ou sem foco visível.
  • Evite usar o mesmo ícone para ações diferentes.
Página de acessibilidade do Primer diferenciando links e botões e mostrando orientação para controles com ícone.
Exemplo real: o Primer mostra que um botão com ícone pode manter um nome acessível visualmente oculto, desde que a ação continue sendo anunciada para tecnologias assistivas. A captura contextualiza a implementação sem transformar o tooltip em único recurso de acessibilidade. Fonte: GitHub Primer — Links and buttons: https://www.primer.style/accessibility/design-guidance/links-and-buttons/

Recomendações

Faça

Práticas recomendadas
  • Nomeie a ação.
  • Prefira texto visível quando houver dúvida.
  • Use ícones conhecidos no contexto.
  • Adicione nome acessível.
  • Mostre foco e estados.
  • Teste com pessoas.
Wireframe minimalista mostrando botão só com ícone familiar, área de toque ampla, foco visível e ajuda contextual.
Exemplo correto: o ícone é familiar, o botão tem área de toque ampla, foco visível e ajuda contextual sem depender apenas da aparência.

Evite

Práticas a evitar
  • Esconder rótulos sem validar.
  • Usar ícone ambíguo.
  • Depender só de tooltip.
  • Repetir ações sem diferenciar o nome.
  • Reduzir a área de toque.
  • Remover o foco.
Wireframe minimalista mostrando muitos controles pequenos e ambíguos, sem espaçamento, foco ou rótulos visíveis.
Exemplo incorreto: ícones pequenos e ambíguos aparecem juntos sem rótulo visível, espaçamento suficiente ou foco perceptível.
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 um controle de ação e orientam comunicar sua função com símbolo, rótulo ou ambos. A captura mostra a referência de produto que ajuda a decidir quando um ícone pode complementar ou substituir o texto, sempre conforme o contexto. Fonte: Apple Human Interface Guidelines — Buttons: https://developer.apple.com/design/human-interface-guidelines/buttons

Acessibilidade

Um botão só com ícone precisa de um nome acessível que comunique a ação, não a forma do símbolo. Prefira texto visível quando ele puder existir. Quando não houver rótulo visível, use texto visualmente oculto dentro do botão ou uma técnica adequada de nomeação, como aria-label ou aria-labelledby. Não escreva “botão” no nome: a tecnologia assistiva já anuncia o papel do controle.

Se o ícone for apenas decorativo ao lado de um rótulo visível, o ícone deve ser ocultado da tecnologia assistiva para não duplicar a informação. Se o ícone for a única representação visual da ação, ele não é decorativo: o nome precisa descrever a função, por exemplo “Fechar”, “Pesquisar” ou “Salvar alterações”, conforme o contexto.

Garanta teclado, foco visível, contraste, área de toque e estados. Em controles de alternância, exponha o estado atual com a semântica apropriada. Não trate tooltip como equivalente a nome acessível: ele ajuda quem vê e aponta o cursor, mas não cobre todos os modos de acesso nem todos os dispositivos.

Checklist

  • A ação é familiar neste contexto?
  • O ícone é inequívoco para o público?
  • O botão possui nome acessível?
  • O nome descreve a ação, não o desenho?
  • O nome diferencia controles repetidos?
  • O ícone decorativo está oculto da tecnologia assistiva?
  • Existe rótulo visível quando a ação é ambígua?
  • O tooltip é apoio, não a única identificação?
  • O foco permanece visível?
  • A área de toque é suficiente?
  • Os estados são perceptíveis sem depender só de cor?
  • O controle funciona com teclado, zoom, toque e leitor de tela?

Referências

W3C WAI-ARIA APG: Providing Accessible Names and Descriptions. Explica que controles interativos precisam de nome acessível, recomenda preferir texto visível e orienta nomear a função, não a forma do ícone. Consultar nomes e descrições acessíveis.

W3C WAI: Button Pattern. Documenta o nome acessível de botões, estados como aria-pressed e comportamentos de foco em mudanças de contexto. Consultar o padrão Button.

W3C WAI: Image button has accessible name. Relaciona nome não vazio de botões de imagem aos critérios WCAG 1.1.1 e 4.1.2. Consultar a regra de botão de imagem.

Baymard Institute: Accounts & Self-Service UX — Consider Having an “Icon-Based” Dashboard. Relata que ícones acompanhados de texto ajudam a esclarecer o destino e que o uso inconsistente de ícones pode fazer itens sem ícone serem ignorados. Consultar a pesquisa sobre dashboards com ícones.

Baymard Institute: Button Design. Reúne achados de pesquisa sobre intenção, foco, estados e área de toque de botões. Consultar boas práticas de botões.

GitHub Primer: Links and buttons. Mostra como um nome visualmente oculto pode tornar um icon button compreensível para tecnologias assistivas. Consultar Links and buttons.

Apple Human Interface Guidelines: Buttons. Orienta comunicar claramente a função de botões com símbolo, rótulo ou ambos e manter área de interação adequada. Consultar Buttons.

Padrão Digital GOV.BR: Button. Documenta botão circular, aria-label, ícones decorativos, tooltip, foco, teclado e área mínima de toque. Consultar o componente Button.

Veja também

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