O que é uma auditoria de acessibilidade? Como verificar se o seu site está em conformidade com as WCAG

De acordo com o relatório mais recente do WebAIM Million, foram detectados 56 milhões de erros distintos de acessibilidade em um milhão de páginas iniciais — uma média de 56 erros por página. Isso significa que a grande maioria dos sites está ativamente falhando com pessoas com deficiência todos os dias. Se você é proprietário de site, desenvolvedor ou responsável por compliance e está se perguntando se seu site está em conformidade com as WCAG, a resposta quase certamente envolve realizar uma auditoria de acessibilidade adequada. A questão é: o que isso realmente significa e como fazer isso da maneira correta?

Por que Auditorias de Acessibilidade se Tornaram Inegociáveis

A acessibilidade na web já ultrapassou há muito tempo o campo das boas intenções. Agora é um requisito legal em um número crescente de jurisdições, e as consequências da não conformidade são concretas e mensuráveis. Mais de 4.000 processos judiciais relacionados à acessibilidade na web foram abertos nos Estados Unidos em 2024, e a tendência continua em alta. Os tribunais nos EUA têm decidido de forma consistente que sites de empresas abertas ao público devem ser acessíveis sob o Título III da ADA. Enquanto isso, o European Accessibility Act passou a ser aplicável em todos os estados-membros da UE em junho de 2025, ampliando os requisitos para além de sites governamentais, abrangendo apps bancários, plataformas de e-commerce, produtos SaaS e mais.

Os números traçam um quadro contundente. Cerca de 16% da população global — aproximadamente 1,3 bilhão de pessoas — vive com algum tipo de deficiência. Só nos Estados Unidos, aproximadamente um em cada quatro adultos tem uma deficiência. Essas pessoas não são casos extremos. São clientes, funcionários, estudantes e cidadãos que encontram barreiras em sites sobre as quais a maioria dos desenvolvedores sequer pensa.

Além do risco jurídico, há um argumento de negócio mensurável. Sites acessíveis têm melhor desempenho em mecanismos de busca, porque a mesma clareza estrutural que ajuda leitores de tela — títulos semânticos, texto alternativo descritivo, marcação limpa — também ajuda os crawlers. O design inclusivo melhora de forma consistente a usabilidade para todos: legendas beneficiam pessoas em ambientes barulhentos, alto contraste ajuda pessoas sob luz solar intensa, e navegação por teclado beneficia usuários avançados. Uma auditoria de acessibilidade é o primeiro passo para capturar todos esses benefícios.

Mais uma mudança importante: o Título II da ADA agora exige explicitamente acessibilidade na web para entidades governamentais estaduais e locais nos EUA, com o DOJ adotando as WCAG 2.1 Nível AA como padrão técnico. Entidades que atendem populações de 50.000 ou mais enfrentam um prazo de conformidade em 26 de abril de 2026. Se você trabalha com clientes do setor público ou atua em setores regulados, auditar deixou de ser opcional — é urgente.

O que Exatamente é uma Auditoria de Acessibilidade WCAG?

Uma auditoria de acessibilidade na web é uma avaliação sistemática da conformidade do seu site com as Web Content Accessibility Guidelines (WCAG) — o padrão técnico internacionalmente reconhecido para acessibilidade digital, desenvolvido pelo W3C. Na prática, uma auditoria identifica barreiras específicas que impedem pessoas com deficiência de perceber, entender, navegar e interagir com seu conteúdo. Ela mapeia essas barreiras em relação aos critérios de sucesso das WCAG, atribui níveis de severidade e produz um roteiro de remediação.

As WCAG estão atualmente na versão 2.2, publicada no final de 2023 e formalmente reafirmada pelo W3C em maio de 2025 como o padrão mais elevado para acessibilidade na web. Ela inclui nove novos critérios de sucesso em relação às WCAG 2.1, cobrindo áreas como visibilidade do foco do teclado, tamanhos mínimos de alvos de toque, alternativas ao movimento de arrastar e mecanismos de ajuda consistentes. Importante: as WCAG 2.2 são retrocompatíveis — atender à 2.2 significa também atender à 2.1 e à 2.0.

