Acessibilidade é capacidade operacional, não apenas uma funcionalidade

Acessibilidade não é um atributo de interface, é uma propriedade operacional do sistema inteiro. Accessibility, como tratado no artigo de Mikhail Prosmitskiy publicado na Smashing Magazine, não é um plugin ou checklist, mas uma disciplina que exige integração contínua em design systems, CI/CD, definições de pronto e até nas instruções dadas à IA. Ela serve a quem depende de leitores de tela, teclado, comandos de voz ou navegação por switch, mas também a engenheiros que querem evitar retrabalho, designers que precisam de consistência real e empresas que não querem perder €17 bilhões em conversões (só no Reino Unido) ou ter vendas bloqueadas por exigências de VPAT em licitações públicas.

O que torna Accessibility tão difícil de internalizar é sua natureza invisível: um componente pode parecer perfeito no navegador, mas ser totalmente inoperante para um usuário do NVDA. É por isso que a CEVIU já havia mostrado, em abril, que a camada de UX para leitores de tela é linear, não visual, e que interfaces geradas por IA são inacessíveis por padrão porque o modelo aprende com o lixo semântico do GitHub, não com os princípios da WCAG 2.2. Não é falha de intenção. É falha de infraestrutura.

Em abril, a CEVIU destacou que IA gera código inacessível por padrão [[LINK:/newsletter/ceviu-web-dev/interfaces-de-usuario-geradas-por-ia-sao-inacessiveis-por-padrao|Interfaces de Usuário Geradas por IA São Inacessíveis por Padrão]]. Em junho, a cobertura já apontava para a urgência de testar a IA *antes* do deploy [[LINK:/newsletter/ceviu-design/a-sua-ia-passa-no-teste-de-acessibilidade|Sua IA passa no teste de acessibilidade?]]. Agora, em julho, o artigo atual fecha o ciclo: não basta testar, é preciso construir guardrails operacionais. A mudança real está na transição do 'teste pós-IA' para o 'controle pré-IA': regras no Cursor, instruções explícitas no Copilot, componentes headless como Radix UI no lugar de widgets caseiros. Isso não é evolução conceitual. É migração de responsabilidade, do desenvolvedor individual para o sistema.

Porque acessibilidade mal feita não só exclui 1,3 bilhão de pessoas, ela corrói a qualidade técnica do produto inteiro. Um com onClick no lugar de um quebra não só o leitor de tela, mas também o foco, o tab index, o comportamento com Enter/Espaço e o suporte a comandos de voz. Isso gera bugs de interação que afetam *todos*, não só usuários com deficiência. E quando você automatiza isso com IA, escala o problema, não a solução. Empresas que tratam Accessibility como capacidade operacional têm menos retrabalho, menos risco jurídico e mais velocidade real, porque eliminam surpresas tardias. É a mesma lógica de segurança: ninguém espera descobrir uma falha XSS no QA final. Por que esperar descobrir que o menu de navegação some para o VoiceOver só depois do deploy?