# A primeira regra de ARIA aprendida da maneira difícil > Um atributo ARIA bem-intencionado quebrou a acessibilidade de um componente que passava em todos os testes. Entenda a primeira regra de ARIA. URL: https://dpw.dev/acessibilidade/a-primeira-regra-de-aria-aprendida-da-maneira-dificil/ Publicado em: 2026-03-23 Categoria: acessibilidade Autor: Tárcio Zemel Há algum tempo, um desenvolvedor publicou um componente que parecia acessível por todas as métricas possíveis de testar. A navegação por teclado funcionava; roles ARIA estavam aplicados corretamente; auditorias automatizadas passavam sem uma única reclamação. E, no entanto, um usuário de leitor de tela não conseguia descobrir como acioná-lo. Ao testar com navegação apenas por teclado e NVDA, o resultado era o mesmo: a interação simplesmente não se comportava como esperado. > Artigo baseado em [I Learned The First Rule of ARIA the Hard Way](https://css-tricks.com/i-learned-the-first-rule-of-aria-the-hard-way/). Nada na checklist apontou um erro. Tecnicamente, tudo estava "certo". Mas, na prática, o componente não era previsível. Aqui está uma versão simplificada do componente que causou o problema: [Exemplo no CodePen](https://codepen.io/anon/pen/qENBxzP) E a correção foi muito mais fácil do que o esperado. Bastou deletar o atributo ARIA `role` que havia sido adicionado com as melhores intenções. [Exemplo no CodePen](https://codepen.io/anon/pen/LEZYdwq) Essa experiência mudou a forma de pensar sobre acessibilidade. A maior lição foi esta: **HTML semântico faz muito mais trabalho de acessibilidade do que costumamos dar crédito** — e ARIA é simples de abusar quando usada tanto como atalho quanto como suplemento. A primeira regra de ARIA já é bem conhecida: não use. Bom, use. Mas não se os benefícios e funcionalidades acessíveis necessários já estiverem embutidos — que era o caso antes de adicionar o atributo `role`. O que segue é uma descrição passo a passo do que aconteceu, porque esse erro é, na verdade, uma prática bem comum. Existem muitos artigos por aí que dizem exatamente a mesma coisa, mas frequentemente ajuda internalizar ouvindo através de uma experiência real. **Nota:** O artigo original foi testado usando navegação por teclado e um leitor de tela (NVDA) para observar o comportamento real de interação entre elementos nativos e modificados por ARIA. ## 1: Comece com a marcação mais simples possível Trata-se apenas de uma página mínima com um único ` ``` Essa única linha dá uma quantidade surpreendente de coisas de graça: * Ativação por teclado com as teclas Enter e Space * Comportamento correto de foco * Uma `role` que a tecnologia assistiva já entende * Anúncios consistentes entre leitores de tela Nesse ponto, não há ARIA (e isso é intencional). Mas já havia uma classe existente para estilizar botões no CSS, então ela foi adicionada: ```html ``` ## 2: Observe o comportamento nativo antes de adicionar qualquer coisa Com apenas o elemento nativo no lugar, três coisas foram testadas: * Apenas teclado (Tab, Enter, Space) * Um leitor de tela (ouvindo como o controle é anunciado) * Ordem de foco dentro da página Tudo se comportou de forma previsível. O navegador estava fazendo exatamente o que os usuários esperam. Esse passo importa porque estabelece uma referência. Se algo quebrar depois, fica claro que não foi o HTML que causou. Na verdade, é possível ver que tudo está em perfeita ordem inspecionando o elemento no painel de Acessibilidade do DevTools.

Painel de Acessibilidade do DevTools mostrando o role acessível de button com um label de Semantic Button.

## 3: Adicione ARIA bem-intencionado O problema apareceu ao tentar fazer o botão se comportar como um link: ```html ``` A decisão foi motivada por razões de estilização e roteamento. Esse botão precisava ser estilizado um pouco diferente da classe `.cta` padrão, e o atributo ARIA pareceu uma opção melhor do que uma classe modificadora Dá para perceber como a estilização começou a ditar e influenciar a funcionalidade. Um ` ``` Parece fácil: se é uma ação, use um ` ``` Assim, simples assim, o elemento foi estilizado como necessário e o usuário que reportou o problema confirmou que tudo funcionava como esperado. Foi um erro inadvertido nascido de um mal-entendido básico sobre o lugar de ARIA na stack. ## Por que isso continua acontecendo Atributos ARIA são usados para definir a natureza de algo, mas eles não redefinem o comportamento padrão dos elementos nativos. Quando a semântica é sobrescrita, silenciosamente assume-se a responsabilidade por: * interações de teclado, * gerenciamento de foco, * anúncios esperados e * peculiaridades específicas de plataforma. Essa é uma grande superfície de manutenção, e é por isso que pequenas mudanças em ARIA podem ter efeitos desproporcionais e imprevisíveis. ## Uma regra a seguir Aqui está o fluxo de trabalho que mais economiza tempo e bugs: 1. Use HTML nativo para expressar a intenção. 2. Teste com teclado e um leitor de tela. 3. Adicione ARIA apenas para comunicar estado ausente, não para redefinir roles. Se ARIA parecer estar fazendo trabalho pesado, geralmente é um sinal de que a marcação está lutando contra o navegador. ## Onde ARIA realmente pertence Um exemplo seria um simples widget de disclosure usando um `