Pointer Events y accesibilidad con ratón, pantalla táctil y lápiz

Pointer Events ofrece a las aplicaciones web un modelo de eventos común para las entradas de ratón, pantalla táctil y lápiz. Ese modelo compartido puede facilitar la organización de acciones como arrastrar, dibujar y manipular elementos directamente, pero no vuelve intercambiables todos los métodos de entrada. Una interfaz fiable trata los eventos de puntero como una forma de interacción, mantiene disponible el uso con teclado, ofrece áreas de activación prácticas y gestiona las interrupciones sin perder el estado.

La pregunta importante de diseño no es cómo averiguar qué dispositivo físico posee una persona, sino si puede completar la acción actual con comodidad mediante los métodos de entrada que tiene disponibles. Una persona puede alternar entre ratón, pantalla táctil, lápiz, teclado, control por voz o tecnología de asistencia durante una misma tarea. Las páginas deben responder a la interacción y a su resultado, no intentar crear un perfil de la persona o del dispositivo.

Para realizar pruebas de interacción de aplicaciones, consulta validación de interacciones en el navegador y pruebas de emulación de dispositivos. Si un flujo de trabajo abarca varias plataformas, perfiles de navegador multiplataforma explica cómo documentar las diferencias esperadas.

Un modelo de eventos compartido, no un clasificador de dispositivos

La especificación Pointer Events define eventos e interfaces para gestionar entradas de puntero de forma independiente del dispositivo. En el código habitual de una aplicación, esto significa que las operaciones comunes pueden usar pointerdown, pointermove, pointerup y pointercancel, en lugar de mantener una lógica de interacción completamente distinta para cada tipo de entrada compatible con punteros. El navegador proporciona propiedades del evento actual, entre ellas un identificador y un tipo de puntero general. Estas propiedades sirven para asociar eventos con una interacción activa; no son una base fiable para deducir la identidad, las capacidades, la propiedad de un dispositivo o las intenciones de una persona.

El ratón, la pantalla táctil y el lápiz tienen características físicas diferentes. Un ratón suele tener un cursor y botones diferenciados. Un dedo toca una zona más amplia de la pantalla y también puede activar gestos de navegación del navegador. Un lápiz permite posicionarse con precisión y, cuando hay compatibilidad, puede incluir botones o propiedades relacionadas con la presión. Además, se puede conectar o desconectar un dispositivo de entrada mientras una página está abierta. Las aplicaciones deben hacer que los controles se entiendan y se puedan manejar sin presuponer una configuración de entrada permanente.

El modelo de eventos facilita compartir comportamientos, no borrar diferencias útiles. Una superficie de dibujo puede ofrecer una función específica para lápiz si la aplicación realmente la necesita, pero un botón básico debe seguir siendo un botón. Un tirador de arrastre no debe ser la única forma de reordenar una lista si se puede proporcionar una alternativa accesible con teclado. Un menú no debe exigir un estado de pasar el cursor que una persona con pantalla táctil no pueda producir. Parte de la tarea y de su resultado, y elige una interacción de entrada fácil de descubrir y con una forma de recuperación.

La Recomendación W3C Pointer Events Level 3 es la fuente normativa del modelo de eventos y su comportamiento. La guía de Pointer Events de MDN ofrece una descripción práctica de su uso en aplicaciones web. La compatibilidad y los detalles de los navegadores pueden cambiar, así que comprueba la compatibilidad actual del evento o la propiedad concreta de la que depende tu producto. Un nombre de API conocido no garantiza un comportamiento idéntico en todas las versiones del navegador ni en todos los navegadores integrados.

Sigue una interacción desde el inicio hasta su finalización

pointerdown es un buen punto de partida para una interacción. Indica que el puntero ha establecido contacto o ha iniciado de otro modo una acción de entrada. Al arrastrar, la aplicación puede registrar el punto de partida, el elemento que se mueve y el identificador del puntero actual. Una herramienta de dibujo puede iniciar un trazo. Un control personalizado puede registrar una posible activación y dejar la decisión final para cuando termine la interacción.

