WCAG 2.2.4: Interrupções

O Que Esta Regra Significa

WCAG 2.2.4: Interrupções é um critério de sucesso de Nível AAA sob a Diretriz 2.2 (Tempo Suficiente). Ele afirma: "As interrupções podem ser adiadas ou suprimidas pelo usuário, exceto interrupções que envolvam uma emergência." Em termos práticos, isso significa que qualquer conteúdo, alerta, notificação, diálogo ou atualização que apareça sem ser diretamente iniciado pelo usuário deve oferecer a esse usuário um mecanismo para adiar ou desativar a interrupção — a menos que a interrupção comunique uma emergência real, como um alarme de incêndio, um alerta médico com risco de vida ou uma falha crítica de sistema.

Uma interrupção, no sentido das WCAG, é qualquer evento que ocorre independentemente da ação atual do usuário e desvia a atenção do que o usuário está fazendo. Isso inclui, mas não se limita a: notificações tipo “toast”, alertas push, widgets de chat que se abrem automaticamente, banners de status que são atualizados ou mudam, mídia com reprodução automática, anúncios de regiões dinâmicas (live regions) injetados por JavaScript, diálogos modais disparados por um temporizador e banners de consentimento de cookies que aparecem no meio da sessão. O critério não proíbe esses padrões por completo; ele exige que os usuários tenham controle sobre eles.

Uma página atende ao 2.2.4 quando toda interrupção que não seja de emergência possui pelo menos um dos seguintes: uma configuração acessível ao usuário que desabilite a interrupção antes que ela ocorra, um mecanismo dentro da própria interrupção para dispensá-la ou adiá-la, ou uma preferência global em nível de site que suprima totalmente tais interrupções. Uma página não atende quando interrupções aparecem automaticamente, não oferecem mecanismo de dispensa ou adiamento e não se relacionam a uma emergência. Por exemplo, uma bolha de chat ao vivo que se expande automaticamente após 10 segundos sem botão de fechar, ou um banner de notificação que alterna mensagens de marketing e não pode ser interrompido, ambos seriam falhas.

A única exceção explicitamente definida são as emergências. Se o conteúdo precisar interromper o usuário para comunicar perigo à saúde, segurança ou vida — por exemplo, um portal hospitalar que envia um alerta crítico de medicação — essa interrupção pode prevalecer sobre as preferências do usuário. Essa exceção é intencionalmente restrita; mensagens rotineiras de marketing, avisos de expiração de sessão com tempo de sobra e atualizações de status de baixa prioridade não se qualificam como emergências.

Como a WCAG 2.2.4 é de Nível AAA, ela não é exigida para declarações de conformidade de base, mas é um padrão significativo para organizações comprometidas com inclusão plena. Ela se aplica a todo conteúdo web: aplicações web para desktop e mobile, aplicações de página única que usam notificações acionadas por JavaScript e progressive web apps que utilizam a API de Notificações da Web.

Por Que Isso Importa

Interrupções inesperadas em uma página web não são apenas irritantes — para muitos usuários, representam uma barreira séria para concluir tarefas e, em alguns casos, um risco direto à saúde.

Usuários com deficiências cognitivas e relacionadas à atenção — incluindo TDAH, lesão cerebral traumática, condições do espectro autista e demência — dependem fortemente de um ambiente estável e previsível para manter o foco. Uma notificação repentina ou um alerta animado pode quebrar completamente a concentração, fazendo com que percam o fio de um processo de múltiplas etapas, como concluir um pedido de benefícios, revisar um prontuário médico ou preencher uma declaração de imposto. Reorientar-se após uma interrupção pode levar significativamente mais tempo para esses usuários do que para usuários neurotípicos e, em alguns casos, eles podem não conseguir recuperar seu lugar.

Usuários de leitores de tela são particularmente afetados por interrupções dinâmicas. Quando uma live region ou um alerta ARIA é injetado no DOM, leitores de tela como NVDA, JAWS e VoiceOver são projetados para anunciá-lo imediatamente, interrompendo o que a tecnologia assistiva estava lendo naquele momento. Se um usuário estiver ouvindo um parágrafo longo de instruções importantes e um toast de marketing for disparado no meio da frase, o leitor de tela abandona o parágrafo e anuncia a notificação. O usuário então precisa voltar, encontrar seu lugar e reler — um processo muito mais oneroso do que parece para alguém que navega apenas por teclado e áudio.

