O scanner encontrou problemas de acessibilidade: como priorizar, corrigir e retestar

Comece conferindo o resultado, não distribuindo todos os alertas

Abra a URL analisada e registre data, ambiente e estado. Confira se a ferramenta examinou a versão esperada e se o componente apontado ainda existe. Um resultado gerado antes de uma atualização pode não representar a tela que a equipe está tentando corrigir.

Ferramentas de avaliação podem gerar resultados incompletos ou enganosos, conforme orienta o W3C. Antes de descartar ou aceitar um alerta, reproduza a condição e entenda a regra. W3C WAI: seleção e limites de ferramentas de avaliação

Se não houver acesso ao código ou ao componente de terceiros, registre essa dependência. Ela exige um responsável para investigar, não o desaparecimento silencioso do item da fila.

Classifique pelo efeito sobre a tarefa

Pergunte o que a pessoa tenta fazer, qual barreira encontra e se existe um caminho utilizável para concluir a ação. Um botão sem nome acessível em uma etapa de pagamento merece atenção diferente de um detalhe visual sem impacto na conclusão.

Como modelo operacional, use três grupos: bloqueio de tarefa essencial, dificuldade importante e melhoria a investigar. Esses grupos são uma recomendação de gestão, não uma classificação oficial da WCAG nem a pontuação de um scanner.

Considere também recorrência e alcance. Corrigir um componente compartilhado pode trazer benefício a várias páginas. Mesmo assim, confirme os contextos de uso para não generalizar um teste de uma tela a todas as ocorrências.

Transforme o alerta em uma tarefa executável

Uma tarefa útil deve informar localização, passos para reproduzir, comportamento atual, resultado esperado, responsável e evidência do reteste. Um título como corrigir acessibilidade é amplo demais para orientar desenvolvimento ou verificar a entrega.

Exemplo ilustrativo: no formulário de orçamento, a mensagem de erro não identifica o campo que precisa ser corrigido. A equipe deve investigar a estrutura e combinar um resultado verificável, como orientação textual associada ao campo e feedback utilizável no fluxo. Não basta mudar a cor da borda.

O tutorial de formulários do W3C reúne orientações sobre rótulos, instruções, validação e notificações. Use referências específicas para discutir a implementação com quem mantém o código. W3C WAI: tutorial de formulários acessíveis

Faça o reteste automático e a verificação da jornada

Repita a consulta nas mesmas condições, quando possível, e registre a nova execução. A pontuação do Lighthouse depende de verificações ponderadas; melhorar um item pode alterar a nota sem representar toda a experiência. Chrome Developers: como a nota de acessibilidade do Lighthouse é calculada

Depois, refaça a tarefa com teclado e com os métodos de avaliação previstos no projeto. Observe estados de erro, retorno e confirmação. Uma correção que funciona na primeira tela pode falhar quando a pessoa tenta recuperar uma informação.

Não declare teste humano realizado se a atividade não ocorreu. Diferencie resultado automático, análise técnica, teste de jornada e participação de usuários nas evidências.

Evite que a barreira volte na próxima campanha

Documente o componente corrigido e compartilhe a orientação com quem cria páginas. Se o problema nasceu de um template, a solução precisa alcançar esse template e o processo de publicação, não apenas uma ocorrência.

Inclua uma verificação proporcional ao risco em atualizações de menu, formulário, checkout e conteúdo. Mantenha um canal para relatos de visitantes e uma pessoa responsável por encaminhá-los. A fila deve mostrar problemas abertos, corrigidos, reavaliados e dependentes de terceiros.

Quando a equipe não consegue explicar o impacto ou a solução, esse é um sinal para contratar avaliação especializada. O artigo sobre scanner e auditoria ajuda a definir o próximo escopo.

Perguntas frequentes