As WCAG são organizadas em três níveis de conformidade. O Nível A cobre as barreiras mais críticas — falhas nesse nível tornam o conteúdo completamente inutilizável para alguns usuários. O Nível AA é o alvo exigido pela maioria das leis de acessibilidade no mundo, incluindo a ADA, o European Accessibility Act e a Seção 508. O Nível AAA representa o patamar mais alto e é tipicamente aspiracional, em vez de legalmente exigido. Quando alguém diz que seu site é “compatível com as WCAG”, quase sempre está se referindo às WCAG 2.1 ou 2.2, Nível AA.

As WCAG são construídas sobre quatro princípios centrais, frequentemente lembrados pelo acrônimo POUR: o conteúdo deve ser Perceptível (os usuários conseguem percebê-lo), Operável (os usuários conseguem interagir com ele), Compreensível (os usuários conseguem entendê-lo) e Robusto (funciona de forma confiável com tecnologias assistivas). Cada critério de sucesso se relaciona a um desses quatro princípios, e uma auditoria completa verifica a conformidade em relação a todos eles.

As Falhas Mais Comuns que Auditorias Revelam

Cerca de 96% de todos os erros de acessibilidade detectados se enquadram em apenas seis categorias. Saber o que procurar é a forma mais rápida de priorizar o esforço da sua auditoria:

• Texto com baixo contraste. Esta é consistentemente a falha mais comum. Quase 84% das páginas iniciais têm texto abaixo do limiar de contraste das WCAG 2 AA de 4,5:1 para texto normal. Auditores verificam as proporções de cor entre primeiro plano e fundo usando ferramentas como o TPGi Colour Contrast Analyser.
• Texto alternativo ausente. Mais de 16% de todas as imagens em páginas iniciais não têm qualquer atributo alt, deixando usuários de leitores de tela sem forma de entender o conteúdo da imagem. Imagens com link e sem texto alternativo são especialmente prejudiciais — tornam-se alvos de navegação sem significado.
• Links vazios. Links que não contêm texto visível nem nome acessível criam becos sem saída para usuários de teclado e leitores de tela, que não conseguem determinar para onde o link leva.
• Rótulos ausentes em campos de formulário. Formulários sem rótulos associados de forma programática são inutilizáveis para usuários de leitores de tela. Isso inclui tanto rótulos visíveis quanto rótulos ocultos usando aria-label ou aria-labelledby.
• Botões vazios. Botões apenas com ícone e sem nome acessível — comuns em navegação e sliders — deixam usuários não visuais incapazes de identificar o que o botão faz.
• Idioma do documento ausente. O atributo lang no elemento <html> informa aos leitores de tela qual idioma usar. Sua ausência causa má pronúncia e desorientação para usuários que dependem de conversão de texto em fala.

Auditorias revelam de forma consistente que as falhas mais prejudiciais também são as mais fáceis de corrigir. Baixo contraste, texto alternativo ausente e campos de formulário sem rótulo muitas vezes podem ser corrigidos em dias, não meses.

Além dessas seis, uma auditoria completa também identificará a ausência de links para pular navegação (que obrigam usuários de teclado a percorrer com Tab todos os elementos de cabeçalho em cada página), hierarquia de títulos inadequada, modais e diálogos inacessíveis que gerenciam o foco de forma incorreta, vídeos sem legendas, PDFs sem estrutura marcada e widgets JavaScript personalizados que não expõem funções e estados acessíveis via ARIA.

Como Conduzir uma Auditoria de Acessibilidade: Passo a Passo

Uma auditoria de acessibilidade adequada não é um único scan — é um processo em múltiplas etapas que combina ferramentas automatizadas com julgamento humano especializado. Veja como abordá-la de forma sistemática:

Passo 1: Defina o Escopo

