WCAG 2.5.6: Mecanismos de entrada concurrentes

Qué significa esta regla

\n

WCAG 2.5.6 — Mecanismos de entrada concurrentes es un criterio de conformidad de nivel AAA en WCAG 2.2. Su requisito central es sencillo: el contenido web no debe restringir ni interferir con la capacidad de la persona usuaria para utilizar múltiples mecanismos de entrada de forma simultánea o intercambiable. En términos prácticos, esto significa que una página web o aplicación no puede detectar mediante programación qué dispositivo de entrada está utilizando la persona en ese momento y luego bloquearla en esa única modalidad, negándole el acceso a otros métodos de entrada disponibles.

\n

Los dispositivos modernos admiten una gran variedad de mecanismos de entrada: teclados físicos, ratones y trackpads, pantallas táctiles, lápices ópticos, controles por interruptor, entrada por voz, seguimiento ocular y más. Muchas personas usan más de uno de estos al mismo tiempo; por ejemplo, una persona que usa un portátil con pantalla táctil puede alternar fluidamente entre el touchpad y la interfaz táctil con el dedo. Una persona usuaria avanzada puede navegar por un formulario con el teclado mientras usa el ratón para desplazarse. Una persona con una discapacidad motora puede usar una combinación de un puntero de cabeza y un dispositivo de interruptor. El criterio protege todos estos flujos de trabajo.

\n

Se produce un fallo cuando un sitio web utiliza JavaScript para detectar el tipo de entrada que se está usando y luego elimina o desactiva la funcionalidad para otros tipos de entrada. Por ejemplo, si un sitio detecta un evento táctil y posteriormente elimina los indicadores de foco del teclado o desactiva la navegación por teclado, eso es una violación directa. De forma similar, bloquear la entrada de puntero tras detectar el uso del teclado, o utilizar APIs de la plataforma para limitar artificialmente la entrada a una sola modalidad, también constituye fallos.

\n

Se produce un cumplimiento cuando las personas pueden interactuar con cualquiera y todos los mecanismos de entrada disponibles en cualquier momento durante su interacción. El contenido debe responder correctamente al mecanismo de entrada que la persona usuaria decida emplear en cada momento sin requerir recargar la página, cambiar de modo ni realizar ninguna acción adicional para volver a habilitar un tipo de entrada.

\n

El criterio contiene una excepción oficial definida en WCAG: se permite la restricción cuando sea esencial, es decir, cuando una modalidad de entrada específica sea intrínsecamente necesaria. Un ejemplo clásico es una aplicación de reconocimiento de escritura manual en la que la entrada táctil o con lápiz óptico es precisamente el objetivo de la funcionalidad. Otro ejemplo podría ser un campo de captura de firma digital que requiera una entrada de puntero específica. Incluso en estos casos, la excepción debe interpretarse de forma restrictiva y la persona autora debe proporcionar medios alternativos para completar la tarea siempre que sea posible.

\n

Es importante señalar que este criterio no exige que las personas autoras añadan compatibilidad con mecanismos de entrada que el dispositivo no posea. Regula las restricciones impuestas a mecanismos que el dispositivo y la plataforma ya admiten. Si un dispositivo no tiene pantalla táctil, no hay nada que restringir.

\n\n

Por qué es importante

\n

La libertad de usar mecanismos de entrada concurrentes o intercambiables no es una función de conveniencia: es un requisito de accesibilidad crítico que afecta directamente a varios grupos de personas usuarias diferentes.

\n

Las personas con discapacidades motoras dependen con frecuencia de tecnología de apoyo que combina múltiples mecanismos de entrada. Una persona con movilidad limitada en las manos puede usar un dispositivo de interruptor de soplo y succión junto con un teclado en pantalla. Alguien con temblor puede empezar a navegar por una página con el teclado pero cambiar a una interfaz de ratón o táctil cuando un atajo de teclado falla. Si un sitio web detecta un tipo de entrada y desactiva otros, estas personas pueden quedar completamente excluidas del contenido o la funcionalidad.

\n

Las personas con discapacidades cognitivas o de aprendizaje suelen beneficiarse de la posibilidad de elegir el método de entrada que les resulte más cómodo o natural para una tarea determinada. Obligar a usar una sola modalidad elimina esa elección y puede introducir una carga cognitiva innecesaria, especialmente cuando la persona no domina el método de entrada principal del dispositivo.

\n

Las personas mayores, que pueden tener dificultades motoras relacionadas con la edad, utilizan cada vez más dispositivos que admiten tanto entrada táctil como por teclado. La capacidad de alternar entre estos mecanismos a medida que el control de la motricidad fina fluctúa a lo largo del día es importante para un uso independiente y sostenido de la web.

\n

Las personas usuarias avanzadas y quienes usan dispositivos multimodales, como quienes usan Surface Pro o iPad Pro, utilizan habitualmente un teclado, un lápiz óptico y una interfaz táctil en el mismo dispositivo y en la misma sesión. Un sitio web que detecta la entrada táctil y elimina los atajos de teclado, o viceversa, degrada la experiencia de una enorme base de personas usuarias que puede no identificarse como personas con discapacidad.

