Como Testar a Acessibilidade na Web: Ferramentas Automatizadas, Testes Manuais e Leitores de Tela

Os números são difíceis de ignorar. De acordo com o relatório WebAIM Million 2026, varreduras automatizadas em um milhão de homepages detectaram mais de 56 milhões de erros de acessibilidade distintos — uma média de 56,1 erros por página, um aumento de mais de 10% em relação ao ano anterior. E como as ferramentas automatizadas conseguem detectar apenas cerca de 30–40% das potenciais violações das WCAG, a verdadeira dimensão do problema é significativamente maior. Se a sua estratégia de testes de acessibilidade começa e termina com uma única varredura por extensão de navegador, você está vendo apenas uma fração das barreiras que seus usuários enfrentam todos os dias.

Por que uma estratégia de testes em múltiplas camadas é inegociável

Testes de acessibilidade na web não são um evento único — são uma disciplina que abrange ferramentas, julgamento humano e experiência vivida. As Web Content Accessibility Guidelines (WCAG) são construídas sobre quatro princípios fundamentais, comumente chamados de POUR: o conteúdo deve ser Perceptível, Operável, Compreensível e Robusto. Ferramentas automatizadas podem verificar se uma imagem tem um atributo alt, mas não conseguem julgar se esse texto alternativo realmente descreve a imagem de forma significativa. Um script pode confirmar que um botão tem um rótulo, mas não pode dizer se uma pessoa usuária de leitor de tela entenderia o que pressioná-lo faz naquele contexto.

É por isso que todo programa sério de acessibilidade combina três abordagens distintas: varredura automatizada para capturar violações sistêmicas e repetíveis em escala; testes manuais para avaliar critérios dependentes de julgamento que exigem um cérebro humano; e testes com tecnologias assistivas — especialmente leitores de tela — para validar a experiência real de pessoas usuárias que dependem dessas ferramentas diariamente. Cada camada compensa os pontos cegos das outras. Pular qualquer uma delas deixa lacunas que eventualmente aparecerão como reclamações de usuários, falhas em auditorias ou exposição legal.

As WCAG 2.2, o padrão atual do W3C desde o final de 2023, dão maior ênfase à usabilidade para navegação por teclado, interações por toque e acessibilidade cognitiva, mantendo todos os requisitos existentes das WCAG 2.1. Testar em relação a elas não é opcional para a maioria das organizações — é cada vez mais exigido por regulamentações, desde a ADA nos Estados Unidos até o European Accessibility Act, que entrou em vigor em junho de 2025. Entender como testar é a base prática que torna a conformidade alcançável.

Testes automatizados: sua primeira linha de defesa

Ferramentas automatizadas aceleram o processo de testes e se integram perfeitamente a pipelines de CI/CD, ajudando equipes a detectar e corrigir erros de acessibilidade cedo e com frequência. Elas devem ser entendidas como um filtro — não vão detectar tudo, mas vão identificar de forma confiável as violações mais comuns e mais mensuráveis, e em uma velocidade que nenhum revisor humano consegue igualar. Pense nelas como um corretor ortográfico: essenciais, mas não um substituto para um editor experiente.

As categorias mais comuns de problemas que ferramentas automatizadas detectam de forma confiável incluem texto alternativo ausente ou vazio em imagens, proporções de contraste de cor insuficientes, campos de formulário sem rótulos associados, texto vazio em links ou botões, declarações de idioma da página ausentes e estruturas de cabeçalhos duplicadas ou ausentes. De acordo com os dados do WebAIM Million, 96,4% dos erros detectados se enquadram em apenas seis categorias — o que significa que ferramentas automatizadas, aplicadas de forma consistente, podem reduzir substancialmente o número de violações antes que qualquer revisor humano toque na interface.

Principais ferramentas de testes automatizados

axe-core / axe DevTools (Deque Systems) é, provavelmente, o mecanismo de testes de acessibilidade mais amplamente adotado na indústria. Seu núcleo open source está incorporado em dezenas de outras ferramentas e frameworks de testes. A extensão de navegador funciona no Chrome, Firefox e Edge, oferecendo feedback instantâneo sobre o DOM renderizado. Para equipes de engenharia, o axe-core se integra com Cypress, Playwright, Selenium e Jest, tornando simples incorporar verificações de acessibilidade diretamente na sua suíte de testes existente.

