WAI-ARIA (Web Accessibility Initiative – Accessible Rich Internet Applications) é uma especificação técnica do W3C que adiciona atributos HTML para tornar componentes web dinâmicos acessíveis a tecnologias assistivas, como leitores de tela. Mantida pelo W3C desde 2014 e atualizada para a versão 1.2 em 2023, é o padrão usado pelo próprio core do WordPress.
Se você gerencia um site WordPress em escala, com múltiplos editores publicando e times de TI sempre sobrecarregados, a acessibilidade costuma ficar no fim da fila. O problema é que cada componente sem marcação semântica exclui parte real do seu público e ainda cria risco legal. Neste guia, mostramos como o WAI-ARIA resolve isso na prática, com exemplos de código, tabela comparativa e os erros que mais vemos em temas e plugins.
A resposta começa pelo tamanho do público. Segundo o Censo 2022 do IBGE, cerca de 18% da população brasileira com mais de dois anos declara ter algum tipo de deficiência. Boa parte dessas pessoas navega com leitor de tela, teclado ou outras tecnologias assistivas. Um site mal marcado simplesmente não funciona para elas.
O cenário técnico é preocupante. De acordo com o relatório WebAIM Million 2024, 95,9% das homepages analisadas apresentaram falhas de acessibilidade detectáveis segundo o WCAG. Ou seja, a regra hoje é o site inacessível, não o contrário.
Para o seu negócio, três pontos pesam:
O WordPress core já usa WAI-ARIA no painel administrativo e nos temas padrão. O problema mora nos temas de terceiros e plugins, que frequentemente quebram ou ignoram essa marcação. É aí que o cuidado contínuo faz diferença.
O WAI-ARIA é mantido pela Web Accessibility Initiative (WAI), grupo dentro do W3C. A versão atual é a ARIA 1.2, publicada como recomendação oficial em 2023. Você pode consultar a especificação oficial WAI-ARIA 1.2 do W3C para detalhes completos.
Na prática, o WAI-ARIA é um conjunto de atributos que você adiciona ao HTML existente. Eles informam às tecnologias assistivas o papel de cada elemento, seu estado atual e suas propriedades. Não muda nada visualmente na tela. Muda tudo para quem depende de um leitor de tela.
A grande vantagem para times de desenvolvimento: você não precisa refazer componentes. Interfaces ricas que usam JavaScript, React ou Gutenberg apenas ganham atributos extras na marcação que já existe.
O WAI-ARIA se organiza em três pilares: roles (funções), states (estados) e properties (propriedades). Entender essa divisão é o primeiro passo para aplicar a especificação sem cometer erros.
<div> usada como caixa de diálogo recebe role="dialog" para que o leitor de tela a anuncie como tal.aria-expanded="true" e aria-expanded="false".aria-label.| Pilar | O que define | Exemplo de atributo | Quando usar |
|---|---|---|---|
| Roles | A função semântica do elemento na interface | role="dialog", role="search" | Quando o HTML nativo não comunica a função (ex: div usada como modal) |
| States | O estado atual e mutável do elemento | aria-expanded="true", aria-hidden="false" | Em componentes cujo estado muda via JavaScript (accordions, menus) |
| Properties | Características fixas que ajudam o usuário | aria-label, aria-describedby | Para rótulos, descrições e relações que o HTML sozinho não expressa |
Os landmarks são o ponto de partida mais simples e útil do WAI-ARIA. Eles marcam regiões navegáveis da página, como cabeçalho, conteúdo principal, navegação e busca. Com eles, um usuário de leitor de tela pula direto para a seção que precisa, sem percorrer a página inteira.
Veja uma marcação comum, sem landmarks:
<div class="wrapper"></div> <form class="frm-search">...</form> <nav class="menu">...</nav>
Agora a mesma estrutura com landmarks e rótulos via aria-label:
<main class="wrapper" aria-label="Conteúdo principal"></main> <form class="frm-search" role="search" aria-label="Busca de conteúdo">...</form> <nav class="menu" aria-label="Menu de editorias">...</nav>
Repare que usamos a tag <main> em vez de role="main". Essa é a regra de ouro: HTML5 semântico primeiro, WAI-ARIA como complemento. O W3C resume isso na máxima “No ARIA is better than Bad ARIA”. Você pode aprofundar no guia oficial de uso do ARIA pelo W3C.
O role="search" permanece porque não existe uma tag HTML nativa equivalente. Já o aria-label é essencial em regiões que se repetem ou não têm texto visível, ajudando o usuário a diferenciar uma navegação da outra.
É nos widgets que o WAI-ARIA mostra todo o seu valor. Accordions, modais, abas e menus dropdown são construídos com <div> e JavaScript, sem semântica nativa. Sem atributos, o leitor de tela não sabe se um painel está aberto, fechado ou sequer existe.
Veja um accordion acessível:
<button aria-expanded="false" aria-controls="painel-1"> Detalhes do plano </button> <div id="painel-1" role="region" aria-hidden="true"> ... </div>
Quando o usuário clica, o JavaScript alterna aria-expanded para true e aria-hidden para false. O leitor de tela anuncia a mudança em tempo real. Os atributos que mais aparecem nesse contexto são:
Esse cuidado é crítico em temas modernos baseados em React e no editor Gutenberg, onde a interface muda constantemente sem recarregar a página. Para mais exemplos prontos, vale consultar a documentação ARIA do MDN e o manual de acessibilidade do WordPress.
Aplicar WAI-ARIA errado costuma ser pior do que não aplicar. Os equívocos que mais encontramos em temas e plugins WordPress são:
<nav role="navigation"> é repetição. A tag <nav> já comunica essa função nativamente. O mesmo vale para <main role="main">.<a role="button"> quando o certo seria um <button> nativo gera comportamento inconsistente de teclado. Escolha a tag correta antes de recorrer ao ARIA.A lógica por trás de todos eles é a mesma: o WAI-ARIA complementa o HTML, nunca o substitui. Quando existe uma tag nativa para o trabalho, use a tag.
Não. O WCAG (Web Content Accessibility Guidelines) é o conjunto de diretrizes de acessibilidade, com critérios e níveis de conformidade. O WAI-ARIA é uma especificação técnica com atributos HTML que ajudam você a cumprir vários desses critérios. Um é o objetivo, o outro é uma das ferramentas para alcançá-lo.
Não. A recomendação oficial do W3C é usar elementos HTML5 nativos sempre que possível, como <button>, <nav> e <main>. O WAI-ARIA entra apenas quando o HTML nativo não consegue expressar a função ou o estado de um componente, como em widgets construídos com JavaScript.
Comece com ferramentas automáticas como o Lighthouse do Chrome, o axe DevTools ou o WAVE. Elas apontam atributos ausentes e roles redundantes. Em seguida, faça testes manuais navegando só com o teclado e com um leitor de tela como NVDA ou VoiceOver. Auditoria automática pega cerca de metade dos problemas, o resto exige teste humano.
De forma indireta, sim. Marcação semântica clara, estrutura de landmarks e rótulos coerentes facilitam o rastreamento e a compreensão da página pelos buscadores. Acessibilidade e SEO técnico compartilham a mesma base: HTML bem estruturado e significativo.
Plugins de acessibilidade ajudam em ajustes pontuais, mas não substituem um tema bem codificado. A maior parte do trabalho de WAI-ARIA acontece no tema e nos templates, não em um plugin que adiciona uma barra de ajustes. Priorize temas que sigam o manual de acessibilidade do WordPress.
O aria-label define um rótulo diretamente como texto no próprio atributo, ideal quando não há texto visível na tela. Já o aria-labelledby aponta para o ID de outro elemento que já contém o rótulo visível, reaproveitando esse texto. Use aria-labelledby quando o rótulo já existe na página.
O WAI-ARIA não exige reescrever sua aplicação. Ele adiciona significado à marcação que você já tem, tornando o site acessível a leitores de tela e a milhões de usuários que hoje ficam de fora. Lembre sempre da regra central: HTML semântico primeiro, WAI-ARIA como complemento. ARIA mal aplicado atrapalha mais do que ajuda.
Em sites WordPress que rodam em escala, com vários editores e atualizações constantes de temas e plugins, manter a acessibilidade consistente é um trabalho contínuo, não um projeto único. Cada deploy pode quebrar uma marcação que estava correta. É por isso que oferecemos o WP Care, nosso serviço de manutenção em que nosso time cuida de acessibilidade, performance e segurança do seu WordPress de forma recorrente. Quer levar seu site ao nível que a LBI e o seu público exigem? Fale com a gente.
Bruno Pulis 
Leandro Vieira Pinho 
Ngoma Fortuna 