\n

Considere este escenario real: el portal en línea de un banco turco detecta que una persona cliente está usando una tableta con pantalla táctil y cambia a un "modo móvil" que desactiva la navegación por teclado. Una persona cliente con una discapacidad motora que usa la tableta con un teclado Bluetooth ya no puede desplazarse por los campos de formulario con la tecla Tab, navegar por los menús con las teclas de flecha ni usar atajos de teclado. No puede completar sus tareas bancarias de forma independiente. Esto no solo es un fallo de accesibilidad, sino también una posible exposición legal en virtud de la normativa de accesibilidad turca.

\n

Desde la perspectiva de la usabilidad y el SEO, respetar los mecanismos de entrada concurrentes se correlaciona con mejores puntuaciones en Core Web Vitals, menores tasas de rebote y mayor satisfacción de las personas usuarias en diversas categorías de dispositivos, todas ellas señales que los motores de búsqueda recompensan.

\n\n

Reglas relacionadas de Axe-core

\n

WCAG 2.5.6 requiere pruebas manuales: no existe ninguna regla automatizada de axe-core que pueda detectar de forma fiable todas las violaciones de este criterio. La razón es fundamental: las herramientas automatizadas pueden inspeccionar el DOM y el CSS estáticos, y pueden detectar ciertos patrones de JavaScript, pero no pueden observar completamente el comportamiento en tiempo de ejecución de los listeners de eventos cuando responden a diferentes modalidades de entrada durante una sesión real de la persona usuaria. La decisión de restringir un mecanismo de entrada suele estar codificada en la lógica de la aplicación que solo se ejecuta en respuesta a eventos específicos, lo que hace que el análisis estático sea insuficiente.

\n

\n
• No existe una regla automatizada específica de axe-core para 2.5.6. Axe-core no incluye una regla que verifique específicamente las restricciones de mecanismos de entrada concurrentes, porque la violación se manifiesta como un comportamiento dinámico de JavaScript en lugar de un problema estructural de HTML o ARIA. Una página puede superar todas las comprobaciones automatizadas de axe y aun así violar 2.5.6 si sus controladores de eventos eliminan o desactivan mediante programación las modalidades de entrada en tiempo de ejecución.
\n
• Eventos de puntero y detección de eventos táctiles: Aunque axe-core no puede detectar la restricción en sí, las personas auditoras manuales deben buscar JavaScript que escuche eventos touchstart o pointerdown y luego modifique el DOM, elimine la gestión del foco o establezca indicadores que alteren el comportamiento del teclado. De forma similar, los listeners de keydown que desencadenan cambios de clases CSS que ocultan objetivos táctiles son señales de alerta que deben inspeccionarse manualmente.
\n
• Por qué la automatización se queda corta: Los escáneres automatizados analizan el documento en un momento determinado. Las restricciones de mecanismos de entrada son condicionales: se activan solo después de que se dispare un evento de entrada específico. Un escáner que se ejecute antes de la interacción de la persona usuaria no puede ver que un controlador de touchstart más tarde llamará a document.querySelectorAll('[tabindex]').forEach(el => el.setAttribute('tabindex', '-1')) y destruirá efectivamente la navegación por teclado. Solo una persona que realiza pruebas manuales y que ejercita ambas modalidades de entrada en secuencia puede descubrir este fallo.
\n

\n\n

Cómo hacer las pruebas

\n

\n
1. Escaneo automatizado de referencia: Ejecute axe DevTools o Lighthouse en la página para establecer una referencia y detectar cualquier problema concurrente. Aunque ninguna de las herramientas tiene una regla específica para 2.5.6, las comprobaciones de buenas prácticas de axe DevTools pueden señalar trampas de teclado o problemas de gestión del foco que son sintomáticos de una restricción de entrada. Anote cualquier fallo para su corrección junto con las comprobaciones manuales que se indican a continuación.
\n
2. Inspeccionar el código fuente JavaScript y los listeners de eventos: Abra Chrome DevTools, vaya al panel Elements y use el panel Event Listeners para comprobar si hay listeners touchstart, pointerdown, pointermove o MSPointerDown adjuntos al documento o al body. En la consola, busque en el código fuente JavaScript de la página patrones como ontouchstart in window, navigator.maxTouchPoints o 'pointer' in navigator combinados con modificaciones del DOM. Estas son técnicas habituales utilizadas para detectar la modalidad de entrada y condicionar la funcionalidad.
\n
3. Prueba de interacción multimodal (teclado + táctil): En un dispositivo que admita tanto entrada táctil como por teclado (por ejemplo, una Surface, un iPad con teclado o un portátil con pantalla táctil), comience a navegar por la página exclusivamente con el teclado (Tab, Shift+Tab, Enter, Space, teclas de flecha). Observe qué elementos interactivos son alcanzables y funcionales. Luego, sin recargar la página, cambie a la navegación táctil: toque enlaces, botones y controles de formulario. Verifique que toda la funcionalidad disponible mediante el teclado siga siendo accesible mediante el tacto y viceversa. Documente cualquier elemento que se vuelva inalcanzable o no funcional después de cambiar.
\n
4. Prueba de entrada combinada con lector de pantalla: Usando NVDA con Firefox, navegue por la página con el teclado para activar el modo de lector de pantalla. Luego use la pantalla táctil (si está disponible) para intentar interactuar con los mismos elementos. Confirme que el lector de pantalla y la página responden correctamente a ambas entradas. Repita con VoiceOver en Safari en un iPad, usando tanto los gestos táctiles como un teclado Bluetooth emparejado. Con JAWS en Chrome, verifique que cambiar entre teclado y ratón no rompa la gestión del foco ni haga que los elementos interactivos dejen de funcionar.
\n
5. Revisión de código en busca de patrones de bloqueo de modalidad: Revise manualmente cualquier biblioteca o framework JavaScript utilizado en la página para detectar mecanismos integrados de detección de modalidad. Algunas bibliotecas de interfaz de usuario, especialmente los frameworks móviles de primera generación, incluyen código que desactiva eventos de ratón o teclado en dispositivos donde se detecta entrada táctil. Revise la documentación y el código fuente de la biblioteca para detectar este comportamiento y verifique que se haya anulado o desactivado.
\n
6. Volver a probar después de interacciones dinámicas: Realice acciones que desencadenen cambios significativos en el DOM, como abrir modales, navegar por rutas de aplicaciones de una sola página o enviar formularios, y vuelva a ejecutar la prueba multimodal después de cada transición. A veces las restricciones solo se introducen en estados específicos de la aplicación.
\n