Usuários com transtornos de ansiedade e TEPT podem experimentar respostas físicas de estresse — aumento da frequência cardíaca, perda de foco ou pânico — desencadeadas por mudanças visuais ou auditivas súbitas e inesperadas. A imprevisibilidade de um ambiente de interrupções sem controle pode tornar alguns sites praticamente inutilizáveis para essas populações.

Usuários com epilepsia ou distúrbios vestibulares podem ser prejudicados por certos tipos de interrupções, especialmente aquelas que envolvem flashes ou movimento rápido. Embora a Diretriz 2.3 trate especificamente dos riscos de convulsão, banners de notificação animados e notificações em vídeo com reprodução automática que aparecem inesperadamente se cruzam com ambos os critérios.

Considere um cenário concreto: uma pessoa com TDAH está usando um portal de banco online para transferir dinheiro entre contas. Ela está revisando cuidadosamente o valor da transferência e o número da conta de destino. Uma notificação de oferta promocional desliza a partir do canto inferior direito, acionando um anúncio do leitor de tela e uma animação de entrada. A pessoa perde seu lugar, não consegue encontrar o botão de dispensar porque a animação desviou o foco e envia o valor errado por engano. Isso não é um caso hipotético extremo — é um resultado previsível de ignorar esse critério.

Além da deficiência, interrupções sem controle também prejudicam a usabilidade para todos os usuários, aumentam as taxas de rejeição (os usuários simplesmente abandonam sites que os bombardeiam) e podem reduzir a conversão nas próprias ações que as interrupções pretendiam promover. Do ponto de vista de SEO, altas taxas de rejeição e baixas durações de sessão estão correlacionadas com sinais de ranqueamento de busca piores, o que significa que acessibilidade e desempenho de negócios estão alinhados aqui.

Regras Relacionadas do Axe-core

WCAG 2.2.4 exige testes manuais. Ferramentas automatizadas, incluindo axe-core, não conseguem detectar de forma confiável se um site produz interrupções incontroláveis, porque isso exigiria que a ferramenta: observasse todo o conteúdo dinâmico injetado durante uma sessão de usuário, avaliasse se cada injeção foi iniciada pelo usuário, verificasse se existe um mecanismo de dispensa ou adiamento e se ele é acessível, e determinasse se o conteúdo se qualifica como uma emergência. Esses são julgamentos contextuais e comportamentais que estão fora do escopo da análise estática do DOM.

• Teste manual obrigatório — Controle de interrupções: Testadores devem interagir manualmente com a página por um período de tempo para observar se algum conteúdo, notificação, diálogo ou mídia é iniciado sem ação do usuário. Para cada interrupção observada, o testador deve verificar se existe um mecanismo acessível para adiá-la ou suprimi-la, se esse mecanismo é acessível por teclado e anunciado pelo leitor de tela e se a interrupção não volta a ocorrer após ser dispensada sem que o usuário a reative.
• Teste manual obrigatório — Avaliação de live regions: Páginas que usam aria-live, role='alert' ou role='status' devem ser revisadas manualmente para determinar se os anúncios são acionados por ações do usuário (aceitável) ou por eventos baseados em tempo ou push do servidor (potencialmente não conformes). Uma ferramenta automatizada pode sinalizar a presença de live regions, mas não pode determinar se elas produzem interrupções inesperadas durante uma sessão real de usuário.
• Teste manual obrigatório — Uso da Notification API: Aplicações web que solicitam permissão para enviar notificações push em nível de navegador devem oferecer um mecanismo claro para que o usuário gerencie ou suprima essas notificações dentro da própria aplicação web, não apenas confiando nos controles em nível de navegador. Isso exige inspeção manual do fluxo de permissão de notificação e da disponibilidade de preferências de notificação dentro do app.

Como Testar

