QA de acessibilidade é lento e caro. A gente tentou mudar isso com IA Generativa
Por Julia Ribeiro , Leticia Fonseca e N. Naomi Sato
A acessibilidade digital já não sofre por falta de diagnóstico. Sofre por falta de escala na correção.
Os dados mostram isso com clareza. 94,8% das 1 milhão de páginas iniciais mais acessadas do mundo apresentavam falhas detectáveis de acessibilidade, segundo o relatório The WebAIM Million realizado em fevereiro de 2025. No Brasil, apenas 2,9% dos sites passaram em todos os testes básicos avaliados em 2024, segundo pesquisa da BigDataCorp em parceria com o Movimento Web para Todos. Ao mesmo tempo, na prática dos times de produto e tecnologia, o que se vê é um acúmulo de pendências já conhecidas, cuja correção avança lentamente ou simplesmente não sai do papel.
Com base no que acompanhamos internamente no último ano, parte das melhorias identificadas nos projetos permaneceu com 0% de resolução após o QA; outras avançaram apenas para 6% ou 43%; poucas chegaram a 90% ou 94%. Não por falta de evidência técnica, mas porque a acessibilidade continua perdendo espaço para urgências concorrentes, restrições de capacidade, mudanças de time e contextos de migração ou reorganização. O QA enquanto diagnóstico pode ser rápido; o difícil é fazer a correção acontecer.
Foi diante desse descompasso entre identificar e resolver que passamos a investigar uma hipótese simples: será que a IA pode ajudar a tornar o QA de acessibilidade e sua sustentação mais viáveis, rápidos e escaláveis?
O que o backlog revela — mercado, sociedade e o nosso trabalho
O Brasil tem legislação desde 2015. A Lei Brasileira de Inclusão determina que empresas com sede no país devem garantir acessibilidade em seus sites e aplicativos. Mas a lei existe e a fiscalização não acompanha. O mercado não cobra. A sociedade ainda não pressiona o suficiente.
Enquanto isso, os números crescem. O Censo 2022 revelou mais de 32 milhões de pessoas com 60 anos ou mais no Brasil (IBGE, Censo Demográfico 2022), um salto de 56% em relação a 2010. Entre a população com 70 anos ou mais, 27,5% tem algum tipo de deficiência (IBGE, Censo Demográfico 2022). O envelhecimento da população não é uma tendência distante: é o cenário que os produtos digitais de hoje já precisam estar preparados para atender.
E acessibilidade vai além de deficiências permanentes. Um produto acessível funciona melhor para todo mundo: quem está com um braço machucado, quem segura um bebê enquanto tenta chamar um motorista de aplicativo, quem usa o celular com uma mão. Inclusão e boa experiência caminham juntas.
A dinâmica dentro dos times reforça o problema. Quando levantamos a pauta de acessibilidade com os clientes, a resposta raramente é "não queremos". É "não agora". Sem uma forma clara de justificar o ROI para quem aprova o orçamento, a pauta perde para outras prioridades. O backlog cresce. O ciclo se repete.
Foi pensando em como quebrar esse ciclo que a gente começou a perguntar: e se a IA mudasse a equação?
Dá pra escalar acessibilidade com IA?
"A gente espera que sim." Foi com essa aposta que iniciamos o experimento.
Slide do case apresentado na reunião anual estratégica da empresa para todas as pessoas colaboradoras
Para entender onde a automação de processos poderia entrar, mapeamos as quatro etapas do fluxo existente:
QA de acessibilidade: inspeção do app em busca de problemas, dependente de especialista e difícil de escalar
Documentação das issues: cada problema registrado com descrição, evidência e orientação de correção
Desenvolvimento: implementação da correção com base na documentação e testes locais
Code review: revisão por outros desenvolvedores antes do merge na branch principal
A decisão de focar primeiro na área de toque, em vez de atacar todos os cinco critérios de acessibilidade de uma vez (área de toque, contraste, movimento reduzido, texto ampliado e leitor de telas), veio de conversas com pessoas do time. Fez sentido começar pelo critério que parecia mais simples, com regra matemática clara e construir a partir daí.
Incluímos a IA nas etapas de QA, desenvolvimento e code review, criando ferramentas de IA (skills) para cada uma delas no Claude Code:
QA: o "Scanner de toque" (identifica os componentes tocáveis do projeto) e o "Auditor de toque" (avalia se atendem ao critério mínimo de área de toque).
Desenvolvimento: o "Corretor de toque", para aplicar as correções necessárias.
Code review: verificação se as mudanças realizadas passavam no critério de área mínima de toque.
Divisão inteligente: o que fica com a IA e o que fica com a pessoa
O começo foi mais simples do que o resultado final. Passamos as informações básicas ao Claude Code e pedimos que ele avaliasse e corrigisse tudo de uma vez. Como era de se esperar, não funcionou bem. Arquivos com violações foram ignorados, outros foram corrigidos de forma errada, e o pior problema era a inconsistência: cada vez que rodávamos o comando, o resultado era diferente.
A primeira melhoria foi separar em etapas. Faz sentido: quando resolvemos um problema complexo manualmente, também dividimos em partes. Mas a inconsistência ainda não havia sumido, e nem sabíamos exatamente como medir a melhora.
O avanço mais importante veio de uma conversa com a Nix da área de IA: o conceito de determinismo. Instruções determinísticas sempre produzem o mesmo resultado para a mesma entrada. A IA generativa por natureza não é determinística, mas algumas partes do nosso processo podiam ser.
A busca por componentes tocáveis, por exemplo, pode ser feita com um comando exato no terminal, da mesma forma que um desenvolvedor faria manualmente para não ter que olhar arquivo por arquivo. Transformamos essa etapa em um comando preciso, passando como parâmetro os padrões de arquivos e códigos que continham componentes tocáveis. O resultado ficou consistente e rápido.
A etapa de avaliação não tinha como ser determinística. Um componente pode ter filhos que já garantem a área mínima, ou estar inserido em um contexto onde alterar o tamanho quebraria o layout. Esse tipo de julgamento contextual não cabe num comando de terminal. O que fizemos foi documentar tudo que conseguimos pensar que poderia afetar a altura e a largura de um componente e passar isso como instrução para a skill de avaliação.
Nossos projetos utilizam design tokens, um sistema de nomenclatura que padroniza valores visuais como espaçamentos, tamanhos e cores em variáveis reutilizáveis. No código, isso aparece como height: theme.spacing.small, por exemplo, em vez do valor numérico direto.
Para facilitar o trabalho da IA nesse contexto, criamos um arquivo de referência com os valores resolvidos de cada token, além de exceções e componentes básicos do projeto. Assim, ao encontrar theme.spacing.small, ela já sabe que aquilo equivale a 12, sem precisar rastrear a origem no código. Isso tornou o processo mais rápido e reduziu as chances de alucinação.
Criar uma IA capaz de corrigir problemas de acessibilidade de forma confiável foi onde o conhecimento humano mais pesou. Não basta instruir: é preciso dizer como, e nessa ordem. Para cada problema identificado, existem múltiplas soluções possíveis: aumentar a área de toque do componente, ajustar o espaçamento ao redor, reorganizar o layout. Qual aplicar primeiro?
Essa priorização não é óbvia, e uma IA sem contexto tende a escolher a solução mais intervencionista, que pode quebrar o design ou criar problemas novos. A lista de prioridades que construímos reflete o que sabemos sobre os padrões da empresa, o nosso template e as boas práticas de acessibilidade. É esse conhecimento prévio, codificado em instruções explícitas, que faz a diferença entre um resultado utilizável e um que precisa ser refeito.
Ao longo do processo, refinamos muito além das prioridades: testamos com e sem skill, com agentes de IA como orquestradores, com modelos diferentes, salvando relatórios intermediários em arquivo. A cada teste, a pergunta era a mesma: o que pesa mais, tempo de execução, custo ou qualidade do resultado? O Skill Creator da Anthropic (uma ferramenta para criar e avaliar skills de IA) ajudou bastante nessa comparação, com uma função de evals (avaliações automáticas de qualidade) que permite confrontar versões diferentes de forma mais objetiva.
Nossa solução está longe de ser perfeita. Mesmo com instruções cada vez mais específicas, a IA ainda esquece algum detalhe, deixa de ler algum arquivo, inventa algo que não deveria. Quando as correções são feitas, ainda precisamos de um humano para testar o aplicativo em funcionamento e conferir se nada está fora do lugar.
Mas ela é um ponto de partida concreto. Do mesmo jeito que quem desenvolve usa IA para acelerar a criação de telas e componentes e depois confere o resultado, é possível usar a IA para garantir que o aplicativo seja acessível e conferir se ela resolveu os problemas corretamente. O processo não deveria ser diferente.
Área de toque foi o piloto. O que vem a seguir.
Muitas empresas celebram o piloto de IA como se fosse a inovação em si. O chatbot funcionou. A demo impressionou. Pronto.
Mas o piloto é a prova de que o problema vale resolver por aquele caminho, não que ele foi resolvido. A inovação real começa depois, quando o experimento vira prática e a prática vira parte do processo.
Nessa mesma lógica, o que descobrimos é que vale apostar na IA para reduzir o custo e aumentar a escala do QA de acessibilidade nos produtos digitais. Mas esse é um trabalho contínuo. O sucesso é medido pelo impacto para as pessoas que usam o produto, não pelo fato de ter atendido ao prazo ou cumprido o escopo.
Projeto pergunta: "Entregamos?"
Produto pergunta: "Está funcionando para quem, em qual medida, e o que precisamos ajustar?"
O experimento mostrou que a solução é viável. Com consistência, conseguimos cobrir 53% dos componentes e na melhor tentativa, chegamos a 84,6% de cobertura com identificação e correção corretas. Gerir como produto é o que vai fazer essa melhora se sustentar.
Se você está enfrentando o mesmo desafio nos seus produtos, entre em contato com a Taqtile que queremos entender o seu contexto e te ajudar.
No nosso roadmap de evolução temos: adaptar a solução para os próximos critérios da WCAG e da NBR 17060, cobrindo contraste, movimento reduzido, texto ampliado e leitor de telas.
Se quiser testar com a gente, tiver sugestões ou quiser contribuir com a evolução dessa solução de escalar a melhoria de acessibilidade em aplicativos com IA, entre em contato.
