Do not make dragging the only way to move things
The only way to move a card between columns, or to reorder a list, is to pick the thing up and drag it. F108 is the failure technique for that, and a match is a defect rather than an interaction pattern. Its scope is tighter than the word dragging suggests. The rule is about moving a target from one position to another, so drag-to-select and drag-to-draw belong to other rules. The alternative you build does not have to be a single click either. A sequence of ordinary clicks counts, which is exactly what a Move to menu is. And there is an exception. Where the dragging belongs to the browser rather than to you, as it does on a native range input you have not restyled, this rule does not reach it.
How we find it in an audit
A reviewer works every interaction with discrete clicks and taps, never holding the button down, and lists whatever cannot be completed that way. Each one gets a second question, which is whether some sequence of ordinary clicks reaches the same outcome. Kanban boards, reorderable lists, file drop zones and sliders are where this lives, and the drop zone usually passes already, because a browse button is sitting right next to it. Native controls get separated out, since the browser owns their dragging.
How affected users experience it
Dragging asks for press, hold, move accurately, release, all in one unbroken action, and plenty of people cannot produce that sequence. Switch users press and release, one input at a time. Eye-gaze users dwell on a point rather than travel between two. Someone with a tremor can start the drag and lose it halfway across. Screen-reader users get no feedback about where the item is being carried, so even a drag that works tells them nothing. A Move to menu answers all four at once.
Passes vs. fails
Passes
card.draggable = true;
<button aria-haspopup="menu">Move to...</button> <!-- the menu lists every column -->Fails
card.draggable = true; // dragging is the only way to change columnsThe other techniques filed under this rule
2 guides on this site are filed under 2.5.7 Dragging Movements. W3C documents this one as a failure of that rule, so it describes a way the rule gets broken rather than a way to pass it.
This guide is our interpretation of W3C technique F108: Failure of Success Criterion 2.5.7 Dragging Movements due to not providing a single pointer method that does not require a dragging movement. W3C publishes its techniques as guidance rather than as the standard, and says so on every one of them. The success criterion is what conformance is measured against, and a technique is one documented way to meet it.