WCAG 2.3.1: Três flashes ou abaixo do limiar

O Que Esta Regra Significa

WCAG 2.3.1 — Três Flashes ou Abaixo do Limite — é um critério de sucesso de Nível A sob o princípio Operável. Ele determina que páginas da web não devem conter nenhum conteúdo que pisque mais de três vezes em qualquer período de um segundo, a menos que esse conteúdo intermitente seja pequeno o suficiente ou pouco luminoso o suficiente para ficar abaixo do limite geral de flash ou do limite de flash vermelho definidos.

Um flash é definido como um par de mudanças opostas na luminância relativa que pode causar convulsões em pessoas suscetíveis. Especificamente, as WCAG definem dois tipos de flashes perigosos:

• Flash geral: Um par de mudanças opostas em que a luminância mais alta é de pelo menos 10% da luminância relativa máxima (0,80), e a diferença de luminância é de pelo menos 10% do máximo. Na prática, isso significa conteúdo alternando rapidamente entre um estado claro e um estado escuro o bastante para produzir um efeito estroboscópico.
• Flash vermelho: Um par de transições opostas envolvendo uma cor vermelha saturada. Isso é tratado com atenção especial porque flashes vermelhos foram clinicamente associados a um risco maior de desencadear crises fotossensíveis.

O critério se aplica a todo conteúdo da web, independentemente do formato — animações em HTML, transições em CSS, efeitos acionados por JavaScript, vídeos incorporados, GIFs, animações SVG, cenas WebGL, gráficos renderizados em canvas e widgets de publicidade de terceiros. Se o conteúdo pisca a uma taxa superior a três flashes por segundo e não fica abaixo dos limites de luminância ou de tamanho, ele falha nesse critério incondicionalmente.

Exceções e limites que permitem a aprovação do conteúdo: WCAG 2.3.1 permite conteúdo intermitente se ele atender a uma das seguintes condições:

• A área combinada de flashes ocorrendo simultaneamente não cobre mais do que um total de 0,006 esterradianos dentro de qualquer campo visual de 10 graus na tela (aproximadamente um retângulo de 341 × 256 pixels em distâncias típicas de visualização, ou cerca de 21.824 pixels quadrados em uma tela com 1024 pixels de largura vista à distância de um braço).
• O flash está abaixo do limite geral de flash (a mudança de luminância é inferior a 10%) ou abaixo do limite de flash vermelho (o componente vermelho saturado não muda mais do que o limite definido).

Um evento de flash único com contraste de luminância muito baixo ou uma área de tela muito pequena pode, portanto, ser permissível. No entanto, como esses limites são sutis e exigem ferramentas de medição fotométrica para verificação precisa, a maioria dos profissionais adota a abordagem conservadora de simplesmente evitar qualquer conteúdo que pisque mais de três vezes por segundo. Conteúdo que pisca exatamente três vezes por segundo (3 Hz) está no limite — conteúdo acima de 3 Hz é não conforme, independentemente do tamanho, a menos que os limites de tamanho ou luminância sejam definitivamente atendidos.

O critério rege qualquer conteúdo que seja renderizado durante a interação normal com a página. Ele não isenta conteúdo oculto atrás de controles acionados pelo usuário se esse conteúdo for reproduzido automaticamente no carregamento da página. Se um vídeo começar a ser reproduzido automaticamente e contiver sequências intermitentes que excedam o limite, a página falha nesse critério desde o momento em que é carregada.

Por Que Isso Importa

A epilepsia fotossensível afeta aproximadamente 1 em cada 4.000 pessoas globalmente — cerca de 3% da população geral com epilepsia. No entanto, a sensibilidade à luz que pisca ou cintila rapidamente é mais ampla do que a epilepsia clínica. Muitas pessoas com enxaqueca, disfunção vestibular, condições do espectro autista e síndrome pós-concussão podem experimentar desconforto significativo, desorientação, náusea ou dor com estímulos visuais que piscam rapidamente, mesmo que não tenham um diagnóstico de distúrbio convulsivo.

