Lighthouse 100 em accessibility dá ao time uma confiança que o site não merece. A ferramenta valida contraste e alt text, e passa batida em ordem de foco confusa, div clicável sem label e modal que prende o teclado. Acessibilidade de verdade combina padrões WCAG aplicados no código com teste manual de leitor de tela; os exemplos abaixo mostram os dois.
Por que HTML semântico vem 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 manda usar HTML nativo onde ele existe; reserve ARIA para widgets customizados.
Como gerenciar o foco em rotas, modais e skip links?
- 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: nonequebra navegação por teclado
Como construir 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, e o navegador preenche melhor.
Quando usar 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.
Como testar 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 basta?
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.
Que práticas cabem no processo do time?
axe-core no CI captura regressões a cada pull request, varredura manual keyboard-only entra no checklist de release e 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.
Curtiu o conteúdo?
Construo produtos web e soluções com IA do jeito certo — arquitetura sólida, código sustentável e entrega real.
Vamos conversar