WAVE (WebAIM) é uma extensão de navegador e ferramenta de avaliação online que fornece feedback visual, na própria página, usando ícones coloridos sobrepostos diretamente ao seu conteúdo. É particularmente adequada para editores de conteúdo e partes interessadas não técnicas que precisam entender problemas de acessibilidade sem ler código. O WAVE destaca erros, alertas, elementos estruturais e papéis ARIA de uma forma que torna a relação entre marcação e experiência do usuário imediatamente visível.

Google Lighthouse é incorporado diretamente ao Chrome DevTools e executa auditorias de acessibilidade junto com verificações de desempenho, SEO e boas práticas. É excelente para auditorias rápidas de front-end durante o desenvolvimento e pode ser executado via linha de comando para integração em CI. Sua pontuação de acessibilidade é alimentada pelo axe-core por baixo dos panos, portanto cobre áreas sobrepostas, mas não idênticas.

Pa11y é uma ferramenta de linha de comando e biblioteca Node.js projetada para integração em pipelines. Ela oferece suporte tanto ao axe quanto ao mecanismo HTML_CodeSniffer, pode testar múltiplas URLs a partir de um arquivo de configuração e gera relatórios legíveis por máquina, adequados para dashboards ou sistemas de tickets. É particularmente útil para monitorar sites grandes ou para organizações que precisam auditar URLs em massa de forma agendada.

Integrando o axe ao seu pipeline de CI/CD

A maneira mais eficaz de evitar regressões de acessibilidade é tratá-las como qualquer outro bug — detectá-las antes que cheguem à produção. Integrar o axe-core ao seu pipeline de CI significa que cada pull request é automaticamente analisado, e builds podem ser configurados para falhar quando as violações excedem limites aceitáveis. Aqui está um exemplo mínimo usando Playwright e o pacote @axe-core/playwright:

import { test, expect } from '@playwright/test';
import AxeBuilder from '@axe-core/playwright';

test.describe('Homepage accessibility', () => {
  test('should have no automatically detectable WCAG violations', async ({ page }) => {
    await page.goto('https://your-site.com/');
    const results = await new AxeBuilder({ page })
      .withTags(['wcag2a', 'wcag2aa', 'wcag21aa'])
      .analyze();
    expect(results.violations).toEqual([]);
  });
});

Esse teste navega até a sua aplicação, executa o axe-core na página renderizada com escopo para as regras WCAG 2.x Nível A e AA, e falha se qualquer violação for retornada. Você pode conectá-lo a um workflow do GitHub Actions para que seja executado a cada push para a main ou a cada pull request. Tenha em mente que, quando você adiciona testes automatizados de acessibilidade a um projeto maduro pela primeira vez, pode descobrir dezenas de problemas pré-existentes. Em vez de bloquear todas as implantações imediatamente, configure uma contagem de violações de linha de base e aperte o limite gradualmente à medida que fizer a correção.

Limitação importante: Ferramentas automatizadas detectam aproximadamente 30–40% das violações das WCAG. Elas são necessárias, mas não suficientes. Testes manuais são imprescindíveis para revelar toda a extensão das barreiras de acessibilidade.

Testes manuais: o que as máquinas não podem julgar

Testes manuais preenchem as lacunas que ferramentas automatizadas estruturalmente não conseguem cobrir. Eles exigem que uma pessoa testadora — idealmente alguém treinado em WCAG e familiarizado com tecnologias assistivas — percorra páginas e interações usando uma metodologia definida. O objetivo não é reverificar o que o scanner automatizado já encontrou, mas avaliar os critérios que exigem julgamento humano: a ordem de leitura é lógica? A gestão de foco faz sentido depois que um modal é aberto? A mensagem de erro é realmente útil ou apenas diz "entrada inválida"?

Uma sessão prática de testes manuais cobre várias áreas distintas. A primeira é a navegação apenas por teclado. Desconecte o mouse e navegue por toda a sua interface usando apenas Tab, Shift+Tab, Enter, Espaço e teclas de seta. Todo elemento interativo — links, botões, campos de formulário, menus suspensos, seletores de data, modais, abas — deve ser alcançável e operável sem mouse. O foco nunca deve ficar preso (a menos que intencionalmente, como em um modal que deve reter o foco). O indicador de foco visível deve ser claro o suficiente para ser acompanhado. As WCAG 2.2 adicionaram o Critério de Sucesso 2.4.11 Focus Appearance, que define um tamanho mínimo e requisito de contraste para indicadores de foco — isso quase sempre é uma verificação manual.