As consequências são singularmente graves para este critério em comparação com a maioria dos outros requisitos de acessibilidade. Uma pessoa que encontra texto alternativo ausente experimenta exclusão e frustração. Uma pessoa que encontra conteúdo que desencadeia uma crise fotossensível pode enfrentar uma emergência médica — incluindo perda de consciência, ferimentos por queda e, em casos raros mas documentados, desfechos com risco de vida. O Harding Flash and Pattern Analyzer, uma ferramenta de transmissão amplamente utilizada, foi desenvolvido especificamente para prevenir tais eventos na televisão, e a web apresenta riscos análogos.

Um cenário concreto do mundo real ilustra bem o perigo: considere um site de notícias que reproduz automaticamente um vídeo promocional contendo uma sequência rápida de quadros alternados claros e escuros — um artefato comum de certos tipos de compressão de vídeo ou efeitos de flash de câmera. Uma pessoa com epilepsia fotossensível visita a página inicial durante o trajeto matinal em um dispositivo móvel. Sem qualquer aviso e sem qualquer oportunidade de desativar o conteúdo, ela é exposta a uma sequência que desencadeia uma crise enquanto está usando o transporte público. Esse cenário não é hipotético; ele já ocorreu em contextos reais, incluindo o infame incidente do episódio de Pokémon de 2007 que desencadeou crises em centenas de espectadores no Japão, e casos documentados envolvendo unidades de publicidade baseadas na web.

Além da dimensão de segurança, a conformidade com esse critério também tem implicações de usabilidade para o público em geral. Conteúdo que pisca rapidamente cria uma experiência de leitura ruim, aumenta a carga cognitiva e é considerado disruptivo e pouco profissional na maioria dos contextos de design. Eliminar esse tipo de conteúdo melhora o foco, reduz as taxas de rejeição e sinaliza confiabilidade — tudo isso contribui positivamente para métricas de SEO como tempo de permanência e taxas de engajamento. Além disso, rastreadores de mecanismos de busca consideram cada vez mais o Core Web Vitals e sinais de experiência do usuário nos rankings, e sites com anúncios ou animações intermitentes invasivas podem ser penalizados indiretamente.

Regras Relacionadas do Axe-core

WCAG 2.3.1 exige testes manuais porque ferramentas automatizadas não conseguem analisar de forma confiável as propriedades fotométricas de conteúdo dinâmico em tempo real. Nenhuma regra automatizada do axe-core mapeia diretamente para esse critério. As razões para essa limitação são fundamentais para o modo como a automação em acessibilidade funciona:

• Por que a automação falha aqui: Varredores automatizados analisam o DOM e o CSS estáticos em um ponto no tempo. Eles podem detectar que existe uma animação ou um elemento de vídeo, mas não conseguem medir a frequência real de flash, os valores de luminância em cada quadro ou a área espacial da região intermitente conforme percebida por uma pessoa a uma distância típica de visualização. Determinar se um flash excede o limite de 3 Hz ou o limite de área de 0,006 esterradianos exige análise fotométrica quadro a quadro — uma tarefa que requer ferramentas dedicadas como o Harding Flash and Pattern Analyzer (HFPA), o Photosensitive Epilepsy Analysis Tool (PEAT) ou revisão manual dos arquivos-fonte da animação.
• Vídeo incorporado e conteúdo de terceiros: Grande parte do conteúdo de maior risco (anúncios em vídeo com reprodução automática, widgets de redes sociais incorporados, bibliotecas de animação de terceiros) é carregada de domínios externos. Ferramentas automatizadas normalmente não conseguem acessar ou analisar conteúdo de origem cruzada em nível de quadro, tornando impossível avaliar programaticamente a frequência de flash nesses recursos.
• Animações GIF e canvas: Arquivos GIF animados e elementos canvas em HTML5 renderizam seus quadros de animação fora da árvore normal de acessibilidade. Axe-core e Lighthouse não têm capacidade de decodificar o tempo entre quadros de GIF ou interceptar chamadas de desenho em canvas para calcular mudanças de luminância entre quadros.
• Animações em CSS e JavaScript: Embora o axe-core consiga detectar a presença de propriedades de animation ou transition em CSS, ele não consegue avaliar se a saída visual resultante em tempo de execução produz mudanças de luminância que excedem os limites de flash geral ou vermelho.