Mantener un estado de interacción pequeño y explícito es más seguro que tratar cada evento como una orden aislada. El estado puede indicar que se está arrastrando un elemento determinado, que hay un trazo activo o que hay una pulsación pendiente. También debe dejar claro cómo se elimina. Si la persona abandona el gesto, navega a otra página o el navegador asume el control de la interacción, la aplicación no debe dejar un control como si siguiera pulsado ni un indicador de arrastre siguiendo coordenadas obsoletas.

pointermove informa del movimiento asociado al puntero. Una página puede utilizarlo para actualizar una vista previa, mover un objeto seleccionado o dibujar un trazo. Los movimientos pueden llegar con mucha frecuencia, y la plataforma o el navegador pueden combinar varias muestras. Por eso, el comportamiento de la aplicación debe depender de la interacción actual y de su resultado final, no de suponer que cada movimiento físico se corresponde con una llamada al controlador. Cuando corresponda, la aplicación puede programar o agrupar las operaciones de renderizado costosas, manteniendo el estado asociado al puntero activo.

En las interfaces compatibles con varios punteros simultáneos, como un gesto de dos dedos en un lienzo, conserva el estado por identificador de puntero en lugar de suponer que solo puede haber uno activo. En los controles más sencillos, puede ser más fácil de explicar y probar admitir deliberadamente una sola interacción activa. En ambos casos, define qué ocurre si empieza un segundo puntero mientras el primero sigue activo. Ignorar el segundo puntero, cancelar la acción actual o pasar a un modo multipuntero debe ser una decisión deliberada del producto, no un efecto secundario accidental.

pointerup marca el final de una acción activa del puntero. Es un momento natural para confirmar el destino de un elemento arrastrado, finalizar un trazo o determinar si una pulsación debe activar un control. Antes de confirmar la acción, valida el destino y comunica el resultado. Si no se puede soltar un elemento en una ubicación, devuélvelo a una posición válida y clara, y explica la restricción en lugar de dejarlo en un estado ambiguo. Una acción similar a un clic tampoco debe activarse solo porque haya empezado una pulsación: la persona puede haberse alejado, haber cancelado o haber realizado un gesto de la plataforma.

La plataforma define los detalles del orden de los eventos de puntero, que puede incluir eventos de compatibilidad para contenido orientado al ratón. Evita conectar la misma acción de negocio a varios grupos de eventos de forma que se active dos veces. Prefiere una ruta clara para cada interacción y pruébala en los navegadores y las condiciones de entrada compatibles con el producto. Si el código de la aplicación también admite la activación con teclado, utiliza el comportamiento semántico normal del control en lugar de duplicar una acción exclusiva del puntero mediante otros controladores de eventos.

La secuencia no tiene por qué terminar con pointerup. La página debe contemplar pointercancel como una vía real de finalización. El navegador puede cancelar una interacción de puntero cuando necesita gestionar otro comportamiento o cuando esta ya no puede continuar como se esperaba. Las circunstancias concretas dependen de la plataforma y de la acción. Trata la cancelación como una señal para detener el gesto actual, descartar o resolver de forma segura su estado temporal y devolver la interfaz a una condición utilizable. No significa que la persona haya hecho algo mal.

La cancelación es especialmente importante en las interacciones táctiles porque el navegador y la página comparten la responsabilidad de gestionar los gestos. Si una persona empieza a moverse sobre una página, el navegador puede interpretar ese movimiento como desplazamiento o zoom, en vez de como un arrastre de la aplicación. La propiedad CSS touch-action permite declarar qué comportamientos de manipulación directa pretende gestionar la aplicación en una región determinada. Elige el comportamiento más limitado que necesite el control. Desactivar ampliamente los gestos del navegador puede dificultar el uso de la página e impedir que funcionen como se espera comportamientos habituales del navegador.

Después de pointerup o pointercancel, elimina el estado de la interacción activa y cualquier tratamiento visual temporal. Si la interacción utiliza la captura de puntero, gestiona también la notificación de pérdida de captura. La limpieza debe poder ejecutarse más de una vez de forma segura: varios finales pueden coincidir con el desmontaje de un componente, cambios de ruta o una cancelación del navegador. Una limpieza idempotente evita confirmaciones duplicadas y una interfaz obsoleta. Por ejemplo, al arrastrar un elemento de una lista, se debe confirmar una sola vez en un destino válido o restaurar la posición anterior, nunca hacer ambas cosas.

