Por que os scanners automatizados de acessibilidade detectam apenas 30% dos problemas (e o que fazer a respeito)

Você executa uma varredura automatizada de acessibilidade, o painel volta todo verde e você solta um suspiro de alívio. Mas aqui vai uma verdade desconfortável: esse relatório limpo pode estar escondendo a maioria das barreiras reais de acessibilidade do seu site. Pesquisas e estudos independentes mostram de forma consistente que scanners automatizados detectam algo entre 30% e 57% das violações reais de WCAG — o que significa que de metade a dois terços dos problemas que seus usuários com deficiência enfrentam todos os dias são completamente invisíveis para as ferramentas das quais a maioria das equipes depende.

O estado dos testes automatizados de acessibilidade

Os testes automatizados de acessibilidade explodiram em popularidade, e por bons motivos. Mais equipes estão recorrendo à automação para rastrear problemas de acessibilidade: 50% dos respondentes em uma pesquisa de 2024 disseram usar ferramentas automatizadas de acessibilidade para identificar possíveis problemas, acima dos 40% em 2023. O apelo é óbvio — scanners são rápidos, relativamente baratos e podem ser integrados diretamente em pipelines de CI/CD. Eles capturam, em escala, as violações óbvias, repetíveis e baseadas em regras: o atributo alt ausente, o campo de formulário sem rótulo, o botão com um nome acessível vazio.

Mas o teto de cobertura é um problema persistente que nenhum fornecedor de scanner conseguiu romper. De acordo com a Deque, "você pode encontrar em média 57% dos problemas de WCAG automaticamente", e mesmo assim as ferramentas retornarão componentes como incompletos quando for necessária revisão manual. Esse número de 57% representa o extremo otimista do espectro, alcançado por um dos mecanismos de acessibilidade mais maduros e amplamente confiáveis do mercado, usando uma metodologia de medição pragmática e do mundo real. Outras estimativas são consideravelmente mais baixas. Ferramentas automatizadas capturam aproximadamente 30–40% das violações de WCAG, com os 60–70% restantes exigindo testes manuais.

A discrepância entre 30% e 57% se resume a como você define o denominador. A Deque chegou ao número de 57% adotando uma abordagem pragmática e do mundo real, em vez de teórica — amostrando um grande número de sites e medindo quantos dos defeitos de acessibilidade realmente documentados teriam sido detectados usando axe-core. Quando pesquisadores medem a cobertura em relação a todos os critérios de sucesso da WCAG como um conjunto teórico, os números caem drasticamente. No momento em que este texto é escrito, filtrar para os níveis A e AA da WCAG 2.2 para mostrar apenas regras de teste automatizado aprovadas revela cobertura parcial ou total para apenas 17 dos 55 critérios de sucesso. De qualquer forma, os testes automatizados deixam uma lacuna significativa — e legalmente perigosa.

O problema é agravado pela dificuldade de enxergar essa lacuna de fora. Uma varredura aprovada sinaliza ativamente segurança, que é exatamente quando as equipes têm mais probabilidade de parar de procurar. O painel está verde. O deploy acontece. Usuários reais com deficiência encontram barreiras reais.

No que os scanners realmente são bons

Antes de mergulhar na lacuna de cobertura, vale deixar claro o que as ferramentas automatizadas realmente fazem bem. Elas são rápidas, consistentes e incansáveis ao verificar coisas que podem ser determinadas apenas lendo o DOM. A automação de acessibilidade pode capturar de forma confiável violações comuns de WCAG, como texto alternativo ausente, links vazios, rótulos de formulário inadequados e baixas taxas de contraste de cor. São verificações estruturais e binárias — ou o atributo existe ou não, ou a taxa de contraste passa 4,5:1 ou falha.

O relatório WebAIM Million, que analisa anualmente as um milhão de home pages mais acessadas, oferece um retrato vívido de quão prevalentes esses erros detectáveis continuam sendo. 95,9% das home pages apresentaram falhas detectadas de WCAG 2. As seis categorias mais comuns — texto com baixo contraste, texto alternativo ausente, rótulos de formulário ausentes, links vazios, botões vazios e idioma do documento ausente — respondem por 96% de todos os erros detectados, e esses erros mais comuns são os mesmos há sete anos. Ferramentas automatizadas são genuinamente úteis para revelar essas violações de alta frequência e baixa complexidade em escala. O problema é que corrigir apenas essas questões ainda deixa um site com a maior parte de suas barreiras reais intactas.

