Acessibilidade AA Web: Comparativa de Ferramentas 2026
A acessibilidade web AA refere-se ao nível de conformidade AA das Diretrizes de Acessibilidade para Conteúdo Web (WCAG) 2.2, publicadas pelo W3C, que exige o cumprimento dos 30 critérios de Nível A mais 20 critérios de Nível AA (50 no total). Para isso, as equipes combinam três tipos de ferramentas: auditores automatizados, assistentes de contraste e leitores de tela, além de uma revisão manual.
Principais Conclusões
- O nível AA das WCAG 2.2 agrupa 50 critérios de sucesso (30 de nível A + 20 de nível AA); é o limiar de acessibilidade web AA que a maioria das legislações exige, incluindo a norma europeia EN 301 549.
- Nenhuma ferramenta detecta sozinha todas as falhas: os auditores automatizados cobrem cerca de um terço dos critérios, portanto, a revisão manual e os testes com leitores de tela são obrigatórios.
- A escolha depende do fluxo de trabalho: extensões de navegador para desenvolvimento diário, suítes com CI para equipes e auditorias externas para certificações formais.
- Os quatro tipos de ferramentas de que você precisa são: auditores automatizados, verificadores de contraste, leitores de tela e validadores de estrutura/HTML.
- Documentar cada decisão de acessibilidade (o que foi testado, com qual versão e em qual navegador) é tão importante quanto corrigir a falha para demonstrar conformidade.
O que realmente significa “AA” em acessibilidade web
O Nível AA das WCAG é o segundo de três níveis de conformidade (A, AA e AAA) definidos pelo W3C. Cada nível combina os critérios do nível anterior: para declarar conformidade AA, você deve satisfazer os 30 critérios de nível A e os 20 critérios de nível AA, o que corresponde a 50 critérios de sucesso. O nível AAA adiciona mais 28 e é raro que seja exigido integralmente porque certos critérios são impossíveis de cumprir em todos os conteúdos.
A diferença prática entre A e AA é substancial. O nível A cobre o essencial (texto alternativo, estrutura semântica, navegação por teclado). O nível AA adiciona requisitos que afetam o design e a cor: contraste mínimo de 4,5:1 para texto normal e 3:1 para texto grande, redimensionamento do texto até 200% sem perda de conteúdo, legendas em vídeo pré-gravado, e cabeçalhos e etiquetas que descrevam o propósito de cada campo.
Esses critérios são os que costumam falhar em sites construídos com XHTML e CSS legados, onde a cor e o tamanho foram fixados em pixels absolutos.
A referência normativa que convém citar é a especificação oficial das WCAG 2.2 do W3C, que inclui a lista completa de critérios e suas técnicas suficientes e de aconselhamento. No contexto europeu, a norma EN 301 549 harmoniza esses requisitos para a contratação pública e a Diretiva de Acessibilidade Web, enquanto nos Estados Unidos a referência equivalente é a Seção 508 e a ADA. Conhecer o marco legal do seu mercado é importante: na Espanha e na América Latina, muitos clientes institucionais exigem conformidade AA explícita nos editais para garantir a acessibilidade web AA.
Os quatro tipos de ferramentas de que você precisa
Nenhuma categoria de ferramenta cobre todo o espectro das WCAG para a acessibilidade web AA. Um fluxo de trabalho sério combina quatro tipos, e cada um responde a perguntas distintas.
Relacionado: — com plano gratuito para começar hoje mesmo.
Auditores automatizados. Escaneiam o DOM e o CSS em busca de padrões de falha conhecidos: imagens sem alt, campos sem etiqueta, contraste insuficiente, cabeçalhos saltados, atributos ARIA mal utilizados. São rápidos e detectam erros repetitivos, mas sua cobertura é parcial: os próprios fabricantes reconhecem que não podem avaliar critérios que dependam do significado, como a qualidade de um texto alternativo ou a clareza de uma mensagem de erro.
Verificadores de contraste. Calculam a relação de contraste entre a cor do texto e o fundo segundo a fórmula de luminância relativa das WCAG. São ferramentas pequenas, mas críticas, porque o contraste é uma das falhas mais frequentes e uma das mais fáceis de medir objetivamente.
Leitores de tela. NVDA (Windows, gratuito), JAWS (Windows, comercial) e VoiceOver (macOS/iOS, integrado) são a prova de fogo. Um auditor pode dizer que um formulário “passa”, mas apenas um leitor de tela revela se a ordem de tabulação faz sentido ou se um aria-label confunde mais do que ajuda.
Vale a pena dar uma olhada: — Acessibilidade gerenciada: automatização combinada com revisão humana.
Validadores de estrutura e HTML. Garantem que a marcação seja válida e semântica. Em sites XHTML, um validador detecta aninhamentos incorretos, atributos obsoletos e problemas de codificação que afetam a interpretação do leitor de tela.
Comparativa: qual ferramenta escolher segundo o seu caso
A tabela a seguir resume o critério de decisão para garantir a acessibilidade web AA. Não é uma lista de preços (que mudam com frequência e dependem da licença), mas de adequação por cenário.
| Tipo de ferramenta | Quando escolhê-la | Principal fortaleza | Limitação chave |
|---|---|---|---|
| Extensão de navegador (auditoria ao vivo) | Desenvolvimento diário, revisão de uma página concreta | Feedback imediato sobre o DOM renderizado | Analisa apenas o que o navegador carregou; não cobre fluxos completos |
| Suíte com integração CI | Equipes com implantação contínua | Detecta regressões antes de publicar | Requer configuração e manutenção de regras |
| Verificador de contraste | Design e revisão de sistemas de cores | Medição objetiva e exata | Não avalia nada além da cor |
| Leitor de tela | Validação final e testes com usuários | Reproduz a experiência real | Curva de aprendizado alta; lento de executar |
| Auditoria externa | Certificação formal, editais públicos | Relatório defensável perante terceiros | Custo e dependência de um fornecedor |
A regra prática: use a extensão de navegador enquanto desenvolve, a suíte em CI para não quebrar o que já funcionava, o verificador de contraste ao definir a paleta, o leitor de tela antes de cada entrega e a auditoria externa apenas quando precisar de um documento formal.
Como avaliar uma ferramenta de acessibilidade antes de adotá-la
Escolher uma ferramenta com base na popularidade é um erro comum. Estes critérios separam uma ferramenta útil de uma que gera ruído.
Cobertura de critérios e transparência. Uma boa ferramenta indica qual critério WCAG corresponde a cada alerta. Se mostrar apenas um “erro de acessibilidade” sem mapeá-lo para um critério de sucesso, você não poderá documentar a conformidade ou priorizar.
Taxa de falsos positivos. Alertas que não são falhas reais consomem tempo e corroem a confiança da equipe. Teste a ferramenta em um site que você já sabe que atende aos padrões de acessibilidade web AA e observe quantos alertas ela gera.
Relacionado: — A que acredita sua experiência e acessibilidade.
Suporte ARIA e componentes dinâmicos. Widgets modernos (menus suspensos, modais, abas, acordeões) dependem de estados ARIA. Uma ferramenta que não avalia aria-expanded, aria-controls ou o gerenciamento de foco em modais deixa passar os erros mais graves.
Integração com sua stack. Se você estiver trabalhando com XHTML e CSS puros, verifique se a ferramenta não assume um framework concreto. Se estiver usando um pipeline de build, verifique se há integração por linha de comando.
Acessibilidade da própria ferramenta. Uma ironia comum: algumas ferramentas de auditoria não são acessíveis por teclado. Se você for usá-la diariamente, certifique-se de que seja navegável sem mouse.
Atualização e manutenção. As WCAG evoluem (2.0, 2.1, 2.2) e os navegadores mudam. Uma ferramenta sem atualizações recentes pode aplicar regras obsoletas.
Fluxo de trabalho AA passo a passo para acessibilidade web
Um processo repetível vai além de qualquer ferramenta simples. Esta é a ordem que funciona em projetos reais.
Passo 1 — Defina o escopo e o nível. Decida quais páginas e fluxos serão incluídos na auditoria e confirme que a meta é AA (não A ou AAA). Documente a versão das WCAG: 2.2 é a recomendação atual do W3C.
Passo 2 — Auditoria automatizada inicial. Execute as páginas principais em um auditor para obter uma linha de base. Observe as falhas repetidas: elas geralmente estão concentradas em templates, não em páginas individuais.
Passo 3 — Revisão manual do que a máquina não vê. Verifique a ordem de tabulação, a visibilidade do foco, a qualidade dos textos alternativos, a clareza das mensagens de erro e a consistência dos cabeçalhos. É aqui que a conformidade é conquistada ou perdida.
Passo 4 — Teste com um leitor de tela. Percorra pelo menos um fluxo completo (por exemplo, um formulário de contato ou uma compra) com NVDA ou VoiceOver. Note onde você se perde.
Passo 5 — Teste com usuários reais quando possível. Pessoas com deficiência detectam barreiras que nenhuma ferramenta ou especialista sem essa experiência percebe. Este é o critério mais valioso e o mais difícil de substituir.
Passo 6 — Documente e corrija. Registre cada descoberta com seu critério WCAG, a técnica aplicada e a evidência (captura de tela, versão do navegador, data). Este registro é o que transforma “acreditamos que está em conformidade” em “podemos provar que está em conformidade”.
Erros frequentes ao buscar o nível AA de acessibilidade web
Confundir “zero erros no auditor” com conformidade. Um relatório limpo de uma ferramenta automática não equivale à conformidade AA. Os auditores cobrem apenas uma fração dos critérios; o restante requer julgamento humano.
Ignorar o contraste em estados interativos. O contraste costuma ser revisado no estado padrão, mas os estados :hover, :focus e :disabled também devem cumprir. Um botão que passa em repouso pode falhar ao receber foco.
Usar ARIA para consertar HTML mal estruturado. A primeira regra do ARIA é não usar ARIA se o HTML nativo já resolve o problema. Um <div com role="button" nunca será tão robusto quanto um <button> real, que já gerencia o foco e o teclado.
Esquecer o redimensionamento do texto. O critério 1.4.4 exige que o texto possa ser ampliado em 200% sem perda de conteúdo ou funcionalidade. Designs com alturas fixas em pixels costumam quebrar aqui.
Não testar em dispositivos móveis. O refluxo (critério 1.4.10) exige que o conteúdo funcione sem rolagem horizontal em telas estreitas. Muitos sites de desktop conformes falham neste ponto.
Perguntas frequentes
Qual a diferença entre acessibilidade A, AA e AAA?
Os níveis de conformidade das WCAG são cumulativos. O Nível A cobre 30 critérios básicos; o AA adiciona mais 20 (50 no total) e é o padrão exigido pela maioria das leis; o AAA adiciona mais 28 e não é exigido de forma geral porque alguns critérios são inviáveis em todo o conteúdo. Para a maioria dos projetos web, o AA é uma meta realista e suficiente para a acessibilidade web AA.
Quantos critérios das WCAG 2.2 devem ser cumpridos para o nível AA?
O Nível AA das WCAG 2.2 exige o cumprimento de 50 critérios de sucesso: os 30 do Nível A mais os 20 do Nível AA. O número permanece o mesmo das WCAG 2.1, mas a 2.2 também adicionou novos critérios, como tamanho do alvo (2.5.8) e ajuda consistente (3.2.6), alguns no nível A e outros no nível AA.
Basta uma ferramenta automática para cumprir o AA?
Não. Ferramentas automatizadas detectam erros objetivos e repetitivos, mas não podem avaliar critérios que dependam de significado ou contexto, como a qualidade do texto alternativo ou a utilidade de uma mensagem de erro. A conformidade AA exige a combinação de auditoria automatizada, revisão manual e testes com leitores de tela e, quando possível, com usuários reais.
Qual leitor de tela convém usar para testar um site?
O NVDA é gratuito e amplamente utilizado no Windows, tornando-se a opção mais acessível para começar. O JAWS é comercial e comum em ambientes corporativos. O VoiceOver vem integrado ao macOS e iOS, sendo a rota natural se você trabalha no ecossistema Apple. Testar com pelo menos duas combinações de navegador e leitor de tela fornece uma imagem mais confiável.
A acessibilidade AA é obrigatória por lei?
Depende do país e do tipo de organização. Na União Europeia, a Diretiva de Acessibilidade Web e a norma EN 301 549 impõem requisitos ao setor público e a muitos serviços privados. Nos Estados Unidos, a Seção 508 e a ADA geram obrigações semelhantes. Na América Latina, vários países possuem regulamentações próprias inspiradas nas WCAG. É aconselhável verificar a legislação aplicável ao seu mercado.
De quanto em quanto tempo é necessário reauditar um site para manter o nível AA?
Não existe um prazo universal, mas qualquer mudança no design, modelo ou componente pode introduzir regressões. Uma abordagem prática é auditar automaticamente durante cada implantação por meio de integração contínua e realizar uma revisão manual completa pelo menos uma vez por ano ou após reformulações significativas. Documentar cada auditoria torna mais fácil demonstrar a conformidade sustentada ao longo do tempo.
Conclusão
A conformidade com AA de acessibilidade na Web não é comprada ou instalada: ela é construída combinando ferramentas e julgamento. Auditores automatizados aceleram o trabalho, verificadores de contraste resolvem uma falha objetiva, leitores de tela revelam a experiência real e a revisão manual cobre o que nenhuma máquina pode julgar.
Escolha suas ferramentas de acordo com seu fluxo de trabalho, não de acordo com sua popularidade, e documente cada decisão. Para aprofundar os critérios e técnicas, a referência definitiva continua sendo a documentação da WCAG do W3C e as diretrizes da iniciativa WAI.
Fontes e leituras adicionais
- Diretrizes de acessibilidade para conteúdo da Web — Wikipedia: As Diretrizes de acessibilidade para conteúdo da Web (WCAG) fazem parte de uma série publicada pela Web Accessibility Initiative (WAI) do World Wide Web Consortium (W3C),…
- Acessibilidade na Web — Wikipédia: Acessibilidade na Web, ou eAccessibility, é a prática inclusiva de garantir que não haja barreiras que impeçam a interação ou o acesso a sites no mundo…
Cumprir WCAG sem tocar no código?
Superposição de IA que promete cumprimento WCAG em 48 horas