Mantén el arrastre asociado mediante la captura de puntero

Durante un arrastre, el puntero puede salir del elemento donde empezó la interacción. Sin una estrategia explícita, el destino de los eventos puede pasar a otro elemento y el control original puede dejar de recibir los eventos necesarios para completar la acción. La captura de puntero permite que un elemento siga recibiendo los eventos de un puntero activo determinado aunque este se desplace a otro lugar de la página. El código puede solicitar la captura con setPointerCapture() para el identificador del puntero activo y liberarla cuando corresponda.

La captura resulta útil en las interacciones cuyo significado continúa fuera del área de activación original: arrastrar el control deslizante, mover un elemento, cambiar el tamaño de un panel o dibujar sobre un lienzo. No congela el puntero ni hace que permanezca dentro del elemento que lo captura. Cambia el destino de los eventos para que la interacción pueda terminarse y limpiarse de manera predecible. Vincula la respuesta visual a la ubicación actual del puntero y haz que el resultado de la acción sea claro.

En las entradas táctiles y de lápiz que el navegador trata como manipulación directa, la plataforma puede establecer una captura de puntero implícita después del inicio del puntero. Este comportamiento ayuda a que un gesto continuo siga asociado al destino donde empezó. Si una aplicación captura un puntero explícitamente, debe hacerlo solo después de que haya empezado un puntero activo y estar preparada para que termine la captura. Al completar o cancelar la acción, libera el estado relacionado y no presupongas que la captura persiste durante todas las transiciones del ciclo de vida.

La captura no sustituye unos límites de interacción bien pensados. Un puntero capturado también puede cancelarse, y la persona debe poder detener o revertir una acción prolongada. Si un arrastre controla algo importante, ofrece una vista previa clara, un momento de confirmación predecible y una forma de recuperarse de una colocación accidental. Evita que un pequeño movimiento impreciso se convierta en una acción irreversible. Si un clic, un comando de teclado o un menú permiten realizar la misma tarea de forma más sencilla, ofrece esas alternativas.

Considera qué sucede si el elemento capturado se elimina o se sustituye durante el renderizado. Los marcos de trabajo pueden volver a crear nodos DOM cuando cambia el estado; el nodo nuevo no hereda automáticamente todas las interacciones del anterior. Cuando sea práctico, mantén estable el elemento responsable de la interacción y asegúrate de que el desmontaje del componente realice la limpieza. Si la persona cambia de ruta o cierra un diálogo durante un arrastre, no dejes una interacción oculta activa en segundo plano.

Haz comprensibles las acciones con ratón, pantalla táctil y lápiz

Una interacción con ratón puede admitir respuestas visuales al pasar el cursor, pero estas deben ser complementarias. No ocultes instrucciones, etiquetas o controles esenciales en un estado que solo pueda mostrar el ratón. Una persona puede tener conectados a la vez una pantalla táctil y un ratón, o usar un teclado en un dispositivo que suele describirse como móvil. Preguntar una sola vez qué dispositivo tiene no describe todas las interacciones posteriores.

La entrada táctil se beneficia de controles fáciles de alcanzar y bien separados de las acciones cercanas. La pantalla táctil no es simplemente un ratón menos preciso: el área de contacto es más amplia, el dedo tapa parte de la pantalla y el navegador puede reservar gestos para desplazarse o ampliar. Deja suficiente espacio entre acciones próximas para evitar selecciones accidentales, usa etiquetas que expliquen el resultado y no hagas que un icono diminuto sea la única zona activa. Un objetivo amplio es una decisión de diseño práctica que reduce errores con varios métodos de entrada, no una forma de identificar el dispositivo.

El lápiz puede ser útil para escribir, dibujar, anotar o seleccionar contenido con precisión. Si la aplicación usa propiedades específicas del lápiz, proporciona también un comportamiento básico razonable para los punteros que no las ofrezcan. Por ejemplo, una interfaz para tomar notas debe seguir siendo utilizable con un dedo o un ratón aunque haya trazos sensibles a la presión disponibles con un lápiz compatible. No conviertas la presión, la inclinación ni una función concreta del lápiz en un requisito para la navegación habitual o para completar formularios.

