WCAG 2.5.4: Ativação por Movimento

O Que Esta Regra Significa

WCAG 2.5.4 — Acionamento por Movimento aborda um cenário específico, porém cada vez mais comum, em aplicações web modernas: funcionalidades acionadas por movimento físico do dispositivo, como sacudir um smartphone, inclinar um dispositivo ou fazer gestos em frente a uma câmera. O critério estabelece dois requisitos paralelos que devem ambos ser atendidos para haver conformidade.

Primeiro, qualquer funcionalidade que possa ser operada por movimento do dispositivo ou movimento do usuário também deve ser operável por meio de um componente da interface do usuário — ou seja, um botão, link, controle de formulário ou elemento interativo similar que não dependa de movimento. Isso garante que pessoas que não podem realizar ou não conseguem realizar de forma confiável gestos de movimento físico não sejam excluídas completamente do acesso a essa funcionalidade.

Segundo, os usuários devem poder desativar a resposta ao movimento para que movimentos acidentais ou involuntários não acionem ações indesejadas. Isso protege usuários que têm tremores ou outras condições motoras que causam movimento involuntário do dispositivo de serem constantemente interrompidos por comportamentos inesperados da aplicação.

O critério se aplica a dois tipos distintos de movimento: movimento do dispositivo, que é detectado por sensores como acelerômetros e giroscópios embutidos em smartphones e tablets (acessados por meio de APIs como DeviceMotionEvent e DeviceOrientationEvent), e movimento do usuário, que é detectado por câmeras ou outros sensores de entrada que rastreiam movimento corporal ou gestos em vez do próprio dispositivo.

Uma implementação em conformidade fornece toda a funcionalidade acionada por movimento por meio de um controle de interface padrão (um botão, link ou equivalente) E permite que o usuário desative a detecção de movimento se assim desejar. Uma implementação não conforme ou fornece acesso a um recurso apenas por movimento, sem controle alternativo na interface, ou fornece uma alternativa, mas não oferece forma de desativar o acionamento por movimento, de modo que o movimento involuntário continue causando problemas.

WCAG 2.5.4 define duas exceções importantes. O acionamento por movimento é isento se o movimento for essencial para a função e desativá-lo alteraria fundamentalmente a atividade — por exemplo, um aplicativo de condicionamento físico que conta passos, em que o rastreamento de movimento é o propósito central, ou um jogo explicitamente projetado em torno de mecânicas de inclinação. A segunda exceção se aplica quando o movimento é usado para operar funcionalidades por meio de uma interface de acessibilidade compatível, ou seja, quando os próprios recursos de acessibilidade da plataforma lidam com a interação por movimento de uma forma que o usuário controla de maneira independente.

Por Que Isso Importa

Barreiras de acionamento por movimento afetam desproporcionalmente pessoas com deficiências motoras e de mobilidade, mas o impacto é mais amplo do que muitos desenvolvedores inicialmente supõem. Entender quem é afetado — e como — ajuda as equipes a priorizar esse critério de forma adequada.

Pessoas com condições que causam tremores — incluindo tremor essencial, doença de Parkinson e esclerose múltipla — podem experimentar movimento involuntário constante ou intermitente das mãos e braços. Quando seguram um smartphone, o tremor natural é suficiente para acionar repetida e inesperadamente diálogos de “sacudir para desfazer”, ações de atualização ou outros recursos ativados por movimento. A Organização Mundial da Saúde estima que aproximadamente 1,3 bilhão de pessoas no mundo vivem com algum tipo de deficiência significativa, e condições que afetam o controle motor fino estão entre as mais prevalentes em todos os grupos etários.

Pessoas com paralisia ou diferenças de membros podem usar seus dispositivos montados em cadeiras de rodas ou suportes, ou podem usar ponteiros de cabeça, rastreamento ocular ou controles por varredura para interagir com seus dispositivos. Esses usuários muitas vezes não conseguem sacudir ou inclinar um dispositivo, tornando recursos exclusivamente baseados em movimento completamente inacessíveis. Se a única forma de desfazer uma entrada de texto em uma aplicação web móvel é sacudir o dispositivo, uma pessoa usuária de cadeira de rodas com o telefone montado simplesmente não consegue acessar esse recurso.

