Swipe actions

A list row is a small piece of screen with a lot of jobs. Tapping it should open the thing, so every other command has to go somewhere else, and the swipe puts them underneath. Dragging the row sideways slides its content out of the way and uncovers buttons that were always there, scoped to that one item. Apple’s Human Interface Guidelines split them by direction: the leading edge for the affirming action (mark as read, mark as done) and the trailing edge for the dangerous one (delete, archive), which is a convention worth keeping because muscle memory is the whole point of a gesture nobody can see.

Two behaviours hide under one word, and they feel completely different. A partial swipe reveals the buttons and waits, so the reader chooses. A full swipe past a further threshold commits to the first action immediately, with no button pressed at all. The full swipe is fast and terrifying, so it belongs only to something reversible: pair it with an undo affordance and never put an irreversible delete on it. In both cases the row should track the finger while the gesture is in progress and settle to a definite position when it is released, never park half open.

Nothing about this is discoverable. There is no visual mark on a row that says it can be swiped, so a swipe action can only ever be an accelerator for a command that also exists somewhere a reader can find it: a detail view, a selection mode, an overflow menu on the row. The same reasoning covers input that cannot swipe at all. A keyboard has no gesture, a screen reader user is moving through the row rather than dragging it, and on the desktop web there is no swipe to speak of. Expose the actions as real buttons in the accessibility tree and make sure they are reachable without the gesture, rather than treating the reveal as the only door.

Building it on the web means owning the drag yourself. Pointer events plus touch-action: none on the row stop the browser from claiming the gesture as a scroll, and the horizontal offset is applied with a transform so a revealed row cannot push its neighbours around. Watch the axis: a list scrolls vertically, so a swipe handler that starts reacting before it knows which way the finger is going will fight the scroller and lose in both directions.