Modelos de IA para código passam em apenas 8 a 25 por cento das verificações automatizáveis de acessibilidade (Aaron Gustafson, junho de 2026). Esse é o piso de onde seus agentes partem quando ninguém os corrige. Eles geram divs que deveriam ser botões, imagens sem texto alternativo, contrastes de cor que reprovam, estados de foco que somem. E fazem isso na velocidade de uma IA que nunca cansa.
Esse é o problema real entre IA e acessibilidade. O modelo não é mal-intencionado. Ele é rápido. E velocidade é exatamente o que machuca aqui.
Aceleração Não Conserta, Amplifica
A IA acelera o processo que você já roda. Ela não conserta um processo quebrado. Aponte um agente para um fluxo que produz interfaces inacessíveis e você recebe interfaces inacessíveis mais rápido, em maior volume, com mais consistência. As barreiras escalam na velocidade da máquina.
Isso importa por causa de quem está do outro lado. Mais de um bilhão de pessoas vivem com alguma deficiência. Quando um agente entrega um formulário que o leitor de tela não consegue interpretar, ele não cometeu um erro cosmético. Ele trancou uma parcela mensurável da população para fora do seu produto, e fez isso em cada tela que tocou.
Os números sobre assistência por IA cortam para os dois lados. Entre usuários do Copilot com dislexia, 76 por cento relatam melhor desempenho no trabalho. A mesma ferramenta mostra 37 por cento das tarefas iniciadas por voz no Copilot abandonadas (Gustafson, citando Jessie Lorenz e Carie Fisher). A IA pode baixar barreiras para alguns usuários e levantar barreiras para outros no mesmo lançamento. A direção depende inteiramente de alguém ter governado o resultado.
Acessibilidade É Métrica de Qualidade, Não Um Bônus
Times de segurança venceram há tempos o argumento de que vulnerabilidade é defeito de qualidade, não um pedido de feature que dá para despriorizar. Acessibilidade pertence à mesma categoria e raramente recebe o mesmo tratamento.
A curva de custo sustenta o argumento. Corrigir um defeito de acessibilidade custa cerca de 10x mais no design do que no conceito, 100x mais no desenvolvimento e 1.000x mais depois do lançamento (Gustafson). A escalada é idêntica à que times de segurança e confiabilidade já usam para justificar antecipar o trabalho. Uma falha de contraste pega numa revisão no Figma é um comentário. A mesma falha pega depois do lançamento é um retrabalho num produto já publicado, um backlog de remediação e, em mercados regulados, exposição jurídica.
Quando agentes geram código de interface, essa curva fica mais íngreme, não mais plana. Um agente que produz 50 componentes numa tarde produz 50 instâncias do mesmo defeito se a base dele é o piso de 8 a 25 por cento. O multiplicador de 1.000x pós-lançamento agora se aplica a um volume que o pipeline humano nunca alcançou. Velocidade sem portão de qualidade é como se fabrica dívida de remediação.
A Armadilha dos 50 Por Cento
Testes determinísticos mudam o piso de forma drástica. Conecte verificações automatizadas de acessibilidade ao pipeline e a taxa de aprovação nos critérios automatizáveis sobe da base de 8 a 25 por cento em direção a 100 por cento (Gustafson). Esse é o argumento mais forte para tratar acessibilidade como código: a máquina que quebrou pode ser obrigada a verificar, a cada commit, sem fadiga humana.
Há uma ressalva que desqualifica a automação como resposta completa. Os testes automatizados cobrem apenas cerca de metade do que a acessibilidade real exige (Gustafson). Um linter confirma que a imagem tem texto alternativo, mas ignora se o texto descreve a imagem. Confirma que um controle é alcançável pelo teclado, e cala sobre a ordem de foco fazer sentido para quem navega sem mouse. Confirma que existe um rótulo, e fica em silêncio sobre o usuário de leitor de tela conseguir concluir a tarefa.
Então um time que automatiza tudo ainda entrega exclusão na metade que a máquina não enxerga. A aprovação de 100 por cento nas verificações automatizáveis é real e vale a pena ter. Lida sozinha, é um número perigoso, porque certifica a metade fácil e fica em silêncio sobre a metade difícil.
A Pilha de Enforcement
Governar acessibilidade num pipeline movido a agentes exige duas camadas, e pular qualquer uma delas deixa a superfície desprotegida.
Verificações determinísticas ao longo de todo o SDLC. Linting de acessibilidade pertence a todo lugar onde código e design são produzidos: na ferramenta de design, no pull request, no CI, no portão de release. A verificação roda em cada artefato que um agente gera, do mesmo jeito que um scanner de segurança. É isso que leva a metade automatizável em direção a 100 por cento e impede que o piso padrão do agente chegue à produção. É inegociável e é a parte barata.
Validação humana obrigatória no loop. Uma pessoa que entende de tecnologia assistiva precisa validar a metade que o linter não alcança. Não como uma revisão opcional no fim, mas como um portão obrigatório antes do release, testando fluxos reais com tecnologia assistiva real. É aqui que ordem de foco, compreensão por leitor de tela e conclusão de tarefa são verificadas. O agente não certifica isso. O linter também não. O humano cobre a metade cega da máquina, e a máquina cobre o tédio do humano. Cada um faz o trabalho em que o outro é ruim.
As duas camadas se encaixam com precisão em como programas maduros de segurança já operam: varredura automatizada a cada commit mais revisão especializada do que os scanners deixam passar. Acessibilidade merece a mesma arquitetura, pela mesma razão. É uma propriedade de qualidade que a automação verifica parcialmente e só um humano julga por completo.
Esse é o mesmo argumento que fizemos sobre design sem governança ser decoração e sobre design systems virarem infraestrutura de governança de IA. Uma biblioteca de componentes que codifica padrões acessíveis transforma a restrição no caminho de menor resistência para o agente. O agente constrói com o que existe. Se o que existe é acessível por construção, o piso determinístico sobe antes de qualquer verificação rodar.
Faça Isto Agora
Adicione um linter de acessibilidade ao seu CI como portão bloqueante esta semana. Trate uma verificação de acessibilidade reprovada exatamente como um scan de segurança reprovado: o build não faz merge. Esse único movimento eleva sua cobertura automatizável do piso de 8 a 25 por cento do agente em direção a 100 por cento e custa quase nada.
Depois agende a parte que a automação não faz. Coloque uma passagem de validação humana no loop, conduzida por alguém fluente em tecnologia assistiva, na frente de cada release. Teste os fluxos reais que seus agentes geraram. Metade do que importa vive no território que nenhum linter certifica, e essa metade é onde a exclusão se esconde depois que o painel fica verde.
Trate acessibilidade como uma propriedade de qualidade governada, no mesmo nível da segurança. A IA aumenta o risco ao escalar tudo o que você deixa de governar. Decida o que seus agentes entregam antes que entreguem mil vezes.
Fontes
- Aaron Gustafson. “Can your AI pass the accessibility test?.” Junho de 2026.
A Victorino ajuda equipes a tratar acessibilidade como um portão de qualidade governado, não uma correria pós-lançamento: contato@victorino.com.br | www.victorino.com.br
Todos os artigos do The Thinking Wire são escritos com o auxílio do modelo LLM Opus da Anthropic. Cada publicação passa por pesquisa multi-agente para verificar fatos e identificar contradições, seguida de revisão e aprovação humana antes da publicação. Se você encontrar alguma informação imprecisa ou deseja entrar em contato com o editorial, escreva para editorial@victorino.com.br . Sobre o The Thinking Wire →
Se isso faz sentido, vamos conversar
Ajudamos empresas a implementar IA sem perder o controle.
Agendar uma Conversa