Botão com ícone: confira o nome da ação

Um botão com ícone precisa comunicar a ação que executa. A lupa pode representar pesquisar; o “X”, fechar um painel. Na revisão, confira tanto o que a pessoa vê quanto o nome que o componente apresenta às tecnologias assistivas. O desenho do ícone não basta para concluir que essa identificação está correta.

O nome acessível é a identificação que o software pode associar ao controle para apresentá-lo ao usuário. Ele pode vir do texto do próprio botão ou de uma associação feita na implementação. Esse nome precisa corresponder à tarefa, sem obrigar a pessoa a adivinhar o significado do desenho.

O guia de landing page relaciona oferta e próximo passo. Aqui, aprofundamos a identificação de controles com ícones. Para escolher primeiro se a interação deve navegar ou executar uma ação, consulte link ou botão no site.

Dê nome à ação antes de revisar o ícone

Escreva o resultado esperado numa frase curta: executar a pesquisa, fechar os detalhes da oferta ou mostrar opções de filtro. “Lupa” e “xis” descrevem o desenho, mas deixam de fora a função. Use essa frase para alinhar conteúdo, design e implementação.

O guia da W3C WAI sobre nomes e descrições acessíveis recomenda nomes que comuniquem função e prefere texto visível quando ele é adequado. Se o contexto permite escrever “Pesquisar” junto da lupa, essa opção também ajuda quem vê o ícone e não reconhece seu significado.

No planejamento, evite nomes extensos que tentem explicar toda a oferta. “Fechar detalhes da oferta” identifica a ação e seu objeto. Uma condição comercial, um prazo de atendimento ou uma instrução longa deve ser apresentada no lugar pertinente, sem sobrecarregar o nome do controle.

Esses nomes são propostas para os contextos declarados. Um ícone parecido pode ter outra função numa página diferente. Se a lupa apenas abre o campo de pesquisa, por exemplo, o nome deve antecipar essa abertura, e não afirmar que a consulta já será executada.

Exemplo fictício: três versões para revisar

Exemplo fictício: uma equipe prepara uma página de oferta com pesquisa e um painel de detalhes. O desenho abaixo compara nomes previstos, sem representar um site funcional ou uma avaliação de usuário. A primeira versão usa apenas X para fechar o painel. A segunda combina lupa e texto “Pesquisar”. A terceira mostra “Pesquisar”, mas recebe o nome “Enviar” na implementação proposta.

1. X simbólico: nome da função

Proposta fictícia para fechar o painel. Nome previsto: Fechar detalhes da oferta.

2. Lupa com texto Pesquisar

Nome previsto: Pesquisar. O nome preserva o texto visível e corresponde à consulta prevista.

3. Pesquisar com nome Enviar

Divergência que precisa de revisão: o nome troca as palavras exibidas no controle.

Limite da comparação

Desenhos estáticos. Nome calculado, funcionamento e tecnologias assistivas dependem de conferência na implementação.

Descrição da figura

Na primeira linha, um X simbólico representa fechar o painel de detalhes, e o nome previsto é Fechar detalhes da oferta. Na segunda, uma lupa acompanhada do texto Pesquisar tem o nome previsto Pesquisar, preservando as palavras visíveis. Na terceira, a aparência continua com Pesquisar, mas o nome proposto é Enviar; essa divergência precisa de revisão. São desenhos estáticos de propostas fictícias, não controles funcionais nem evidência de nome calculado pelo navegador. A conferência da implementação deve incluir o comportamento e as condições de uso pertinentes.

Na primeira versão, a equipe deve fornecer uma identificação da ação, como “Fechar detalhes da oferta”, e conferir o nome resultante no componente. Na segunda, o texto “Pesquisar” já expressa a ação prevista. Na terceira, o nome “Enviar” troca as palavras que a pessoa vê e precisa ser revisto.

A explicação do critério 2.5.3 da WCAG 2.2, Label in Name trata de controles com rótulos que incluem texto: o nome deve conter esse texto visível. Essa correspondência ajuda quem usa as palavras da tela em comandos de voz. O critério não exige essa comparação quando não existe rótulo de texto visível, como no X simbólico usado neste exemplo; a necessidade de um nome adequado continua.

Por isso, não avalie os três casos pela mesma pergunta. Para o X, confira se a função pode ser identificada. Para o botão com “Pesquisar”, confira também se essas palavras permanecem no nome. O nome acessível pode ter uma informação adicional pertinente, desde que preserve o rótulo e não anuncie outra ação.

Peça à implementação o nome resultante

Para um botão que contém apenas um ícone, a implementação pode usar um recurso de nomeação, como aria-label. No caso fictício de fechar o painel, esse atributo pode fornecer “Fechar detalhes da oferta”. Ele não cria o fechamento nem substitui a programação e a conferência do comportamento.

