WCAG 2.2 Dragging Movements: Giving Sliders and Sortable Lists a Tap Alternative

## The short answer

WCAG 2.2 success criterion **2.5.7 Dragging Movements** (AA) requires that any functionality operated by a **dragging movement** can also be operated by a **single pointer without dragging** - for example by tapping or clicking - unless the dragging is **essential** or the action is provided by the user agent and not modified by you. In practice this means sliders, sortable lists, drag-to-reorder, kanban boards, range selectors, swipe-to-delete, and map panning all need a click/tap-based alternative. The alternative does not have to be on screen permanently, but it must exist and be discoverable.

## Why dragging is a barrier

Dragging requires pressing, holding, moving precisely, and releasing - all in one continuous action. That is difficult or impossible for people with tremors, limited fine motor control, or who use a head pointer, switch device, or other assistive input. It is also awkward on a trackpad or a touchscreen for many people without disabilities. A single tap or click is far more forgiving.

Note that 2.5.7 is specifically about the **dragging** path. It does not on its own require keyboard operability - that is covered by the long-standing 2.1.1 Keyboard criterion. A complete solution usually provides both a pointer alternative (for 2.5.7) and keyboard operation (for 2.1.1).

## What "essential" means

The exception for essential dragging is narrow. Dragging is essential when the path of the movement is itself the point - for example drawing a freehand signature, or a digital painting tool where the brush stroke carries meaning. Reordering a list is **not** essential, because the outcome (a new order) can be achieved another way. Adjusting a slider value is not essential, because the value can be set by other controls. Treat "essential" as the rare exception, not a default escape hatch.

## Patterns and how to give them an alternative

- **Sliders / range inputs**: Provide buttons (increment / decrement) or a number input, in addition to the draggable thumb. Native `input[type=range]` is keyboard operable by default; custom sliders need explicit alternatives.

- **Drag-to-reorder lists**: Add up/down buttons on each item, or a 'move to position' control. The drag handle stays, but it is no longer the only way.

- **Kanban boards**: Offer a menu on each card to move it to another column.

- **Swipe-to-delete / swipe actions**: Provide a visible delete or action button, not only the swipe.

- **Map panning and zoom**: Provide pan arrows and zoom buttons alongside drag-to-pan.

- **Drag-to-resize panels**: Offer preset size buttons or a numeric width control.

- **File drag-and-drop upload**: Always pair the drop zone with a normal 'choose file' button (this is a classic, and many teams already do it).

## Discoverability matters

An alternative that nobody can find does not help. The single-pointer alternative should be visible, or revealed by an obvious, single-pointer action such as opening a menu. Hiding the only alternative behind another drag gesture defeats the purpose. Where space is tight, a per-item overflow menu is a reliable container for move and reorder actions.

## Common failure patterns

- Custom sliders with no buttons or numeric entry - drag is the only way to change the value.

- Reorderable lists where the drag handle is the sole reordering mechanism.

- Image comparison sliders operable only by dragging the divider.

- Carousels advanced only by swiping, with no next/previous buttons.

- Signature fields that are genuinely essential but offer no typed-name fallback where one would be acceptable.

## Testing it

- For every draggable element, try to achieve the same result using only single clicks or taps. If you cannot, you have a gap.

- Separately, try keyboard-only operation to satisfy 2.1.1.

- On touch devices, confirm tap-based alternatives are reachable with one finger and no sustained press.

- Review whether each "essential" claim truly holds - most do not.

## Building it in

Drag interactions are usually built once as shared components - a sortable list, a slider, a board. That is the right place to add the alternative, so every consumer of the component inherits it. When we build enterprise-grade products at neart.ai, our reorder and slider primitives ship with buttons and keyboard support as standard, so a feature team using them cannot accidentally ship a drag-only control. Retrofitting alternatives onto bespoke per-feature drag code is far more expensive than getting the shared component right.

## Practical takeaway

Go through every drag interaction in your product and ensure the same outcome is reachable by tapping or clicking, with the alternative discoverable rather than buried. Reserve the 'essential' exception for cases where the movement path itself is the content, like freehand drawing, and put the alternatives inside your shared slider, reorder and board components so they are inherited everywhere.