WCAG 2.3.2: Três Flashes

O Que Esta Regra Significa

WCAG 2.3.2 Três Flashes é um critério de sucesso de Nível AAA sob o princípio Operável. Ele estabelece que páginas da web não devem conter nada que pisque mais de três vezes em qualquer período de um segundo. Diferentemente de seu equivalente de Nível AA (2.3.1 Três Flashes ou Abaixo do Limite), este critério não permite nenhuma exceção para áreas pequenas que piscam ou para flashes que fiquem abaixo dos limites gerais de flash e de flash vermelho. A regra é absoluta: se o conteúdo pisca mais de três vezes por segundo, ele falha, independentemente de tamanho, cor ou contraste.

Um flash é definido pelo WCAG como um par de mudanças opostas na luminância relativa que podem causar convulsões em algumas pessoas. De forma mais prática, qualquer piscar visível de liga-desliga, animação tipo estroboscópio, imagens que ciclam rapidamente ou vídeo tremeluzente que complete mais de três ciclos completos por segundo se enquadra no escopo desta regra. O termo "três flashes" refere-se a três oscilações completas — ou seja, conteúdo que alterna entre um estado mais claro e mais escuro três vezes dentro de um único segundo.

Os tipos de conteúdo afetados são amplos e incluem GIFs animados, animações CSS usando @keyframes, atualizações de DOM acionadas por JavaScript que causam alternância visual rápida, animações em HTML5 Canvas, conteúdo de vídeo incorporado, animações SVG e redes de anúncios de terceiros ou widgets que incorporam mídia animada. Mesmo um tremeluzir sutil em texto de letreiro rolante ou visualizações de dados que se atualizam rapidamente pode acionar este critério se a taxa exceder três flashes por segundo.

Um aprovado em 2.3.2 significa que a página não contém nenhum conteúdo piscante que exceda o limite de três flashes por segundo. Uma falha ocorre sempre que qualquer parte da página — independentemente de quão pequena seja a área — pisca mais de três vezes dentro de qualquer janela de um segundo. Não há exceção de área segura neste critério, o que o diferencia de 2.3.1. Um pequeno cursor piscante, um ícone de carregamento animado ou um banner de anúncio que cicla rapidamente podem todos constituir falhas se piscarem em frequências superiores a 3 Hz.

Por Que Isso Importa

A epilepsia fotossensível afeta aproximadamente 1 em cada 4.000 pessoas globalmente, mas a população total suscetível a alguma forma de resposta neurológica fotossensível — incluindo enxaquecas fotossensíveis, distúrbios vestibulares e fotossensibilidade não epiléptica — é significativamente maior. Para essas pessoas, a exposição a conteúdo que pisca rapidamente em uma tela não é um mero incômodo: pode desencadear crises convulsivas generalizadas, perda de consciência, lesões ou, em casos raros, morte. Diferentemente de muitas barreiras de acessibilidade que degradam a experiência do usuário, conteúdo piscante representa um risco agudo à segurança.

Considere um cenário prático: um site de notícias turco incorpora um ticker ao vivo com um efeito de destaque animado que pulsa a 8 Hz para chamar atenção para notícias de última hora. Uma pessoa com epilepsia fotossensível abre a página no celular enquanto se desloca. Em poucos segundos, o tremeluzir rápido desencadeia uma crise focal, fazendo a pessoa deixar o telefone cair e perder o controle muscular momentaneamente. Ela não teve aviso, nem como desativar o efeito com antecedência, nem recurso algum. Esse cenário é totalmente evitável limitando as taxas de flash a três por segundo ou menos — ou eliminando completamente o conteúdo piscante, como 2.3.2 exige.

Além da dimensão de segurança neurológica, cumprir este critério também beneficia pessoas com distúrbios vestibulares (que sentem tontura, náusea ou desorientação com movimento), pessoas com enxaquecas desencadeadas por padrões visuais e pessoas com transtornos de déficit de atenção que consideram conteúdo piscando rapidamente impossível de ignorar ou contornar. Reduzir ou eliminar conteúdo piscante também tende a melhorar a percepção de profissionalismo da página e reduzir taxas de abandono, já que muitas pessoas — com deficiência ou não — acham animações agressivas irritantes.

Do ponto de vista de SEO e desempenho, eliminar animações pesadas e transições CSS rápidas reduz a carga de CPU e GPU, melhorando métricas Core Web Vitals como Total Blocking Time e Cumulative Layout Shift, ambas sinais de ranqueamento do Google.

Regras Relacionadas do Axe-core

WCAG 2.3.2 exige testes manuais. Nenhuma regra automatizada do axe-core mapeia diretamente para este critério, e isso é intencional — eis por que ferramentas automatizadas não conseguem detectar violações de forma confiável:

• Teste manual necessário — Detecção da taxa de flash: Scanners de acessibilidade automatizados inspecionam o DOM e o CSS estáticos em um único ponto no tempo. Eles não conseguem observar como o conteúdo se comporta ao longo de um segundo de reprodução da animação, medir a frequência de oscilação de luminância de um vídeo ou GIF animado, ou avaliar a taxa de quadros de uma animação em Canvas. A taxa de flash é uma propriedade temporal que exige observação em tempo real, o que a torna fundamentalmente fora do alcance de ferramentas de análise estática como o axe-core. Uma pessoa testadora — ou ferramentas especializadas de análise de fotossensibilidade, como o Photosensitive Epilepsy Analysis Tool (PEAT) — deve revisar o conteúdo animado em movimento para determinar se ele excede o limite de três flashes por segundo.
• Teste manual necessário — Conteúdo de terceiros e incorporado: Anúncios, vídeos incorporados, widgets de redes sociais e iframes podem injetar conteúdo animado que o axe-core não consegue analisar, porque ele opera dentro das restrições de política de mesma origem do navegador. Uma pessoa testadora deve observar manualmente todo o conteúdo incorporado e de terceiros durante a reprodução para avaliar a conformidade.
• Teste manual necessário — Animações acionadas por JavaScript: Alternar classes CSS rapidamente, atualizar pixels de canvas ou manipular elementos SVG via JavaScript em alta frequência pode produzir efeitos de flash que são invisíveis em um instantâneo estático do DOM. Pessoas testadoras devem executar a página em um navegador real, observar todos os estados animados e cronometrar os ciclos de flash manualmente ou com ferramentas de análise de taxa de quadros.

Como Testar

1. Execute uma varredura automatizada como linha de base: Use axe DevTools, Lighthouse ou a auditoria integrada do widget Accsible para identificar quaisquer problemas relacionados a animação que sejam sinalizados. Embora nenhuma regra mapeie diretamente para 2.3.2, essas ferramentas podem exibir alertas relacionados a animações CSS ou regiões ARIA ao vivo que se atualizam rapidamente. Anote quaisquer itens sinalizados, mas entenda que um relatório automatizado limpo não confirma conformidade com 2.3.2.
2. Identifique todo o conteúdo animado manualmente: Carregue a página em um navegador e observe-a por pelo menos 30 segundos sem interagir. Anote todos os elementos que piscam, brilham, animam ou mudam de estado visual repetidamente. Inclua ícones de carregamento, banners, animações de destaque, vídeos em reprodução automática, planos de fundo animados e quaisquer widgets de terceiros. Crie um inventário desses elementos.
3. Use o Photosensitive Epilepsy Analysis Tool (PEAT): Para conteúdo em vídeo ou gravações de tela de animações, use o PEAT (uma ferramenta gratuita do Trace Research and Development Center) para analisar o material quadro a quadro. O PEAT sinalizará quaisquer sequências que excedam os limites de flash e informará tanto o limite geral de flash quanto o limite de flash vermelho. Uma falha em 2.3.2 é qualquer flash que exceda três por segundo, independentemente de outros limites.
4. Meça as taxas de animação em CSS e JavaScript: Abra as DevTools do navegador (Chrome ou Firefox) e use a aba Performance para gravar uma sessão de 5 segundos enquanto as animações são reproduzidas. Inspecione o gráfico de chamas em busca de operações de paint ou layout que se repitam rapidamente. Você também pode abrir o painel Animations nas DevTools do Chrome para ver as animações em execução e suas durações — divida 1000ms pela duração da animação para calcular a frequência em Hz.
5. Teste com NVDA + Firefox, VoiceOver + Safari e JAWS + Chrome: Usuários de leitores de tela não estão isentos de fotossensibilidade. Inicie cada leitor de tela e navegue pela página normalmente. Se qualquer conteúdo que pisca visualmente também for apresentado de forma que cause atualizações rápidas de tela (como uma região ao vivo anunciando cada quadro de um contador), documente isso. O piscar visual continua sendo uma violação mesmo para usuários de leitores de tela, porque eles podem ter alguma visão funcional.
6. Verifique conteúdo de terceiros e incorporado: Role por todos os iframes, posts incorporados de redes sociais, espaços de anúncios e players de vídeo. Reproduza manualmente quaisquer vídeos com reprodução automática desativada e observe se há tremeluzir rápido. Verifique GIFs animados clicando com o botão direito e inspecionando os dados de quadros em um editor de imagens ou na aba Network do navegador para estimar a taxa de quadros.
7. Repita os testes em diferentes dispositivos e navegadores: Algumas animações rodam em velocidades diferentes em dispositivos móveis e desktops devido a diferenças de aceleração de hardware. Teste tanto em um navegador de desktop quanto em um dispositivo móvel (Safari no iOS e Chrome no Android) para confirmar conformidade consistente.