No deduzcas la habilidad ni las necesidades de accesibilidad de una persona a partir de pointerType. La propiedad describe una categoría general del evento en la API; no demuestra que alguien sostenga un producto específico, utilice una mano determinada, pueda realizar un gesto o prefiera ese método de entrada. Las personas pueden depender de dispositivos de conmutación, entrada de voz, punteros alternativos o funciones de accesibilidad del navegador que no encajan claramente en las categorías de ratón, pantalla táctil o lápiz. Las aplicaciones deben evitar conservar características del puntero como señal de identidad y recopilar solo los datos de interacción que tengan una finalidad de producto clara y comunicada.

El navegador sigue siendo responsable de muchos aspectos del entorno de interacción, incluidos los gestos nativos, el comportamiento del foco y la integración con tecnologías de asistencia. Una página web no debe intentar reemplazar esos mecanismos mediante la simulación de eventos personalizados ni ocultar el método de entrada a un sitio o servicio. Diseña para que la persona controle la interacción legítimamente: muestra el estado actual, respeta el comportamiento de la plataforma y permite elegir una forma disponible de continuar.

El acceso mediante teclado es una vía paralela

Pointer Events no proporciona por sí solo acceso mediante teclado. Un control de arrastre que parece obvio puede seguir siendo inutilizable para quien navega con teclado. Todas las tareas esenciales para completar un flujo de trabajo deben poder alcanzarse y manejarse sin mover el puntero. Siempre que se ajusten a la tarea, utiliza elementos interactivos nativos para botones, enlaces, campos de formulario e interruptores. Los controles nativos ya participan en el foco y en la interacción mediante teclado, algo que los elementos visuales personalizados no heredan automáticamente.

La guía de teclado de WCAG describe el requisito paralelo: la funcionalidad debe poder operarse mediante una interfaz de teclado sin exigir un recorrido particular del puntero. Pointer Events puede respaldar una vía de interacción, pero no sustituye este requisito de teclado.

Para un componente personalizado, define cómo se accede a él, cómo se recorren sus partes, cómo se activa una acción y cómo se sale. El foco debe permanecer visible. Usa el comportamiento de teclado esperado para el tipo de control y expón su nombre, función y estado mediante la semántica adecuada. Por ejemplo, un control deslizante personalizado necesita más que un indicador que siga a pointermove: requiere un control que pueda recibir el foco, información de valor comprensible y ajustes con teclado. Una lista ordenable debe ofrecer un método con teclado para seleccionar un elemento, moverlo, confirmar su nueva posición o cancelar y restaurar el orden anterior.

No vincules la lógica de la aplicación únicamente a un evento de puntero de bajo nivel cuando un botón semántico o un control de formulario pueda expresar la misma acción. Activar un botón nativo con teclado, tecnología de asistencia o puntero debe ejecutar el mismo comando. En interacciones complejas con lienzo donde la semántica nativa no sea suficiente, acompaña el lienzo con controles o una alternativa estructurada que permita realizar el mismo trabajo significativo. Si la tarea requiere editar o elegir valores, una descripción textual que no permita continuar no es una alternativa adecuada.

Las rutas con teclado y con puntero no tienen que parecer idénticas. Arrastrar puede ser un gesto natural con puntero, mientras que quienes usan teclado pueden disponer de comandos explícitos para «subir» y «bajar». Lo importante es que ambas rutas permitan alcanzar el mismo resultado significativo y comuniquen los cambios de estado. Anuncia o muestra una confirmación cuando se mueva un elemento, conserva el foco en un elemento razonable y permite cancelar. Evita límites de tiempo que obliguen a completar un gesto con rapidez.

Prueba el orden del foco junto con el orden de las interacciones con puntero. Al abrir un elemento emergente, coloca el foco donde corresponda a la interacción; al cerrarlo, devuélvelo a un lugar comprensible. Seleccionar con el puntero no debe eliminar globalmente los indicadores de foco. Una persona puede seleccionar un control con la pantalla táctil y continuar después con un teclado físico. Trata estas transiciones como situaciones normales y mantén visible el estado actual del foco y la selección.

