An impressive gesture should not be the only entrance
Moving a card with a mouse seems natural until someone must keep the button pressed, retain the object and reach a narrow destination simultaneously. On a phone, the gesture may also compete with page scrolling. We therefore start with the intended outcome: reorder something, choose a value or view another image. Dragging is one route to that outcome, not the task itself. A considered interface keeps it for people who find it convenient without requiring everyone else to practise precision.
One action, two genuinely equivalent routes
A sortable list can offer Move up and Move down beside the selected row. Moving between groups may be better served by a list of destinations. A slider can have an exact-value field or step buttons where these fit the task. A gallery can include ordinary previous and next controls. Every route should update the same data, honour the same limits and make the same result visible. Otherwise the alternative is decorative rather than functional. Decide how the controls behave at the first or last position, rather than leaving people to discover an unexplained dead end.
What the accessibility requirement actually asks
WCAG 2.2 criterion 2.5.7 requires a single-pointer way to perform dragging functionality without dragging, with exceptions for essential dragging and unmodified user-agent behaviour. Keyboard support alone is not enough: a touchscreen user may have no physical keyboard. Keyboard operation still needs checking as a separate requirement; our guide to navigation without a mouse explores that subject. Normal browser-controlled scrolling should not be confused with a custom dragging mechanism implemented by the website.
Test a completed task, not just an animation
Reorder three items using only short taps or clicks, with no held-button movement. Then repeat using a keyboard and a phone. Is the selected item clear? Can you identify its new location and correct a mistake? Do not reveal the alternative only on hover. Leave room between actions and check that buttons have meaningful accessible names. Our practical measure is whether the same goal can be reached through several understandable routes, not how many animations play. Passing this component-level exercise does not establish accessibility of the entire website.