HTML semântico primeiro: acessibilidade que dispensa ARIA

A maior parte dos problemas de acessibilidade vem do elemento errado, não de um atributo ARIA que falta. Um button recebe foco, funciona pelo teclado e tira o próprio nome do texto. Uma div com um handler de clique não tem nada disso até você reconstruir cada comportamento na mão. O HTML semântico é a primeira camada porque o navegador e o leitor de tela já concordam sobre o que esses elementos significam.

Por que o HTML semântico é a primeira camada

O navegador lê a sua marcação e monta uma árvore de acessibilidade. Cada elemento entrega um papel, um nome e um estado para essa árvore. A tecnologia assistiva lê a árvore, não os pixels, então a árvore é a única versão da sua página que quem usa leitor de tela recebe.

A WCAG 2.2 é uma Recomendação do W3C publicada em 12 de dezembro de 2024. Ela escreve o requisito como critério de sucesso testável. O Critério de Sucesso 1.3.1, nível A, pede que estrutura e relações transmitidas pela apresentação sejam determinadas por programa. O Critério de Sucesso 4.1.2, também nível A, pede que o nome e o papel de cada componente de interface sejam determinados por programa.

Esse segundo critério carrega uma nota que vale ler duas vezes. Ela diz que controles HTML padrão já atendem ao critério quando usados conforme a especificação. O caminho mais barato para a conformidade é então escolher o elemento cujo papel já é o papel que você quer.

Na prática isso significa nav para navegação, main para o conteúdo principal e h1 a h6 para títulos. Também significa ul e ol para listas, label ligado ao seu campo e fieldset com legend para controles agrupados. Nada disso custa uma linha de JavaScript.

O que o elemento certo resolve e o que nenhum atributo resolve

O elemento certo chega com o comportamento embutido, e o navegador mantém esse comportamento para você.

button traz foco, ativação com Enter e Espaço, estado desabilitado e nome acessível tirado do próprio texto. A MDN o descreve como um elemento ativado por mouse, teclado, dedo, comando de voz ou outra tecnologia assistiva.
a com href traz o papel de link, o foco e a navegação cuidada pelo navegador.
details com summary traz expandir e recolher sem script e sem ARIA.
dialog traz comportamento modal, contenção de foco e a tecla Escape.

Outros problemas não se resolvem com atributo nenhum. Vale conhecer quais são, para não perder tempo procurando um.

Nenhum atributo dá significado ao conteúdo. O ARIA consegue nomear um controle. Ele não decide que um parágrafo é um título, nem que três itens são uma lista.
Nenhum atributo conserta ordem de leitura. O Critério de Sucesso 1.3.2 pede que uma sequência de leitura correta seja determinada por programa. Essa sequência vem da ordem do seu markup.
Nenhum atributo conserta ordem de foco depois de uma reordenação visual. O order do CSS move caixas na tela e deixa a sequência de tabulação onde estava. A MDN alerta contra CSS que muda a ordem dos elementos focáveis.
Nenhum atributo conserta contraste, tamanho de alvo ou espaçamento de texto. São propriedades visuais, e os critérios que cobrem isso tratam de CSS.

Foco, teclado e ordem de leitura

Foco é o cursor do teclado. O que consegue recebê-lo, e em que ordem, decide se quem usa teclado consegue terminar a tarefa.

Alguns elementos são focáveis por padrão. A MDN lista: a com href, area com href, button, input, select, textarea, summary, iframe, object e frame. Eles entram na sequência de tabulação na ordem do documento. Esse fato sozinho explica o conselho mais repetido da referência: escreva o documento com os elementos em sequência lógica.

O tabindex muda esse padrão e é fácil errar com ele. tabindex="0" coloca o elemento na sequência de tabulação na posição em que ele está no código. tabindex="-1" deixa o elemento focável por script e fora da sequência de tabulação. Um valor positivo joga o elemento na frente da ordem do documento, e é por isso que a MDN recomenda usar só 0 e -1.

O Critério de Sucesso 2.4.3, nível A, pede que componentes focáveis recebam foco numa ordem que preserve significado e operabilidade. O Critério de Sucesso 2.4.7, nível AA, pede um indicador de foco visível. A WCAG 2.2 acrescentou o Critério de Sucesso 2.4.11, Foco Não Obscurecido no nível mínimo, que cobre o cabeçalho fixo que esconde o campo em que você acabou de tabular. O estado de interação e o foco visível são o tema de estado e interação.

Ordem de leitura é um eixo separado da ordem de foco, e quem usa leitor de tela anda por ela pela estrutura. A pessoa pula de título em título, de lista em lista, de região em região. A MDN observa que navegar por títulos é uma técnica comum e que pular um nível deixa a pessoa se perguntando onde foi parar o título que falta. Um h1 por página, depois h2, depois h3, sem buraco. A ideia antiga de que um section reiniciava o esboço de títulos nunca foi implementada e hoje não é conforme.

Quando o ARIA é necessário e quando ele piora

O ARIA não é o inimigo. Ele é a ferramenta para os casos que o HTML não cobre, e esses casos são reais.

A Primeira Regra do Uso de ARIA (em inglês) enuncia o princípio e depois lista as exceções. Prefira um elemento ou atributo nativo que já carregue a semântica e o comportamento que você precisa. Use ARIA em quatro casos. O recurso não está implementado no HTML, falta suporte da tecnologia assistiva ao elemento nativo, o design visual inviabiliza o elemento nativo, ou o HTML simplesmente não tem esse recurso.

Casos concretos em que o ARIA é a resposta certa:

Regiões ao vivo. Um filtro muda e a página precisa anunciar que restaram três resultados. role="status" ou aria-live fazem isso, e o HTML não tem elemento que anuncie sozinho. O Critério de Sucesso 4.1.3, Mensagens de Status no nível AA, existe exatamente para isso, e pede uma mensagem que chegue à tecnologia assistiva sem receber foco.
aria-expanded num controle de abertura customizado, para o estado ser lido, além de visto.
aria-current="page" no link ativo da navegação, um estado que o HTML não expressa.
aria-labelledby apontando uma região para um título que já existe, em vez de copiar o texto para um segundo rótulo.

Onde o ARIA piora:

role="button" numa div com handler de clique. O papel anuncia um botão e não acrescenta o resto. Ele não adiciona foco e não adiciona ativação por teclado. A Terceira Regra do Uso de ARIA (em inglês) exige que todo controle interativo com ARIA seja utilizável pelo teclado, e nomeia o dever específico: o elemento precisa receber foco e responder a Enter e a Espaço. Esse dever agora é seu.
aria-hidden="true" num elemento focável. A Quarta Regra do Uso de ARIA (em inglês) proíbe isso, porque o resultado é uma pessoa focando no nada. A mesma regra vale para ancestrais, já que esconder um contêiner esconde os filhos interativos dentro dele.
Um papel que não corresponde ao comportamento. Ele falha em silêncio e diz ao leitor de tela algo falso, o que é pior do que não dizer nada.

Uma ressalva para quem quiser citar as regras. O W3C hoje lista o documento Using ARIA como Rascunho Descontinuado, datado de 24 de fevereiro de 2026, e mantém as quatro regras como referência. A fonte atual para padrões de componente é o ARIA Authoring Practices Guide (em inglês). A própria WAI-ARIA 1.2 segue como Recomendação do W3C (em inglês) de 6 de junho de 2023.

O erro comum de usar ARIA para consertar marcação errada

O padrão é conhecido. O card precisa ser clicável, então o desenvolvedor põe role="button" e tabindex="0" numa div. Depois um aria-label para dar o nome. Depois um handler de teclado para Enter e um segundo para Espaço, porque o primeiro não disparou. Quarenta linhas substituem um <button>.

A Segunda Regra do Uso de ARIA (em inglês) nomeia isso direto. Não mude a semântica nativa a menos que você realmente precise, e o exemplo da própria especificação é um título transformado em aba. O conserto é o elemento que você deveria ter usado, e não um atributo melhor.

O sinal é o acúmulo. Quando uma div precisa de papel, tabindex, handler de teclado e rótulo para agir como controle, o elemento é o bug. Troque o elemento e apague os atributos.

Há outro sinal, no sentido contrário. Quando o ARIA repete o que o elemento já diz, ele é ruído. role="navigation" num nav não acrescenta nada. role="list" num ul não acrescenta nada. ARIA redundante custa manutenção e pode sair de sincronia com o elemento.

Como verificar, sem ferramenta paga

A maior parte do trabalho é testável com teclado, navegador e paciência.

Solte o mouse e tabule pela página a partir da barra de endereço. Se o foco some ou pula um controle, você achou um defeito e não uma preferência. Os Critérios de Sucesso 2.4.7 (em inglês) e 2.4.11 (em inglês) tratam disso.
Compare a ordem de tabulação com a ordem visual. Quando as duas discordam, a ordem do DOM é a que o teclado segue, e o order do CSS é o primeiro suspeito.
Abra a árvore de acessibilidade nas ferramentas de desenvolvedor do navegador e leia o papel e o nome calculados de cada controle. É a mesma informação que o leitor de tela recebe.
Desligue o CSS e leia a página. Os títulos, listas e rótulos que sobrevivem são os que você marcou direito.
Aplique 200 por cento de zoom e confira que nada fica cortado, porque reflow é critério e não questão de gosto.
Confira se o esboço de títulos tem buracos, porque a lista de títulos é como muita gente que usa leitor de tela folheia uma página.

Mas isso tem limite. Verificadores automáticos pegam uma parte dos defeitos e nenhum dos significados. A ferramenta diz que a imagem tem texto alternativo. Ela não diz que o texto alternativo está errado. Uma sessão real de leitor de tela e uma pessoa real são o único teste para isso, e nenhum script gratuito substitui as duas. As checagens que se sustentam antes de qualquer pessoa abrir a página estão em acessibilidade conferível.

A ordem do trabalho é fixa. Escolha o elemento que já significa o que você quer dizer. Mantenha a ordem do DOM igual à ordem visual. Mantenha o foco visível. Recorra ao ARIA só onde o HTML não tem resposta, e então escreva o mínimo possível dele. O ARIA que você mantém é o ARIA que você ainda consegue acertar daqui a um ano.

Um argumento parecido sobre herdar trabalho em vez de repetir está no texto sobre Material Design.

Onde o Nielsen Norman Group discorda

O Nielsen Norman Group não mede acessibilidade por conformidade. O texto sobre acessibilidade não bastar (em inglês) afirma que tratar acessibilidade como item de pontuação não ajuda quem tem deficiência, e que lista de verificação não ensina ninguém a escrever texto alternativo. O texto sobre design inclusivo (em inglês) põe a régua além da conformidade. Este post mantém um critério de sucesso da WCAG como régua testável, o que é uma tese mais estreita.

Uma preferência corre contra o resto do post. O texto sobre acesso direto contra acesso sequencial (em inglês) prefere o acesso direto, enquanto a orientação aqui é sobre o caminho sequencial da tecla Tab e do salto de título em título.

Os outros dois textos não se contradizem. Como as pessoas leem na web (em inglês) trata de varredura, e o texto sobre navegação por teclado (em inglês) trata de operação. Canais diferentes, teses diferentes.