Como nenhuma regra automatizada detecta essa violação, todo o ônus da conformidade recai sobre a revisão manual de design, a análise de vídeo antes da publicação e a conscientização de desenvolvedores durante a fase de criação de conteúdo. Isso torna os controles de processo editorial e de QA — não apenas a correção técnica — essenciais para uma conformidade sustentável.

Como Testar

1. Inventariar todo o conteúdo dinâmico: Antes de qualquer teste baseado em ferramentas, audite a página em busca de todo conteúdo que se move, pisca, cintila ou anima. Isso inclui vídeos com reprodução automática, GIFs animados, animações com keyframes em CSS, animações acionadas por JavaScript, animações SVG, elementos canvas e widgets de terceiros incorporados, como unidades de publicidade ou embeds de redes sociais. Documente cada instância com sua origem e mecanismo de controle.
2. Usar o Photosensitive Epilepsy Analysis Tool (PEAT): PEAT é uma ferramenta gratuita desenvolvida pelo Trace Research and Development Center, projetada especificamente para analisar conteúdo de vídeo quanto a riscos de flash conforme a especificação Harding. Grave uma captura de tela da página da web ou animação em questão em resolução total e, em seguida, importe o arquivo de vídeo para o PEAT. A ferramenta informará se alguma sequência excede o limite geral de flash ou o limite de flash vermelho e em quais timestamps.
3. Aplicar o Harding Flash and Pattern Analyzer para conteúdo em qualidade de transmissão: Para conteúdo de vídeo que será incorporado a partir de fluxos de produção (por exemplo, sites de emissoras, organizações de notícias), execute os arquivos de vídeo-fonte no HFPA antes da publicação. Esta é a ferramenta padrão-ouro para triagem pré-publicação.
4. Observação manual — a contagem de três flashes: Para animações em CSS, efeitos em JavaScript ou arquivos GIF em que a análise baseada em ferramentas é impraticável, reproduza a animação e tente contar o número de ciclos completos claro-escuro-claro dentro de um único segundo. Se você observar três ou mais ciclos completos por segundo, o conteúdo provavelmente não está em conformidade. Use software de gravação de tela com reprodução quadro a quadro para auxiliar nessa contagem.
5. Verificar conteúdo de vídeo quadro a quadro: Abra arquivos de vídeo em um editor de vídeo (como o DaVinci Resolve, versão gratuita) que exiba dados de waveform ou histograma em nível de quadro. Percorra seções de mudança visual rápida e verifique padrões alternados de luminância alta-baixa ocorrendo mais de três vezes por segundo. Observe especialmente sequências envolvendo vermelho saturado sobre fundos escuros.
6. Testar com ferramentas de desenvolvedor do navegador para animações em CSS: No Chrome DevTools, abra o painel Animations (More Tools → Animations). Inspecione as durações de animação declaradas e ciclos de iteração. Uma animação com duração inferior a 333 milissegundos que alterna entre estados de alto contraste em cada iteração excederá o limite de 3 Hz. Calcule: se um ciclo completo claro-escuro-claro se completa em menos de 333 ms, o conteúdo não está em conformidade.
7. Avaliar a área espacial em casos limítrofes: Se o conteúdo pisca a uma taxa acima de 3 Hz, mas parece muito pequeno na tela, meça suas dimensões em pixels. Em uma tela com 1024 pixels de largura em distância normal de visualização (aproximadamente 57–60 cm), o limite de área segura é de cerca de 21.824 pixels quadrados. Multiplique a largura e a altura da região intermitente; se o resultado estiver abaixo desse limite, o conteúdo pode se enquadrar na exceção de área segura — mas documente essa avaliação cuidadosamente.
8. Testar vídeo com reprodução automática no carregamento da página: Desative qualquer interação com a página após o carregamento e observe se algum vídeo ou animação começa a ser reproduzido automaticamente. Se isso acontecer, aplique imediatamente os testes acima ao conteúdo com reprodução automática, já que a pessoa usuária não tem oportunidade de intervir antes da exposição.