A segunda área é a revisão de conteúdo e estrutura. Leia a página com um olhar crítico para a hierarquia de cabeçalhos. Cabeçalhos devem transmitir o esboço da página — <h1> para o título da página, <h2> para seções principais, <h3> para subseções — sem pular níveis. Verifique se o texto de links é descritivo isoladamente ("Baixar o Relatório Anual 2025" é bom; "clique aqui" não é). Confira se imagens com conteúdo significativo têm texto alternativo preciso e se imagens decorativas têm atributos alt vazios (alt=''). Revise os rótulos de formulários: todo campo deve ter um rótulo associado programaticamente, não apenas um placeholder.

A terceira área são as interações dinâmicas e ARIA. Interfaces pesadas em JavaScript — aplicações de página única, modais, resultados de busca em tempo real, carrosséis, acordeões — criam desafios de acessibilidade que scanners estáticos frequentemente não detectam. Quando um modal é aberto, o foco se move para dentro dele? Quando é fechado, o foco retorna ao elemento que o acionou? Quando uma região dinâmica é atualizada (uma contagem de resultados de busca, uma mensagem de validação de formulário), isso é anunciado para tecnologias assistivas? ARIA mal utilizada é uma das fontes mais comuns de regressões de acessibilidade. Os dados do WebAIM Million mostram consistentemente que páginas que usam atributos ARIA têm, em média, significativamente mais erros do que aquelas sem — não porque ARIA seja ruim, mas porque é frequentemente implementada de forma incorreta.

Um checklist prático de testes manuais

• Navegação por teclado: Use Tab em todos os elementos interativos; confirme ordem lógica, ausência de armadilhas de foco e indicadores de foco visíveis que atendam às WCAG 2.2 SC 2.4.11.
• Estrutura de cabeçalhos: Verifique uma hierarquia lógica, sem saltos, usando uma extensão de navegador como HeadingsMap ou a barra de ferramentas WAVE.
• Texto de links e botões: Confirme que todos os elementos interativos têm nomes acessíveis descritivos e únicos — não "clique aqui" ou "saiba mais" repetidos dezenas de vezes.
• Acessibilidade de formulários: Verifique se todo campo tem um rótulo explícito, se as mensagens de erro são específicas e associadas programaticamente, e se campos obrigatórios são indicados de forma que tecnologias assistivas possam transmitir.
• Cor e contraste: Verifique manualmente qualquer texto ou componente de UI que ferramentas automatizadas tenham sinalizado como incerto. Texto com baixo contraste foi encontrado em 83,9% das homepages no relatório WebAIM Million 2026 — é a falha de acessibilidade mais comum.
• Tamanho de alvo de toque: As WCAG 2.2 SC 2.5.8 exigem que alvos interativos tenham pelo menos 24×24 pixels CSS (com boa prática recomendada em 44×44 pixels). Inspecione botões pequenos, links apenas com ícone e elementos de navegação móvel.
• Zoom e reflow: Teste com zoom do navegador em 200% e 400%. O conteúdo deve se reorganizar sem rolagem horizontal em 400% (WCAG SC 1.4.10).

Testes com leitores de tela: o proxy mais próximo da experiência real

Testes com leitores de tela são a parte mais exigente de um programa de acessibilidade, e também a mais reveladora. Uma pessoa usuária de leitor de tela experimenta uma página web como um fluxo linear de texto e informação semântica — o layout visual é irrelevante. Cabeçalhos, marcos, listas, tabelas, rótulos de formulários e papéis ARIA são o esqueleto de navegação. Se esse esqueleto estiver quebrado ou ausente, a página se torna inutilizável, independentemente de quão bem ela se saia em verificações automatizadas.

De acordo com a WebAIM Screen Reader User Survey conduzida no final de 2023 e início de 2024, o JAWS continua sendo o leitor de tela desktop primário mais citado, com 40,5% das respostas, com o NVDA logo atrás, com 37,7%. O VoiceOver detém 9,7% do mercado desktop primário, mas é de longe o leitor de tela dominante em dispositivos móveis, com 70,6% das pessoas usuárias de leitores de tela móveis dependendo dele. Isso significa que um programa de testes abrangente deve cobrir, no mínimo: NVDA com Chrome no Windows, JAWS com Chrome no Windows e VoiceOver com Safari no iOS.

Os principais leitores de tela em resumo

JAWS (Job Access With Speech), desenvolvido pela Freedom Scientific, tem sido o padrão ouro em ambientes corporativos por décadas. Ele oferece integração profunda com o Microsoft Office, scripts avançados para aplicações não padronizadas e descrição de imagens com IA. O JAWS exige uma licença paga (aproximadamente US$ 1.000 para uma licença padrão, ou US$ 95/ano para uma assinatura doméstica), o que o torna menos acessível para testes ocasionais, mas essencial para validar que fluxos de trabalho em nível corporativo funcionam para profissionais que usam leitores de tela.

