WCAG 2.5.1: Gestos con puntero

Qué Significa Esta Regla

WCAG 2.5.1 Gestos del Puntero requiere que cualquier funcionalidad en una página web que dependa de gestos multipunto (gestos que usan dos o más puntos de contacto simultáneos, como un pellizco con dos dedos para hacer zoom o un deslizamiento con tres dedos) o gestos basados en trazos (gestos en los que la trayectoria recorrida por el puntero importa, como un deslizamiento, un arrastre a lo largo de una ruta específica o una forma dibujada) también sea operable usando un único puntero de una manera que no requiera un gesto basado en trazos. Un único puntero es cualquier entrada que opera en un solo punto: esto incluye un toque con un solo dedo, un clic de ratón, un toque con un lápiz óptico y entradas similares.

En términos prácticos, si tu carrusel avanza las diapositivas cuando la persona usuaria desliza horizontalmente sobre él, también debes proporcionar botones de avance y retroceso que puedan activarse con un solo toque o clic. Si tu widget de mapa personalizado responde a un pellizco con dos dedos para acercar o alejar, también debes proporcionar controles de acercar y alejar que solo requieran un toque. El criterio no prohíbe los gestos multipunto o basados en trazos: simplemente exige que siempre exista una alternativa equivalente de un solo puntero.

La excepción oficial de WCAG establece: el requisito no se aplica cuando el gesto multipunto o basado en trazos es esencial. Un gesto esencial es aquel cuya eliminación cambiaría fundamentalmente la información o la funcionalidad, y el texto u otra alternativa no pueden lograr el mismo propósito. Un widget de firma a mano alzada o una aplicación de dibujo donde la trayectoria dibujada en sí misma es el resultado calificarían como esenciales. Sin embargo, la gran mayoría de las interacciones de navegación, carrusel, mapa y control deslizante no califican para esta excepción, porque pueden replicarse con alternativas simples de toque/clic sin ninguna pérdida de información.

Este criterio se aplica a toda entrada de puntero: pantallas táctiles, ratón, lápiz óptico, punteros de seguimiento ocular y cualquier otro dispositivo apuntador. Es un requisito de Nivel A según WCAG 2.2, lo que significa que se considera un requisito básico de accesibilidad que debe cumplirse para la conformidad mínima.

Una implementación aprobada proporciona al menos un mecanismo para lograr cada función dependiente de gestos usando una activación de un solo punto y no basada en trazos, normalmente un botón visible, un enlace u otro control enfocable. Una implementación fallida depende exclusivamente de un gesto de deslizamiento, pellizco, separación, rotación o trazo dibujado para realizar una función, sin que se proporcione una alternativa equivalente de un solo puntero.

Por Qué Importa

Las discapacidades motoras afectan a una parte significativa de la población mundial. Afecciones como la enfermedad de Parkinson, el temblor esencial, la parálisis cerebral, la hemiplejía relacionada con un accidente cerebrovascular, las diferencias en las extremidades y las lesiones por esfuerzo repetitivo pueden dificultar o imposibilitar que las personas usuarias realicen de forma fiable gestos precisos multipunto o basados en trazos. Según la Organización Mundial de la Salud, aproximadamente 1,3 mil millones de personas en todo el mundo viven con algún tipo de discapacidad significativa, y las discapacidades motoras y de movilidad se encuentran entre las categorías más comunes. Cuando las interfaces web dependen exclusivamente de gestos complejos, estas personas quedan completamente excluidas de funcionalidades que las personas videntes sin discapacidad dan por sentadas.

Considera un escenario concreto del mundo real: una persona usuaria con temblor esencial está navegando por un sitio de comercio electrónico turco en una tableta. La galería de imágenes del producto usa solo un gesto de deslizamiento para moverse entre fotos. La persona no puede ejecutar de forma fiable un deslizamiento horizontal limpio: su temblor provoca toques accidentales, movimientos diagonales o toques accidentales con varios dedos. Sin botones de anterior/siguiente, no puede ver fotos adicionales del producto y puede abandonar la compra por completo. Añadir dos simples botones de flecha le cuesta al equipo de desarrollo unos minutos pero elimina por completo una barrera para esta persona.