Por que a lacuna existe: o que os scanners não conseguem avaliar

O teto de cobertura não é uma falha de engenharia — é uma limitação fundamental do que uma máquina pode avaliar sem julgamento humano. A lacuna existe porque máquinas não conseguem entender contexto, intenção do usuário ou questões subjetivas, como se a hierarquia de títulos faz sentido ou se o texto alternativo é preciso. Um scanner pode confirmar que uma imagem tem um atributo alt. Ele não pode dizer se esse atributo é "photo-123-final-v2.jpg" ou uma descrição realmente útil. Ferramentas podem sinalizar que uma imagem tem texto alternativo, mas só uma pessoa pode julgar se esse texto realmente descreve bem a imagem.

Estas são as principais categorias de problemas que escapam de forma consistente à detecção automatizada:

• Experiência com leitor de tela: Ferramentas automatizadas não conseguem ouvir como um leitor de tela anuncia o conteúdo. Elas podem verificar a validade de atributos ARIA, mas não conseguem determinar se os anúncios resultantes fazem sentido para os usuários. Um campo de formulário pode ter um aria-label tecnicamente válido que é lido como uma sequência confusa de caracteres para um usuário real de NVDA ou JAWS.
• Ordem lógica de leitura e foco: Na prática, a ordem de leitura muitas vezes não faz sentido quando usuários de leitores de tela acessam informações que visualmente podem parecer perfeitamente adequadas. Em um layout em colunas, um leitor de tela lê a primeira linha da coluna 1, depois da coluna 2, gerando confusão. Scanners analisam a ordem do DOM isoladamente, sem o contexto de como o layout visual transforma essa ordem para um usuário vidente.
• Texto significativo de links e botões em contexto: Ferramentas automatizadas podem verificar se um link existe e se ele inclui texto, mas nem sempre conseguem julgar se a finalidade desse link está clara. Cinco links "Leia mais" na mesma página passam em verificações automatizadas e falham para usuários reais que precisam entender para onde cada um leva.
• Conteúdo dinâmico e regiões ao vivo: Ferramentas automatizadas não conseguirão capturar problemas com conteúdo carregado dinamicamente. Será preciso executar o teste novamente depois que a atualização dinâmica for adicionada — mas, mesmo assim, a ferramenta não consegue dizer se um leitor de tela irá lê-lo ou não.
• Acessibilidade cognitiva e linguagem simples: A automação pode detectar problemas estruturais como ordem de títulos ou presença de rótulos, mas não consegue avaliar legibilidade, clareza ou se as instruções são fáceis de seguir. Um checkout complexo em várias etapas com mensagens de erro confusas pode ser estruturalmente "limpo" e, ao mesmo tempo, profundamente inacessível para usuários com deficiências cognitivas.
• Navegação por teclado em interações complexas: A automação pode testar foco básico de teclado e operabilidade, mas não consegue validar totalmente interações complexas em várias etapas, gestos personalizados ou dispositivos de entrada alternativos. Um widget de seletor de data personalizado pode ser totalmente operável por teclado em teoria e uma armadilha completa na prática.
• Elementos visuais sobrepostos e contraste em gradiente: Ferramentas automatizadas podem avaliar taxas de contraste, mas nem sempre levam em conta elementos sobrepostos, imagens atrás do texto ou conteúdo dinâmico que interfere na legibilidade.

Uma varredura automatizada limpa significa que você tratou dos 30–40% de problemas que a automação consegue capturar. Os 60–70% restantes não foram testados. Nunca declare conformidade com a WCAG com base apenas em testes automatizados.

Uma evidência particularmente marcante: em um estudo, defensores de acessibilidade do governo do Reino Unido criaram intencionalmente uma página da web com 142 barreiras de acessibilidade e depois analisaram a página com 13 ferramentas automatizadas de acessibilidade. A ferramenta com melhor desempenho conseguiu identificar apenas 40% das barreiras. A ferramenta com pior desempenho encontrou apenas 13%. Mesmo quando o cenário favorecia as ferramentas — usando uma página controlada com problemas conhecidos e documentados — os resultados foram desanimadores. E combinar ferramentas não resolve totalmente: mesmo usando seis ferramentas em paralelo, metade de todos os critérios de sucesso da WCAG 2 não é coberta e 6 em cada 10 violações passam despercebidas.

O risco legal de depender demais da automação