Antes de executar qualquer teste, decida o que você vai auditar. Para um site grande, testar todas as páginas é impraticável. Em vez disso, aplique a abordagem WCAG-EM (Website Accessibility Conformance Evaluation Methodology) desenvolvida pelo W3C: defina uma amostra representativa que cubra todos os templates de página exclusivos, todas as jornadas de usuário significativas e todos os tipos de conteúdo distintos. Uma amostra para um site de e-commerce pode incluir a página inicial, uma página de categoria, uma página de detalhes de produto, o carrinho, o fluxo de checkout, login de conta, formulário de contato e um post de blog. Certifique-se de incluir estados dinâmicos — menus abertos, mensagens de erro de formulário, diálogos modais e resultados de busca carregados precisam ser avaliados.

Passo 2: Execute Scans Automatizados

Ferramentas automatizadas são a base de qualquer auditoria eficiente. Elas analisam seu HTML rapidamente, sinalizam violações de regras inequívocas e fornecem uma lista inicial de problemas. Ferramentas principais incluem:

• axe DevTools (extensão de navegador ou CLI) — amplamente utilizada, baixa taxa de falsos positivos, integra-se a pipelines de CI/CD
• WAVE (WebAIM) — anota páginas visualmente com ícones de erro, tornando-o intuitivo para membros de equipe não técnicos
• Lighthouse (embutido no Chrome DevTools) — fornece uma pontuação de acessibilidade junto com métricas de desempenho e SEO
• Colour Contrast Analyser (TPGi) — seleciona qualquer cor na tela e a verifica em relação aos limiares das WCAG
• PAC 2024 — verificador dedicado de acessibilidade de PDFs para documentos para download

Uma limitação crítica: ferramentas automatizadas conseguem detectar apenas entre 30% e 40% dos problemas de WCAG. Elas são excelentes para sinalizar falhas baseadas em regras, como atributos ausentes, funções ARIA inválidas e proporções de contraste. Mas não conseguem julgar se o texto alternativo é significativo, se um formulário é logicamente estruturado ou se um usuário consegue de fato concluir uma tarefa. É por isso que a automação é o Passo 2, não a auditoria inteira.

Passo 3: Testes Manuais por Especialistas

Testes manuais por uma pessoa experiente — ou idealmente uma equipe — é o que determina a profundidade de uma auditoria. Isso inclui:

• Navegação apenas por teclado. Desconecte o mouse e tente concluir todas as jornadas de usuário principais usando apenas Tab, Shift+Tab, Enter, Espaço e teclas de seta. Você consegue alcançar todos os elementos interativos? O indicador de foco está sempre visível? O foco desaparece em algum componente?
• Testes com leitor de tela. Use NVDA com Chrome ou Firefox no Windows, e VoiceOver com Safari no macOS e iOS. Navegue por títulos, landmarks, links e formulários. A página faz sentido sem contexto visual? Todos os elementos interativos são anunciados corretamente?
• Análise visual e cognitiva. Verifique a hierarquia de títulos em busca de estrutura lógica, confirme se as mensagens de erro são descritivas e associadas ao campo correto, confirme se mídias temporizadas têm legendas e transcrições e revise se instruções não dependem apenas de cor, forma ou posição.
• Inspeção de código. Revise semântica HTML, uso de ARIA, gerenciamento de foco em widgets personalizados e regiões de landmark. Um modal que não prende o foco, ou uma região ARIA live que dispara a cada tecla pressionada, só será identificado nesse nível.

Passo 4: Testes com Tecnologias Assistivas e Usuários Reais

O padrão ouro — e muitas vezes a etapa mais reveladora — é testar com usuários reais que dependem diariamente de tecnologias assistivas. Pessoas que usam leitores de tela, dispositivos de acesso por varredura ou softwares de controle por voz navegam de maneiras que nem mesmo testadores manuais experientes reproduzem totalmente. Incluir pessoas com deficiência na sua avaliação revela atritos do mundo real que ferramentas e checklists simplesmente não conseguem antecipar.

Passo 5: Documente e Priorize as Conclusões

