Saber que seu site tem problemas de acessibilidade é o primeiro passo. Saber exatamente quais são, onde estão e qual é a prioridade para corrigi-los — isso é o que uma auditoria de acessibilidade entrega. Este post explica como conduzir esse processo de forma estruturada, quais ferramentas usar e o que fazer com os resultados.

O que é uma auditoria de acessibilidade

Uma auditoria de acessibilidade é uma avaliação sistemática do site com base em critérios estabelecidos — principalmente o WCAG (Web Content Accessibility Guidelines) e, no caso de sites brasileiros, a ABNT NBR 17225. O objetivo é identificar barreiras que impedem ou dificultam o acesso de pessoas com deficiência ao conteúdo e às funcionalidades do site.

A auditoria pode ser automatizada (via ferramentas de scanner), manual (revisão feita por especialista) ou combinada — que é a abordagem mais completa e recomendada. Estima-se que ferramentas automáticas identifiquem entre 20% e 40% dos problemas reais de acessibilidade. O restante exige verificação humana e testes com tecnologias assistivas.

Fase 1: diagnóstico automático com scanner

O ponto de partida mais acessível para qualquer gestor de site é uma ferramenta de scanner automático. Essas ferramentas analisam o HTML das páginas e identificam violações dos critérios WCAG, classificando-as por nível de severidade e pela diretriz violada.

O scanner de acessibilidade do plano profissional do MLab Acessibilidade faz esse diagnóstico automaticamente, gerando um relatório com os problemas encontrados, os critérios WCAG correspondentes e sugestões de correção. É um ponto de partida rápido e de fácil leitura para gestores sem formação técnica.

Ferramentas externas como WAVE (wave.webaim.org), axe DevTools (extensão do Chrome) e o Lighthouse do próprio Chrome DevTools também realizam essa função de forma gratuita e são amplamente usadas por desenvolvedores.

Fase 2: verificação manual das páginas críticas

Após o scanner, o próximo passo é a verificação manual das páginas mais importantes do site — página inicial, formulários, páginas de produto ou serviço, checkout e páginas de contato. Essa verificação inclui:

Navegação por teclado. Acesse o site usando apenas Tab, Shift+Tab, Enter e setas. Verifique se é possível alcançar e operar todos os elementos interativos sem mouse, e se o foco está sempre visível.

Verificação de contraste. Use um verificador de contraste (como o Colour Contrast Analyser) para confirmar se todos os textos atendem à relação mínima de 4,5:1 (texto normal) ou 3:1 (texto grande).

Estrutura de headings. Verifique se a hierarquia de títulos (H1, H2, H3…) é lógica e sequencial — sem pular níveis, sem usar headings apenas por tamanho de fonte.

Textos alternativos. Inspecione imagens e verifique se todas têm texto alternativo descritivo — não apenas “imagem” ou o nome do arquivo.

Formulários. Confirme que cada campo tem rótulo associado via atributo for/id ou aria-label, e que as mensagens de erro são descritivas e associadas ao campo correto.

Fase 3: testes com tecnologias assistivas

A verificação mais próxima da experiência real é testar o site com um leitor de tela. Os mais usados são NVDA (Windows, gratuito), JAWS (Windows, pago) e VoiceOver (Mac e iOS, nativo do sistema).

Durante o teste, navegue pelo site usando apenas o teclado e o leitor de tela ativo. Preste atenção em: se o leitor anuncia corretamente o conteúdo das imagens, se os links fazem sentido fora de contexto, se modais e pop-ups funcionam corretamente e se formulários podem ser preenchidos e submetidos.

O que fazer com os resultados

Os problemas encontrados devem ser organizados em uma lista de prioridades. Critérios de nível A são os mais críticos — bloqueadores absolutos de acesso. Critérios de nível AA são os esperados para conformidade. Critérios de nível AAA são melhorias avançadas.

A priorização deve considerar também o impacto no usuário: uma imagem sem alt text em uma página de produto é mais urgente do que a mesma ausência em uma imagem decorativa. Um formulário de contato inacessível tem impacto maior do que um rodapé mal estruturado.

Entenda melhor como o MLab Acessibilidade pode ajudar no diagnóstico e na jornada de correção: veja o guia completo de instalação e recursos.

Periodicidade da auditoria

A acessibilidade não é um projeto com data de conclusão — é um processo contínuo. Sempre que o site recebe novas funcionalidades, novos conteúdos ou atualizações de design, novos problemas podem ser introduzidos. O recomendado é realizar uma auditoria completa ao menos uma vez por ano, e verificações rápidas com scanner sempre que houver mudanças significativas.

Perguntas frequentes

Quanto tempo leva uma auditoria de acessibilidade?
Depende do tamanho do site. Uma auditoria automática de um site pequeno leva minutos. Uma auditoria manual completa de um site complexo pode levar dias ou semanas.

Preciso contratar um especialista para fazer a auditoria?
Para uma auditoria inicial, ferramentas automáticas e os passos manuais descritos aqui já entregam muito valor. Para conformidade formal ou auditorias de sites críticos, contratar um especialista em acessibilidade é recomendado.

O scanner do MLab Acessibilidade verifica todas as páginas do site?
O scanner verifica as páginas configuradas para análise. Em sites com muitas páginas, é recomendável priorizar as páginas de maior tráfego e as que têm mais interatividade.

Como apresentar os resultados da auditoria para a equipe de desenvolvimento?
Organize os problemas por critério WCAG, nível de severidade (A, AA, AAA) e tipo de elemento. Um relatório com captura de tela do problema, o critério violado e o código de exemplo facilita muito a correção.

A auditoria precisa ser feita por uma empresa certificada?
Não há certificação formal obrigatória no Brasil. Para fins legais ou contratuais, uma declaração de conformidade assinada por especialista reconhecido é o padrão mais usado.

Quer saber onde estão as barreiras de acessibilidade do seu site? O MLab Acessibilidade oferece scanner de diagnóstico no plano profissional. 💬 Fale com nossa equipe