Isso não é apenas uma preocupação teórica sobre experiência do usuário. As apostas legais para a não conformidade em acessibilidade estão aumentando rapidamente, e uma varredura automatizada aprovada oferece quase nenhuma proteção em um processo judicial. Em 2024, mais de 4.000 processos foram abertos em tribunais dos EUA alegando barreiras à acessibilidade de sites ou aplicativos móveis. Só na primeira metade de 2025, houve 2.014 processos de sites sob a ADA — um aumento de 37% em relação a 2024.

Acordos extrajudiciais têm média de US$30.000, enquanto decisões judiciais têm média de US$85.000. Honorários de defesa entre US$30.000 e US$175.000 se somam a isso em todos os casos. Pior, fazer um acordo uma vez não é garantia de segurança: 45–46% dos processos federais de acessibilidade digital em 2025 tiveram como alvo empresas que já haviam sido processadas antes. Ser processado e corrigir apenas o que as ferramentas automatizadas apontam, sem tratar das lacunas estruturais mais amplas, simplesmente coloca um alvo nas suas costas para o próximo autor da ação.

Também vale abordar um equívoco comum sobre widgets e overlays de acessibilidade como atalho para conformidade. Dados de 2025 mostram que 456 processos sob a ADA foram abertos contra sites que tinham widgets de acessibilidade instalados, representando 22,64% do total de processos — enfatizando que simplesmente adicionar um widget de acessibilidade não é uma solução abrangente. Ferramentas automatizadas conseguem detectar apenas 30% dos problemas de WCAG, o que significa que qualquer ferramenta ou widget que dependa puramente de detecção automatizada está, por definição, deixando a maioria dos problemas sem tratamento. O que diferencia um SDK de acessibilidade genuinamente valioso — como o Accsible — dos produtos de overlay que enfrentaram reações legais e regulatórias é a combinação de remediação automatizada com um compromisso com uma estratégia honesta e em camadas de conformidade, em vez de garantias falsas.

Uma estratégia de testes em camadas que realmente funciona

A resposta para a lacuna de cobertura não é abandonar os scanners automatizados — é usá-los corretamente, como a primeira camada de uma estratégia abrangente, não a última. Dos 86 critérios de sucesso da WCAG 2.2, setenta por cento exigem revisão humana para interpretar adequadamente os critérios e aplicá-los às áreas cinzentas fora do escopo da tecnologia de acessibilidade automatizada. Isso significa que o julgamento humano não é opcional — ele é estruturalmente exigido pelo próprio padrão.

Um programa robusto de testes de acessibilidade normalmente funciona em três camadas:

1. Varredura automatizada (contínua): Integre scanners como o axe-core ao seu pipeline de CI/CD e execute-os em cada build. Capture as violações estruturais e binárias antes que cheguem à produção. Defina limites e faça o build falhar em novas violações críticas. Esta é sua rede de segurança para o que é óbvio — rápido, escalável e barato. Execute ferramentas automatizadas cedo e com frequência durante o desenvolvimento. Integre axe ou WAVE ao seu pipeline de CI/CD para que os problemas sejam capturados antes que o código chegue ao QA. Isso desloca os testes de acessibilidade para a esquerda, capturando problemas quando é mais barato corrigi-los.
2. Auditoria manual especializada (periódica): Conduza auditorias manuais estruturadas com base na lista completa de verificação da WCAG, realizadas por pessoas com profundo conhecimento em acessibilidade. Testes manuais de acessibilidade são realizados por especialistas treinados que usam ativamente sites com tecnologias assistivas, como leitores de tela, navegação por teclado ou softwares de ampliação. Eles avaliam contexto e experiência do usuário — a ordem lógica de foco e a sensação intuitiva da navegação, a clareza de formulários e mensagens de erro, a legibilidade em conteúdo complexo. Auditorias manuais normalmente acontecem trimestralmente ou quando grandes funcionalidades são lançadas, e devem cobrir de ponta a ponta as jornadas de usuário de maior tráfego. Auditorias manuais guiadas de acessibilidade ficam entre testes totalmente manuais e totalmente automatizados, reduzindo a lacuna de cobertura, com algumas estimativas colocando a cobertura em até 80% com essa abordagem.
3. Testes com tecnologia assistiva e usuários (contínuos): Você não pode depender apenas de ferramentas automatizadas para determinar problemas de acessibilidade no seu site. Todo projeto de site precisa de uma estratégia de testes com usuários, e é altamente recomendável incluir grupos de usuários com acessibilidade — usuários de leitores de tela, usuários que navegam apenas por teclado, pessoas com deficiência auditiva, usuários com deficiências motoras. Usuários reais com deficiência encontram problemas que nenhuma lista de verificação antecipa. Teste com NVDA e JAWS no Windows, VoiceOver no macOS e iOS, e TalkBack no Android. Navegue por todo o seu fluxo de checkout ou cadastro usando apenas o teclado. Ouça de fato como seu conteúdo soa quando é lido em voz alta.