Uma lista bruta de falhas não é um relatório de auditoria — é um ponto de partida. Um documento de auditoria útil deve especificar: a URL ou componente afetado, o critério de sucesso das WCAG violado, a severidade (crítica, alta, média, baixa), o impacto sobre os usuários afetados e orientações específicas de remediação com exemplos de código quando aplicável. A prioridade deve ser atribuída com base primeiro no impacto sobre o usuário, não na conveniência técnica. Um rótulo de formulário quebrado que impede o checkout é mais urgente do que um nível de título subótimo na barra lateral de um blog.

Passo 6: Corrija, Valide e Monitore

Depois que as correções forem implementadas, valide-as — não presuma que a remediação funcionou. Reteste cada correção com a mesma combinação de ferramentas e verificações manuais usadas na auditoria original. Após atingir um nível básico de conformidade, implemente monitoramento contínuo. Novo conteúdo, atualizações de CMS e scripts de terceiros podem introduzir regressões a qualquer momento. Trate acessibilidade como segurança: algo que você mantém, não algo que você alcança uma vez e esquece.

Scans Automatizados vs. Auditorias Completas: Entendendo a Diferença

Essa distinção é extremamente importante, especialmente em um contexto jurídico. Um scan automatizado executa uma verificação baseada em regras sobre o HTML renderizado. Leva segundos ou minutos e retorna uma lista de violações detectadas. É excelente para identificar problemas óbvios e de alto volume e para integrar em fluxos de CI/CD, evitando que novas regressões sejam lançadas. Muitos produtos de overlay e widgets — incluindo ferramentas de acessibilidade — oferecem painéis de scans automatizados como parte de seu conjunto de recursos, e eles são realmente úteis para monitoramento contínuo.

Uma auditoria completa, por outro lado, avalia seu site em relação a todos os critérios de sucesso das WCAG aplicáveis, usando uma combinação de scans automatizados, revisão manual por especialistas, testes com leitores de tela e navegação apenas por teclado. Uma auditoria abrangente que combine métodos automatizados e manuais pode revelar mais de 90% dos problemas de acessibilidade, em comparação com o teto de 30–40% da automação isolada. Se você enfrentar uma carta de notificação jurídica, exigência de compra ou investigação regulatória, apenas uma auditoria completa produz a documentação de que você precisa.

Muitas organizações usam uma estratégia híbrida prática: scans automatizados são executados continuamente em CI/CD para detectar regressões cedo, enquanto uma auditoria manual completa é conduzida anualmente ou após grandes reformulações do site. Isso equilibra profundidade com eficiência e mantém a conformidade administrável ao longo do tempo.

Nenhuma ferramenta sozinha pode determinar se um site atende aos padrões de acessibilidade. Uma avaliação humana qualificada é necessária para determinar se um site é genuinamente acessível. — W3C Web Accessibility Initiative

O que Fazer com os Resultados da Auditoria: Planejamento de Remediação

Uma auditoria concluída só é valiosa se gerar ação. A forma como você prioriza o trabalho de remediação é tão importante quanto identificar os problemas em primeiro lugar. Um framework prático para priorização de remediação se parece com isto:

1. Crítico (corrigir imediatamente): Problemas que bloqueiam completamente usuários de concluir tarefas centrais — um formulário de checkout quebrado, um modal de login inacessível, um menu de navegação inacessível por teclado. Eles representam o maior risco jurídico e o maior impacto sobre usuários.
2. Alto (corrigir no sprint ou ciclo de release atual): Problemas que prejudicam significativamente a usabilidade para pessoas com deficiência, mas não as bloqueiam totalmente — texto alternativo ausente em imagens de produto, baixo contraste no texto do corpo, botões de ícone sem rótulo em toda a interface.
3. Médio (remediação agendada): Problemas que causam atrito, mas têm alternativas — indicadores de foco inconsistentes, links para pular navegação ausentes, hierarquia de títulos subótima.
4. Baixo (backlog com responsável definido): Problemas que são melhorias de boas práticas, mas improváveis de afetar a usabilidade na maioria dos casos — aprimoramentos de nível AAA, pequenas melhorias de verbosidade em ARIA.