NVDA (NonVisual Desktop Access) é gratuito, open source e confiável para milhões de pessoas. Seu conjunto de recursos cresceu a ponto de se equiparar ao JAWS para a grande maioria das tarefas web do dia a dia, e sua portabilidade — pode ser executado a partir de um pendrive em qualquer máquina Windows — o torna a escolha prática para a maioria das equipes de desenvolvimento que estão começando a testar com leitores de tela. NVDA com Chrome é a segunda combinação de leitor de tela e navegador mais comum no uso real.

VoiceOver vem incorporado em todos os dispositivos macOS e iOS, sem necessidade de instalação. No desktop, funciona melhor com o Safari. No iPhone e iPad, é o leitor de tela dominante de longe. Se o seu site tem tráfego móvel significativo — e a maioria tem — o VoiceOver no iOS é uma parte obrigatória da sua matriz de testes. Seu modelo de navegação baseado em gestos em telas sensíveis ao toque é significativamente diferente da navegação por teclado no desktop, o que significa que problemas de acessibilidade específicos de dispositivos móveis só podem ser encontrados testando em um dispositivo iOS real.

TalkBack é o leitor de tela do Google para Android e é usado por cerca de 35% das pessoas usuárias de leitores de tela móveis. Se o seu público inclui usuários de Android, testes com TalkBack devem fazer parte do seu programa de acessibilidade móvel.

Como conduzir um teste eficaz com leitor de tela

Comece desligando o monitor ou fechando os olhos. O objetivo é simular a experiência de alguém que não pode ver a tela. Navegue pela página usando apenas os comandos do leitor de tela. Para NVDA e JAWS, os padrões de navegação mais importantes a exercitar são: leitura linear da página com as setas ou o comando de leitura contínua; saltar entre cabeçalhos usando H; navegar por marcos usando D (NVDA) ou ; (JAWS) para alternar entre regiões de conteúdo principal, navegação e rodapé; usar Tab apenas para elementos interativos; e usar o modo de formulários para interagir com campos de entrada.

À medida que você navega, pergunte-se: a ordem de leitura é lógica? O título da página faz sentido quando anunciado? As imagens são descritas de forma significativa ou o leitor de tela anuncia "imagem" sem contexto? Campos de formulário anunciam seu rótulo, tipo e valor atual? Quando você envia um formulário com erros, as mensagens de erro são anunciadas e fáceis de localizar? Quando o conteúdo dinâmico é atualizado — um banner de notificação, um estado de carregamento, uma contagem de resultados de busca — a atualização é anunciada sem exigir que a pessoa usuária volte a navegar para encontrá-la?

Leitores de tela permitem que usuários interajam em modos diferentes — modo de leitura, modo de formulários e modo de aplicação — e podem produzir resultados muito diferentes em cada um. Um elemento que funciona corretamente em um modo pode falhar silenciosamente em outro. Sempre teste a mesma interação em múltiplos modos de navegação.

Uma das falhas mais comuns e mais prejudiciais em aplicações web modernas é a gestão de foco quebrada. Quando uma caixa de diálogo modal é aberta, o foco deve se mover para dentro dela; quando é fechada, o foco deve retornar ao elemento que a acionou. Quando uma aplicação de página única transita para uma nova visualização, o título da página e o cabeçalho principal devem ser anunciados. Quando ocorre um erro durante o envio de um formulário, o foco deve se mover para o resumo de erros ou para o primeiro campo inválido. Esses padrões não podem ser validados por nenhuma ferramenta automatizada — eles exigem uma pessoa testadora com um leitor de tela aberto.

Construindo um programa de testes de acessibilidade duradouro

O erro mais comum que organizações cometem é tratar testes de acessibilidade como uma auditoria pontual. Um site que passa hoje desenvolverá novas violações amanhã, à medida que conteúdo é publicado, recursos são lançados e scripts de terceiros são atualizados. A acessibilidade precisa ser incorporada ao ciclo de desenvolvimento como uma prática contínua, não um checklist periódico.

Um programa sustentável tem três camadas em execução paralela. A camada automatizada roda a cada commit de código, capturando regressões antes que cheguem à produção. A camada manual roda a cada sprint, à medida que novos recursos são desenvolvidos — não como uma barreira no final, mas como uma verificação durante o desenvolvimento. A camada de tecnologias assistivas roda como parte dos testes de aceitação para qualquer recurso que envolva padrões de interação significativos: formulários, mudanças de navegação, modais, conteúdo dinâmico e fluxos de usuário. Para a maioria das equipes, isso significa pelo menos NVDA com Chrome e VoiceOver no iOS.