Idosos são outro grupo significativamente afetado. Condições relacionadas à idade, incluindo redução da força de preensão, artrite e tremor essencial, tornam-se cada vez mais comuns com o avanço da idade, o que significa que um segmento crescente da população — que também é cada vez mais ativo digitalmente — pode ter dificuldades com gestos de movimento precisos ou intencionais.

Considere um cenário concreto do mundo real: um site de e-commerce turco adiciona um recurso de “sacudir para embaralhar” que mostra ao usuário uma recomendação de produto aleatória quando ele sacode o telefone, tornando a navegação mais envolvente. O recurso é divertido e inovador, mas não há um botão equivalente para acionar o embaralhamento, e não há como desativar a detecção de sacudidas. Uma pessoa com doença de Parkinson que visita esse site experimenta ativações de embaralhamento constantes e incontroláveis, à medida que seu tremor natural aciona o gesto. Ela não consegue navegar com calma porque a página continua pulando para produtos aleatórios. Essa pessoa está, na prática, impedida de ter uma experiência normal de compra — e, segundo os regulamentos de acessibilidade da Turquia, isso não é apenas um problema de UX, mas uma falha de conformidade legal.

Além do acesso para pessoas com deficiência, desativar ou fornecer alternativas a recursos baseados em movimento também melhora a experiência para usuários em ambientes em que o movimento do dispositivo é pouco confiável — em transporte público, em escritórios ou em qualquer contexto em que o usuário não possa mover o dispositivo livremente.

Regras Relacionadas do Axe-core

WCAG 2.5.4 exige testes manuais porque ferramentas automatizadas não conseguem detectar de forma confiável a presença ou ausência de funcionalidades baseadas em movimento apenas analisando HTML e CSS estáticos. O acionamento por movimento depende de listeners de eventos JavaScript e de comportamento em tempo de execução que scanners automatizados não conseguem inspecionar completamente. A seguir, é explicado por que a automação é insuficiente e o que a avaliação manual deve cobrir.

• Não existe regra automatizada direta do axe-core para 2.5.4. Axe-core e mecanismos automatizados similares funcionam inspecionando o DOM, atributos ARIA e estilos computados. Eles não conseguem observar se uma página registrou um listener de evento devicemotion ou deviceorientation, nem determinar se existe um controle de interface equivalente para qualquer funcionalidade acionada por movimento. Uma página pode ter ampla interatividade baseada em movimento sem nenhum indicador visível no DOM, tornando a detecção automatizada fundamentalmente pouco confiável. O axe-core, portanto, marca esse critério como exigindo revisão manual, em vez de tentar uma detecção automatizada que produziria altas taxas de falso negativo.
• É necessária inspeção manual de listeners de eventos JavaScript. Testadores devem usar as ferramentas de desenvolvedor do navegador para procurar registros de DeviceMotionEvent, DeviceOrientationEvent e APIs de câmera/visão, como a Shape Detection API. O painel de Event Listeners nas DevTools do navegador pode revelar se esses eventos estão anexados ao objeto window ou document.
• A equivalência funcional não pode ser automatizada. Mesmo que uma ferramenta pudesse detectar um listener de movimento, ela não conseguiria determinar se um botão ou link em outra parte da interface fornece a mesma funcionalidade. Avaliar a equivalência funcional exige um testador humano que entenda os recursos da aplicação e possa verificar se cada ação acionada por movimento tem uma alternativa de interface alcançável e operável.
• A possibilidade de desativar não pode ser automatizada. Determinar se o usuário pode desativar respostas ao movimento exige interagir com as configurações ou preferências da aplicação — um teste de comportamento para o qual ferramentas automatizadas não são projetadas de forma abrangente.

Como Testar