Como Corrigir

GIF com reprodução automática e flash rápido — Incorreto

<!-- An animated GIF that cycles between a bright yellow and black frame
     at approximately 10 times per second, far exceeding the 3 Hz threshold -->
<img src='attention-flash.gif' alt='Special offer alert' width='600' height='300'>

GIF com reprodução automática e flash rápido — Correto

<!-- Replace the flashing GIF with a static image and use a subtle CSS
     animation that does not alter luminance rapidly. The animation here
     uses a gentle scale pulse at a rate well below 3 Hz (one cycle per 2 seconds). -->
<img src='attention-static.png'
     alt='Special offer alert'
     class='pulse-attention'
     width='600'
     height='300'>

<style>
  @keyframes gentlePulse {
    0%, 100% { transform: scale(1); }
    50% { transform: scale(1.03); }
  }
  .pulse-attention {
    animation: gentlePulse 2s ease-in-out infinite;
  }
</style>

Animação de keyframes em CSS piscando entre cores de alto contraste — Incorreto

<!-- A CSS animation that alternates a banner between white and black
     with a 100ms total duration, producing 10 flashes per second -->
<div class='flash-banner'>SALE NOW ON</div>

<style>
  @keyframes flashEffect {
    0% { background-color: #ffffff; color: #000000; }
    50% { background-color: #000000; color: #ffffff; }
    100% { background-color: #ffffff; color: #000000; }
  }
  .flash-banner {
    animation: flashEffect 0.1s linear infinite;
  }
</style>

Animação de keyframes em CSS piscando entre cores de alto contraste — Correto

<!-- Slowing the animation duration to 1 second per full cycle means
     the luminance alternates once per second (1 Hz), well below the 3 Hz limit.
     Alternatively, use prefers-reduced-motion to disable animation entirely
     for users who have opted into reduced motion at the OS level. -->
<div class='flash-banner'>SALE NOW ON</div>

<style>
  @keyframes flashEffect {
    0% { background-color: #ffffff; color: #000000; }
    50% { background-color: #000000; color: #ffffff; }
    100% { background-color: #ffffff; color: #000000; }
  }
  .flash-banner {
    animation: flashEffect 1s linear infinite;
  }

  @media (prefers-reduced-motion: reduce) {
    .flash-banner {
      animation: none;
      background-color: #1a1a8c;
      color: #ffffff;
    }
  }
</style>

Vídeo incorporado com reprodução automática e sequências de flash — Incorreto

<!-- Auto-playing video with no controls, no PEAT analysis performed,
     and no mechanism for the user to stop or pause before exposure -->
<video src='promo.mp4' autoplay loop muted width='800' height='450'></video>

Vídeo incorporado com reprodução automática e sequências de flash — Correto

<!-- Best practice: provide controls so users can pause immediately,
     add a poster frame so no video plays without interaction,
     or use preload='none' to prevent auto-loading. If autoplay is
     genuinely required by business logic, the video MUST have been
     screened with PEAT or HFPA and confirmed free of flash hazards. -->
<video
  src='promo-screened.mp4'
  controls
  muted
  preload='metadata'
  poster='promo-poster.jpg'
  width='800'
  height='450'>
  <track kind='captions' src='promo-captions.vtt' srclang='tr' label='Türkçe'>
</video>
<p>Bu video flaş analizi aracıyla (PEAT) incelenmiş ve güvenli bulunmuştur.</p>

Erros Comuns

• Presumir que arquivos GIF são seguros por padrão: Muitos desenvolvedores acreditam que, por serem um formato legado, GIFs animados são inerentemente inofensivos. Na realidade, GIFs podem alternar entre quadros em taxas que excedem 3 Hz, e o formato não impõe nenhum limite técnico à taxa de quadros. Todo GIF com quadros alternados de alto contraste deve ter seu tempo e conteúdo avaliados.
• Ignorar scripts de publicidade de terceiros: Redes de publicidade gráfica frequentemente veiculam peças criativas que contêm animações intermitentes ou piscantes. Publicadores que incorporam tags de anúncios sem revisar o conteúdo criativo continuam responsáveis por quaisquer violações da WCAG 2.3.1 que esses anúncios produzam em suas páginas. Implemente políticas de revisão de peças publicitárias e requisitos contratuais com as redes de anúncios.
• Confundir WCAG 2.3.1 com WCAG 2.2.2 (Pausar, Parar, Ocultar): Algumas equipes tratam o sintoma adicionando um botão de pausa (o que satisfaz 2.2.2), mas não tratam a taxa de flash subjacente (que viola 2.3.1). Os dois critérios são independentes: um controle de pausa não torna retroativamente conforme o conteúdo que já começou a piscar em relação a 2.3.1, porque a pessoa usuária é exposta antes de poder interagir.
• Não considerar separadamente o limite de flash vermelho: Desenvolvedores que conhecem o limite geral de 3 Hz às vezes ignoram o limite separado de flash vermelho. Conteúdo envolvendo valores de vermelho saturado alternando rapidamente pode desencadear crises fotossensíveis mesmo em frequências ligeiramente abaixo de 3 Hz em algumas pessoas. Animações com vermelho saturado devem ser revisadas com atenção especial.
• Ignorar conteúdo carregado em iframes: Páginas que incorporam conteúdo de terceiros por meio de elementos <iframe> — incluindo widgets de redes sociais, ferramentas de chat ao vivo ou dashboards incorporados — são responsáveis pela acessibilidade desse conteúdo conforme renderizado em sua página. Riscos de flash dentro de um iframe são tão perigosos quanto aqueles no documento principal.
• Ignorar a implementação da media query prefers-reduced-motion: Mesmo quando as animações básicas estão abaixo do limite de 3 Hz, deixar de implementar @media (prefers-reduced-motion: reduce) significa que pessoas que sinalizaram preferências de redução de movimento no sistema operacional não recebem nenhuma acomodação. Embora isso seja tratado principalmente pela WCAG 2.3.3 em nível AAA, incluir a media query é uma prática de baixo custo e alto impacto que demonstra compromisso com acessibilidade e reduz o risco.
• Usar setInterval ou requestAnimationFrame em JavaScript sem limitar a taxa: Animações acionadas por setInterval(fn, 50) são executadas a cada 50 milissegundos, produzindo 20 ciclos por segundo — muito acima do limite de 3 Hz. Desenvolvedores devem calcular explicitamente a duração do intervalo necessária para permanecer em ou abaixo de uma mudança a cada 333 ms para qualquer animação que altere a luminância.
• Deixar de examinar conteúdo de vídeo antes da publicação: Muitas organizações têm um fluxo de publicação que inclui QA visual e revisão de direitos autorais, mas não inclui uma etapa de triagem de riscos de flash. Sem integrar PEAT ou HFPA ao pipeline de pré-publicação, riscos de fotossensibilidade em conteúdo de vídeo podem passar despercebidos até causarem danos.
• Tratar a exceção de tamanho como algo fácil de explorar: Alguns desenvolvedores tomam conhecimento da exceção de área segura de 0,006 esterradianos e tentam usá-la para justificar a manutenção de efeitos de flash perigosos, apenas reduzindo seu tamanho. Na prática, calcular com precisão se o conteúdo se enquadra no limite exige conhecimento da distância de visualização e da resolução da tela — variáveis que o desenvolvedor não controla. Confiar na exceção de tamanho sem medição fotométrica é arriscado e juridicamente precário.
• Não documentar avaliações de risco de flash: Organizações que testam conteúdo de vídeo ou animação quanto a riscos de flash frequentemente deixam de manter registros dessas avaliações. Em caso de reclamação de usuário ou auditoria regulatória, evidências documentadas de que a triagem com PEAT ou HFPA foi realizada e de que o conteúdo foi considerado conforme são essenciais para demonstrar diligência.

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 requisitos obrigatórios de acessibilidade web e móvel alinhados com a WCAG 2.2. A WCAG 2.3.1, como critério de sucesso de Nível A, está dentro do escopo de conformidade obrigatória para todas as entidades abrangidas.

A circular define um cronograma de conformidade em fases: instituições e órgãos públicos devem alcançar conformidade total de Nível A dentro de um ano a partir da data de vigência da circular, enquanto entidades do setor privado abrangidas pela regulamentação têm dois anos para se adequar. Dada a natureza crítica de segurança da WCAG 2.3.1 — que se relaciona diretamente ao risco de desencadear emergências médicas em pessoas usuárias — a não conformidade com esse critério específico acarreta exposição reputacional e jurídica aumentada, mesmo em relação a outros requisitos de Nível A.

Os seguintes tipos de entidades são explicitamente abrangidos pela Circular Presidencial 2025/10 e, portanto, devem cumprir a WCAG 2.3.1:

• Instituições públicas e órgãos governamentais: Todos os órgãos governamentais centrais e locais, ministérios, municípios e organizações vinculadas ao Estado que operem sites ou aplicativos móveis voltados ao público.
• Plataformas de e-commerce: Operadores de varejo online e marketplaces que fornecem bens ou serviços a consumidores por meio de plataformas digitais, independentemente do setor.
• Bancos e instituições financeiras: Todos os bancos licenciados, bancos de participação, corretoras de investimento e operadores de fintech que fornecem serviços bancários ou financeiros digitais.
• Hospitais e prestadores de serviços de saúde: Hospitais públicos e privados, policlínicas e redes de saúde que oferecem serviços digitais voltados a pacientes, incluindo agendamento de consultas e portais de pacientes.
• Empresas de telecomunicações com 200.000 ou mais assinantes: Principais operadoras de telefonia móvel e provedores de internet que atendam ao limite de assinantes, incluindo seus portais de autoatendimento e aplicativos móveis.
• Agências de viagens: Agências de viagens e turismo licenciadas que oferecem serviços de reserva, agendamento ou informação online.
• Empresas de transporte privado: Companhias aéreas, operadoras de ônibus intermunicipais, operadoras de balsas e outros prestadores de transporte privado com plataformas digitais voltadas a consumidores.
• Escolas privadas autorizadas pelo Ministério da Educação Nacional (MoNE): Instituições de ensino privadas com autorização do MoNE que operam sites ou plataformas digitais de aprendizagem.

Para as entidades abrangidas, a conformidade com a WCAG 2.3.1 exige não apenas uma auditoria pontual, mas um compromisso operacional contínuo. Como os riscos de flash são mais comumente introduzidos por meio de conteúdo dinâmico — uploads de vídeo, animações de marketing, publicidade de terceiros — as organizações devem incorporar a triagem de riscos de flash em seus fluxos de publicação de conteúdo, e não apenas em sua auditoria inicial do site. O uso de ferramentas como o PEAT para triagem de vídeo antes da publicação, combinado com treinamento de desenvolvedores sobre limites seguros de taxa de animação e implementação de prefers-reduced-motion em CSS, representa o padrão mínimo de diligência operacional esperado das entidades abrangidas pela circular. Organizações que dependem de sistemas de gerenciamento de conteúdo ou de publicidade de terceiros também devem garantir cláusulas contratuais que exijam conformidade com a WCAG 2.3.1 por parte de seus fornecedores, já que a obrigação regulatória recai sobre a entidade que opera o serviço digital voltado ao público.