Que parcela dos defeitos de acessibilidade encontrados em auditorias manuais ou por usuários já tinha passado nas verificações automáticas do CI, e que tipos escaparam?

Pergunta em aberto

Os verificadores automáticos de acessibilidade são baratos de executar: um motor de regras inspeciona o DOM renderizado a cada build e faz o pipeline falhar quando há texto alternativo ausente, contraste baixo, controles de formulário sem rótulo ou atributos ARIA inválidos. A orientação do W3C WAI sobre a escolha de ferramentas de avaliação é explícita: as ferramentas poupam tempo, mas não fazem tudo, porque algumas verificações de acessibilidade não podem ser automatizadas e exigem intervenção manual. Ainda assim, a tentação é tratar uma execução automática verde como "acessibilidade resolvida", porque uma auditoria manual custa dinheiro e os relatos de usuários chegam pelos canais de suporte, e não pelo build.

O que falta à wiki é um registro dessa diferença em sites reais. Quando uma auditoria manual (revisão por especialista com leitor de tela e teclado, ou uma sessão com usuários com deficiência) foi feita num site cujos builds já passavam num verificador automático, que parcela dos defeitos encontrados estava presente nas páginas verificadas e, mesmo assim, passou? Que tipos de defeito dominam essa parcela: ordem e perda de foco, armadilhas de teclado em widgets personalizados, texto de link sem significado que, tecnicamente, está rotulado, ordem de leitura errada, mensagens de status que nunca são anunciadas, texto alternativo presente mas incorreto, movimento que não pode ser pausado? E o inverso: que parcela dos achados automáticos se revelou irrelevante para qualquer usuário do site, a ponto de a equipe aprender a ignorar a ferramenta? A diferença diminui quando a execução automática inclui interação de teclado com scripts, ou quando a própria biblioteca de componentes foi auditada, de modo que os defeitos restantes estão na composição das páginas e não nos componentes?

A resposta decide para onde deve ir o esforço limitado de acessibilidade de uma equipe pequena: mais regras no CI, uma passagem manual periódica ou uma auditoria do design system.

O que uma resposta útil contém

O tipo de site, o framework e a biblioteca de componentes, e o verificador com o seu conjunto de regras e versão. O número de páginas cobertas pela execução automática e pela auditoria manual. Para cada defeito encontrado manualmente ou reportado por um usuário: o critério de sucesso em questão, se a página tinha passado na execução automática e se existe uma regra para ele na ferramenta que, mesmo assim, não disparou. Para cada achado automático no mesmo período: se foi corrigido, suprimido ou considerado falso positivo, com o motivo. O método de auditoria (revisão por especialista, teste com tecnologia assistiva, sessão com usuários), já que cada um encontra coisas diferentes. Se a equipe mudou alguma coisa em consequência: adicionou regras, incluiu uma checklist manual na revisão ou substituiu componentes. Relatos de um único site são bem-vindos se o conjunto de regras e o método de auditoria forem indicados; comparações entre sites com a mesma ferramenta são mais úteis.