<button type="button" aria-label="Fechar detalhes da oferta">
  <span aria-hidden="true">×</span>
</button>

O trecho é apresentado como texto, sem controle funcional neste artigo. Nele, o símbolo é separado da identificação da ação. A equipe ainda precisa implementar o fechamento, integrar o controle ao painel e testar foco, teclado e continuidade da tarefa nas condições pertinentes.

Quando o botão já tem texto adequado, use esse conteúdo como ponto de partida e evite acrescentar um nome diferente sem necessidade. Os atributos de nomeação podem substituir o nome vindo do conteúdo. Uma correção aparente, feita apenas para preencher um campo de acessibilidade no construtor, pode introduzir a divergência “Pesquisar” versus “Enviar”.

Se houver versões em outros idiomas ou várias ocorrências do componente, inclua-as na conferência. O texto da tela pode mudar enquanto um nome definido separadamente permanece antigo. Registre qual versão foi examinada para que a correção alcance o controle realmente usado na página.

Teste nome, teclado e resultado separadamente

Na página implementada, peça à equipe que examine o controle na árvore de acessibilidade do navegador e compare o nome calculado com a especificação. Esse painel mostra informações que o navegador expõe; não equivale a ouvir o anúncio em todas as combinações de leitor de tela e navegador.

Percorra o controle com teclado, observe o foco e confira o que acontece ao ativá-lo. O padrão de botão da W3C WAI indica Enter e Espaço para ativação quando o botão está com foco. Depois, a continuidade depende da ação realizada. Um painel fechado exige uma conferência diferente de uma pesquisa que mostra resultados.

No exemplo, feche os detalhes e confira se a pessoa consegue continuar a tarefa. No campo de pesquisa, diferencie abrir a busca, executar a consulta e apresentar o resultado. Para testes que enviam dados ou alteram registros, prepare um ambiente e um cenário autorizados antes de acionar operações reais.

Inclua os modos de uso pertinentes ao público, como leitor de tela e controle por voz, com pessoas e recursos adequados. Uma inspeção do nome ou um teste por teclado cobre parte da revisão. Registre o alcance de cada teste e as pendências sem apresentar essas etapas como auditoria completa de acessibilidade.

Confira o contexto no celular e guarde a evidência

Veja se o texto continua visível, se o ícone ficou isolado após a adaptação de tela e se há outros controles próximos. Se o projeto retirar a palavra “Pesquisar” no celular, a equipe precisa revisar essa condição, incluindo a identificação e a compreensão do controle. Não presuma que a versão maior representa todas as apresentações.

Confira também o estado depois da ação e os elementos que podem cobrir o controle ou o resultado. Se houver um problema, registre a página, a condição inicial, o que foi acionado, o que apareceu e o ajuste esperado. Essa evidência ajuda a reproduzir a falha e conferir a correção.

Página, seção, versão e tamanho de tela: [registrar]
Ação esperada e modo de reconhecer o resultado: [descrever]
Ícone e texto visível: [identificar]
Nome acessível esperado: [definir]
Nome calculado pelo navegador: [conferir na implementação]
Correspondência com o texto visível, quando existe: [verificar]
Percurso por teclado e visibilidade do foco: [testar]
Resultado da ativação e continuidade: [testar]
Condições com leitor de tela e voz efetivamente testadas: [registrar]
Idiomas e outras ocorrências examinados: [anotar]
Problema, responsável e ajuste: [definir]
Nova conferência e evidência: [guardar]
Limites e pendências: [explicitar]

Perguntas frequentes sobre botão com ícone

O nome de um X deve ser “xis”?

Se o símbolo fecha um painel, o nome deve comunicar essa função no contexto, como Fechar detalhes da oferta. Descrever apenas o desenho deixa de fora a ação.

Todo botão precisa receber aria-label?

Não. Um botão com texto adequado pode obter o nome desse conteúdo. Atributos adicionais devem ser usados com cuidado, pois podem substituir o nome e criar divergência com o texto visível.

Posso mostrar Pesquisar e usar Enviar como nome?

Essa divergência deve ser revista. Quando o rótulo inclui texto, o critério Label in Name exige que o nome contenha o texto apresentado visualmente. O nome também precisa corresponder à ação.

Conferir o nome comprova acessibilidade completa?

Não. Também é necessário examinar operação, foco, resultado e demais condições pertinentes. Inspeção no navegador, teste por teclado e teste com tecnologias assistivas têm alcances próprios, que devem ser registrados.

Se sua página precisa de chamadas mais claras, converse conosco sobre conteúdo e percurso do visitante. Podemos ajudar a definir ações e rótulos. Implementação, testes com tecnologias assistivas e avaliação com pessoas precisam de responsabilidades e escopos combinados.