O que são atributos ARIA? WAI-ARIA explicado de forma simples

ARIA significa Accessible Rich Internet Applications. É um conjunto de atributos HTML, padronizado pelo W3C como WAI-ARIA (versão atual 1.2, publicada em junho de 2023), que dá a tecnologias assistivas, como leitores de tela, informações adicionais sobre elementos da interface. O ARIA se torna necessário onde a semântica do HTML nativo acaba: uma interface de abas, um acordeão, um dropdown customizado ou uma mensagem de status que aparece dinamicamente. O vocabulário é formado por três blocos de construção: roles descrevem o que um elemento é, estados descrevem a condição atual dele e propriedades descrevem características e relações. O ARIA é poderoso e perigoso ao mesmo tempo. Usado corretamente, torna widgets complexos utilizáveis para quem usa leitor de tela; usado de forma incorreta, quebra ativamente a acessibilidade, e é por isso que a regra mais importante do ARIA é preferir elementos HTML nativos sempre que eles derem conta do recado.

O que significa ARIA e por que ele existe?

O HTML tem uma semântica embutida rica: um button é anunciado como botão, um nav é uma navegação, uma caixa de seleção marcada informa seu estado sozinha. Os leitores de tela leem tudo isso a partir da árvore de acessibilidade que o navegador constrói com base na sua marcação. O problema começa com tudo aquilo para o qual o HTML não tem elemento. Não existe painel de abas nativo, nem acordeão, nem notificação toast. As pessoas desenvolvedoras constroem isso com divs e spans, e para quem usa leitor de tela um acordeão feito de divs é apenas silêncio: sem nome, sem role, sem estado.

O WAI-ARIA preenche exatamente essa lacuna. Ele permite que você diga à tecnologia assistiva o que o seu widget customizado é e o que ele está fazendo, sem mudar nada na aparência ou no comportamento da página para todo mundo.

Roles, estados e propriedades: os três blocos de construção do ARIA

• Roles definem o que um elemento é. role="dialog", role="tablist", role="alert". Um role é uma promessa ao usuário: esta coisa vai se comportar como um diálogo.
• Estados descrevem a condição atual e mutável de um elemento. aria-expanded="true", aria-checked="false", aria-disabled="true". Os estados mudam enquanto o usuário interage, e o seu JavaScript precisa mantê-los sincronizados.
• Propriedades descrevem características e relações que raramente mudam. O aria-labelledby aponta para o elemento que dá nome a este, o aria-controls aponta para o elemento que este opera, o aria-required marca um campo obrigatório.

A distinção entre estados e propriedades é acadêmica no dia a dia, ambos são apenas atributos. O modelo mental que importa: o role diz o que a coisa é, todo o resto diz como ela se chama, o que ela está fazendo e a que ela pertence.

A primeira regra do ARIA: não use ARIA

O documento Using ARIA, do W3C, abre com uma regra que soa como piada, mas é totalmente séria: se já existe um elemento HTML nativo com a semântica e o comportamento de que você precisa, use-o em vez de reaproveitar outro elemento e acrescentar ARIA. Compare estas duas formas de construir um botão:

<!-- Parece um botão para quem enxerga, é um div morto para todo o resto -->
<div class="btn" onclick="save()">Save</div>

<!-- Tudo incluído: role, suporte a teclado, foco -->
<button type="button" onclick="save()">Save</button>

Para consertar a versão com div, você precisaria de role="button", tabindex="0" e JavaScript adicional para Enter e Espaço. O elemento nativo faz tudo isso de graça e vai continuar fazendo em navegadores que você nunca testou. A mesma lógica vale para links, caixas de seleção, campos de formulário e títulos.

Há um dado desanimador por trás dessa regra. A WebAIM analisa todo ano o primeiro milhão de páginas iniciais, e seus relatórios encontram de forma consistente que páginas que usam ARIA têm, em média, mais erros de acessibilidade detectados do que páginas sem ARIA. Isso não é porque o ARIA seja ruim, mas porque ele é aplicado incorretamente com muita frequência. Nenhum ARIA é melhor do que ARIA quebrado.

Os atributos ARIA mais importantes explicados

• aria-label: dá a um elemento seu nome acessível diretamente. O caso de uso clássico é um botão só com ícone: aria-label="Fechar" no X de um modal.
• aria-labelledby: aponta para o ID de outro elemento cujo texto visível vira o nome. Preferível ao aria-label quando existe um rótulo visível, porque os dois não podem se distanciar.
• aria-describedby: aponta para um texto descritivo adicional, tipicamente uma dica ou uma mensagem de erro abaixo de um campo de formulário.
• aria-hidden="true": remove um elemento e seus filhos da árvore de acessibilidade. Certo para ícones decorativos, perigoso em qualquer coisa focável.
• aria-expanded: sinaliza no gatilho se a área controlada está aberta ou fechada. A espinha dorsal de acordeões, menus dropdown e navegação mobile.
• aria-controls: conecta um gatilho ao elemento que ele opera.
• aria-live: transforma um elemento em uma live region, cujas mudanças de conteúdo são anunciadas automaticamente. O polite espera uma pausa, o assertive interrompe imediatamente e deveria ficar reservado a mensagens genuinamente urgentes.
• aria-current: marca o item atual dentro de um conjunto, por exemplo aria-current="page" no link de navegação ativo.
• aria-required e aria-invalid: comunicam campos obrigatórios e falhas de validação em formulários. Com a validação nativa do HTML, o required sozinho já cobre a primeira parte.

