WCAG 2.5.1: Gestos de Ponteiro

O Que Esta Regra Significa

WCAG 2.5.1 Pointer Gestures exige que qualquer funcionalidade em uma página da web que dependa de gestos multiponto (gestos que usam dois ou mais pontos de toque simultâneos, como o movimento de pinça com dois dedos para ampliar ou um deslizar com três dedos) ou gestos baseados em trajeto (gestos em que o trajeto percorrido pelo ponteiro é importante, como um swipe, um arrastar ao longo de uma rota específica ou um formato desenhado) também seja operável usando um único ponteiro de uma forma que não exija um gesto baseado em trajeto. Um único ponteiro é qualquer entrada que opere em um único ponto — isso inclui um toque com um único dedo, um clique de mouse, um toque com caneta e entradas semelhantes.

Em termos práticos, se o seu carrossel avança os slides quando o usuário desliza horizontalmente sobre ele, você também deve fornecer botões de avançar e voltar que possam ser ativados com um único toque ou clique. Se o seu widget de mapa personalizado responde a uma pinça com dois dedos para ampliar ou reduzir, você também deve fornecer controles de zoom in e zoom out que exijam apenas um único toque. O critério não proíbe gestos multiponto ou baseados em trajeto — ele simplesmente exige que sempre exista uma alternativa equivalente com um único ponteiro.

A exceção oficial do WCAG afirma: a exigência não se aplica quando o gesto multiponto ou baseado em trajeto é essencial. Um gesto essencial é aquele cuja remoção mudaria fundamentalmente a informação ou a funcionalidade, e texto ou outra alternativa não conseguem atingir o mesmo propósito. Um widget de assinatura à mão livre ou um aplicativo de desenho em que o próprio trajeto desenhado é o resultado se qualificariam como essenciais. No entanto, a grande maioria das interações de navegação, carrossel, mapa e slider não se qualifica para essa exceção, porque podem ser reproduzidas com alternativas simples de toque/clique sem qualquer perda de informação.

Este critério se aplica a toda entrada por ponteiro: telas sensíveis ao toque, mouse, caneta, ponteiros por rastreamento ocular e qualquer outro dispositivo apontador. É um requisito de Nível A sob o WCAG 2.2, o que significa que é considerado um requisito básico de acessibilidade que deve ser atendido para a conformidade mínima.

Uma implementação aprovada fornece pelo menos um mecanismo para realizar cada função dependente de gestos usando uma ativação de ponto único, não baseada em trajeto — tipicamente um botão visível, link ou outro controle focável. Uma implementação reprovada depende exclusivamente de um gesto de swipe, pinça, afastar dedos, girar ou desenhar um trajeto para executar uma função, sem que seja fornecida uma alternativa equivalente de único ponteiro.

Por Que Isso Importa

Deficiências motoras afetam uma parcela significativa da população global. Condições como doença de Parkinson, tremor essencial, paralisia cerebral, hemiplegia relacionada a AVC, diferenças de membros e lesões por esforço repetitivo podem tornar difícil ou impossível para usuários executarem gestos multiponto ou baseados em trajeto com precisão de forma confiável. De acordo com a Organização Mundial da Saúde, aproximadamente 1,3 bilhão de pessoas em todo o mundo vivem com algum tipo de deficiência significativa, e deficiências motoras e de mobilidade estão entre as categorias mais comuns. Quando interfaces web dependem exclusivamente de gestos complexos, esses usuários ficam totalmente excluídos de funcionalidades que usuários videntes e sem deficiência consideram garantidas.

Considere um cenário concreto do mundo real: uma pessoa com tremor essencial está navegando em um site de e-commerce turco em um tablet. A galeria de imagens do produto usa apenas um gesto de swipe para mover entre as fotos. A pessoa não consegue executar de forma confiável um swipe horizontal limpo — seu tremor causa toques acidentais, movimentos diagonais ou toques acidentais com vários dedos. Sem botões de anterior/próximo, ela não consegue ver fotos adicionais do produto e pode abandonar a compra completamente. Adicionar dois simples botões de seta custa à equipe de desenvolvimento alguns minutos, mas remove uma barreira completa para essa pessoa.