1. Varredura automatizada como ponto de partida: Execute axe DevTools, Lighthouse ou o verificador de acessibilidade Accsible na página. Essas ferramentas não sinalizarão violações de 2.5.4 automaticamente, mas podem revelar problemas relacionados. Anote quaisquer itens sinalizados e, em seguida, prossiga para as etapas manuais. A ausência de alertas automatizados não significa que a página esteja em conformidade com 2.5.4.
2. Identifique funcionalidades acionadas por movimento: Abra o Chrome DevTools e navegue até o painel Elements. Pesquise nos arquivos de código-fonte JavaScript da página (usando a aba Sources e a busca global com Ctrl+Shift+F) pelas strings devicemotion, deviceorientation, accelerat, gyro e shake. Documente cada ocorrência encontrada e a funcionalidade associada.
3. Verifique se existem alternativas na interface: Para cada funcionalidade acionada por movimento descoberta na etapa anterior, tente realizar a mesma ação usando apenas navegação por teclado e cliques de mouse — sem movimento do dispositivo. Navegue pela interface usando Tab, Enter, Espaço e teclas de seta. Se você não conseguir encontrar um controle operável na interface que produza o mesmo resultado, o critério falha.
4. Verifique se o movimento pode ser desativado: Procure um menu de configurações, painel de preferências, configurações de acessibilidade ou um toggle específico para recursos de movimento. Tente desativar o acionamento por movimento. Se não existir tal controle, ou se desativar o movimento também desativar a alternativa na interface, o critério falha.
5. Teste em dispositivo físico: Carregue a página em um smartphone ou tablet real. Movimente deliberadamente o dispositivo de forma suave (simulando tremor involuntário — movimentos pequenos e contínuos) e observe se funcionalidades são acionadas de forma não intencional. Em seguida, tente o mesmo teste após desativar o movimento por meio de quaisquer configurações disponíveis.
6. Teste com leitor de tela e teclado: Usando NVDA com Firefox, VoiceOver com Safari no iOS ou JAWS com Chrome, navegue pela página usando apenas o teclado e comandos do leitor de tela. Confirme que toda funcionalidade acessível por movimento também é acessível pela navegação do leitor de tela e que o controle de desativação de movimento (se existir) é acessível pelo teclado e está devidamente rotulado.
7. Simulação de dispositivo nas DevTools do navegador: No Chrome DevTools, abra o painel Sensors (More Tools > Sensors) e use os controles de simulação de orientação do dispositivo e acelerômetro para acionar eventos de movimento programaticamente. Isso permite testar comportamentos acionados por movimento em desktop sem um dispositivo físico.

Como Corrigir

Sacudir para Atualizar sem Alternativa — Incorreto

<!-- Motion listener attached, but no UI button provided to refresh -->
<script>
  window.addEventListener('devicemotion', function(event) {
    var acceleration = event.accelerationIncludingGravity;
    if (Math.abs(acceleration.x) > 15 || Math.abs(acceleration.y) > 15) {
      refreshContent();
    }
  });
</script>
<div id='content'>...page content...</div>

Sacudir para Atualizar sem Alternativa — Correto

<!-- Motion alternative: a visible button provides the same refresh action.
     A settings toggle lets users disable the motion trigger entirely. -->
<div id='motion-controls'>
  <button type='button' id='refresh-btn' onclick='refreshContent()'>
    Refresh Content
  </button>
  <label>
    <input type='checkbox' id='disable-motion' onchange='toggleMotion(this.checked)' />
    Disable shake-to-refresh
  </label>
</div>
<div id='content'>...page content...</div>
<script>
  var motionEnabled = true;
  function toggleMotion(disabled) {
    motionEnabled = !disabled;
  }
  window.addEventListener('devicemotion', function(event) {
    if (!motionEnabled) return;
    var acceleration = event.accelerationIncludingGravity;
    if (Math.abs(acceleration.x) > 15 || Math.abs(acceleration.y) > 15) {
      refreshContent();
    }
  });
  function refreshContent() {
    // fetch and update content
  }
</script>

Carrossel que Inclina para Rolar sem Opção de Desativar — Incorreto

<!-- Carousel advances on device tilt; no way to turn this off -->
<div id='carousel'>
  <div class='slide'>Slide 1</div>
  <div class='slide'>Slide 2</div>
  <div class='slide'>Slide 3</div>
</div>
<script>
  window.addEventListener('deviceorientation', function(event) {
    if (event.gamma > 30) advanceCarousel();
    if (event.gamma < -30) retreatCarousel();
  });
</script>

Carrossel que Inclina para Rolar sem Opção de Desativar — Correto

<!-- Previous/Next buttons provide UI alternatives.
     A settings checkbox lets users opt out of tilt control.
     The carousel is also keyboard accessible via arrow keys. -->