1. Execute uma varredura automatizada como linha de base. Abra a página no Chrome ou Firefox e execute o axe DevTools ou o Lighthouse. Embora nenhuma das ferramentas tenha uma regra dedicada para 2.2.4, a varredura automatizada sinalizará problemas relacionados: ausência de roles em conteúdo dinâmico, live regions configuradas incorretamente e problemas de gerenciamento de foco em diálogos. Anote quaisquer regiões aria-live ou elementos role='alert' sinalizados, pois eles precisarão de acompanhamento manual.
2. Observe a página passivamente por pelo menos dois a três minutos. Sem clicar em nada, observe e ouça qualquer conteúdo que mude, apareça ou se anuncie. Use um leitor de tela em segundo plano (NVDA com Firefox ou VoiceOver com Safari no macOS) e ouça qualquer anúncio que não tenha sido acionado por sua ação. Anote cada interrupção, seu tempo e seu conteúdo.
3. Teste fluxos interativos que comumente disparam notificações. Faça login na aplicação, se aplicável, navegue até um formulário ou processo de múltiplas etapas e comece a preenchê-lo lentamente. Anote quaisquer interrupções que ocorram: avisos de expiração de sessão, convites de chat, banners promocionais, atualizações de progresso ou prompts de assinatura. Para cada uma, tente dispensar ou adiá-la usando apenas o teclado (Tab, Escape, Enter, Espaço). Verifique se o foco retorna a um local lógico após a dispensa.
4. Teste com NVDA e Firefox. Ative o NVDA, abra o Firefox e navegue pela página. Ouça atentamente qualquer saída de voz que interrompa sua leitura atual. Se uma notificação automática for disparada, tente dispensá-la usando controles de teclado e verifique se o NVDA anuncia a confirmação de dispensa ou se o foco retorna adequadamente.
5. Teste com JAWS e Chrome. Repita os testes de observação passiva e de fluxos interativos usando JAWS com Chrome. JAWS e NVDA tratam live regions de forma diferente, portanto é importante testar ambos para garantir que as interrupções sejam anunciadas de forma consistente e que os mecanismos de dispensa funcionem em ambos os leitores de tela.
6. Teste com VoiceOver e Safari no iOS. Em um dispositivo móvel ou simulador, use o VoiceOver com Safari para navegar pela página. Passe o dedo pelo conteúdo e observe se ocorrem interrupções. Teste o mecanismo de dispensa usando gestos de toque (toque duplo para ativar) e verifique se o foco retorna a um local significativo.
7. Verifique se há uma configuração de preferência de notificação. Procure um perfil de usuário, painel de configurações ou seção de preferências de acessibilidade dentro da aplicação. Verifique se existe um controle para suprimir ou configurar notificações globalmente e teste se ativar essa configuração realmente impede que interrupções ocorram durante uma sessão subsequente.
8. Revise o código-fonte JavaScript ou a atividade de rede. Nas DevTools do navegador, observe as abas Network e Console durante a sessão. Procure conexões WebSocket, intervalos de polling ou chamadas setTimeout/setInterval que injetem conteúdo no DOM. Cada uma delas é uma fonte potencial de interrupções e deve ser rastreada para garantir que o controle do usuário esteja implementado.

Como Corrigir

Widget de chat que abre automaticamente — Incorreto

<!-- Chat widget opens automatically after 10 seconds with no close button -->
<div id='chat-widget' role='dialog' aria-label='Live chat'>
  <p>Hi! Can we help you today?</p>
  <button>Start chat</button>
</div>

<script>
  setTimeout(function() {
    document.getElementById('chat-widget').style.display = 'block';
  }, 10000);
</script>

Widget de chat que abre automaticamente — Correto

<!-- Chat widget includes a dismiss button and respects a user preference -->
<div id='chat-widget' role='dialog' aria-label='Live chat' aria-modal='true'>
  <p>Hi! Can we help you today?</p>
  <button id='chat-start'>Start chat</button>
  <!-- Dismiss button allows user to postpone the interruption -->
  <button id='chat-dismiss' aria-label='Dismiss chat offer'>No thanks</button>
</div>

<script>
  // Check whether the user has previously dismissed the chat offer
  if (!sessionStorage.getItem('chat-dismissed')) {
    setTimeout(function() {
      var widget = document.getElementById('chat-widget');
      widget.removeAttribute('hidden');
      // Move focus into the dialog so screen reader users are aware of it
      document.getElementById('chat-dismiss').focus();
    }, 10000);
  }

  document.getElementById('chat-dismiss').addEventListener('click', function() {
    // Suppress for the remainder of the session
    sessionStorage.setItem('chat-dismissed', 'true');
    var widget = document.getElementById('chat-widget');
    widget.setAttribute('hidden', '');
    // Return focus to the element the user was on before the interruption
    document.getElementById('main-content').focus();
  });
</script>

Notificação de marketing tipo toast incontrolável — Incorreto

