Integração de acessibilidade em CI/CD

O bug de acessibilidade mais barato é aquele que nunca chega a ser integrado. A integração de acessibilidade em CI/CD desloca os testes para a esquerda, para dentro do seu pipeline de desenvolvimento, para que as regressões sejam detetadas automaticamente em cada pull request, em vez de surgirem meses depois numa auditoria — ou numa reclamação.

Porquê integrar a acessibilidade no CI/CD

A maioria das equipas testa a acessibilidade a posteriori: uma auditoria periódica produz uma longa lista, a equipa corrige-a e, depois, as mesmas classes de problemas regressam discretamente com as funcionalidades seguintes. Automatizar as verificações no pipeline quebra esse ciclo. Cada alteração é avaliada à medida que é feita, os programadores recebem feedback enquanto o código está fresco, e a conformidade conquistada com esforço fica protegida contra regressões silenciosas.

Como funciona

A funcionalidade Code Analysis da QualiBooth integra-se com GitHub Actions. Uma vez configurado, o workflow corre automaticamente em cada push e pull request:

1. Instale a GitHub Action da QualiBooth e adicione o seu segredo QUALIBOOTH_ORG_UUID.
2. Faça commit do ficheiro de workflow — o GitHub aciona os scans de acessibilidade automaticamente a partir desse momento.
3. Os resultados aparecem no dashboard Scan Runs da QualiBooth, pesquisável por repositório, branch ou hash de commit.
4. Cada violação é localizada num caminho de ficheiro e número de linha com gravidade Error ou Warning.
5. Após uma correção ser integrada, o scan seguinte marca o problema como Corrigido — o progresso é mensurável execução a execução.

O scan baseado em ESLint suporta atualmente projetos React, Vue, JavaScript e TypeScript. O suporte para frameworks e plataformas de CI adicionais está no roadmap.

O que configuramos

1. Integração com GitHub Actions — a ação da QualiBooth integrada no workflow do seu repositório.
2. Feedback nos PRs — verificações automáticas que comentam os resultados diretamente nos pull requests.
3. Deteção de regressões — cada análise é comparada com uma baseline para que os novos problemas sejam claramente separados do backlog existente.
4. Baselines — um instantâneo dos problemas existentes para que os gates incidam sobre os novos problemas, e não sobre todo o backlog de uma só vez.
5. Dashboard de Scan Runs — cada execução registada com branch, commit, contagens de problemas e rastreamento de problemas corrigidos.

Onde correm as verificações

• Pull requests — scans rápidos dos ficheiros alterados para feedback ágil dos revisores
• Branch pushes — monitorização contínua para detetar regressões antes do review do PR
• Verificações pré-merge — detetar novas regressões antes que cheguem ao branch principal
• Varreduras agendadas — scans noturnos ou de release mais completos em toda a aplicação

Um limite honesto

Os testes automatizados detetam de forma fiável apenas 30–40% dos critérios de sucesso das WCAG. Somos explícitos quanto a isso: a integração em CI/CD é a forma de impedir que os problemas automatizáveis cheguem alguma vez a ser lançados e de se proteger contra regressões — mas não substitui o discernimento humano. O nosso guia sobre testes de acessibilidade automatizados em CI/CD explica onde essa linha se situa na prática. A imagem completa resulta da combinação de gates automáticos com auditorias manuais por pessoas com deficiência e auditorias recorrentes.

Para quem é

Equipas de engenharia e de plataforma que lançam de forma contínua e que querem que a acessibilidade seja um gate de qualidade padrão e automático — tal como os testes e o linting. É um componente natural de um programa mais amplo de melhoria do processo de acessibilidade.