\n\n

Cómo corregirlo

\n

Detectar entrada táctil para desactivar la navegación por teclado: incorrecto

\n

<!-- JavaScript detecta la entrada táctil y elimina todos los valores de tabindex,\n     rompiendo la navegación por teclado para las personas que cambian de modo de entrada -->\n<script>\n  window.addEventListener('touchstart', function() {\n    document.querySelectorAll('a, button, input, [tabindex]').forEach(function(el) {\n      el.setAttribute('tabindex', '-1');\n    });\n  }, { once: true });\n</script>

\n

Detectar entrada táctil para desactivar la navegación por teclado: correcto

\n

<!-- No restrinja la accesibilidad por teclado en función de la detección táctil.\n     Permita que ambas modalidades de entrada funcionen de forma concurrente.\n     Si necesita gestionar los estilos de foco por motivos estéticos, use la\n     pseudoclase CSS :focus-visible en lugar de eliminar tabindex. -->\n<style>\n  /* Mostrar los anillos de foco solo para la navegación por teclado, no para clics de ratón,\n     sin eliminar por completo el acceso por teclado */\n  :focus:not(:focus-visible) {\n    outline: none;\n  }\n  :focus-visible {\n    outline: 3px solid #005fcc;\n    outline-offset: 2px;\n  }\n</style>\n<!-- No se necesita detección de modalidad con JavaScript -->

\n\n

Evento de puntero usado para suprimir eventos de teclado: incorrecto

\n

<!-- Un control deslizante personalizado que, al recibir entrada de puntero, deja de\n     responder a las teclas de flecha del teclado, obligando a la persona usuaria\n     a interactuar solo con el puntero -->\n<div id='slider' role='slider' aria-valuenow='50' aria-valuemin='0'\n     aria-valuemax='100' tabindex='0'></div>\n<script>\n  var slider = document.getElementById('slider');\n  var pointerUsed = false;\n  slider.addEventListener('pointerdown', function() {\n    pointerUsed = true;\n  });\n  slider.addEventListener('keydown', function(e) {\n    if (pointerUsed) return; // el teclado se desactiva tras la interacción con el puntero\n    if (e.key === 'ArrowRight') { /* incrementar */ }\n    if (e.key === 'ArrowLeft') { /* decrementar */ }\n  });\n</script>

\n

Evento de puntero usado para suprimir eventos de teclado: correcto

\n

<!-- Tanto las interacciones con puntero como con teclado se gestionan de forma independiente.\n     No se establece ninguna marca que impida que una modalidad funcione después de\n     que se haya utilizado la otra. -->\n<div id='slider' role='slider' aria-valuenow='50' aria-valuemin='0'\n     aria-valuemax='100' tabindex='0'></div>\n<script>\n  var slider = document.getElementById('slider');\n  var value = 50;\n\n  function updateSlider(newValue) {\n    value = Math.max(0, Math.min(100, newValue));\n    slider.setAttribute('aria-valuenow', value);\n  }\n\n  // Manejador de puntero: siempre activo\n  slider.addEventListener('pointermove', function(e) {\n    if (e.buttons === 1) {\n      // calcular el nuevo valor a partir de la posición del puntero\n    }\n  });\n\n  // Manejador de teclado: siempre activo, no se desactiva por el uso del puntero\n  slider.addEventListener('keydown', function(e) {\n    if (e.key === 'ArrowRight') updateSlider(value + 1);\n    if (e.key === 'ArrowLeft') updateSlider(value - 1);\n  });\n</script>

\n\n

Framework móvil que desactiva automáticamente los eventos de ratón: incorrecto

\n\n

(Content truncated due to token limit — please retry this article.)