<!-- Toast fires every 30 seconds, no way to stop it -->
<div role='alert' id='promo-toast'>
  <p>Use code SAVE20 for 20% off your next order!</p>
</div>

<script>
  setInterval(function() {
    document.getElementById('promo-toast').style.display = 'block';
    setTimeout(function() {
      document.getElementById('promo-toast').style.display = 'none';
    }, 5000);
  }, 30000);
</script>

Notificação de marketing tipo toast incontrolável — Correto

<!-- Toast fires once, includes a dismiss control, and respects a preference -->
<div role='status' id='promo-toast' hidden>
  <p>Use code SAVE20 for 20% off your next order!</p>
  <!-- Dismiss button suppresses future promos in this session -->
  <button id='promo-dismiss' aria-label='Dismiss promotion'>&times;</button>
</div>

<script>
  // Only show once, and only if the user has not opted out
  if (!localStorage.getItem('promos-suppressed')) {
    setTimeout(function() {
      document.getElementById('promo-toast').removeAttribute('hidden');
    }, 30000);
  }

  document.getElementById('promo-dismiss').addEventListener('click', function() {
    // Suppress all future promotional interruptions permanently
    localStorage.setItem('promos-suppressed', 'true');
    document.getElementById('promo-toast').setAttribute('hidden', '');
  });
</script>

Modal de expiração de sessão sem controle do usuário — Incorreto

<!-- Modal fires automatically, traps focus with no postpone option -->
<div id='timeout-modal' role='dialog' aria-label='Session expiring'>
  <p>Your session will expire in 60 seconds.</p>
  <button id='logout-now'>Log out</button>
</div>

Modal de expiração de sessão sem controle do usuário — Correto

<!-- Modal provides both a continue option and a postpone option,
     and announces itself clearly to screen readers -->
<div id='timeout-modal' role='alertdialog'
     aria-labelledby='timeout-heading'
     aria-describedby='timeout-description'
     aria-modal='true'>
  <h2 id='timeout-heading'>Session Expiring Soon</h2>
  <p id='timeout-description'>
    Your session will expire in <span id='countdown'>5 minutes</span>.
    Would you like to continue, or shall we log you out now?
  </p>
  <button id='continue-session'>Continue session</button>
  <button id='logout-now'>Log out now</button>
  <!-- Postpone option gives the user meaningful control -->
  <button id='remind-later'>Remind me in 5 more minutes</button>
</div>

Erros Comuns