Quando as equipes implementam as três camadas, a cobertura combinada pode se aproximar de 80–90% dos problemas do mundo real — uma melhoria dramática em relação ao teto de 30–57% da automação isolada. O objetivo não é perfeição no primeiro dia; é um processo sistemático e documentado que demonstre esforço genuíno de boa-fé e reduza continuamente a lacuna.

Integrando acessibilidade ao seu fluxo de desenvolvimento

A mudança cultural mais importante é tirar a acessibilidade de uma lista de verificação pré-lançamento e transformá-la em prática contínua. Muitas organizações cometem o erro de tratá-la como uma auditoria pontual que encomendam quando temem um processo, em vez de um padrão de qualidade incorporado a cada sprint. Quando uma auditoria revela problemas em um sistema em produção, o custo de corrigi-los é de cinco a dez vezes maior do que teria sido na fase de design.

Comece tornando critérios de acessibilidade parte da sua definição de pronto. Quando uma pessoa desenvolvedora entrega um novo componente, uma verificação automatizada rápida deve ser executada automaticamente. Quando uma pessoa designer cria um novo padrão, contraste de cor e estados de foco devem ser revisados antes mesmo de o design ser repassado. Quando uma pessoa editora de conteúdo adiciona uma nova imagem, ela deve ter um entendimento claro de como é um texto alternativo significativo — não apenas que texto alternativo é obrigatório.

Para gestores de conformidade, a implicação prática é documentação. Algumas equipes executam testes automatizados, mas nunca tratam dos achados. Isso não gera valor e cria documentação de que você sabia dos problemas, mas não os corrigiu — algo problemático em situações legais. Um programa de acessibilidade só é defensável se você puder mostrar um processo razoável e de boa-fé de melhoria contínua: varreduras regulares, achados documentados, um roadmap de remediação e evidências de que você está agindo com base no que aprende. A conformidade com a WCAG não é um binário que você atinge uma vez — é uma postura que você mantém.

Ferramentas como o Accsible existem para apoiar essa abordagem em camadas — fornecendo um SDK que incorpora melhorias de acessibilidade diretamente na experiência do usuário, revelando problemas em tempo real e complementando o processo de auditoria manual em vez de tentar substituí-lo. O overlay ou SDK certo não é um escudo mágico contra processos; é um componente de um programa bem pensado que reconhece o que a automação pode e não pode fazer.

Pontos principais

• Scanners automatizados são um ponto de partida, não a linha de chegada. Mesmo as melhores ferramentas detectam entre 30% e 57% das violações reais de WCAG. Um relatório de varredura limpo não significa que seu site é acessível — significa que o subconjunto detectável de problemas foi tratado.
• A maioria dos critérios de sucesso da WCAG exige julgamento humano. Experiência com leitor de tela, ordem lógica de leitura, texto significativo de links em contexto, clareza cognitiva e interações complexas por teclado são todas áreas em que a automação é estruturalmente incapaz de fornecer uma resposta confiável.
• O ambiente legal é hostil à complacência. Mais de 5.100 processos federais sob a ADA relacionados a sites foram abertos em 2025, acordos rotineiramente custam entre US$30.000 e US$85.000 mais honorários de defesa, e quase metade dos réus já havia sido processada antes — sugerindo que correções superficiais não são suficientes.
• Uma estratégia em três camadas — varredura automatizada, auditorias manuais especializadas e testes reais com tecnologia assistiva — pode elevar a cobertura para 80–90% e oferece a postura de conformidade documentada e de boa-fé que tribunais e reguladores esperam ver.
• Desloque a acessibilidade para a esquerda. Capturar problemas nas fases de design e desenvolvimento custa uma fração do que custa remediá-los após o lançamento. Integre verificações automatizadas ao CI/CD, torne a acessibilidade parte da sua definição de pronto e conduza auditorias manuais regulares nas jornadas de usuário de maior tráfego.