Como Corrigir

Animação CSS Keyframe Piscando Rápido Demais — Incorreto

<!-- Um selo que pisca para chamar atenção, completando 8 ciclos por segundo -->
<style>
  @keyframes flash-badge {
    0%, 49% { background-color: red; }
    50%, 100% { background-color: transparent; }
  }
  .alert-badge {
    animation: flash-badge 0.125s infinite; /* 8 Hz — excede em muito 3 por segundo */
  }
</style>
<span class='alert-badge'>NEW</span>

Animação CSS Keyframe Piscando Rápido Demais — Correto

<!-- Animação desacelerada para completar menos de 3 ciclos por segundo -->
<style>
  @keyframes flash-badge {
    0%, 49% { background-color: red; }
    50%, 100% { background-color: transparent; }
  }
  .alert-badge {
    animation: flash-badge 0.4s infinite; /* ~2.5 Hz — com segurança abaixo do limite de 3 Hz */
  }
</style>
<span class='alert-badge'>NEW</span>
<!-- Melhor ainda: remova totalmente a animação e use um selo estático de alto contraste -->

Alternância de DOM em JavaScript Causando Tremeluzir Rápido — Incorreto

<!-- Script alterna a visibilidade 10 vezes por segundo para simular um efeito estroboscópico -->
<div id='strobe-element' style='width:200px;height:200px;background:white;'></div>
<script>
  setInterval(function() {
    var el = document.getElementById('strobe-element');
    el.style.background = el.style.background === 'white' ? 'black' : 'white';
  }, 100); /* Dispara a cada 100ms = 10 flashes por segundo -- um sério risco de convulsão */
</script>

Alternância de DOM em JavaScript Causando Tremeluzir Rápido — Correto

<!-- Removida totalmente a alternância rápida; transmita a mudança de estado por texto ou ícone em vez disso -->
<div id='status-element' style='width:200px;height:200px;background:#005fcc;'>
  <p style='color:white;padding:1rem;'>System Active</p>
</div>
<!-- Se a animação for realmente necessária, mantenha-a bem abaixo de 3 Hz e prefira transições
     de opacidade/cor em vez de mudanças de luminância de alto contraste -->

GIF Animado com Alta Taxa de Quadros — Incorreto

<!-- Um anúncio em GIF animado que cicla pelos quadros a 10 fps -->
<img src='promo-flash.gif' alt='Special offer — 50% off this weekend only'>
<!-- O atraso interno de quadros do GIF é definido para 10ms por quadro, criando tremeluzir rápido -->

GIF Animado com Alta Taxa de Quadros — Correto

<!-- Substitua o GIF animado por uma imagem estática ou reexporte o GIF
     com atraso mínimo de 334ms por quadro (3 fps ou mais lento) -->
<img src='promo-static.png' alt='Special offer — 50% off this weekend only'>
<!-- Se o movimento precisar ser preservado, use uma animação CSS com suporte a prefers-reduced-motion -->
<picture>
  <source srcset='promo-static.png' media='(prefers-reduced-motion: reduce)'>
  <img src='promo-slow.gif' alt='Special offer — 50% off this weekend only'>
</picture>

Erros Comuns