Más allá de las discapacidades motoras, este criterio también beneficia a personas usuarias con prótesis de extremidades superiores o dispositivos de acceso de un solo interruptor que emulan un único puntero, personas que operan dispositivos montados en sillas de ruedas donde la rotación o el multitáctil son mecánicamente poco prácticos, y personas mayores que encuentran los gestos táctiles complejos poco intuitivos o difíciles de aprender. Las personas que usan un dispositivo con ratón o un lápiz óptico no táctil también se ven directamente afectadas: estos métodos de entrada son inherentemente de un solo puntero y no pueden realizar gestos multipunto en absoluto.

Desde la perspectiva de la usabilidad y del negocio, proporcionar controles explícitos de un solo puntero (botones, enlaces) también mejora la capacidad de descubrimiento para todas las personas usuarias, reduce la carga cognitiva y puede contribuir positivamente a las tasas de finalización de tareas y a los indicadores de conversión. Los motores de búsqueda también pueden analizar y seguir la navegación basada en botones de forma más fiable que las interacciones basadas en gestos, ofreciendo beneficios secundarios de SEO para patrones de navegación rastreables.

Reglas Relacionadas de Axe-core

WCAG 2.5.1 requiere pruebas manuales porque las herramientas automatizadas no pueden detectar de forma fiable si un comportamiento dependiente de gestos tiene una alternativa de un solo puntero. Ninguna regla automatizada de axe-core se asigna directamente a este criterio. Las razones por las que la detección automatizada es insuficiente son:

• Se requieren pruebas manuales — detección de gestos: Los escáneres automatizados analizan la estructura estática del DOM y los estilos calculados. No pueden observar el comportamiento de los listeners de eventos de JavaScript en tiempo de ejecución de una manera que distinga si un manejador de touchstart/touchmove/touchend implementa un deslizamiento dependiente de la trayectoria o simplemente un toque. Un escáner ve que hay eventos táctiles presentes pero no puede determinar si la funcionalidad resultante también está disponible mediante una alternativa de un solo puntero. Esto requiere que una persona probadora interactúe con la interfaz usando tanto métodos basados en gestos como de un solo puntero y compare la funcionalidad disponible.
• Se requieren pruebas manuales — verificación de equivalencia: Incluso si una herramienta pudiera marcar que existe un listener de gesto multipunto, no puede evaluar si un botón o enlace proporcionado logra resultados funcionalmente equivalentes. Verificar la equivalencia — que la alternativa desencadena el mismo resultado, que es visible y alcanzable, y que no está oculta detrás de un paso adicional — requiere juicio humano informado por la intención del criterio.
• Se requieren pruebas manuales — excepción de gesto esencial: Determinar si un gesto califica para la excepción de “esencial” requiere una comprensión contextual del propósito de la aplicación que ninguna regla automatizada puede evaluar de forma fiable.

Las personas probadoras deben usar las herramientas de desarrollo del navegador para inspeccionar los listeners de eventos adjuntos (en Chrome DevTools, haz clic derecho en un elemento, selecciona “Inspect” y luego ve a la pestaña “Event Listeners”) como punto de partida para identificar qué elementos tienen manejadores de eventos táctiles o de puntero, y luego verificar manualmente la presencia y equivalencia de alternativas de un solo puntero.

Cómo Probar