Documente seu plano de remediação e cronograma, mesmo antes de todas as correções estarem concluídas. Órgãos reguladores e tribunais geralmente veem de forma favorável melhorias contínuas e de boa-fé, em comparação com a inação. Se você receber uma carta de notificação, ter em mãos um relatório de auditoria mais um cronograma de remediação é uma posição muito mais forte do que não ter documentação alguma.

Widgets de overlay e ferramentas de SDK — como a oferecida pela Accsible — podem desempenhar um papel significativo na fase de remediação. Eles podem fornecer correções imediatas para uma parte relevante dos problemas comuns (especialmente preferências visuais como contraste, tamanho de fonte e espaçamento), enquanto sua equipe de desenvolvimento trabalha em remediações mais profundas no código. O essencial é entender o que os overlays resolvem bem e usá-los como parte de uma estratégia em camadas, não como substitutos de correções em nível de código para barreiras críticas.

Com que Frequência Você Deve Realizar uma Auditoria de Acessibilidade?

Uma auditoria pontual é um retrato do seu site em um dia específico. Sites são produtos vivos — o conteúdo muda, scripts de terceiros são atualizados, componentes são substituídos e novos recursos são lançados. Cada um desses eventos pode introduzir novas barreiras de acessibilidade. Um programa sustentável de acessibilidade normalmente se parece com isto:

• Monitoramento automatizado contínuo integrado ao seu pipeline de CI/CD ou via painel de monitoramento, detectando regressões antes que cheguem à produção
• Verificações manuais trimestrais em páginas de alto tráfego e alto risco (checkout, login, formulários de contato, páginas de destino principais)
• Auditoria completa anual conduzida por especialistas qualificados em acessibilidade, especialmente após grandes reformulações ou migrações de plataforma
• Auditoria na fase de design para qualquer novo recurso importante ou redesign — acessibilidade é significativamente mais barata de incorporar desde o início do que de adaptar depois

A abordagem mais econômica é deslocar a acessibilidade para a esquerda — integrando-a ao processo de design e desenvolvimento desde o primeiro dia, em vez de tratá-la como um exercício de conformidade pós-lançamento. Desenvolvedores que entendem os requisitos das WCAG identificam problemas na origem. Designers que conhecem contraste de cor e tamanhos de alvos de toque fazem escolhas acessíveis por padrão. A auditoria então se torna um portão de qualidade, e não uma intervenção de emergência.

Principais Conclusões

• A maioria dos sites falha nas WCAG. Mais de 95% das páginas iniciais têm erros de acessibilidade detectáveis, e as seis falhas mais comuns — baixo contraste, texto alternativo ausente, links vazios, rótulos de formulário ausentes, botões vazios e idioma do documento ausente — respondem pela grande maioria. Todas são corrigíveis.
• Ferramentas automatizadas são necessárias, mas não suficientes. Scanners automatizados detectam, na melhor das hipóteses, 30–40% dos problemas de WCAG. Uma auditoria completa exige testes com teclado, testes com leitores de tela e revisão humana especializada de código e fluxos de UX.
• WCAG 2.2 Nível AA é o alvo. É o padrão referenciado pela ADA, pelo European Accessibility Act, pela Seção 508 e pela maioria dos outros frameworks de acessibilidade no mundo. Mirar em 2.2 AA significa cobrir automaticamente todas as versões anteriores.
• Remediação precisa de um framework de prioridade. Comece com problemas que bloqueiam totalmente jornadas centrais de usuário, depois avance pelos problemas de alto impacto e alta frequência. Documente tudo — seu relatório de auditoria e plano de remediação são sua melhor defesa jurídica.
• Acessibilidade é contínua, não algo pontual. Combine monitoramento automatizado contínuo com auditorias manuais periódicas e incorpore acessibilidade ao seu processo de design e desenvolvimento desde o início. Um widget de overlay como o Accsible pode cobrir lacunas enquanto remediações mais profundas estão em andamento.