• Pressupor que a exceção de "área pequena" de 2.3.1 se aplica a 2.3.2: WCAG 2.3.1 permite conteúdo piscante que ocupa menos de 25% de um campo visual de 10 graus. WCAG 2.3.2 não tem essa exceção — um pequeno cursor piscante ou um ponto de carregamento pequeno que pisca mais de três vezes por segundo é uma violação completa em nível AAA.
• Definir animation-duration em CSS com valores como 0.1s ou 0.2s sem calcular a taxa de flash resultante: Uma animação de 0.1s que oscila entre dois estados completa 10 ciclos por segundo (10 Hz). Divida 1 pela duração em segundos para obter Hz; garanta que o resultado seja 3 ou menos.
• Incorporar scripts de anúncios de terceiros sem revisar o comportamento das animações: Redes de anúncios frequentemente veiculam criativos animados com altas taxas de flash otimizadas para cliques, não para acessibilidade. Sempre audite conteúdo de terceiros usando PEAT ou inspeção manual de quadros antes de implantar.
• Usar loops de setInterval ou requestAnimationFrame para alternar classes CSS rapidamente em indicadores de carregamento ou progresso: Qualquer loop em JavaScript que altere a luminância ou visibilidade de um elemento mais de três vezes por segundo cria uma violação de 2.3.2, mesmo que o efeito pareça sutil em condições normais de visualização.
• Não testar SVGs animados e elementos Canvas: Animações SVG usando <animate> ou SMIL, e jogos ou visualizações de dados baseados em Canvas, raramente são testados com PEAT ou ferramentas de taxa de quadros, mas são totalmente capazes de exceder o limite de flash.
• Confiar apenas em axe-core ou Lighthouse para confirmar conformidade com 2.3.2: Ferramentas automatizadas não conseguem detectar este critério. Um resultado limpo em uma varredura automatizada não significa nada para 2.3.2; apenas revisão manual e análise com PEAT podem confirmar conformidade.
• Tratar prefers-reduced-motion como uma solução completa para 2.3.2: Respeitar a media query prefers-reduced-motion é uma boa prática e ajuda muitas pessoas, mas é um mecanismo de adesão por parte do usuário. WCAG 2.3.2 exige que o conteúdo seja seguro por padrão, não apenas quando a pessoa configurou uma preferência no sistema. Usuários que não configuraram essa opção continuam em risco.
• Aplicar limites de taxa de flash apenas a vídeo, mas não a animações em CSS, JavaScript ou GIF: Equipes às vezes auditam conteúdo em vídeo com PEAT, mas ignoram animações CSS com keyframes e alternâncias acionadas por JavaScript. Todas as tecnologias de animação devem ser avaliadas.
• Usar propriedades CSS background-image para exibir GIFs animados: GIFs animados definidos como imagens de fundo em CSS são menos visíveis para pessoas que testam visualmente e são fáceis de ignorar durante auditorias. Sempre inclua imagens de fundo em seu inventário de animações.
• Deixar de testar novamente após testes A/B ou mudanças de personalização que injetam novo conteúdo animado: Sistemas de marketing e personalização podem injetar dinamicamente banners ou sobreposições com animações que nunca foram revisadas quanto à conformidade com WCAG 2.3.2. Estabeleça uma etapa de revisão para qualquer conteúdo injetado dinamicamente.

Relação com os Regulamentos de Acessibilidade da Turquia

A Circular Presidencial 2025/10 da Turquia, publicada no Diário Oficial nº 32933 em 21 de junho de 2025, estabelece padrões obrigatórios de acessibilidade web e móvel para uma ampla gama de entidades que operam na Turquia. A circular adota o WCAG 2.2 como sua referência técnica, com conformidade obrigatória geralmente exigida nos níveis A e AA.

WCAG 2.3.2 é um critério de Nível AAA e, portanto, não é legalmente obrigatório sob a circular para a maioria das entidades abrangidas. No entanto, seu tema — a prevenção de conteúdo que pode desencadear convulsões — se relaciona diretamente com o dever geral de cuidado e os princípios de não discriminação que sustentam a regulamentação. Os seguintes tipos de entidades são abrangidos pela circular e devem tratar 2.3.2 como uma forte obrigação de melhor prática, mesmo quando não for estritamente exigido: plataformas de e-commerce, instituições públicas e órgãos governamentais, bancos e instituições financeiras, hospitais e prestadores de serviços de saúde, empresas de telecomunicações com 200.000 ou mais assinantes, agências de viagens, empresas de transporte privado e escolas privadas autorizadas pelo Ministério da Educação Nacional (MoNE).

Para instituições públicas e prestadores de serviços de saúde em particular, as implicações éticas de 2.3.2 são especialmente altas. Um portal de saúde governamental ou uma página de informações para pacientes de um hospital que desencadeie uma convulsão em uma pessoa visitante fotossensível representaria tanto uma falha de segurança quanto uma crise de reputação. Embora a circular não exija explicitamente conformidade com o nível AAA, organizações que buscam demonstrar acessibilidade de ponta — seja para elegibilidade em licitações, confiança pública ou parcerias de negócios internacionais — devem implementar 2.3.2 juntamente com suas obrigações obrigatórias de níveis A e AA.

Organizações que fornecem serviços ao mercado da União Europeia também devem observar que o European Accessibility Act (EAA), que entrou em aplicação em junho de 2025, faz referência à EN 301 549, que por sua vez faz referência ao WCAG. Empresas turcas que exportam produtos ou serviços digitais para estados-membros da UE podem enfrentar requisitos mais rigorosos por esse canal. Implementar 2.3.2 de forma proativa posiciona bem as organizações turcas tanto para conformidade doméstica quanto transfronteiriça.

Do ponto de vista prático de implementação, o SDK do widget de overlay Accsible pode ajudar organizações abrangidas fornecendo às pessoas usuárias a opção de pausar ou interromper todas as animações em uma página, o que ajuda a reduzir o risco de fotossensibilidade para quem tem consciência de sua condição. No entanto, esse controle acionado pelo usuário é uma medida suplementar, não um substituto para remover ou desacelerar o conteúdo piscante na origem, como 2.3.2 exige.