Comprueba los resultados en distintas condiciones de entrada

Las pruebas entre dispositivos son más útiles cuando comprueban la misma tarea de usuario bajo un conjunto pequeño y explícito de condiciones. Incluye una ruta con ratón y teclado en un ordenador, una ruta prioritaria para pantalla táctil en un teléfono o tableta y entrada con lápiz cuando la aplicación realmente la admita. Añade el uso solo con teclado en un ordenador y al menos una ventana gráfica estrecha. Si se investiga un problema de compatibilidad, registra las versiones del navegador y de la plataforma, pero no conviertas la prueba en un censo de dispositivos de los usuarios.

Para cada tarea, define un resultado comprobable: un menú se abre y se puede cerrar, una tarjeta se mueve a una ubicación válida, se completa un dibujo, se cambia un valor o se puede corregir un error. Después, prueba todo el ciclo de vida. Inicia la acción, sal del objetivo original, termínala fuera y dentro del control cuando corresponda, cancélala, interrumpe el componente y repite la acción. Comprueba que la interfaz nunca quede atascada en un estado pulsado, de arrastre o modal.

Incluye los gestos del navegador en las pruebas táctiles. Desplázate por una página que contenga una región arrastrable. Comprueba que la región permita el desplazamiento normal donde corresponda y que una interacción deliberada de manipulación directa no absorba accidentalmente todo el movimiento de la página. Comprueba el valor de touch-action en el elemento pertinente más pequeño en vez de desactivar los gestos en toda la aplicación. Verifica que la ampliación y la navegación del navegador sigan disponibles, salvo que el producto tenga un requisito de interacción específico y justificado.

Comprueba la calidad de los objetivos en tamaños de visualización realistas. Usa la interfaz con una sola mano cuando sea una condición de uso plausible, prueba controles próximos a los bordes de la pantalla y busca controles demasiado juntos. No te limites a hacer clic en el centro de un monitor grande con un cursor preciso. Pregúntate si las etiquetas y el estado visibles siguen siendo claros cuando el dedo o la mano de la persona tapan parte del control. Prueba también la orientación y el desplazamiento si el flujo de trabajo los admite.

Después, repite la tarea principal sin usar el puntero. Navega con el teclado, activa controles, cambia valores, reordena contenido y corrige un error. Comprueba que el foco siga visible y no quede oculto detrás de un diálogo o una región fija. Si el flujo de trabajo promete compatibilidad con tecnologías de asistencia, incluye las tecnologías y plataformas que el producto se compromete a admitir. Una prueba de eventos de puntero no sustituye las pruebas de nombres, funciones, anuncios de estado y orden de lectura.

Las pruebas automatizadas pueden ayudar a verificar la limpieza del estado y el tratamiento de eventos, pero no demuestran que el objetivo sea cómodo, que las etiquetas se entiendan o que la ruta con teclado tenga sentido. Combina las comprobaciones automatizadas con una revisión práctica en dispositivos y versiones representativos del navegador. Registra una matriz concisa con la tarea, la ruta de entrada, el resultado esperado, el resultado observado, el navegador y la plataforma, y las acciones pendientes. Limita las capturas de pantalla y los registros de interacción a lo que necesite la prueba, y evita recoger contenido personal o telemetría innecesaria del puntero.

Si aparece un defecto en una plataforma, primero aísla el comportamiento visible para la persona. Comprueba si la página recibió una cancelación, si terminó la captura del puntero, si cambió el foco y si la gestión de los gestos del navegador coincide con el diseño previsto. Compara una actualización compatible del navegador u otro dispositivo representativo solo cuando esa comparación ayude a explicar el comportamiento. No deduzcas la identidad de una persona ni fabriques patrones de eventos para forzar un resultado distinto. El trabajo de compatibilidad debe mejorar la interacción real de quienes usan la aplicación.

Usa esta matriz de aceptación ejecutable para cada interacción importante:

Ejecuta estos casos según la Recomendación W3C Pointer Events Level 3 y los criterios aplicables de WCAG 2.2. Usa dos tareas concretas: arrastrar una tarjeta para reordenarla y dibujar un trazo en un lienzo. Registra el resultado visible, no el dispositivo supuesto.