<div id='carousel-wrapper'>
  <button type='button' aria-label='Previous slide' onclick='retreatCarousel()'>&laquo;</button>
  <div id='carousel' role='region' aria-label='Image carousel' aria-live='polite'>
    <div class='slide' aria-hidden='false'>Slide 1</div>
    <div class='slide' aria-hidden='true'>Slide 2</div>
    <div class='slide' aria-hidden='true'>Slide 3</div>
  </div>
  <button type='button' aria-label='Next slide' onclick='advanceCarousel()'>&raquo;</button>
</div>
<label>
  <input type='checkbox' id='disable-tilt' onchange='tiltEnabled = !this.checked' />
  Disable tilt navigation
</label>
<script>
  var tiltEnabled = true;
  window.addEventListener('deviceorientation', function(event) {
    if (!tiltEnabled) return;
    if (event.gamma > 30) advanceCarousel();
    if (event.gamma < -30) retreatCarousel();
  });
</script>

Recurso de Gesto por Câmera sem Alternativa — Incorreto

<!-- User waves hand in front of camera to dismiss a modal;
     no button or keyboard method exists to dismiss it otherwise -->
<div id='modal' role='dialog' aria-modal='true' aria-label='Notification'>
  <p>Wave your hand to dismiss this message.</p>
</div>
<script>
  startCameraGestureDetection(function onWave() {
    document.getElementById('modal').hidden = true;
  });
</script>

Recurso de Gesto por Câmera sem Alternativa — Correto

<!-- A clearly labeled close button provides the UI alternative.
     The modal is fully keyboard operable and focus is managed correctly. -->
<div id='modal' role='dialog' aria-modal='true' aria-labelledby='modal-title'>
  <h2 id='modal-title'>Notification</h2>
  <p>Wave your hand or press the button below to dismiss this message.</p>
  <button type='button' id='dismiss-btn' onclick='dismissModal()'>Dismiss</button>
</div>
<script>
  function dismissModal() {
    document.getElementById('modal').hidden = true;
    // return focus to triggering element
  }
  startCameraGestureDetection(dismissModal);
  // Allow Escape key to also dismiss
  document.addEventListener('keydown', function(e) {
    if (e.key === 'Escape') dismissModal();
  });
</script>

Erros Comuns

• Fornecer um botão alternativo na interface, mas esquecer o toggle para desativar o movimento: Muitos desenvolvedores adicionam um botão equivalente, mas nunca implementam uma forma de desativar o listener de movimento, deixando usuários com tremores ainda sujeitos a ativações indesejadas, mesmo que o recurso seja tecnicamente operável por outros meios.
• Esconder a opção de desativar o movimento dentro de um menu hambúrguer ou em uma página de configurações muito profunda: O controle para desativar o movimento deve ser, ele próprio, facilmente alcançável. Se uma pessoa com tremor aciona “sacudir para atualizar” repetidamente antes de conseguir navegar por cinco níveis de menu para desativá-lo, a opção de desativar não é praticamente acessível.
• Presumir que a preferência de “reduzir movimento” no sistema operacional satisfaz 2.5.4: A media query prefers-reduced-motion e as configurações de acessibilidade do sistema operacional tratam de animações e preocupações vestibulares, mas não desativam automaticamente listeners de eventos de movimento do dispositivo em aplicações web. Você deve tratar isso no seu próprio código.
• Definir limiares de movimento muito baixos: Usar limiares muito sensíveis para valores de aceleração de DeviceMotionEvent significa que tremores involuntários leves podem ultrapassar o limiar. Os limiares devem exigir movimento deliberado e de alta magnitude e, mesmo assim, uma opção de desativar continua sendo obrigatória.
• Registrar listeners de movimento globalmente em window sem nunca removê-los: Anexar um listener e nunca fornecer um caminho de código para removê-lo com removeEventListener significa que o toggle de desativação só pode suprimir o comportamento condicionalmente — se o próprio toggle falhar ou for redefinido ao recarregar a página, o movimento permanece ativo.
• Tornar a checkbox de desativar movimento inacessível: Implementar o toggle de desativação como um <div> ou <span> estilizado com um listener de clique, em vez de um <input type='checkbox'> adequado ou um controle aprimorado com ARIA, significa que usuários de teclado e leitores de tela não conseguem alcançar ou operar o próprio controle que deveria ajudá-los.
• Não persistir as preferências de movimento do usuário entre sessões: Se um usuário desativa o acionamento por movimento, mas a preferência não é salva (por exemplo, via localStorage ou configuração na conta do usuário), ele precisa desativá-lo novamente a cada visita, criando um ônus repetido justamente para as pessoas mais afetadas.
• Aplicar a exceção de função essencial de forma muito ampla: A exceção de “essencial” é restrita. Uma galeria de produtos que usa “sacudir para embaralhar” não é essencial — o recurso de embaralhar não é a função central de um site de compras. Equipes às vezes aplicam essa exceção de forma indevida para evitar trabalho de implementação.
• Não testar em um dispositivo físico real com movimento real: Confiar apenas em ferramentas de simulação em desktop ou varreduras automatizadas significa que problemas de sensibilidade ao movimento no mundo real — incluindo como o recurso se comporta quando o usuário tem um tremor natural — nunca são descobertos até que usuários os relatem.
• Esquecer que recursos de movimento adicionados por SDKs de terceiros ou bibliotecas de analytics também devem estar em conformidade: Listeners de movimento incorporados em widgets de chat de terceiros, SDKs de gamificação ou ferramentas de testes A/B ainda fazem parte da responsabilidade de conformidade da página. Se um script de terceiros registra um listener devicemotion sem fornecer uma alternativa, a página falha em 2.5.4.

