Acessibilidade em React: Além do aria-label

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.

tsxCopiar
// ❌ 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:

cssCopiar
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

tsxCopiar
<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:

tsxCopiar
<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.