Quando falamos de Qualidade de Software (QA), é muito comum limitarmos nosso escopo à automação funcional e à validação de regras de negócio. No entanto, um software só tem excelência de verdade quando ele pode ser utilizado por todas as pessoas, independente de suas limitações visuais, motoras ou cognitivas.
Foi com esse compromisso que decidi transformar este portfólio em um laboratório prático de Acessibilidade (A11y), seguindo as diretrizes internacionais da WCAG (Web Content Accessibility Guidelines).
1. Desenvolvendo os "Superpoderes" de Acessibilidade
O painel de A11y que você vê no canto inferior esquerdo deste site possui funcionalidades críticas baseadas nas necessidades reais dos usuários:
- Fonte para Dislexia: Substitui a fonte padrão por uma de base pesada (como a Comic Sans), evitando que letras semelhantes (p, q, b, d) girem ou espelhem na mente de leitores com dislexia.
- Pausar Animações: Fundamental para usuários com TDAH ou Epilepsia Fotossensível. Esse recurso desliga as transições e paralisa a digitação no terminal da tela inicial.
- Destacar Links: Adiciona sublinhados grossos em elementos interativos, reduzindo a carga cognitiva para que o usuário não precise "adivinhar" onde pode clicar.
2. Auditoria Contínua com Axe-Core e Playwright
Como QA Sênior, eu sei que validar o visual não é o suficiente. O HTML "invisível" precisa estar estruturado corretamente para Leitores de Tela (Screen Readers). É aqui que entra a automação!
Em vez de fazer verificações manuais tediosas, integrei a poderosa biblioteca Axe-Core ao meu framework em Java + Playwright. Criei o Cenário 10 da nossa suíte de testes especificamente para atuar como um auditor cego.
AxeResults results = new AxeBuilder(page).analyze();
if (!results.getViolations().isEmpty()) {
System.out.println("Falhas de Acessibilidade Encontradas!");
Assert.fail("O site não atende às normas da WCAG.");
}
3. Shift-Left A11y na Esteira CI/CD
Com o teste automatizado pronto, conectei a execução na nossa esteira do GitHub Actions. Isso significa que toda vez que um código novo é atualizado no repositório, o Axe-Core varre a aplicação inteira em busca de imagens sem alt, baixo contraste de cores e botões sem rótulos semânticos (aria-label).
Conclusão
Acessibilidade não deve ser a última etapa do ciclo de desenvolvimento, nem um "puxadinho" no final da Sprint. Ao implementar controles visuais interativos e garantir a varredura autônoma de A11y no pipeline, conseguimos provar que a inclusão digital é um pilar não negociável da Qualidade de Software.