A priorização importa. Se sua auditoria revelar cinquenta problemas, nem todos têm o mesmo peso. Violações das WCAG são categorizadas por impacto — problemas críticos que tornam o conteúdo completamente inacessível para algumas pessoas devem ser corrigidos antes de problemas graves, que por sua vez têm precedência sobre problemas moderados e menores. Concentre-se primeiro nos padrões que afetam tipos inteiros de página: se sua navegação está quebrada para usuários de teclado, corrija o template de navegação e você corrige isso em todos os lugares de uma vez. Se o tratamento de erros de formulário é inacessível, corrigir o padrão corrige todos os formulários.

Documentação não é opcional para responsáveis por conformidade. Mantenha um registro de testes de acessibilidade que indique quais páginas foram testadas, quais ferramentas e tecnologias assistivas foram usadas, quais violações foram encontradas e qual correção foi aplicada e quando. Essa documentação se torna inestimável durante auditorias de acessibilidade ou processos legais, demonstrando um esforço contínuo e de boa-fé para alcançar e manter a conformidade.

O papel dos widgets de overlay na sua estratégia de testes

Widgets de overlay de acessibilidade, como o Accsible SDK, desempenham um papel significativo em uma estratégia de acessibilidade em camadas — especialmente para organizações que precisam fornecer melhorias imediatas ao conteúdo existente enquanto um trabalho de correção mais profundo está em andamento. Um overlay bem implementado pode disponibilizar ferramentas assistivas para usuários, como aumento de texto, ajuste de contraste e melhorias na navegação por teclado, que abordam barreiras comuns sem exigir uma reconstrução completa do site.

No entanto, overlays não são um substituto para testes. Eles complementam um programa de testes em vez de substituí-lo. A abordagem mais eficaz é usar um overlay para tratar problemas superficiais, na camada de apresentação, que podem ser resolvidos de forma programática, enquanto se utilizam varreduras automatizadas, testes manuais e validação com leitores de tela para identificar e corrigir problemas estruturais — semântica quebrada, papéis ARIA ausentes, widgets personalizados inacessíveis — que exigem correções no código. Overlays funcionam melhor quando a base de código subjacente já foi testada e as lacunas restantes estão no campo de preferências de usuário, e não em barreiras fundamentais de interação.

Ao avaliar qualquer ferramenta de acessibilidade, overlay ou não, pergunte se ela foi testada com leitores de tela reais. Um widget que cria uma barra de ferramentas de acessibilidade visível, mas introduz armadilhas de foco ou conflitos de ARIA na página, piorou a situação, em vez de melhorá-la. As metodologias de testes deste guia se aplicam às próprias ferramentas de acessibilidade, não apenas aos sites em que elas são executadas.

Principais conclusões

• Nenhuma ferramenta isolada é suficiente. Scanners automatizados detectam apenas 30–40% das violações das WCAG. Um programa completo exige testes automatizados, revisão manual e testes reais com tecnologias assistivas funcionando juntos como camadas complementares.
• Traga a acessibilidade para o início do processo. Integrar axe-core ou Pa11y ao seu pipeline de CI/CD significa que violações são detectadas antes de chegarem à produção, onde corrigi-las custa exponencialmente mais em tempo, reputação e risco legal.
• Teste com os leitores de tela que seus usuários realmente usam. NVDA com Chrome e JAWS com Chrome dominam o uso em desktop; VoiceOver no iOS domina o uso em dispositivos móveis. Cubra essas combinações, no mínimo, e teste interações dinâmicas — modais, erros de formulário, mudanças de rota em SPAs — que ferramentas automatizadas nunca vão detectar.
• Corrija padrões, não apenas instâncias. Se a estrutura de cabeçalhos está quebrada, corrija o template. Se o tratamento de erros de formulário é inacessível, corrija o componente. Correções sistemáticas entregam valor exponencialmente maior do que remendos pontuais.
• Torne os testes de acessibilidade contínuos, não periódicos. Um site que passa em uma auditoria hoje vai se degradar. Incorpore testes ao seu ciclo de desenvolvimento — automatizados a cada commit, manuais a cada sprint, testes com tecnologias assistivas em cada funcionalidade significativa — e a acessibilidade se torna uma propriedade mantida do seu produto, e não um projeto de correção.