Un gesto vistoso no debe ser la única entrada
Mover una tarjeta con el ratón parece natural hasta que hay que mantener pulsado el botón, controlar el objeto y acertar en un destino estrecho. En el móvil, además, puede competir con el desplazamiento de la página. Por eso empezamos por el resultado: cambiar un orden, escoger un valor o ver otra imagen. Arrastrar es un camino hacia ese resultado, no la tarea en sí. Una interfaz cuidada conserva ese camino para quien lo prefiera, sin exigir a todos la misma precisión.
Dos opciones con la misma capacidad
Una lista puede mostrar Subir y Bajar junto al elemento seleccionado. Para cambiar de grupo, puede resultar más claro escoger un destino. Un deslizador puede acompañarse de un campo de valor exacto o botones de incremento adecuados. Una galería puede incluir Anterior y Siguiente. Todas las opciones deben modificar los mismos datos, respetar los mismos límites y mostrar el mismo resultado. También hay que decidir qué ocurre en los extremos de una lista: un botón que no responde sin explicación produce dudas. La alternativa tiene que ser funcional, no un añadido visual.
Qué pide la accesibilidad
El criterio 2.5.7 de WCAG 2.2 exige que las funciones de arrastre puedan realizarse con un único puntero sin arrastrar, con excepciones para el arrastre esencial y el comportamiento no modificado del agente de usuario. Ofrecer solo teclado no basta: una persona con pantalla táctil puede no tener teclado físico. Su funcionamiento sigue necesitando una comprobación independiente; lo tratamos en navegar sin ratón. No hay que confundir el desplazamiento normal del navegador con un mecanismo de arrastre propio de la web.
Probar hasta completar la tarea
Reordene tres elementos con pulsaciones breves, sin mover el ratón mientras mantiene un botón presionado. Repita con teclado y teléfono. ¿Se distingue la selección? ¿Se entiende la nueva posición? ¿Puede corregirse un error? No esconda la alternativa detrás del efecto hover. Compruebe el espacio entre acciones y los nombres accesibles de los botones. Nuestro criterio práctico es que varios caminos comprensibles permitan alcanzar el mismo objetivo, no la cantidad de animaciones. Superar esta prueba de un componente no acredita la accesibilidad de todo el sitio.