• Usar role='alert' em mensagens promocionais ou de baixa prioridade. O role alert sinaliza urgência para leitores de tela e causa interrupção imediata da leitura. Mensagens de marketing, dicas e anúncios de funcionalidades devem usar role='status' ou aria-live='polite', que anunciam o conteúdo apenas depois que o leitor de tela termina sua saída atual.
• Fornecer um botão de fechar que só é visível ao passar o mouse ou ao focar, tornando-o praticamente inacessível. Se o mecanismo de dispensa exigir que o usuário passe o mouse para revelá-lo, usuários apenas de teclado e usuários de leitores de tela não poderão vê-lo ou alcançá-lo. O botão de dispensa deve estar sempre visível ou, no mínimo, sempre alcançável via ordem de tabulação do teclado.
• Retornar o foco para document.body após dispensar uma notificação. Quando uma notificação ou diálogo é dispensado, o foco deve retornar a um elemento significativo e contextualmente apropriado — normalmente o elemento com o qual o usuário estava interagindo antes da interrupção. Jogar o foco em body força usuários de leitores de tela a renavegar toda a página.
• Disparar múltiplas regiões aria-live simultaneamente. Quando várias live regions são atualizadas ao mesmo tempo, leitores de tela enfileiram ou descartam anúncios de forma imprevisível. Cada interrupção deve ser gerenciada cuidadosamente para que apenas uma live region seja disparada por vez, e as atualizações sejam agrupadas sempre que possível.
• Tratar o prompt nativo de permissão de notificação do navegador como controle de usuário suficiente. A caixa de permissão do navegador para a Web Notifications API opera em nível de sistema operacional, não em nível de aplicação. A WCAG 2.2.4 exige que os usuários possam gerenciar notificações dentro da própria aplicação web, não apenas bloqueando o site no nível do navegador.
• Redefinir uma notificação dispensada a cada carregamento de página. Se um usuário dispensar uma notificação e ela reaparecer na próxima vez que ele navegar para a mesma página ou outra página do site, a ação de dispensa foi inútil. As preferências devem persistir pelo menos durante a sessão usando sessionStorage ou permanentemente usando localStorage ou uma preferência no servidor.
• Usar setInterval para alternar banners ou dicas rotativas sem um controle de pausa. Conteúdo rotativo que é atualizado por temporizador é uma interrupção. Se o conteúdo mudar enquanto um usuário de leitor de tela estiver lendo, o anúncio será reiniciado. Esses carrosséis e banners rotativos exigem um controle de reproduzir/pausar e não devem ficar em loop indefinidamente sem consentimento do usuário.
• Injetar uma notificação no DOM em uma posição que cause saltos inesperados de rolagem. Se um banner de notificação for injetado no topo da página e a página se deslocar para baixo, os usuários perdem sua posição de leitura visual. As notificações devem ser injetadas de forma que não afetem o layout do conteúdo que o usuário está visualizando no momento, normalmente usando posicionamento fixo ou absoluto.
• Presumir que um temporizador curto de auto-dispensa satisfaz o critério. Um toast que desaparece após cinco segundos não dá aos usuários controle significativo — muitos usuários não conseguem ler, processar ou responder ao conteúdo tão rapidamente, especialmente aqueles com deficiências cognitivas ou que usam leitores de tela. Fornecer apenas um temporizador de auto-dispensa sem um botão de dispensa controlado pelo usuário não está em conformidade.
• Deixar de testar o comportamento de interrupções quando o sistema operacional ou o navegador do usuário tem preferências de movimento reduzido ou de notificações ativadas. Alguns usuários definem preferências em nível de sistema operacional para movimento reduzido ou supressão de notificações. Esses sinais devem ser respeitados pela aplicação, e desenvolvedores devem testar com a media query prefers-reduced-motion: reduce ativa para garantir que interrupções animadas sejam suprimidas adequadamente.

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 um quadro vinculativo de acessibilidade web para uma ampla gama de organizações que operam na Turquia. A circular adota a WCAG 2.2 como seu padrão técnico de referência e exige conformidade para as entidades abrangidas. Os tipos de entidades explicitamente cobertos pela circular incluem instituições e órgãos públicos, plataformas de e-commerce, bancos e prestadores de serviços financeiros, hospitais e organizações de serviços de saúde, empresas de telecomunicações com 200.000 ou mais assinantes, agências de viagens licenciadas, empresas de transporte privado e escolas privadas que operam sob autorização do Ministério da Educação Nacional (MoNE).

WCAG 2.2.4: Interrupções é um critério de Nível AAA, o que significa que não está entre os requisitos de conformidade de base sob a Circular Presidencial 2025/10 para a maioria das entidades abrangidas. Organizações que alcançam e declaram conformidade de Nível A e Nível AA são consideradas legalmente em conformidade com os requisitos mínimos da circular. No entanto, critérios de Nível AAA como o 2.2.4 têm peso prático e reputacional significativo no contexto do mercado turco.

Vários dos tipos de entidades abrangidas — especialmente hospitais, bancos e instituições públicas — atendem populações de usuários com taxas elevadas de condições cognitivas e neurológicas, transtornos de ansiedade e dificuldades de atenção relacionadas ao envelhecimento. Para essas organizações, interrupções sem controle em interfaces digitais representam não apenas uma falha de acessibilidade, mas um risco potencial de segurança do paciente ou de dano financeiro. Um portal de pacientes de hospital que dispara lembretes de medicação ou notificações de consulta incontroláveis durante um fluxo crítico de preenchimento de formulário, ou uma aplicação bancária que exibe banners promocionais que não podem ser suprimidos durante a revisão de uma transação, cria danos concretos para usuários desses grupos.

Para organizações na Turquia que buscam demonstrar liderança em acessibilidade digital — especialmente aquelas que perseguem declarações voluntárias de WCAG 2.2 Nível AAA, respondem a requisitos de acessibilidade em compras públicas ou miram mercados europeus onde o European Accessibility Act (EAA) estabelece um padrão mais elevado — implementar o 2.2.4 é um diferencial significativo. O SDK de overlay Accsible apoia as organizações no atendimento a esses padrões mais altos, fornecendo recursos configuráveis de gerenciamento de notificações, persistência de preferências do usuário e comportamentos de widgets conscientes de acessibilidade que se alinham tanto às expectativas regulatórias turcas quanto às melhores práticas internacionais.