Uma checklist curta e opinativa para botões web acessíveis

O problema com os conselhos sobre acessibilidade de botões

A maior parte das orientações sobre acessibilidade de botões cai em dois campos: ou é uma interpretação de 40 páginas das WCAG que ninguém lê, ou é uma sugestão vaga para "tornar os botões acessíveis" sem passos acionáveis. Nenhuma das duas ajuda quando você está lançando uma funcionalidade na quinta-feira.

Esta checklist cobre as cinco falhas mais comuns de acessibilidade em botões que vemos em produção. Ela não vai transformar você em especialista em WCAG, mas vai detectar os problemas que realmente afetam os usuários.

1. Use o elemento button para botões

Se ele se comporta como um botão, deve ser um elemento <button>. Não um <div> com onclick, não um <span> com role="button", não um <a> com href="#" e preventDefault.

O elemento <button> oferece navegação por teclado, gerenciamento de foco e anúncios para leitores de tela sem custo adicional. Quando você usa um <div>, está reconstruindo tudo isso do zero — e vai errar.

A única exceção: se a ação navega para uma nova página ou altera a URL, use um elemento <a>. Links e botões são semanticamente diferentes. Usuários de leitores de tela navegam por tipo de elemento, e esperam que botões executem ações e links naveguem.

2. Faça o alvo de acionamento ter pelo menos 44×44 pixels

A WCAG 2.5.5 (Nível AAA) exige que elementos interativos tenham um tamanho mínimo de alvo de 44×44 pixels CSS. Não se trata do tamanho visual — trata-se da área clicável.

Você pode ter um botão visualmente pequeno com padding adequado, ou pode ampliar o alvo de acionamento com um pseudoelemento. O que importa é que o usuário não precise mirar com precisão.

Usuários em dispositivos móveis, pessoas com deficiências motoras e qualquer pessoa usando um dispositivo em movimento vão errar alvos pequenos. Um botão de ícone de 24×24 pixels pode parecer limpo, mas é uma falha de usabilidade.

3. Forneça estados de foco visíveis que não sejam apenas os padrões do navegador

O anel de foco padrão do navegador é melhor do que nada, mas é inconsistente entre navegadores e muitas vezes invisível contra certos fundos. Você precisa de um estado de foco personalizado que funcione no seu design system.

Um bom indicador de foco tem três qualidades:

• Alto contraste: pelo menos 3:1 em relação às cores adjacentes
• Deslocamento visível: não fica oculto pela própria borda ou pelo fundo do botão
• Formato consistente: os usuários devem reconhecê-lo como indicador de foco em toda a sua interface

Não remova outline: none sem substituí-lo por algo melhor. E não torne os estados de foco tão sutis que só você consiga vê-los em condições perfeitas de iluminação.

4. Escreva rótulos de botão que façam sentido fora de contexto

Usuários de leitores de tela muitas vezes navegam saltando entre botões. Quando fazem isso, ouvem uma lista de rótulos de botões sem o contexto ao redor.

Um botão rotulado como "Saiba mais" é inútil nessa lista. O mesmo vale para "Clique aqui" ou "Enviar". O rótulo deve descrever a ação: "Baixar a checklist de acessibilidade", "Assinar atualizações", "Excluir este comentário".

Se o seu design exige um rótulo visual curto, use aria-label para fornecer uma alternativa descritiva. Mas a melhor solução é escrever rótulos que funcionem para todos.

Para botões somente com ícone, aria-label é obrigatório. Um botão com apenas um ícone de lupa precisa de aria-label="Search" ou texto equivalente. O ícone não é acessível para leitores de tela.

5. Garanta contraste de cor suficiente

A WCAG 2.1 exige uma taxa de contraste de pelo menos 4.5:1 para texto normal e 3:1 para texto grande (18pt ou 14pt em negrito). Rótulos de botões geralmente são texto normal.

Texto cinza-claro em um botão branco falha. Azul pálido em um fundo azul-claro falha. Essas combinações podem parecer sofisticadas, mas excluem usuários com baixa visão, daltonismo ou qualquer pessoa vendo a tela sob luz solar intensa.

Use um verificador de contraste durante o design, não depois do lançamento. Corrigir problemas de contraste em produção é caro porque muitas vezes exige mudanças no design system.

Se você trabalha com ferramentas de processamento de imagem, o processamento no lado do cliente pode ajudar a preservar a privacidade ao gerar ativos visuais acessíveis — especialmente ao testar combinações de cores ou gerar estados de pré-visualização.

O que esta checklist não cobre

Esta lista é deliberadamente incompleta. Ela não cobre semântica de estados desabilitados, estados de carregamento, tratamento de erros ou padrões complexos de botões, como botões divididos ou gatilhos de dropdown. Esses padrões precisam de suas próprias orientações.

Ela também não cobre a questão mais ampla de quando usar um botão em vez de outros elementos interativos. Para isso, você precisa entender HTML semântico e a árvore de acessibilidade — tópicos que merecem seus próprios artigos.

