Seu site obtém 100/100 na auditoria axe-core. E, no entanto, desde a última atualização de CSS, o contraste dos seus botões caiu abaixo do limite legal e o indicador de foco desapareceu — invisível para o analisador de código, mas bem real para o usuário e para o regulador. Esse é o ponto cego das ferramentas de acessibilidade clássicas: elas leem o código, não o que é renderizado.
E os desafios não são apenas estéticos. As obrigações de acessibilidade web variam conforme a jurisdição: a União Europeia impõe o nível AA via o European Accessibility Act, os Estados Unidos exigem conformidade com a Section 508 sob o ADA, o Canadá alinha o ACA ao WCAG 2.1 AA, e o Reino Unido aplica suas próprias regras via o Equality Act. Este guia compara as exigências por região, detalha as etapas de um teste WCAG completo e explica como o teste visual automatizado complementa as ferramentas de análise estática para cobrir a totalidade dos critérios.
A acessibilidade web, segundo o W3C, significa "projetar e desenvolver sites, ferramentas e tecnologias de modo que pessoas com deficiência possam utilizá-los" (fonte: W3C, Web Accessibility Initiative). Por mais ampla que seja essa definição, ela se baseia em grande parte em critérios visuais. O contraste de cores, o tamanho do texto, a visibilidade do foco do teclado, o espaçamento entre elementos: todos esses aspectos são tanto requisitos de acessibilidade quanto propriedades mensuráveis visualmente.
E, no entanto, a maioria das equipes trata a acessibilidade e o teste visual como duas práticas distintas, gerenciadas por pessoas diferentes, com ferramentas diferentes, em momentos diferentes do ciclo de desenvolvimento.
Isso é um erro estratégico. A acessibilidade visual é testável automaticamente, e o teste visual é a ferramenta mais natural para monitorá-la continuamente.
Sua auditoria de código diz "conforme", mas a tela conta outra história? O Delta-QA detecta as diferenças de contraste, de foco ou de layout que os analisadores estáticos não enxergam, no seu desktop e sem cadastro. Testar o Delta-QA grátis →
Sumário
- O que as WCAG exigem visualmente
- Requisitos de Teste WCAG por Região
- Como realizar um teste WCAG completo: as etapas
- Por que as ferramentas de acessibilidade clássicas não são suficientes
- O teste visual como rede de segurança para a acessibilidade
- Os critérios WCAG que o teste visual detecta nativamente
- Como implementar uma vigilância visual da acessibilidade
- A acessibilidade visual não é um luxo, é uma obrigação
- FAQ
O que as WCAG exigem visualmente
As WCAG (Web Content Accessibility Guidelines) na versão 2.2 contêm 86 critérios de sucesso distribuídos em três níveis de conformidade: A, AA e AAA. Entre esses critérios, uma proporção significativa diz respeito diretamente à aparência visual das interfaces.
Vejamos os mais importantes.
O contraste de cores (critério 1.4.3 para o nível AA, 1.4.6 para o AAA) impõe uma relação de contraste mínima de 4.5:1 para o texto normal e de 3:1 para o texto de tamanho grande. Este critério é puramente visual: é verificado comparando as cores do texto e do seu fundo.
O tamanho do texto (critério 1.4.4) exige que o conteúdo possa ser ampliado até 200% sem perda de informação ou funcionalidade. Isso significa que com zoom de 200%, o texto não deve transbordar seus contêineres, os elementos não devem se sobrepor e as informações devem permanecer legíveis. Tudo isso é verificável visualmente.
O indicador de foco (critério 2.4.7 para o AA, reforçado por 2.4.11 e 2.4.12 nas WCAG 2.2) exige que cada elemento interativo exiba um indicador visível quando recebe o foco do teclado. Este indicador deve ter contraste suficiente e uma superfície mínima. Mais uma vez, é um critério visual.
O espaçamento do texto (critério 1.4.12) exige que o conteúdo permaneça funcional quando o usuário modifica a altura da linha para 1,5 vezes o tamanho da fonte, o espaçamento entre parágrafos para 2 vezes, o espaçamento entre letras para 0,12 vezes e o espaçamento entre palavras para 0,16 vezes. Se esses ajustes quebrarem o layout, é uma violação de acessibilidade detectável visualmente.
O redimensionamento do conteúdo (critério 1.4.10, também chamado de "reflow") impõe que o conteúdo seja exibido sem rolagem horizontal em uma largura de 320 pixels CSS. É exatamente o que o teste responsive verifica.
A conclusão é clara: uma parte importante da conformidade WCAG se baseia em propriedades visuais mensuráveis.
Requisitos de teste WCAG por região
As obrigações legais em matéria de acessibilidade digital diferem conforme a jurisdição. A tabela abaixo compara as exigências de quatro regiões principais.
| Região | Norma exigida | Nível WCAG obrigatório | Prazo / Ano | Texto legal | Ferramenta(s) recomendada(s) |
|---|---|---|---|---|---|
| UE / EAA | EN 301 549 (alinhada ao WCAG 2.1) | AA | Junho 2025 (entrada em vigor) | European Accessibility Act (EAA) — Diretiva 2019/882 | axe-core, WAVE, Lighthouse |
| EUA / ADA + Section 508 | Section 508 (alinhada ao WCAG 2.0) | AA | Section 508: janeiro 2018 (atualização); ADA: jurisprudência contínua | ADA.gov — Section 508 (29 U.S.C. § 794d) | axe-core, ANDI, WAVE |
| Canadá / ACA | ACA (alinhada ao WCAG 2.1) | AA | Junho 2024 (fase 1); junho 2025 (fase 2) | Lei Canadense sobre Acessibilidade (ACA) | axe-core, Accessibility Insights |
| UK / EQS | Public Sector Bodies Accessibility Regulations 2018 | AA | Setembro 2020 (setor público) | Equality Act 2010 — Accessibility Regulations | axe-core, WAVE, Pa11y |
Pontos-chave da tabela:
- As quatro jurisdições exigem, no mínimo, o nível WCAG AA. Nenhuma impõe o AAA, mas alcançá-lo reduz o risco jurídico.
- A União Europeia tem o prazo mais recente e mais restritivo com o EAA, que cobre também o setor privado.
- Os Estados Unidos permanecem no WCAG 2.0 via a Section 508, mas os tribunais aplicam cada vez mais o WCAG 2.1 AA como referência sob o ADA.
- O Canadá e o Reino Unido se alinharam ao WCAG 2.1 AA, com calendários de aplicação escalonados.
- O axe-core, desenvolvido pela Deque Systems, é a ferramenta mais citada em todas as jurisdições — integra-se aos frameworks de teste e ao CI/CD.
Como realizar um teste WCAG completo: as etapas
Um teste WCAG completo combina análise automatizada, verificação visual e auditoria manual. Veja as etapas a seguir, em ordem.
- Definir o perímetro do teste. Identifique as páginas e componentes a testar, a jurisdição ou jurisdições aplicáveis (veja a tabela acima) e o nível de conformidade desejado (AA na quase totalidade dos casos).
- Executar uma análise automatizada com axe-core. Execute o axe-core em cada página do perímetro. Essa ferramenta detecta aproximadamente 30 a 50% das violações WCAG — aquelas verificáveis por análise do DOM (alternativas textuais ausentes, papéis ARIA incorretos, estrutura de títulos, atributos de formulário).
- Executar uma auditoria Lighthouse. Complemente a análise do axe-core com o Google Lighthouse, que avalia a categoria "Accessibility" em 100 pontos e sinaliza problemas comuns com sugestões de correção.
- Verificar os critérios visuais por teste de captura de tela. Capture suas páginas nas condições de acessibilidade: zoom de 200%, largura de 320 px, espaçamentos WCAG injetados (critério 1.4.12), foco do teclado forçado. Compare os resultados com uma baseline conforme para detectar regressões. O teste de regressão visual é o método mais confiável para esta etapa.
- Testar manualmente a navegação por teclado. Percorra cada página apenas com o teclado (Tab, Shift+Tab, Enter, Espaço, setas). Verifique se a ordem de tabulação é lógica, se cada elemento interativo recebe um foco visível e se não existe nenhuma armadilha de teclado.
- Verificar a compatibilidade com tecnologias assistivas. Teste suas páginas com um leitor de tela (NVDA no Windows, VoiceOver no macOS/iOS, TalkBack no Android). Verifique se o conteúdo é anunciado corretamente, se as landmarks de região estão presentes e se os formulários são utilizáveis.
- Testar em vários navegadores e dispositivos. Os problemas de acessibilidade variam de um motor de renderização para outro. Um contraste conforme no Chrome pode não sê-lo no Safari. O teste visual cross-browser captura essas diferenças.
- Documentar os resultados e as correções. Para cada violação detectada, referencie o critério WCAG envolvido, a jurisdição aplicável, a gravidade e a correção aplicada. Esta documentação serve como prova de conformidade em caso de auditoria.
- Integrar os testes ao pipeline CI/CD. Automatize as etapas 2, 3 e 4 para que sejam executadas em cada pull request. Qualquer regressão é bloqueada antes da implantação em produção.
- Planejar uma auditoria recorrente. Mesmo com uma automação completa, uma auditoria manual trimestral ou semestral por um especialista WCAG continua recomendada para cobrir os critérios não automatizáveis.
Por que as ferramentas de acessibilidade clássicas não são suficientes
Ferramentas de auditoria de acessibilidade como axe-core ou Lighthouse são indispensáveis. Elas analisam o DOM, verificam os atributos ARIA, detectam tags ausentes e sinalizam violações estruturais. Ninguém questiona isso.
Mas essas ferramentas têm uma limitação fundamental: analisam o código, não a renderização. Verificam o que o HTML e o CSS declaram, não o que o usuário realmente vê.
Um exemplo concreto. Imagine um botão cujo texto é branco sobre fundo azul, com uma relação de contraste em conformidade de 5.2:1. Durante uma atualização de CSS, um desenvolvedor modifica a cor de fundo do botão para um tom mais claro, sem alterar o texto. A relação cai para 2.8:1. O axe-core pode detectar isso em alguns casos, mas apenas se a folha de estilos for corretamente interpretada pelo motor de análise. O teste visual, por outro lado, captura essa regressão imediatamente, porque compara a renderização real do botão antes e depois da modificação.
Outro caso frequente: o indicador de foco é definido em CSS, mas uma atualização do framework remove ou sobrescreve o estilo outline. Funcionalmente, o botão continua clicável. Estruturalmente, o HTML está intacto. Mas visualmente, o foco desapareceu. Nenhuma ferramenta de análise de DOM sinaliza esse problema de forma confiável. O teste visual detecta a diferença de renderização.
Essas ferramentas também não detectam problemas relacionados ao zoom. Quando um usuário amplia o texto para 200%, os transbordamentos, sobreposições e textos truncados são problemas puramente visuais. Não aparecem na análise estática do código.
As ferramentas de acessibilidade clássicas são necessárias, mas insuficientes. Cobrem os critérios estruturais (alternativas textuais, estrutura de títulos, papéis ARIA), mas deixam um ponto cego em tudo que diz respeito à renderização visual.
Conformidade WCAG não precisa de orçamento de consultoria Verifique regressões visuais que quebram a acessibilidade direto no seu desktop, sem código e com a versão gratuita do Delta-QA. Testar o Delta-QA grátis →
O teste visual como rede de segurança para a acessibilidade
O teste visual automatizado consiste em capturar screenshots das suas páginas e componentes, e depois compará-los a uma referência (baseline) para detectar qualquer mudança visual não intencional. Aplicado à acessibilidade, esse mecanismo se torna uma rede de segurança formidável.
Veja por quê.
Ele detecta regressões, não apenas violações. Uma auditoria de acessibilidade informa se o seu site está em conformidade em um dado momento. O teste visual alerta você assim que uma mudança no código degrada a acessibilidade visual. É a diferença entre um diagnóstico e um sistema de alarme.
Funciona sobre a renderização real. O teste visual captura o que o navegador realmente exibe, após aplicar todas as folhas de estilos, scripts JavaScript e cálculos de layout. Não interpreta o CSS — constata o resultado.
Cobre os casos multi-navegador e multi-resolução. Os problemas de acessibilidade visual variam entre navegadores e tamanhos de tela. Um contraste em conformidade no Chrome pode não estar no Safari se as fontes forem renderizadas de forma diferente. O teste visual cross-browser captura essas diferenças.
Integra-se ao CI/CD. Ao executar testes visuais em cada pull request, você detecta regressões de acessibilidade antes que cheguem à produção. É prevenção, não correção.
Não requer experiência em acessibilidade para ser configurado. Qualquer membro da equipe pode configurar um teste visual que capture as páginas em diferentes níveis de zoom ou com estilos de foco forçados. A comparação é automática.
Os critérios WCAG que o teste visual detecta nativamente
Vejamos critério por critério os aspectos WCAG que o teste visual cobre eficazmente.
Critérios 1.4.3 e 1.4.6 — Contraste. Ao combinar o teste visual com filtros de simulação de daltonismo ou extraindo as cores dos screenshots, você pode verificar que o contraste permanece em conformidade após cada modificação. Uma mudança de paleta que degrade o contraste será imediatamente visível na comparação de screenshots.
Critério 1.4.4 — Redimensionamento do texto. Capture suas páginas com zoom de 200%. Qualquer regressão (texto truncado, elementos que se sobrepõem, contêineres que transbordam) será detectada pela comparação visual.
Critério 1.4.10 — Reflow. Capture suas páginas em uma largura de 320 pixels CSS. O teste visual responsive verifica que o conteúdo se adapta corretamente sem rolagem horizontal.
Critério 1.4.12 — Espaçamento do texto. Injete os estilos de espaçamento exigidos pelo critério (altura de linha 1.5, espaçamento de parágrafo 2x, letras 0.12em, palavras 0.16em) e capture o resultado. Compare com a baseline para detectar os elementos que quebram sob essas restrições.
Critérios 2.4.7, 2.4.11, 2.4.12 — Foco visível. Force o foco do teclado em cada elemento interativo e capture o resultado. O teste visual detecta o desaparecimento ou a degradação do indicador de foco.
Critério 1.4.11 — Contraste de elementos não textuais. Ícones, bordas de campos de formulário, indicadores de estado: todos esses elementos devem ter uma relação de contraste de pelo menos 3:1. O teste visual os monitora naturalmente.
Como implementar uma vigilância visual da acessibilidade
A implementação prática se baseia em alguns princípios simples.
Crie baselines em condições de acessibilidade. Não se limite a capturar suas páginas no estado padrão. Crie baselines adicionais: com zoom de 200%, com largura de 320 pixels, com os estilos de espaçamento WCAG injetados e com o foco forçado nos elementos interativos.
Integre esses testes ao seu pipeline CI/CD. Cada pull request deve acionar uma comparação visual em todas essas condições. Se uma mudança de CSS degradar a acessibilidade visual, o teste bloqueia o merge.
Use limites de tolerância adaptados. Para os testes de acessibilidade, reduza o limite de diferença aceitável. Uma mudança de 2 pixels em um indicador de foco pode torná-lo não conforme. A tolerância deve ser mais rigorosa do que para um teste visual generalista.
Documente suas baselines de acessibilidade. Cada baseline deve ser associada ao critério WCAG que ela verifica. Isso facilita a auditoria e a rastreabilidade em caso de inspeção.
Combine com ferramentas de análise estática. O teste visual não substitui o axe-core ou o Lighthouse. Ele os complementa. Use as ferramentas de análise para os critérios estruturais (alternativas textuais, estrutura de títulos, ARIA), e o teste visual para os critérios de renderização. Juntos, cobrem praticamente a totalidade das WCAG.
Uma ferramenta como o Delta-QA, que permite configurar testes visuais sem escrever código, torna essa abordagem acessível para toda a equipe, incluindo os responsáveis por acessibilidade que não são desenvolvedores.
A acessibilidade visual não é um luxo, é uma obrigação
Desde junho de 2025, o European Accessibility Act (EAA) obriga as empresas da União Europeia a tornar seus produtos e serviços digitais acessíveis. Nos Estados Unidos, a ADA e a Section 508 impõem exigências semelhantes. No Canadá, a Lei Canadense sobre Acessibilidade entra em aplicação progressiva. No Reino Unido, as Public Sector Bodies Accessibility Regulations 2018 estão em vigor desde 2020. No Brasil, a Lei Brasileira de Inclusão (Lei 13.146/2015) e as diretrizes eMAG impõem requisitos semelhantes para serviços digitais do setor público.
As sanções financeiras existem e estão aumentando. Mas além do risco jurídico, a acessibilidade é uma vantagem competitiva. Segundo a Organização Mundial da Saúde, mais de um bilhão de pessoas no mundo vivem com alguma forma de deficiência. Ignorar a acessibilidade é ignorar um mercado considerável.
A acessibilidade visual é a parte mais facilmente automatizável dessa obrigação. Você não precisa de um especialista WCAG para capturar screenshots em diferentes condições e comparar os resultados. Você precisa de uma ferramenta de teste visual bem configurada.
Pronto para transformar sua conformidade WCAG em vigilância contínua? Capture uma primeira baseline acessível e deixe o Delta-QA bloquear cada regressão visual antes da produção, grátis e sem cadastro. Testar o Delta-QA grátis →
FAQ
Como testar a conformidade WCAG por região?
Comece identificando a jurisdição ou jurisdições aplicáveis ao seu produto (UE, EUA, Canadá, UK ou outra). Consulte a tabela comparativa acima para conhecer a norma e o nível exigido. Execute um teste automatizado com axe-core para as violações estruturais, complemente com um teste visual automatizado (capturas a 200% de zoom, 320 px de largura, foco forçado) para os critérios de renderização e finalize com uma auditoria manual por teclado e leitor de tela. Documente cada resultado com a referência jurisdicional.
O teste WCAG é obrigatório na UE?
Sim. O European Accessibility Act (Diretiva 2019/882), em vigor desde junho de 2025, impõe a conformidade com a norma EN 301 549, ela própria alinhada ao WCAG 2.1 nível AA. O não cumprimento expõe a sanções nacionais variáveis conforme o Estado-membro. O perímetro cobre os produtos e serviços digitais destinados aos consumidores: e-commerce, serviços bancários, transportes, telecomunicações, mídia.
Qual nível WCAG é exigido para conformidade legal?
As quatro jurisdições principais (UE, EUA, Canadá, UK) exigem o nível AA. Nenhuma impõe legalmente o nível AAA, embora alguns critérios AAA (notadamente o contraste reforçado a 7:1) sejam recomendados para reduzir o risco de litígio. Na prática, visar o WCAG 2.1 AA cobre as obrigações de todas as regiões listadas neste guia.
Qual é o prazo do European Accessibility Act?
O EAA foi adotado em 2019 (Diretiva 2019/882) e entrou em vigor em 28 de junho de 2025. As empresas deveriam estar conformes nessa data. Os Estados-membros deveriam transpor a diretiva para o direito nacional — alguns tiveram atraso, mas a obrigação se aplica independentemente da transposição local. As microempresas (menos de 10 funcionários e menos de 2 milhões de euros de faturamento) beneficiam-se de isenções.
Qual a precisão das ferramentas automatizadas de teste WCAG?
As ferramentas automatizadas como o axe-core detectam entre 30 e 50% das violações WCAG, segundo os estudos realizados pela Deque Systems e pelo W3C WAI. Elas cobrem eficazmente os critérios estruturais (alternativas textuais, papéis ARIA, estrutura de títulos), mas deixam um ponto cego nos critérios de renderização visual e na experiência real do usuário. É por isso que um teste completo combina automação, teste visual e auditoria manual.
O teste visual substitui uma auditoria completa de acessibilidade WCAG?
Não. O teste visual cobre os critérios visuais das WCAG (contraste, foco, espaçamento, zoom, reflow), mas não os critérios estruturais como alternativas textuais, navegação por teclado ou papéis ARIA. Ele complementa uma auditoria, não a substitui. Aproximadamente 30 a 40% dos critérios WCAG 2.2 têm um componente visual direto.
Quais níveis de conformidade WCAG o teste visual ajuda a verificar?
O teste visual é relevante para os três níveis: A, AA e AAA. O nível AA, que é o mais comumente exigido pelas regulamentações, contém vários critérios visuais importantes (contraste 1.4.3, foco visível 2.4.7, reflow 1.4.10, espaçamento 1.4.12). O nível AAA reforça os requisitos de contraste (1.4.6 com relação de 7:1) e adiciona critérios suplementares, todos verificáveis visualmente.
Como testar a acessibilidade visual sem competência técnica?
Com uma ferramenta no-code como o Delta-QA, você configura as páginas a testar, define as condições (tamanho de tela, zoom, navegador), e a ferramenta captura e compara automaticamente os screenshots. Nenhuma linha de código é necessária. A interface mostra as diferenças visuais e você decide se são aceitáveis ou não.
Com que frequência a acessibilidade visual deve ser verificada?
A cada modificação do código front-end. A integração ao CI/CD é a melhor abordagem: cada pull request aciona automaticamente os testes. Se você não puder automatizar nesse nível, um teste semanal é um mínimo aceitável para detectar regressões antes que se acumulem.
O teste visual detecta problemas de acessibilidade em dispositivos móveis?
Sim, desde que você configure testes nas resoluções móveis comuns (360px, 375px, 414px de largura). O teste visual responsive captura a renderização real em cada resolução e detecta problemas de reflow, texto truncado, elementos pequenos demais para ativação por toque e contrastes degradados pela renderização móvel.
O European Accessibility Act se aplica à minha empresa?
Se você vende produtos ou serviços digitais para consumidores na União Europeia, sim. O EAA se aplica desde junho de 2025 a sites de e-commerce, serviços bancários, mídia, transporte e telecomunicações, entre outros. Microempresas com menos de 10 funcionários e menos de 2 milhões de euros de faturamento beneficiam-se de isenções, mas as demais devem cumprir.
- Teste Visual para Drupal: O Guia para Proteger a Renderização do seu CMS Enterprise
Conclusão
Um teste WCAG eficaz por região exige conhecer as obrigações legais de cada jurisdição, combinar análise automatizada e teste visual, e integrar essas verificações no ciclo de desenvolvimento. As quatro regiões principais (UE, EUA, Canadá, UK) convergem para o nível WCAG AA, mas os referenciais, prazos e perímetros diferem. O teste visual automatizado preenche a lacuna das ferramentas de análise estática verificando a renderização real — o que o usuário vê, não o que o código declara.
Em vez de tratar a acessibilidade como uma auditoria pontual realizada uma vez por ano, integre o teste visual ao seu pipeline para transformá-la em vigilância contínua. É mais eficaz, mais confiável e infinitamente menos custoso do que a correção tardia.