Swipe actions en listas

Toda funcionalidad que dependa de un gesto de deslizamiento debe tener una alternativa accesible con un solo punto de contacto: un tap, un botón visible o el teclado. El swipe es un gesto de trayectoria (path-based) y su exclusividad viola WCAG 2.5.1 (Nivel A): usuarios con temblor, Parkinson, paralisis cerebral o control ocular no pueden ejecutar deslizamientos precisos. Exponer los mismos controles como acciones contextuales garantiza que nadie quede excluido. El swipe acelera al experto; la alternativa visible incluye a todos.

Cuando el usuario inicia el swipe, el fondo revelado debe comunicar la acción con tres capas simultaneas: color de fondo distintivo, icono reconocible y etiqueta de texto. Depender solo del color excluye a usuarios con daltonismo y eleva la carga cognitiva del resto, que deben adivinar entre rojo-eliminar y rojo-archivar. Apple HIG reserva el borde trailing para acciones destructivas o de cierre como Eliminar o Archivar, senaladas con rojo y papelera. El texto desambigua lo que el color por si solo no puede.

Hay dos umbrales: el deslizamiento parcial revela botones que requieren un tap explicito, y el deslizamiento completo atraviesa el ancho del elemento y ejecuta directo la acción primaria. El full swipe debe reservarse a la acción más frecuente y esperada, y nunca a una irreversible: Apple lo expone como allowsFullSwipe precisamente para controlarlo. NN/g advierte que los gestos fáciles arriesgan borrados no intencionados sin salvaguardas. Atar el full swipe a una acción segura (archivar) evita perdidas accidentales.

Eliminar, archivar permanentemente o cualquier acción irreversible disparada por swipe debe ofrecer protección ante el error: un dialogo de confirmación previo, o una notificación con acción Deshacer prominente que persista varios segundos. NN/g lo pide de forma explicita: pedir confirmación antes de acciones destructivas, o dar opciones de undo prominentes. El undo tipo snackbar es preferible porque no interrumpe el flujo; la confirmación modal sirve cuando no hay forma de revertir. Ejecutar sin salvaguarda expone perdidas accidentales.

iOS y Android asignan el borde trailing (derecha a izquierda) a acciones destructivas o de cierre como Eliminar o Archivar, y el borde leading (izquierda a derecha) a acciones positivas o de estado como Marcar como leido, Fijar o Responder. Apple HIG lo establece así de forma explicita. NN/g advierte: no uses el mismo gesto de swipe para significar cosas distintas en áreas distintas de la misma pantalla. La consistencia con el sistema reduce la carga cognitiva porque el usuario transfiere lo aprendido en otras apps.

Cuando el deslizamiento alcanza el umbral que separa revelar acciones de ejecutar el full swipe, el sistema debe dar una señal inequivoca: cambio visual en el elemento (expansión del área, intensificación del color, transformación del icono) y retroalimentación haptica. Sin ese feedback el usuario no sabe si cruzo el punto de no retorno y actua con incertidumbre. Apple expone UIImpactFeedbackGenerator y UISelectionFeedbackGenerator para estos momentos. El umbral debe ser visualmente notorio antes de soltar el dedo.

Los swipe actions son gestos invisibles: ningun control los anuncia. NN/g documenta que la mayoría de usuarios no los descubre, o lo hace solo por accidente, y que deslizar sigue siendo menos descubrible que casi cualquier otra forma de manipular contenido móvil, por lo que deben incluirse pistas visibles. El costo de esconder es real: NN/g documenta un aumento del 21% en dificultad percibida con navegación oculta vs visible. Mitiga con un peek animado en el primer uso, un onboarding breve o un ligero desplazamiento del item que sugiera que es deslizable.

Quien navega con VoiceOver (iOS) o TalkBack (Android) no puede ejecutar swipes de forma confiable, y nunca debe quedar sin acceso a borrar o archivar. Cada acción disponible por swipe debe exponerse como acción de accesibilidad en el nodo de la fila, y en navegación por teclado (iPad con Magic Keyboard, Android con teclado físico) debe alcanzarse vía menú contextual o atajos documentados. Esto satisface a la vez WCAG 2.5.1 y WCAG 2.1.1, ambos Nivel A: la operación por un solo puntero sin trayectoria y por teclado no son opcionales.