Voltar para o Blog

Acessibilidade em React: Além do aria-label

18/02/2026 Glauber A. Magalhães 2 minutos de leitura

Colocar 

aria-label
em tudo não torna uma interface acessível. Em projetos com requisitos de compliance, o que mais ajuda é HTML semântico, navegação por teclado e feedback claro para leitores de tela.

Trabalhei com dashboards LGPD, e-commerce e portais enterprise. Estas práticas são as que mais impactam quem usa leitor de tela ou só o teclado.

1. HTML semântico antes de ARIA

A regra do WAI-ARIA continua válida: se existe elemento nativo, use ele.

// ❌ div disfarçado de botão
<div role="button" tabIndex={0} onClick={handleClick}>Salvar</div>

// ✅ botão real
<button type="button" onClick={handleClick}>Salvar</button>

Use 

<nav>
, 
<main>
, 
<article>
, 
<button>
e headings em ordem (
h1
→ 
h2
). Leitores de tela navegam por landmarks — 
div
genérica quebra esse fluxo.

2. Foco visível e ordem de tabulação

Todo elemento interativo precisa de 

:focus-visible
claro. Não remova o outline sem dar uma alternativa:

button:focus-visible {
  outline: 3px solid rgba(124, 58, 237, 0.55);
  outline-offset: 4px;
}

Em modais e menus, prenda o foco dentro do painel e devolva o foco ao botão que abriu ao fechar. Teste só com Tab e Shift+Tab.

3. Acordeões e painéis expansíveis

Para FAQ, filtros e menus, o padrão correto é:

  • aria-expanded
    no botão que abre
  • aria-controls
    apontando para o id do painel
  • role="region"
    no conteúdo com 
    aria-labelledby
<button
  aria-expanded={isOpen}
  aria-controls="faq-panel-1"
  id="faq-trigger-1"
>
  Pergunta
</button>
<div id="faq-panel-1" role="region" aria-labelledby="faq-trigger-1">
  Resposta
</div>

Evite 

display: none
sem pensar no anúncio — o conteúdo precisa ser acessível quando aberto.

4. Live regions para mudanças dinâmicas

Busca, filtros e toasts devem anunciar o que mudou:

<div aria-live="polite" aria-atomic="true" className="visually-hidden">
  {resultCount === 0 ? 'Nenhum resultado encontrado' : `${resultCount} resultados`}
</div>

Use 

polite
para atualizações normais e 
assertive
só para erros críticos.

5. Teste com ferramentas e com teclado

Automatize o básico com axe-core ou eslint-plugin-jsx-a11y, mas valide manualmente:

  • Navegação só com teclado
  • VoiceOver (macOS) ou NVDA (Windows)
  • Contraste com Lighthouse ou DevTools

Um 

aria-label
bem escrito não compensa contraste baixo ou heading pulado.

Conclusão

Acessibilidade em React é trabalho de produto: HTML certo, foco previsível, estados anunciados e testes contínuos.

Comece pelo HTML nativo, trate o teclado com prioridade e, quando possível, teste com pessoas reais. Interfaces acessíveis costumam ser mais robustas para todo mundo.

Glauber A. Magalhães

Escrito por Glauber A. Magalhães

Desenvolvedor full-stack sênior. Escrevo sobre React, performance, acessibilidade e segurança — com exemplos de projetos reais.

LinkedInGitHub