Além das deficiências motoras, esse critério também beneficia pessoas com próteses de membros superiores ou dispositivos de acesso por único interruptor que emulam um único ponteiro, pessoas que operam dispositivos montados em cadeiras de rodas em que rotação ou multitoque é mecanicamente impraticável, e pessoas idosas que consideram gestos de toque complexos pouco intuitivos ou difíceis de aprender. Pessoas que operam um dispositivo com mouse ou caneta não sensível ao toque também são diretamente afetadas — esses métodos de entrada são inerentemente de único ponteiro e não conseguem executar gestos multiponto.

Do ponto de vista de usabilidade e negócios, fornecer controles explícitos de único ponteiro (botões, links) também melhora a capacidade de descoberta para todos os usuários, reduz a carga cognitiva e pode contribuir positivamente para taxas de conclusão de tarefas e métricas de conversão. Mecanismos de busca também podem analisar e seguir a navegação baseada em botões de forma mais confiável do que interações baseadas em gestos, oferecendo benefícios secundários de SEO para padrões de navegação rastreáveis.

Regras Relacionadas do Axe-core

WCAG 2.5.1 exige testes manuais porque ferramentas automatizadas não conseguem detectar de forma confiável se um comportamento dependente de gestos possui uma alternativa de único ponteiro. Nenhuma regra automatizada do axe-core mapeia diretamente para esse critério. As razões pelas quais a detecção automatizada é insuficiente são:

• Teste manual necessário — detecção de gestos: Scanners automatizados analisam a estrutura estática do DOM e estilos computados. Eles não conseguem observar o comportamento de listeners de eventos JavaScript em tempo de execução de uma forma que distinga se um handler de touchstart/touchmove/touchend implementa um swipe dependente de trajeto ou apenas um toque. Um scanner vê que eventos de toque estão presentes, mas não consegue determinar se a funcionalidade resultante também está disponível por meio de uma alternativa de único ponteiro. Isso exige que uma pessoa testadora interaja com a interface usando métodos baseados em gestos e de único ponteiro e compare a funcionalidade disponível.
• Teste manual necessário — verificação de equivalência: Mesmo que uma ferramenta pudesse sinalizar que existe um listener de gesto multiponto, ela não consegue avaliar se um botão ou link fornecido alcança resultados funcionalmente equivalentes. Verificar a equivalência — se a alternativa aciona o mesmo resultado, se é visível e alcançável, e se não está escondida atrás de uma etapa adicional — exige julgamento humano informado pela intenção do critério.
• Teste manual necessário — exceção de gesto essencial: Determinar se um gesto se qualifica para a exceção de "essencial" exige compreensão contextual do propósito da aplicação que nenhuma regra automatizada consegue avaliar de forma confiável.

As pessoas testadoras devem usar as ferramentas de desenvolvedor do navegador para inspecionar listeners de eventos anexados (no Chrome DevTools, clique com o botão direito em um elemento, selecione "Inspect" e depois veja a aba "Event Listeners") como ponto de partida para identificar quais elementos possuem handlers de eventos de toque ou ponteiro e, em seguida, verificar manualmente a presença e a equivalência de alternativas de único ponteiro.

Como Testar