Caso	Preparación y acción	Criterios de aprobación	Evidencia que se registra
Finalización de arrastre	Toma una tarjeta, sal del objetivo original y suelta en un destino válido.	Un ciclo pointerdown/pointerup confirma un solo reordenamiento; el nuevo orden y un estado de éxito son visibles.	Registro de eventos, orden y estado visible.
Finalización de dibujo	Pulsa el lienzo, dibuja un trazo y suelta dentro o apenas fuera de la zona inicial.	El trazo se confirma una vez, permanece visible y su finalización se expone visualmente y a la tecnología de asistencia.	Traza del puntero, trazo renderizado y estado/anuncio.
Cancelación	Ejecuta pointercancel (o Escape/abortar explícito) y observa la limpieza de lostpointercapture. Repite pointerup seguido de lostpointercapture.	La cancelación revierte una sola vez; la ruta confirmada por pointerup permanece confirmada una sola vez. lostpointercapture por sí solo nunca revierte ni duplica; se limpian captura, estilos y trazo temporal.	Secuencia de eventos y aserción posterior a cancelar/confirmar.
Alternativa y foco	Reordena la tarjeta solo con teclado y cancela una vez. Para dibujar, decide si la tarea es dependiente del trazado; si no lo es, ofrece una alternativa estructurada/de valores equivalente.	La reordenación por teclado es alcanzable y operable, el foco permanece visible y se anuncian éxito/cancelación. Para dibujar se documenta la alternativa de producto cuando corresponde; una descripción no basta para editar o elegir valores.	Teclas, elemento enfocado, decisión de tarea y texto de estado.
Recuperación y fallo	Usa un destino no válido o elimina la vista propietaria y vuelve a intentarlo.	Se elimina el estado temporal; la persona ve un mensaje de fallo accionable y un resultado restaurado claro; el reintento no duplica trabajo.	Mensaje de fallo, estado restaurado, acción y segundo resultado.

Considera fallido un caso si falta algún criterio o si el resultado se infiere solo de pointerType, del tiempo o de una etiqueta de dispositivo. La aceptación es el resultado observable, no un detector de quién o qué produjo la entrada.

Una lista de comprobación práctica

Antes de publicar, confirma que cada interacción personalizada con puntero tenga definidos el inicio, el movimiento, la finalización correcta, la cancelación y la limpieza. Verifica que el estado temporal se elimine después de una interrupción y que una acción no pueda confirmarse dos veces. Usa la captura de puntero solo cuando la interacción necesite seguir recibiendo eventos fuera de su elemento original y gestiona el final de la captura.

Confirma que pasar el cursor no sea la única manera de descubrir o usar una función. Los objetivos táctiles deben tener un tamaño práctico y suficiente separación, el desplazamiento y la ampliación del navegador deben seguir disponibles, y las mejoras exclusivas para lápiz no deben impedir que otras personas completen la tarea. Elige touch-action deliberadamente y limita cualquier restricción a la interacción que la necesite.

Por último, completa la misma tarea esencial usando solo el teclado. Comprueba la visibilidad del foco, la semántica, la información de estado y la cancelación. Prueba una combinación representativa de navegadores, ventanas gráficas y métodos de entrada; registra lo que se haya verificado realmente y mantén las pruebas en proporción con su propósito. Pointer Events es una base compartida útil, pero la interacción accesible depende de la experiencia completa que la rodea: controles comprensibles, capacidad de elección, recuperación y compatibilidad con el comportamiento de la plataforma.

Fuentes públicas

• Recomendación W3C Pointer Events Level 3
• MDN Pointer Events
• WCAG: Teclado
• WCAG 2.5.2: Cancelación del puntero (fuente directa de las filas de cancelación)
• WCAG 2.5.8: Tamaño del objetivo (mínimo) (guía de tamaño; la aplicación puede exigir más)
• WCAG 2.4.7: Foco visible y 2.4.11: Foco no oculto (mínimo) (criterios de foco; las comprobaciones de una confirmación y reintento son de la aplicación)