Por que sistemas de design não garantem acessibilidade total

Sistemas de design são como kits de peças pré-aprovadas: oferecem botões, cards e formulários com contraste válido, foco visível e semântica correta, mas não garantem que você os monte certo. Um botão acessível pode virar inacessível se for inserido dentro de um div com role='button' sem gerenciamento de teclado, ou se seu texto alternativo for genérico ('clique aqui') em vez de descritivo ('enviar formulário de contato'). A WCAG 2.2, reafirmada em maio de 2025, já exige coisas que nenhum sistema resolve sozinho: foco visível mesmo após arrastar, alvos de toque maiores em dispositivos móveis, e navegação lógica entre elementos dinâmicos, tudo dependente de implementação contextual, não de biblioteca.

O relatório WebAIM Million de 2025 é contundente: 95,9% das páginas mais visitadas do mundo têm falhas detectáveis. E o dado mais revelador não está na taxa de erro, mas na natureza dos problemas: 73% dos erros críticos envolvem decisões de conteúdo (como rótulos confusos ou hierarquia de títulos quebrada) e interação (foco perdido, leitores de tela ignorando atualizações), áreas onde nenhuma ferramenta automatizada, nem mesmo as impulsionadas por IA, consegue substituir o julgamento humano. Acessibilidade não é um checklist de componentes; é uma cadeia de escolhas, desde a escrita do microcopy até o fluxo de tabulação.

Ignorar essa lacuna custa caro: além do risco legal (Lei Brasileira de Inclusão 13.146/2015 exige conformidade WCAG 2.1 nível AA), empresas perdem usuários reais. Cerca de 28 milhões de brasileiros têm alguma deficiência visual, auditiva ou motora, muitos usam tecnologias assistivas diariamente. Um formulário com campos sem rótulo explícito ou um menu que trava no teclado não é apenas 'não conforme'; é uma barreira que impede conversão, fidelização e até acesso a serviços essenciais. Designers e devs que confiam só no sistema estão entregando interfaces que parecem acessíveis, mas falham na prática, sob pressão real de uso.