1. Execute uma varredura automatizada como linha de base: Use axe DevTools, Lighthouse ou a auditoria integrada do widget Accsible para analisar a página. Embora nenhuma regra mapeie diretamente para 2.5.1, os resultados da varredura podem sinalizar problemas relacionados (como falta de controles focáveis) que fornecem contexto para a revisão manual. Observe quaisquer elementos interativos sinalizados por falta de suporte a teclado ou ponteiro.
2. Identifique funcionalidades dependentes de gestos: Explore manualmente a página em um dispositivo de toque (ou usando emulação de dispositivo do navegador no Chrome DevTools — ative a barra de ferramentas de dispositivo e interaja usando toque simulado). Procure por carrosséis, sliders, mapas, acordeões, galerias de imagens, painéis roláveis, interfaces de arrastar e soltar, ferramentas de desenho e qualquer outro componente que responda a gestos de toque. Documente cada função que você descobrir que é acionada por um swipe, pinça, rotação ou outro gesto baseado em trajeto ou multiponto.
3. Tente equivalentes de único ponteiro: Para cada função dependente de gestos identificada, tente realizar a mesma função usando apenas toques únicos (ou cliques de mouse em um desktop). Verifique se existem controles visíveis como botões, setas ou links que acionem o mesmo resultado. Tente operar esses controles usando um mouse, um teclado (Tab para focar, Enter/Barra de espaço para ativar) e um leitor de tela.
4. Verificação com leitor de tela (NVDA + Firefox): Abra o NVDA e o Firefox. Navegue pelos componentes interativos usando Tab e teclas de seta. Verifique se os controles de único ponteiro (botões, links) para funções baseadas em gestos são anunciados pelo leitor de tela, são alcançáveis via teclado e produzem o resultado esperado quando ativados.
5. Verificação com leitor de tela (VoiceOver + Safari no iOS): Ative o VoiceOver em um iPhone ou iPad. Deslize para a direita com um dedo para navegar pelos elementos. Verifique se todos os controles que fornecem alternativas de único ponteiro para gestos são alcançáveis e ativáveis por meio do gesto de toque do VoiceOver e se produzem o resultado correto.
6. Verificação com leitor de tela (JAWS + Chrome): Use o JAWS com o Chrome no Windows. Use Tab para percorrer os componentes interativos e verifique se os controles alternativos aos gestos são focáveis, devidamente rotulados e funcionais.
7. Avalie a exceção essencial: Para qualquer função dependente de gestos que não tenha uma alternativa de único ponteiro, determine se o gesto é realmente essencial para o conteúdo ou funcionalidade. Se você não conseguir justificar a exceção, registre isso como uma falha. Documente suas descobertas com capturas de tela e etapas para reprodução.

Como Corrigir

Carrossel de Imagens com Navegação Apenas por Swipe — Incorreto

<!-- Carousel that only listens for touch swipe events, no button controls -->
<div id='carousel' class='carousel'>
  <div class='slides'>
    <img src='product-1.jpg' alt='Product view 1'>
    <img src='product-2.jpg' alt='Product view 2'>
    <img src='product-3.jpg' alt='Product view 3'>
  </div>
</div>
<!-- JavaScript only adds touchstart/touchend swipe detection -->
<script>
  // Only gesture-based: no keyboard or click alternative
  carousel.addEventListener('touchstart', handleSwipeStart);
  carousel.addEventListener('touchend', handleSwipeEnd);
</script>

Carrossel de Imagens com Navegação Apenas por Swipe — Correto

<!-- Carousel with both swipe gesture support AND visible single-pointer button controls -->
<div id='carousel' class='carousel' role='region' aria-label='Product images'>
  <button id='prev-btn' aria-label='Previous image' onclick='prevSlide()'>
    &lsaquo; Previous
  </button>
  <div class='slides'>
    <img src='product-1.jpg' alt='Product view 1'>
    <img src='product-2.jpg' alt='Product view 2'>
    <img src='product-3.jpg' alt='Product view 3'>
  </div>
  <button id='next-btn' aria-label='Next image' onclick='nextSlide()'>
    Next &rsaquo;
  </button>
</div>
<!-- Swipe is retained as an enhancement; buttons provide the single-pointer alternative -->
<script>
  carousel.addEventListener('touchstart', handleSwipeStart);
  carousel.addEventListener('touchend', handleSwipeEnd);
  function prevSlide() { /* move to previous slide */ }
  function nextSlide() { /* move to next slide */ }
</script>

Mapa com Apenas Pinça para Zoom — Incorreto

