Visão geral
Auditoria de Acessibilidade é uma técnica de validação usada para identificar barreiras de acessibilidade antes que cheguem à produção — problemas de contraste, navegação por teclado, compatibilidade com leitores de tela, estrutura semântica — garantindo que o produto seja usável por pessoas com deficiências visuais, motoras, auditivas e cognitivas. A utilidade dela está menos no ritual em si e mais na forma como ajuda o time a transformar uma dúvida de projeto em evidências, decisões ou próximos passos observáveis.
Ela faz sentido quando use antes de releases importantes, após redesigns significativos, ao integrar novos componentes ao Design System, ou quando houver requisito legal de conformidade com WCAG (Lei Brasileira de Inclusão, ADA, EN 301 549). Ao aplicar Auditoria de Acessibilidade, o time deve chegar a lista de issues com severidade e critério WCAG violado, Relatório de conformidade e Backlog priorizado de correções, mantendo rastreabilidade entre o que foi observado, o que foi decidido e quais limites ainda precisam ser considerados.
Como entra no fluxo
Auditoria de Acessibilidade entra quando já existe uma pergunta de trabalho clara e o time precisa conduzir uma atividade estruturada antes de avançar para decisão, protótipo, priorização ou entrega.
Atenção ao usar
Auditoria técnica não substitui teste com usuários com deficiência.
Combina bem com
- Heuristic Evaluation
- Usability Test
- Regression Testing
Para que serve
Identificar barreiras de acessibilidade antes que cheguem à produção — problemas de contraste, navegação por teclado, compatibilidade com leitores de tela, estrutura semântica — garantindo que o produto seja usável por pessoas com deficiências visuais, motoras, auditivas e cognitivas.
Quando usar
Use antes de releases importantes, após redesigns significativos, ao integrar novos componentes ao Design System, ou quando houver requisito legal de conformidade com WCAG (Lei Brasileira de Inclusão, ADA, EN 301 549).
Contexto
Objetivos
Outputs
Situações ideais
- alta incerteza
Como executar
Pré-requisitos
- Interface navegável (protótipo funcional ou produto em staging)
- Critérios de conformidade definidos (WCAG 2.1 AA é o padrão mínimo)
- Conhecimento básico de WCAG ou checklist de referência
Materiais
- Ferramentas automáticas — Axe DevTools, Wave, Lighthouse
- Leitor de tela — NVDA (Windows), VoiceOver (Mac/iOS), TalkBack (Android)
- Checklist WCAG 2.1 ou 2.2 nível AA
- Planilha de registro de issues com severidade
Passo a passo
- 1Definir escopo — quais fluxos e componentes serão auditados.
- 2Executar varredura automatizada com Axe ou Wave para capturar issues óbvios.
- 3Testar navegação por teclado em todos os fluxos críticos (Tab, Shift+Tab, Enter, Esc, setas).
- 4Testar com leitor de tela — verificar ordem de leitura, labels, anúncios de mudança de estado.
- 5Verificar contraste de cor em texto, ícones e componentes interativos.
- 6Verificar redimensionamento de texto até 200% sem perda de conteúdo.
- 7Registrar cada issue com critério WCAG violado, severidade e evidência.
- 8Priorizar correções por impacto e risco legal.
Critérios de qualidade
- Ferramentas automáticas usadas como triagem, não como auditoria completa
- Teste com leitor de tela real, não simulado
- Issues registrados com referência ao critério WCAG específico violado
- Severidade classificada por impacto (bloqueante, grave, moderado, leve)
Dicas
- Automação encontra apenas 30–40% dos problemas de acessibilidade — teste manual é obrigatório.
- Inclua usuários com deficiência no teste quando possível.
- Acessibilidade começa no design — componentes do DS devem ser auditados antes de implementar.
- WCAG 2.1 AA é requisito mínimo — 2.2 AA é o estado da arte atual.
Antes (entradas)
- Interface ou protótipo funcional
- Critérios de conformidade (WCAG 2.1 ou 2.2, nível AA ou AAA)
Depois (saídas)
- Lista de issues com severidade e critério WCAG violado
- Relatório de conformidade
- Backlog priorizado de correções
Variações
Auditoria rápida
Foco em automação e verificação de contraste e teclado — 2-4 horas — para triagem antes de auditoria completa.
Auditoria com usuários
Teste de usabilidade conduzido com pessoas com deficiência usando tecnologias assistivas reais, combinando critérios técnicos com experiência real.
Auditoria de Design System
Foco nos componentes da biblioteca de design para garantir que a base é acessível antes de ser usada em múltiplos produtos.
Uso estratégico
Quando evitar
- Interface ainda é wireframe sem interatividade real
- Equipe sem conhecimento mínimo de WCAG — investir em capacitação primeiro
Limitações
- Auditoria técnica não substitui teste com usuários com deficiência
- Conformidade com WCAG não garante boa experiência de uso
- Ferramentas automáticas têm falsos positivos e negativos
Riscos
- Tratar acessibilidade como checklist de conformidade, não como qualidade de experiência
- Corrigir issues de auditoria sem testar com tecnologias assistivas reais
- Não integrar acessibilidade ao processo de design — descobrir tarde demais
Exemplos de uso
- 01Auditar fluxo de cadastro antes de lançamento para conformidade com LBI.
- 02Revisar componentes de formulário do Design System para garantir labels e feedback de erro acessíveis.
- 03Identificar problemas de navegação por teclado em dashboard após redesign.
Perfis responsáveis
Também conhecido como
Referências e leitura
Ajude a melhorar este conteúdo
Encontrou erro, lacuna técnica ou exemplo fraco? Envie uma correção com contexto para revisão.
