Lighthouse 100 em accessibility dá ao time uma confiança que o site ainda não conquistou. A ferramenta valida contraste e alt text, mas não detecta ordem de foco confusa, div clicável sem label ou modal que prende o teclado. A especificação WCAG 2.2 exige que você teste padrões ARIA no código e valide com leitor de tela.

HTML semântico antes de ARIA

Um <button> entrega foco visível, suporte a teclado e anúncio para leitores de tela de graça. A mesma interação com <div onclick> exige tabindex, handler de Enter e role reconstruídos à mão, cada um com chance de bug. A primeira regra do ARIA, documentada pelo W3C, manda usar HTML nativo onde ele existe.

Gestão de foco

  • Mudança de rota envia o foco para o heading do novo conteúdo
  • Modal prende Tab dentro do diálogo e restaura o foco no elemento original ao fechar
  • Skip link pula a navegação repetida e leva direto ao conteúdo principal
  • Estilo de foco visível é redesenhado quando a marca pede; removê-lo com outline: none quebra navegação por teclado

Formulários acessíveis

Associe cada label via for/id e ligue mensagens de erro com aria-describedby dentro de uma região aria-live. Campo obrigatório se marca em texto, além de cor. Atributos autocomplete corretos (cc-csc, email) ajudam pessoas com limitações cognitivas e motoras.

Live regions

Toast de sucesso usa aria-live="polite". Falha crítica de pagamento pede "assertive". Regiões live em excesso afogam o usuário em anúncios e transformam o NVDA em ruído. Uma região por contexto resolve.

Teste com leitores de tela

NVDA no Windows e VoiceOver no macOS cobrem a maior parte da base de usuários. Aprenda dois comandos antes de confiar em qualquer walkthrough: lista de headings (navegue com H) e forms mode no NVDA. Cinco minutos de navegação keyboard-only por release revelam problemas que nenhum score mostra.

Contraste 4.5:1

O mínimo WCAG AA passa nos checks automáticos e falha na rua, com sol batendo na tela do celular. Para texto corrido, mire em 7:1 (nível AAA) e valide no brilho máximo do aparelho.

Processo do time

axe-core no CI captura regressões a cada pull request. Varredura manual keyboard-only entra no checklist de release. Critérios de acessibilidade aparecem escritos no ticket da feature. O checklist serve de piso; o código correto e o teste com leitor de tela constroem o resto.