<!-- Map widget that only responds to two-finger pinch gestures for zoom -->
<div id='map' class='map-widget'></div>
<script>
  // Only multipoint pinch gesture is wired up; no zoom buttons provided
  map.addEventListener('touchstart', detectPinch);
  map.addEventListener('touchmove', handlePinchZoom);
</script>

Mapa com Apenas Pinça para Zoom — Correto

<!-- Map widget with pinch-to-zoom PLUS visible zoom controls for single-pointer access -->
<div class='map-container' role='application' aria-label='Interactive map'>
  <div id='map' class='map-widget'></div>
  <div class='map-controls'>
    <!-- Single-pointer alternatives for zoom in and out -->
    <button type='button' aria-label='Zoom in' onclick='mapZoomIn()'>+</button>
    <button type='button' aria-label='Zoom out' onclick='mapZoomOut()'>&minus;</button>
  </div>
</div>
<script>
  map.addEventListener('touchstart', detectPinch);
  map.addEventListener('touchmove', handlePinchZoom);
  function mapZoomIn() { /* increase zoom level by one step */ }
  function mapZoomOut() { /* decrease zoom level by one step */ }
</script>

Slider de Faixa com Gesto Apenas de Arrastar no Trajeto — Incorreto

<!-- Custom price range slider that only works by dragging a thumb along a track -->
<div class='price-slider' id='priceSlider'>
  <div class='track'>
    <div class='thumb' id='sliderThumb'></div>
  </div>
</div>
<!-- No keyboard support, no input field, no increment/decrement buttons -->

Slider de Faixa com Gesto Apenas de Arrastar no Trajeto — Correto

<!-- Use the native <input type='range'> which provides built-in keyboard and single-pointer support -->
<label for='priceRange'>Maximum price: <span id='priceValue'>500</span> TL</label>
<input
  type='range'
  id='priceRange'
  name='priceRange'
  min='0'
  max='1000'
  value='500'
  step='10'
  aria-valuemin='0'
  aria-valuemax='1000'
  aria-valuenow='500'
  aria-label='Maximum price in Turkish lira'
  oninput='document.getElementById("priceValue").textContent = this.value'
>
<!-- Native range input supports click, tap, keyboard arrow keys, and touch drag --
     covering all single-pointer and path-based interaction needs natively -->

Erros Comuns

• Fornecer carrosséis apenas com swipe, sem quaisquer botões de controle anterior/próximo: Muitas bibliotecas de carrossel são fornecidas apenas com suporte a gestos; desenvolvedores devem configurar e renderizar explicitamente botões de navegação para fornecer uma alternativa de único ponteiro.
• Ocultar botões de navegação em dispositivos de toque via media queries de CSS: Um padrão comum oculta botões de seta em telas que se presume serem dispositivos de toque (por exemplo, @media (pointer: coarse)), removendo a alternativa de único ponteiro para pessoas com deficiência motora que dependem dela mesmo em telas sensíveis ao toque.
• Confiar exclusivamente em um gesto de pinça com dois dedos para zoom em mapas sem oferecer botões de zoom: Embeds de mapas de terceiros (implementações personalizadas) frequentemente omitem controles de zoom, deixando a pinça como o único mecanismo de zoom.
• Usar padrões de swipe-para-excluir ou swipe-para-revelar sem botão de ação alternativo: Itens de lista em aplicativos web que revelam opções de exclusão ou ação apenas por meio de um swipe horizontal não possuem mecanismo equivalente baseado em toque para pessoas que não conseguem deslizar de forma confiável.
• Interfaces personalizadas de arrastar e soltar que não possuem alternativa de reordenação por teclado ou clique: Interações de arrastar são, por natureza, baseadas em trajeto; deixar de fornecer um mecanismo alternativo (como botões de subir/descer ou um modelo de recortar e colar) viola esse critério.
• Widgets de desenho ou assinatura que presumem que o próprio trajeto desenhado não é o resultado: Desenvolvedores às vezes invocam equivocadamente a exceção de "essencial" para widgets que na verdade são apenas controles de interface (por exemplo, um padrão de gesto para desbloquear e revelar conteúdo) em vez de ferramentas genuínas de entrada à mão livre.
• Colocar controles alternativos de único ponteiro fora da área visível do viewport ou em estado recolhido por padrão: Se os botões equivalentes existem no DOM, mas estão visualmente ocultos ou exigem uma interação extra para serem revelados, eles não satisfazem plenamente o requisito de uma alternativa de único ponteiro perceptível e operável.
• Implementar bibliotecas de gestos que interceptam eventos de ponteiro e impedem o comportamento padrão: Bibliotecas que chamam event.preventDefault() em eventos de toque podem, inadvertidamente, bloquear as próprias interações de único ponteiro e rolagem do navegador, criando falhas não intencionais além do próprio critério de gestos.
• Presumir que adicionar aria-label a uma zona apenas de gestos é suficiente: Rotular uma área de swipe não fornece uma alternativa de único ponteiro — isso apenas a descreve para usuários de leitor de tela que ainda não conseguem operá-la sem suporte a gestos.
• Não testar em dispositivos reais ou com simulação de toque: Desenvolvedores que testam apenas em desktop com mouse podem nunca descobrir que um recurso é operado exclusivamente por gestos no mobile, porque o fallback de clique de mouse funciona no desktop, mas o caminho de código apenas para toque não possui equivalente de clique.

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 obrigações obrigatórias de acessibilidade web e móvel para uma ampla gama de entidades públicas e privadas que operam na Turquia. A circular adota o WCAG 2.2 como seu padrão técnico normativo, tornando todos os critérios de sucesso de Nível A — incluindo WCAG 2.5.1 Pointer Gestures — requisitos legais obrigatórios de base.