O que são os landmark roles do ARIA?

Landmarks dividem uma página em regiões nomeadas entre as quais quem usa leitor de tela pode saltar diretamente, do mesmo jeito que quem enxerga varre visualmente um layout. A boa notícia: elementos HTML modernos criam a maior parte dos landmarks implicitamente, então, em um documento bem estruturado, você raramente escreve esses roles à mão.

• header corresponde ao landmark banner
• nav corresponde a navigation
• main corresponde a main, e deveria haver exatamente um por página
• aside corresponde a complementary
• footer corresponde a contentinfo
• form e section viram landmarks form e region quando têm um nome acessível

Um hábito que vale adotar: se uma página tem duas navegações, diferencie-as com aria-label="Menu principal" e aria-label="Menu do rodapé". Ouvir navegação duas vezes sem nenhuma distinção não ajuda ninguém.

Exemplos práticos de ARIA: acordeão e live region

Um cabeçalho de acordeão acessível mínimo mostra como as peças funcionam juntas. O botão carrega o estado, o painel é referenciado por ID e o JavaScript inverte os dois no clique:

<h3>
  <button aria-expanded="false" aria-controls="panel-shipping">
    Envio e devoluções
  </button>
</h3>
<div id="panel-shipping" hidden>
  <p>Enviamos em 2 a 4 dias úteis...</p>
</div>

E uma live region para retorno que aparece sem recarregar a página, por exemplo após uma ação de adicionar ao carrinho ou uma busca filtrada:

<div aria-live="polite" class="visually-hidden" id="status"></div>

<script>
  document.getElementById('status').textContent = '12 produtos encontrados'
</script>

Sem a live region, quem usa leitor de tela filtra uma lista de produtos e não ouve absolutamente nada. Com ela, a contagem de resultados é anunciada no momento em que muda. Atributo pequeno, diferença grande.

Erros comuns de ARIA que você deve evitar

• aria-hidden="true" em elementos focáveis: o elemento some da árvore de acessibilidade, mas continua na ordem de tabulação. Quem navega por teclado aterrissa em um fantasma. Esse é um dos erros de ARIA mais frequentes no mundo real.
• Roles redundantes: role="button" em um button ou role="navigation" em um nav só acrescenta ruído e mostra que a marcação não foi compreendida.
• Roles sem comportamento: role="tab" promete navegação pelas setas do teclado. Se o seu JavaScript não entrega isso, o role deixa as coisas piores do que role nenhum, porque cria expectativas que o widget não consegue cumprir.
• Estados desatualizados: um aria-expanded que fica eternamente em false porque ninguém o atualiza no manipulador de clique. Quem usa leitor de tela ouve recolhido enquanto encara um painel aberto.
• aria-label em elementos de texto puro: em um div ou span sem role, o aria-label é ignorado pela maioria das tecnologias assistivas. Ele não é um tooltip de uso geral.
• Abusar de live regions assertivas: se cada atualização de carrinho, aviso de cookies e caixa de newsletter interrompe o usuário, os anúncios realmente importantes se afogam.

ARIA em temas e plugins WordPress

O núcleo do WordPress está em situação razoável: o bloco de navegação gerencia o aria-expanded nos botões de submenu, a classe CSS screen-reader-text para rótulos visualmente ocultos é uma convenção antiga, e os componentes de formulário do núcleo vêm com atributos sensatos. O problema costuma chegar com o que é instalado por cima. Construtores de páginas, plugins de slider, mega menus e ferramentas de popup são os lugares onde a sopa de divs com ARIA ausente ou quebrado se acumula. Ao avaliar um tema, a tag accessibility-ready no diretório de temas do WordPress é um sinal genuíno, já que esses temas passam por uma revisão contra critérios definidos. Para todo o resto, o ARIA Authoring Practices Guide documenta padrões comprovados para quase todo widget que você um dia vá construir, com comportamento de teclado funcionando.

Como o InspectWP verifica o uso de ARIA?

O InspectWP examina suas páginas renderizadas como parte da análise de acessibilidade e sinaliza problemas relacionados a ARIA que ferramentas automatizadas conseguem detectar de forma confiável: nomes de role inválidos, atributos ARIA que não são permitidos no elemento em que estão, referências a IDs que não existem, elementos focáveis ocultos com aria-hidden e elementos interativos sem nome acessível. Os achados são agrupados por gravidade, então um nome quebrado na sua navegação principal fica acima de um role redundante no rodapé. Como o comportamento do leitor de tela é o que decide no fim das contas o que funciona, trate o relatório como sua primeira passagem rápida e repetível e verifique os fluxos críticos com um leitor de tela real depois.