O que ela cobre são os ganhos mais fáceis: os erros que aparecem em quase toda revisão de código, que afetam mais usuários e que são mais fáceis de corrigir durante o desenvolvimento.

Como integrar isso ao seu fluxo de trabalho

Checklists de acessibilidade só funcionam se fizerem parte do processo de desenvolvimento, não se forem acrescentadas depois. Veja como fazer isso acontecer:

No design: adicione estados de foco e anotações de alvo de acionamento aos seus arquivos de design. Não deixe isso para os desenvolvedores adivinharem.

Na revisão de código: verifique elementos <button>, aria-label em botões de ícone e CSS de estado de foco. Isso é rápido de identificar.

Nos testes: percorra sua interface com a tecla Tab. Se você não consegue alcançar um botão ou não consegue ver onde está o foco, seus usuários também não conseguirão.

Na documentação: inclua requisitos de acessibilidade de botões na sua biblioteca de componentes. Torne mais fácil fazer a coisa certa do que fazer a coisa errada.

Se você está depurando problemas em produção, ferramentas para inspecionar cabeçalhos HTTP e redirecionamentos podem ajudar a entender como tecnologias assistivas estão interpretando sua marcação — especialmente ao solucionar problemas de gerenciamento de foco após a navegação.

O custo de pular este trabalho

Botões inacessíveis não apenas falham na conformidade com as WCAG — eles quebram fluxos de trabalho. Um usuário que não consegue clicar em um botão de envio não consegue concluir um formulário. Um usuário que não consegue ver estados de foco não consegue navegar com teclado. Um usuário que não consegue distinguir o texto do botão do fundo não consegue ler o rótulo.

Esses não são casos extremos. Aproximadamente 15% da população global tem alguma forma de deficiência, e limitações temporárias (mouse quebrado, luz solar intensa, segurar um bebê) acabam afetando todo mundo em algum momento.

A boa notícia é que a acessibilidade de botões é, em grande parte, um conjunto de problemas já resolvidos. Você não precisa inventar novos padrões nem esperar suporte dos navegadores. Só precisa usar a plataforma corretamente e testar seu trabalho.

Principais conclusões

• Use elementos <button> para botões e elementos <a> para navegação — a diferença semântica importa para tecnologias assistivas
• Garanta que os alvos de acionamento tenham pelo menos 44×44 pixels CSS para acomodar deficiências motoras e usuários móveis
• Forneça estados de foco visíveis e de alto contraste que funcionem em todo o seu design system
• Escreva rótulos de botão que façam sentido quando lidos isoladamente, e use aria-label para botões somente com ícone
• Verifique o contraste de cores durante o design, não depois do lançamento, para evitar retrabalho caro

FAQ

Q: Posso usar role="button" em um <div> se eu adicionar manipuladores de teclado?

A: Você pode, mas não deveria. Você precisará tratar Enter, Espaço, gerenciamento de foco e estados desabilitados manualmente — e inevitavelmente vai deixar algo passar. O elemento <button> faz tudo isso corretamente por padrão. Use-o.

Q: E quanto a botões que alternam estado, como um botão de reproduzir/pausar?

A: Use aria-pressed="true" ou aria-pressed="false" para indicar o estado atual. O rótulo do botão também deve refletir a ação que acontecerá no clique ("Pausar" quando estiver reproduzindo, "Reproduzir" quando estiver pausado), não o estado atual. Usuários de leitores de tela precisam saber o que o botão fará, não em que estado o sistema está.

Q: Botões desabilitados precisam atender aos requisitos de contraste?

A: A WCAG 2.1 isenta controles desabilitados dos requisitos de contraste (1.4.3), mas isso é controverso. Botões desabilitados com baixo contraste são difíceis de perceber para todos. Se você vai mostrar um botão desabilitado, torne-o legível. Melhor ainda, oculte-o ou explique por que ele está desabilitado.

Q: Como testo a acessibilidade de botões sem um leitor de tela?

A: Use o teclado. Percorra a interface com Tab e verifique se você consegue alcançar todos os botões, ver onde está o foco e ativar botões com Enter ou Espaço. Isso detecta a maioria dos problemas. Para testes mais aprofundados, use o inspetor de acessibilidade no Chrome ou no Firefox DevTools para verificar a função e o rótulo computados.

Q: Qual é a diferença entre aria-label e aria-labelledby?

A: aria-label fornece uma string de texto diretamente. aria-labelledby referencia o ID de outro elemento cujo conteúdo de texto se torna o rótulo. Use aria-labelledby quando o texto do rótulo já existir em outro lugar no DOM. Use aria-label quando você precisa fornecer um rótulo que não está visível na tela.

Fontes

• Web Content Accessibility Guidelines (WCAG) 2.1 — W3C
• Inclusive Components: Toggle Buttons — Heydon Pickering
• The ARIA Button Pattern — W3C ARIA Authoring Practices Guide
• WebAIM: Keyboard Accessibility — WebAIM