Acessibilidade componentes: checklist prático

Acessibilidade componentes interativos é o que separa uma interface que funciona para todos de uma que exclui sem perceber. Este checklist serve para designers e devs verificarem botões, modais, menus e formulários antes de cada release. Aplique como critério de aceite, não como auditoria de última hora.

Foco e navegação por teclado

• Foco visível em todos os elementos interativos. Se o usuário não vê onde está, ele se perde. Pelo menos 3:1 de contraste entre o indicador e o fundo.
• Ordem de tabulação segue a leitura visual. Teste com Tab e Shift+Tab. Se o foco pula para o rodapé antes do menu, a ordem está errada.
• Nenhum elemento interativo recebe foco sem ação. Links vazios ou botões decorativos não devem entrar na tabulação.

Rótulos e ARIA

• Todo botão tem texto acessível. Ícone sem rótulo precisa de aria-label ou texto visível. "X" não diz nada para leitor de tela.
• ARIA não substitui HTML semântico. Use button, não div com role="button". ARIA é remédio, não atalho.
• Estados dinâmicos são anunciados. aria-expanded, aria-checked e aria-live informam mudanças sem recarregar a página.

Contraste e feedback

• Texto e ícones atingem 4.5:1 e 3:1 respectivamente. Ferramentas de contraste ajudam, mas valide no contexto real.
• Erros de formulário são descritos, não apenas coloridos. Cor sozinha não comunica. Use texto e associe ao campo com aria-describedby.
• Estados de foco, hover e disabled são distintos. Se o usuário não diferencia, a interação falha.

O erro mais comum

Tratar acessibilidade como etapa final. Quando o componente já está pronto, corrigir foco e ARIA custa mais caro e quebra layout. O certo é incluir essas verificações no design system e no code review. Marca é o que dizem de você quando você não está na sala, e a experiência de quem usa leitor de tela também constrói essa reputação.

FAQ

O que é acessibilidade em componentes interativos?

É garantir que botões, modais, menus e formulários funcionem por teclado, leitores de tela e diferentes contextos. Envolve foco visível, ordem de tabulação, rótulos ARIA, contraste e feedback de erro. Não é opcional: é requisito de qualidade.

Por que o foco visível é obrigatório?

Sem indicador de foco, usuários de teclado não sabem onde estão. Isso impede navegação e causa erros. O contraste mínimo recomendado é 3:1 entre o indicador e o fundo. Teste com Tab em cada componente.

ARIA resolve todos os problemas de acessibilidade?

Não. ARIA só deve ser usado quando o HTML semântico não cobre a função. Usar role="button" em div não substitui um button real. ARIA mal aplicado piora a experiência de leitores de tela.

Como testar acessibilidade em componentes?

Comece com navegação por teclado (Tab e Shift+Tab). Depois use leitor de tela como NVDA ou VoiceOver. Verifique contraste com ferramentas e valide estados dinâmicos. Inclua esses testes no code review.

Qual o contraste mínimo para texto e ícones?

Texto normal exige 4.5:1. Ícones e elementos gráficos exigem 3:1. Esses valores vêm das WCAG e valem para fundos claros e escuros. Meça no contexto real, não apenas no design.

Quando aplicar este checklist?

Antes de cada release, como critério de aceite. Não deixe para auditoria final. Incluir no design system e no fluxo de desenvolvimento reduz retrabalho e garante consistência.