1 bilhão de pessoas no mundo vivem com algum tipo de deficiência. Acessibilidade web não é diferencial — é requisito ético e, em muitos países, requisito legal. Mas além do imperativo moral e jurídico, acessibilidade bem implementada melhora a experiência para todos os usuários: navegação por teclado beneficia power users, contraste alto ajuda em telas ao sol, e estrutura semântica melhora SEO. Este guia é técnico — foca em como implementar, não apenas por que importa.
Semântica HTML: a fundação que não pode ser ignorada
HTML semântico é 80% da acessibilidade. Usar <button> em vez de <div onclick> não é apenas estético — buttons são focáveis por teclado automaticamente, anunciados como “botão” por screen readers, e ativados com Enter e Space sem JavaScript extra. <nav>, <main>, <header>, <footer> e <aside> criam landmarks que usuários de screen reader usam para pular para seções sem percorrer o conteúdo linearmente. <h1> a <h6> criam uma hierarquia de título navegável — usuários de NVDA e JAWS pulam entre headings como você usaria a barra de rolagem.
Inputs de formulário precisam de labels associadas explicitamente via for/id ou encapsulamento. Placeholder não é label — desaparece quando o usuário começa a digitar e tem contraste tipicamente insuficiente. ARIA labels (aria-label, aria-labelledby) complementam quando HTML semântico não é suficiente — por exemplo, um ícone de botão sem texto: <button aria-label="Fechar modal"><X /></button>. A regra do ARIA: use HTML semântico nativo primeiro, ARIA apenas para preencher lacunas. ARIA mal aplicado é pior que a ausência — pode confundir screen readers com informações contraditórias.
Navegação por teclado e foco
Todo elemento interativo deve ser acessível via teclado na ordem lógica do conteúdo. Tab navega para frente, Shift+Tab para trás, Enter ativa, Space ativa toggles e botões, Arrow keys navegam dentro de widgets compostos (menu, tabs, radiogroup). O foco visível é obrigatório — nunca use outline: none sem substituir por outro indicador visível. O design do focus ring deve ter ratio de contraste de pelo menos 3:1 com o fundo. :focus-visible mostra o anel apenas para navegação por teclado, não ao clicar com mouse — solução elegante que satisfaz both usability audiences.
Modais e dialogs exigem gerenciamento de foco cuidadoso: quando abre, o foco deve mover para o primeiro elemento interativo do modal; quando fecha, retornar ao elemento que abriu. Focus trap dentro do modal impede Tab de sair para o conteúdo por trás (que deve ser aria-hidden="true" enquanto modal está aberto). Menus dropdown: ao abrir com Enter/Space, mover foco para o primeiro item; Arrow keys navegam entre itens; Escape fecha e retorna foco ao trigger. Esses comportamentos não são opcionais — são os padrões definidos pelo ARIA Authoring Practices Guide (APG) da W3C, que usuários esperam.
Contraste, tipografia e zoom
WCAG 2.1 AA exige contraste mínimo de 4.5:1 para texto normal e 3:1 para texto grande (18px+ normal ou 14px+ bold). O erro mais comum é usar placeholders e labels com cinza claro que falha no contraste. Ferramentas: axe DevTools (extensão de browser), Lighthouse (auditoria integrada no Chrome DevTools), e color.review ou WebAIM Contrast Checker para verificar paletas. Nunca transmita informação apenas por cor — “campos em vermelho são obrigatórios” não funciona para daltônicos; combine com ícone, label ou texto.
A fonte base do browser é 16px por uma razão — usuários com baixa visão geralmente aumentam para 20-24px. Layouts responsivos com unidades relativas (rem, em, %) respeitam configurações do usuário. Nunca fixe max-height em containers de texto — ao aumentar o zoom para 400% (WCAG AAA), o conteúdo pode ficar invisível. Teste com Ctrl++ até 400% zoom e verifique se o layout continua funcional e sem overflow horizontal para colunas únicas de texto.
Testes automatizados e manuais
axe-core é a biblioteca de testes de acessibilidade mais precisa e abrangente. Integre com Jest via jest-axe: expect(await axe(container)).toHaveNoViolations() falha o teste se houver problemas de acessibilidade detectáveis automaticamente. Storybook com addon-a11y mostra violações axe por componente durante o desenvolvimento. Playwright e Cypress com plugins axe rodam audits E2E automaticamente. Mas: ferramentas automáticas detectam apenas 30-40% dos problemas de acessibilidade. Teste manual é insubstituível.
Roteiro de teste manual mínimo: navegue a aplicação inteira usando apenas o teclado (Tab, Enter, Space, Escape, Arrow keys) sem usar o mouse. Ative um screen reader (NVDA no Windows gratuito, VoiceOver no Mac/iOS nativo, TalkBack no Android nativo) e navegue pages críticas — o que é anunciado faz sentido? Formulários podem ser preenchidos? Erros são comunicados? Zeem para 200% e 400% — tudo ainda visível e funcional? Desabilite CSS e verifique que o HTML ainda comunica estrutura e informação. Esses 4 testes identificam a maioria dos problemas críticos antes de envolver usuários reais com deficiência.
Tem um projeto em mente?
Somos especialistas em transformar ideias em produtos digitais. Apps, sites, automações e IA — vamos construir juntos.