Relação com os Regulamentos de Acessibilidade da Turquia

O Decreto Presidencial nº 2025/10 da Turquia, publicado no Diário Oficial (nº 32933) em 21 de junho de 2025, estabelece requisitos obrigatórios de acessibilidade na web alinhados com WCAG 2.2. WCAG 2.5.4 Acionamento por Movimento é um critério de Nível A, o que significa que está no nível mais alto de prioridade de conformidade obrigatória sob esse decreto.

O decreto abrange uma ampla gama de entidades dos setores público e privado. Instituições públicas — incluindo todos os órgãos governamentais centrais e locais, ministérios e agências públicas — devem alcançar conformidade total de Nível A em até um ano após a publicação do decreto. Entidades do setor privado nas categorias abrangidas devem alcançar o mesmo padrão em até dois anos. As categorias do setor privado abrangidas incluem plataformas e marketplaces de e-commerce, bancos e instituições financeiras, hospitais e prestadores de serviços de saúde privados, 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).

O acionamento por movimento é particularmente relevante para serviços digitais turcos porque o uso de internet móvel na Turquia é muito alto, com a maioria do tráfego web vindo de smartphones. Aplicações web mobile-first e mobile-only são, portanto, extremamente comuns em todos os setores abrangidos. Qualquer site de e-commerce turco, aplicação bancária ou portal governamental que tenha implementado “sacudir para atualizar”, navegação por inclinação, interações baseadas em gestos ou recursos de movimento similares sem fornecer alternativas na interface e controles de desativação está em violação direta de um requisito obrigatório de Nível A sob o Decreto Presidencial 2025/10.

Para entidades abrangidas que estejam preparando roteiros de conformidade, o acionamento por movimento deve ser avaliado como parte de uma auditoria mais ampla de acessibilidade móvel. Como ferramentas automatizadas não conseguem detectar violações de 2.5.4, as organizações devem incluir testes manuais por especialistas em acessibilidade qualificados como parte do processo de verificação de conformidade. Dado que o decreto não inclui um período de carência para recursos implementados antes de sua publicação — apenas um cronograma para alcançar a conformidade — qualquer funcionalidade baseada em movimento atualmente em produção em sites abrangidos deve ser corrigida dentro do prazo aplicável.

Entidades que não cumprirem os requisitos do decreto podem enfrentar sanções administrativas e estão sujeitas à fiscalização pelas autoridades supervisoras relevantes para seu setor. Além do risco regulatório, a não conformidade com 2.5.4 em um site móvel turco de alto tráfego representa uma falha real de usabilidade para milhões de usuários que podem ter deficiências motoras, tremores ou usar tecnologia assistiva — uma população cujas necessidades são explicitamente reconhecidas e protegidas pela adoção, no decreto, de WCAG 2.2 Nível A como padrão básico.