1. Ejecuta un escaneo automatizado como línea base: Usa axe DevTools, Lighthouse o la auditoría integrada del widget Accsible para escanear la página. Aunque ninguna regla se asigna directamente a 2.5.1, los resultados del escaneo pueden señalar problemas relacionados (como controles enfocables faltantes) que proporcionan contexto para la revisión manual. Toma nota de cualquier elemento interactivo marcado por falta de soporte de teclado o puntero.
2. Identifica la funcionalidad dependiente de gestos: Explora manualmente la página en un dispositivo táctil (o usando la emulación de dispositivo del navegador en Chrome DevTools: activa la barra de herramientas de dispositivo e interactúa usando el tacto simulado). Busca carruseles, controles deslizantes, mapas, acordeones, galerías de imágenes, paneles desplazables, interfaces de arrastrar y soltar, herramientas de dibujo y cualquier otro componente que responda a gestos táctiles. Documenta cada función que descubras que se active mediante un deslizamiento, pellizco, rotación u otro gesto basado en trazos o multipunto.
3. Intenta equivalentes de un solo puntero: Para cada función dependiente de gestos identificada, intenta lograr la misma función usando solo toques simples (o clics de ratón en un escritorio). Comprueba si existen controles visibles como botones, flechas o enlaces que desencadenen el mismo resultado. Intenta operar esos controles usando un ratón, un teclado (Tab para enfocar, Enter/Espacio para activar) y un lector de pantalla.
4. Verificación con lector de pantalla (NVDA + Firefox): Abre NVDA y Firefox. Navega por los componentes interactivos usando las teclas Tab y de flecha. Verifica que los controles de un solo puntero (botones, enlaces) para funciones basadas en gestos sean anunciados por el lector de pantalla, sean alcanzables mediante el teclado y produzcan el resultado esperado cuando se activan.
5. Verificación con lector de pantalla (VoiceOver + Safari en iOS): Activa VoiceOver en un iPhone o iPad. Desliza a la derecha con un dedo para navegar por los elementos. Verifica que todos los controles que proporcionan alternativas de un solo puntero a los gestos sean alcanzables y activables mediante el gesto de toque de VoiceOver, y que produzcan el resultado correcto.
6. Verificación con lector de pantalla (JAWS + Chrome): Usa JAWS con Chrome en Windows. Recorre con Tab los componentes interactivos y verifica que los controles alternativos a los gestos sean enfocables, estén correctamente etiquetados y sean funcionales.
7. Evalúa la excepción de esencialidad: Para cualquier función dependiente de gestos que carezca de una alternativa de un solo puntero, determina si el gesto es realmente esencial para el contenido o la funcionalidad. Si no puedes justificar la excepción, regístralo como un fallo. Documenta tus hallazgos con capturas de pantalla y pasos para reproducir.

Cómo Corregir

Carrusel de Imágenes con Navegación Solo por Deslizamiento — Incorrecto

<!-- 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>

Carrusel de Imágenes con Navegación Solo por Deslizamiento — Correcto

<!-- 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 con Solo Pellizcar para Hacer Zoom — Incorrecto

<!-- 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 con Solo Pellizcar para Hacer Zoom — Correcto

<!-- 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>

Control Deslizante de Rango con Solo Gesto de Arrastre en la Trayectoria — Incorrecto

<!-- 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 -->

Control Deslizante de Rango con Solo Gesto de Arrastre en la Trayectoria — Correcto

<!-- 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 -->

Errores Comunes

• Proporcionar carruseles solo por deslizamiento sin ningún control de botón anterior/siguiente: Muchas bibliotecas de carrusel se entregan solo con soporte de gestos; las personas desarrolladoras deben configurar y renderizar explícitamente los botones de navegación para proporcionar una alternativa de un solo puntero.
• Ocultar botones de navegación en dispositivos táctiles mediante media queries de CSS: Un patrón común oculta los botones de flecha en pantallas que se asumen como dispositivos táctiles (por ejemplo, @media (pointer: coarse)), eliminando la alternativa de un solo puntero para personas con discapacidad motora que dependen de ella incluso en pantallas táctiles.
• Depender únicamente de un gesto de pellizco con dos dedos para el zoom del mapa sin ofrecer botones de zoom: Las inserciones de mapas de terceros (implementaciones personalizadas) con frecuencia omiten los controles de zoom, dejando el pellizco como el único mecanismo de zoom.
• Usar patrones de deslizar para eliminar o deslizar para revelar sin ningún botón de acción alternativo: Los elementos de lista en aplicaciones web que revelan opciones de eliminación o acción solo mediante un deslizamiento horizontal no tienen un mecanismo equivalente basado en toques para personas que no pueden deslizar de forma fiable.
• Interfaces personalizadas de arrastrar y soltar que no tienen una alternativa de reordenación basada en teclado o clic: Las interacciones de arrastre son por naturaleza basadas en trazos; no proporcionar un mecanismo alternativo (como botones de subir/bajar o un modelo de cortar y pegar) viola este criterio.
• Widgets de dibujo o firma que asumen que la trayectoria dibujada en sí misma no es el resultado: Las personas desarrolladoras a veces invocan por error la excepción de “esencial” para widgets que en realidad son solo controles de interfaz de usuario (por ejemplo, un patrón de desbloqueo por gesto para revelar contenido) en lugar de auténticas herramientas de entrada a mano alzada.
• Colocar controles alternativos de un solo puntero fuera del viewport visible o en un estado colapsado por defecto: Si los botones equivalentes existen en el DOM pero están ocultos visualmente o requieren una interacción adicional para mostrarse, no satisfacen plenamente el requisito de una alternativa de un solo puntero perceptible y operable.
• Implementar bibliotecas de gestos que interceptan eventos de puntero y evitan el comportamiento por defecto: Las bibliotecas que llaman a event.preventDefault() en eventos táctiles pueden bloquear inadvertidamente las propias interacciones de un solo puntero y el desplazamiento del navegador, creando fallos no intencionados más allá del propio criterio de gestos.
• Asumir que añadir aria-label a una zona solo de gestos es suficiente: Etiquetar un área de deslizamiento no proporciona una alternativa de un solo puntero: solo la describe a las personas usuarias de lectores de pantalla que aún no pueden operarla sin soporte de gestos.
• No probar en dispositivos reales o con simulación táctil: Las personas desarrolladoras que solo prueban en escritorio con ratón pueden no descubrir nunca que una función se opera exclusivamente mediante gestos en dispositivos móviles, porque la alternativa de clic con ratón funciona en escritorio pero la ruta de código solo táctil carece de un equivalente de clic.

