Pular para o conteúdo
Guia Prático
Navegação
v0.1.1

Acessibilidade

Em produção

Acessibilidade não é uma 'feature', é um direito. Construir para todos melhora o produto para qualquer um.

Por que importa

Quando negligenciamos a acessibilidade, estamos decidindo ativamente (mesmo sem querer) quem pode e quem não pode usar o produto. Além do aspecto ético, acessibilidade melhora a usabilidade para todos (ex: contraste alto ajuda quem usa o celular no sol).

Checklist Mínimo (Frontend)

Critérios indispensáveis antes de considerar uma tela pronta para produção.

1. Contraste e Cor

  • Verifique se o texto tem contraste suficiente com o fundo (WCAG AA).
  • Não use a cor como único meio de transmitir informação (erro, sucesso, status).
  • Links no meio de parágrafos devem ter identificação visual além da cor (sublinhado ou peso).

2. Navegação por Teclado

  • Todo elemento interativo (link, botão, input) deve ser alcançável pela tecla Tab.
  • O foco deve ser visível. Nunca remova o outline sem fornecer uma alternativa clara.
  • A ordem do foco deve seguir a leitura lógica da página.

3. Semântica

  • Use botões para ações (`button`) e links para navegação (`a`). Não confunda os dois.
  • Headings (H1, H2, H3) devem respeitar hierarquia, sem pular níveis.
  • Inputs de formulário precisam sempre de etiquetas descritivas (`labels`).

Sobre ARIA

A primeira regra do ARIA é: não use ARIA se o HTML nativo resolver.

Um elemento `button` já comunica ao leitor de tela que é clicável. Uma `div` com `onClick` precisa de uma infraestrutura enorme de ARIA para fazer o mesmo trabalho. Prefira sempre elementos nativos.

Ferramentas de Validação

  • Navegação manual: Tente usar sua própria interface apenas com o teclado. É a validação mais honesta possível.
  • Lighthouse / axe DevTools: Auditorias automáticas pegam problemas estruturais óbvios.
  • Leitores de tela: Testes reais com VoiceOver (Mac) ou NVDA (Windows) revelam problemas que ferramentas automáticas ignoram.