O cronograma de conformidade sob a circular é escalonado: instituições e órgãos públicos são obrigados a alcançar conformidade dentro de um ano da entrada em vigor da circular, enquanto entidades do setor privado abrangidas pela regulamentação têm um prazo de dois anos para atingir conformidade total. O não cumprimento expõe as entidades abrangidas a escrutínio regulatório e ações de fiscalização pelas autoridades supervisoras competentes.

As entidades abrangidas pela circular incluem uma ampla seção transversal de provedores turcos de serviços digitais. Instituições públicas em todos os níveis de governo e seus órgãos afiliados estão incluídos. No setor privado, a circular se aplica a plataformas e marketplaces de e-commerce, bancos e instituições financeiras, hospitais privados e prestadores de serviços de saúde, empresas de telecomunicações com 200,000 ou mais assinantes, agências de viagens, empresas privadas de transporte de passageiros e escolas privadas que operam sob autorização do Ministério da Educação Nacional (MoNE).

Para essas organizações, o WCAG 2.5.1 tem implicações diretas e práticas. Sites de e-commerce turcos frequentemente usam galerias de imagens de produtos baseadas em gestos, navegação por categorias baseada em swipe e visualizadores de produtos com pinch-to-zoom — todos os quais agora devem ter alternativas de único ponteiro. Aplicações bancárias e financeiras que usam padrões de autenticação baseados em gestos ou interfaces de transação baseadas em arrastar devem ser auditadas e corrigidas. Portais de saúde com localizadores de clínicas baseados em mapa usando pinch-zoom devem fornecer botões de zoom. Portais de autoatendimento de telecomunicações com seletores de planos baseados em swipe devem adicionar controles baseados em toque.

As organizações que operam na Turquia são fortemente aconselhadas a incluir o WCAG 2.5.1 em suas listas de verificação de auditoria de acessibilidade imediatamente, já que os padrões de interação por gestos afetados por esse critério são onipresentes no design web responsivo moderno e no desenvolvimento mobile-first — mas são frequentemente negligenciados porque parecem funcionar corretamente para a maioria das pessoas usuárias. Abordar esse critério de forma proativa como parte de um programa de conformidade com o WCAG 2.2 Nível A é tanto uma obrigação legal sob a Circular Presidencial 2025/10 quanto uma melhoria significativa na inclusão digital para pessoas usuárias turcas com deficiências motoras.