Testes de Acessibilidade: pipeline prático para validar interfaces e reduzir risco
Testes de acessibilidade são práticas de verificação que garantem que pessoas com limitações visuais, motoras, auditivas, cognitivas ou temporárias consigam perceber, operar e entender sua interface. Desde 28 de junho de 2025, com o European Accessibility Act (EAA) em vigor, conformidade deixou de ser diferencial e virou obrigação legal para produtos e serviços na União Europeia. No Brasil, a ABNT NBR 17225/2025 consolida requisitos alinhados à WCAG nos níveis A e AA.
Para evitar retrabalho, funciona melhor tratar acessibilidade como um semáforo de conformidade:
- Verde: passa nos critérios WCAG A e AA aplicáveis, sem barreira em teclado e leitor de tela.
- Amarelo: falhas de AA em áreas não críticas, com correção planejada, SLA e owners definidos.
- Vermelho: barreiras que impedem fluxo principal (login, busca, checkout, formulário, navegação) ou bloqueiam uso por teclado.
Se você atende usuários na UE, trate "vermelho" como incidente — o EAA já está em vigor.
O que muda com WCAG 2.2 e as novas obrigações legais
O padrão WCAG 2.2 é recomendação oficial do W3C e serve como referência de critérios e linguagem comum entre times de produto, design e engenharia. No Brasil, a ABNT NBR 17225/2025 estrutura requisitos e recomendações alinhadas à WCAG, com itens obrigatórios nos níveis A e AA.
O impacto prático é direto: testes de acessibilidade passam a ser rotina de engenharia e design, não esforço pontual antes do lançamento. Times que tratavam acessibilidade como "acabamento" agora enfrentam risco legal, retrabalho e perda de mercado.
Para contextos de governo e serviços públicos no Brasil, o alinhamento com padrões e materiais do gov.br para Acessibilidade Digital é o ponto de partida recomendado.
Como planejar testes de acessibilidade com matriz de risco
A forma mais eficiente de escalar testes de acessibilidade é parar de pensar em "testar páginas" e começar a pensar em jornadas e componentes. Uma correção no design system costuma remover o mesmo defeito em dezenas de telas.
Workflow de planejamento (60 a 90 minutos)
- Liste 3 a 5 jornadas críticas: cadastro, login, compra, suporte, alteração de senha.
- Mapeie componentes-chave nelas: input, select, modal, toast, tabela, tabs.
- Defina critérios mínimos: WCAG A e AA, mais regras internas de UX inclusiva.
- Escolha técnicas por risco: automação para varredura, manual para interação, usuários para validação.
Matriz de priorização
Monte uma tabela no seu backlog com três dimensões:
| Dimensão | Critério |
|---|---|
| Impacto | Alto (bloqueia tarefa), médio (atrapalha), baixo (incômodo) |
| Frequência | Toda sessão, semanal, rara |
| Exposição | % do tráfego e presença em jornadas críticas |
Qualquer item com impacto alto e alta frequência entra como vermelho no semáforo. Isso transforma acessibilidade em decisão de produto, não em checklist de conformidade.
Testes automatizados: Lighthouse, axe-core e listas do W3C
Automação é o melhor custo-benefício para capturar falhas recorrentes e impedir regressão. O erro comum é achar que automação "fecha" acessibilidade — ela não fecha, mas evita reintroduzir problemas básicos a cada release.
Ferramentas que valem o tempo do time
- Lighthouse: útil para auditoria rápida e acompanhamento de tendência de score em PRs e releases.
- axe-core: motor de regras amplamente adotado, fácil de integrar em testes automatizados e usado como base por diversas ferramentas do ecossistema.
- Lista de ferramentas do W3C (WAI): referência para comparar soluções por tipo (scanner, manual, simulação) e selecionar conforme seu stack.
Quality gate em pull request
Defina um gate objetivo para o semáforo:
- Violações críticas do axe-core em componentes do fluxo principal bloqueiam o merge do PR.
- Violações moderadas abrem issue automaticamente e entram em amarelo com SLA definido.
Trate o score do Lighthouse como sinal de tendência e regressão, não como meta final. Você ainda precisa confirmar com teclado e leitor de tela.
Testes manuais: teclado, foco, zoom e leitor de tela com NVDA
A parte manual existe porque acessibilidade é comportamento, não só marcação. É aqui que aparecem as barreiras reais de experiência que automação não detecta.
Checklist manual (15 minutos por tela crítica)
- Teclado apenas: navegue com Tab, Shift+Tab, Enter e setas.
- Foco visível: sempre dá para ver onde você está na tela.
- Ordem lógica: o foco segue o fluxo visual e não "teleporta" entre elementos.
- Componentes complexos: modais prendem foco, menus abrem e fecham sem armadilha de teclado.
- Zoom e reflow: aumente o zoom e verifique se o conteúdo ainda funciona sem scroll horizontal.
"Dia do leitor de tela" — o teste que muda cultura
Reserve um bloco mensal para rodar a jornada crítica com NVDA no Windows, sem mouse. NVDA é gratuito e amplamente usado, o que o torna uma escolha pragmática para times que estão começando.
Critérios para o semáforo:
- Não consegue concluir login ou checkout com teclado + NVDA: vermelho.
- Conclui, mas com fricção (rótulos confusos, mensagens mal anunciadas): amarelo.
Esse ritual torna acessibilidade observável e elimina discussões abstratas sobre "parece ok".
Testes com pessoas: como validar WCAG, inclusão e usabilidade
Automação e testes manuais encontram falhas técnicas. Testes com pessoas encontram barreiras de entendimento. Para acertar WCAG, inclusão e usabilidade ao mesmo tempo, os três níveis são necessários.
Recrutamento mínimo viável
Para uma rodada leve, comece com três perfis:
- Uma pessoa usuária de leitor de tela.
- Uma pessoa com baixa visão (que usa zoom e alto contraste).
- Uma pessoa com limitação motora (uso intenso de teclado ou teclado alternativo).
Defina no máximo três tarefas por sessão:
- Encontrar uma informação.
- Preencher um formulário.
- Concluir uma ação principal (compra, agendamento, inscrição).
Métricas que geram decisão
- Taxa de conclusão por perfil e por tarefa.
- Tempo para completar e pontos de travamento.
- Número de intervenções do moderador.
Conversão para o semáforo:
- Taxa de conclusão abaixo de 80% em tarefa crítica: vermelho.
- Taxa alta, mas com várias intervenções do moderador: amarelo.
Para times que atendem o mercado europeu, documentar essas sessões cria evidência de diligência e evolução contínua pós-EAA.
Operação contínua: backlog, SLA e evidência de conformidade
A maior falha em testes de acessibilidade é tratá-los como auditoria anual. Acessibilidade quebra com mudanças pequenas: um novo componente, um modal, um banner, uma biblioteca atualizada.
Cadência para times ágeis
| Frequência | Atividade |
|---|---|
| Por pull request | Automação com axe-core e auditoria rápida |
| Quinzenal | Bateria manual em jornadas críticas |
| Mensal | "Dia do leitor de tela" + sessão curta com pessoas |
| Trimestral | Revisão do design system e componentes mais usados |
Para contexto brasileiro, considere incorporar ferramentas como AMAWeb para avaliação e monitoramento quando fizer sentido ao seu processo.
Métricas que o negócio entende
Troque "quantidade de issues" por métricas acionáveis:
- % de jornadas críticas em verde.
- Tempo médio para sair do vermelho.
- Regressões por release (deve cair com gate em PR).
Se você usa design system, o ganho é evidente: corrigir tokens, componentes e padrões reduz o custo marginal de conformidade em cada nova tela. Em contexto de governo, o Padrão de Governo Digital reforça padronização e consistência como estratégia de escala.
Próximos passos para implementar o pipeline
Comece com o mínimo viável e expanda conforme o time ganha confiança:
- Semana 1: configure o gate automatizado com axe-core em PRs.
- Semana 2: rode o checklist manual nas 3 jornadas mais críticas.
- Mês 1: agende o primeiro "dia do leitor de tela" com NVDA.
- Mês 2: recrute 3 pessoas para uma rodada de testes com usuários reais.
Testes de acessibilidade tratados como pipeline — automação para bloquear regressão, manual para validar interação, pessoas para validar experiência real — transformam acessibilidade em parte do produto, não em projeto paralelo. O semáforo simplifica a tomada de decisão e tira o tema do campo opinativo para o campo mensurável.
