A acessibilidade que é verificada apenas uma vez por ano, em uma revisão manual única, quase sempre se desgasta rapidamente — qualquer pequena atualização de código pode quebrar algo que já foi corrigido. A solução: incorporar testes de acessibilidade no próprio processo de desenvolvimento (CI/CD) como uma etapa automatizada, para que os problemas sejam detectados antes de chegarem à produção. Este artigo explica como.
Resumindo – o que este artigo cobre
Por que uma verificação única não é suficiente
Uma equipe de desenvolvimento que envia atualizações toda semana, ou às vezes todos os dias, não pode contar com uma auditoria anual de acessibilidade para manter a conformidade contínua. Um novo componente adicionado sem a acessibilidade em mente, ou uma alteração de CSS que reduz acidentalmente o contraste, pode quebrar a acessibilidade que já foi corrigida – e ninguém percebe até que um usuário ou uma reclamação revelem isso. O mesmo princípio também se aplica a documentos — consulte nosso guia sobremapeamento de erros comuns.
Quais ferramentas automatizadas no pipeline de CI/CD podem capturar
Ferramentas como axe-core, Pa11y ou Lighthouse CI podem ser executadas automaticamente em cada solicitação pull ou antes de cada implantação – em segundos, elas verificam coisas como: contraste de cores, tags ARIA incorretas ou duplicadas, texto alternativo ausente, rótulos de formulário ausentes e ordem de cabeçalho incorreta. Se a verificação falhar, a mesclagem da solicitação pull será automaticamente bloqueada – assim como uma revisão de código normal ou um teste de unidade com falha.
💡 Dica prática
Inicie em "modo de aviso" (sem bloqueio) por algumas semanas para ver quantos problemas já existem na base de código, e somente após uma limpeza inicial transforme a verificação em um bloqueador de implantação - dessa forma a equipe não fica "presa" enfrentando centenas de erros no primeiro dia.
Onde o teste manual ainda é necessário
Assim como acontece com o teste de documentos, as ferramentas automatizadas no pipeline de CI/CD detectam problemas estruturais claros, mas não podem julgar a experiência real do usuário: se a navegação pelo teclado faz sentido, se um leitor de tela "conta uma história coerente" na página ou se um componente personalizado (como um carrossel ou modal) é genuinamente utilizável no uso no mundo real. É por isso que vale a pena combinar as verificações automatizadas contínuas com uma auditoria manual periódica – trimestralmente, por exemplo.
Como implementar na prática
- Escolha uma ferramenta de teste adequada à sua pilha de tecnologia (axe-core para a maioria dos projetos JavaScript, Lighthouse CI para projetos baseados em navegador).
- Execute-o como uma etapa em seu pipeline de CI — geralmente como uma ação do GitHub, um trabalho de CI do GitLab ou uma etapa equivalente em qualquer ferramenta de CI/CD que você usa.
- Defina um limite de falha claro (por exemplo: nenhum problema de nível "crítico" por núcleo de machado) antes que a verificação se torne um bloqueador.
- Cubra seus arquivos PDF também: se sua organização gera documentos automaticamente (faturas, relatórios), considere adicionar a digitalização automatizada para eles também, como parte do processo de publicação.
Quer adicionar testes automatizados de PDF ao seu processo também?
Nossa ferramenta verifica arquivos PDF e atribui a cada documento uma pontuação de acessibilidade — você pode executá-la como uma verificação periódica junto com seu processo de CI/CD.
Examine seu site gratuitamente ←Após a digitalização, você também pode tornar os documentos encontrados acessíveis direta e gratuitamente viaAccessiDoc.