Relación con las Regulaciones de Accesibilidad de Turquía

La Circular Presidencial 2025/10 de Turquía, publicada en el Boletín Oficial n.º 32933 el 21 de junio de 2025, establece obligaciones obligatorias de accesibilidad web y móvil para una amplia gama de entidades públicas y privadas que operan en Turquía. La circular adopta WCAG 2.2 como su estándar técnico normativo, lo que convierte todos los criterios de éxito de Nivel A — incluido WCAG 2.5.1 Gestos del Puntero — en requisitos básicos legalmente obligatorios.

El calendario de cumplimiento bajo la circular es escalonado: las instituciones y organismos públicos están obligados a lograr la conformidad en el plazo de un año desde la entrada en vigor de la circular, mientras que las entidades del sector privado cubiertas por la regulación tienen un plazo de dos años para alcanzar el cumplimiento total. El incumplimiento expone a las entidades cubiertas a escrutinio regulatorio y acciones de ejecución por parte de las autoridades supervisoras competentes.

Las entidades cubiertas por la circular incluyen una amplia sección transversal de proveedores turcos de servicios digitales. Las instituciones públicas en todos los niveles de gobierno y sus organismos afiliados están cubiertos. En el sector privado, la circular se aplica a plataformas y mercados de comercio electrónico, bancos e instituciones financieras, hospitales privados y proveedores de atención sanitaria, empresas de telecomunicaciones con 200,000 o más abonados, agencias de viajes, empresas privadas de transporte de pasajeros y escuelas privadas que operan bajo autorización del Ministerio de Educación Nacional (MoNE).

Para estas organizaciones, WCAG 2.5.1 tiene implicaciones directas y prácticas. Los sitios turcos de comercio electrónico usan con frecuencia galerías de imágenes de productos basadas en gestos, navegación por categorías basada en deslizamientos y visores de productos con pellizco para hacer zoom, todo lo cual ahora debe tener alternativas de un solo puntero. Las aplicaciones bancarias y financieras que usan patrones de autenticación basados en gestos o interfaces de transacciones basadas en arrastrar deben ser auditadas y corregidas. Los portales de salud con buscadores de clínicas basados en mapas que usan pellizco para hacer zoom deben proporcionar botones de zoom. Los portales de autoservicio de telecomunicaciones con selectores de planes basados en deslizamientos deben añadir controles basados en toques.

Se recomienda encarecidamente a las organizaciones que operan en Turquía que incluyan WCAG 2.5.1 en sus listas de verificación de auditoría de accesibilidad de inmediato, ya que los patrones de interacción por gestos afectados por este criterio son omnipresentes en el diseño web adaptable moderno y el desarrollo mobile-first, pero con frecuencia se pasan por alto porque parecen funcionar correctamente para la mayoría de las personas usuarias. Abordar este criterio de forma proactiva como parte de un programa de conformidad con WCAG 2.2 de Nivel A es tanto una obligación legal en virtud de la Circular Presidencial 2025/10 como una mejora significativa en la inclusión digital para las personas usuarias turcas con discapacidades motoras.