2.5.7 Dragging Movements
- Level AA
- Operable
- New in WCAG 2.2
Summary
Dragging is one of the hardest pointer actions there is: press down, hold, move with precision, release at exactly the right spot. For people with tremors, limited dexterity or strength, or those using a head pointer, eye tracker, or certain switch setups, sustaining that sequence is somewhere between exhausting and impossible. This criterion requires that anything operated by dragging (sliders, reorderable lists, kanban boards, map panning, swipe actions, colour pickers, split-pane resizers) can also be operated with simple single-pointer actions such as taps or clicks.
The requirement is new in WCAG 2.2 at Level AA. The dragging interaction itself can stay; users who can drag should keep the fluid experience. What must exist alongside it is a non-dragging path to the same outcome. Only two exceptions apply: dragging that is essential to the function (a signature field, a freehand drawing canvas), and behaviour determined by the user agent rather than the author. Both are narrow, and most audit disputes turn on stretching "essential" further than it goes.
Official wording
All functionality that uses a dragging movement for operation can be achieved by a single pointer without dragging, unless dragging is essential or the functionality is determined by the user agent and not modified by the author.
EN 301 549 mapping
This success criterion is new in WCAG 2.2. EN 301 549 V3.2.1, the harmonised European standard currently in force, references WCAG 2.1 and contains no clause for it. A revision aligned with WCAG 2.2 is in progress; until it is published and cited in the Official Journal of the EU, this criterion is not part of the harmonised standard.
Checked against EN 301 549 V3.2.1 (2021-03).
In practice
Web
Start with an inventory: walk each page and list every interaction that requires press-move-release. Sliders and range inputs, sortable lists and grids, kanban and file-upload drop zones, drawing or cropping tools, resizable panels, carousels operated by swipe, and custom colour pickers are the usual suspects.
For each one, look for a single-pointer alternative that reaches the same result. Acceptable patterns include plus and minus steppers or a text input beside a slider, up and down buttons on list items instead of drag-to-reorder, a "move to" or "send to column" menu on a kanban card, click-to-place instead of drag-and-drop for file targets, and next and previous buttons on a swipeable carousel. Clicking a point on a slider track also counts, but only if every value the drag can reach is reachable by clicking; a track that snaps to five coarse positions is not an alternative to a drag that selects one of a hundred.
The classic auditor trap: keyboard support does not satisfy this criterion. 2.5.7 sits in the pointer accessible guideline and asks for a single pointer alternative. A slider you can nudge with arrow keys but can only operate by dragging with a mouse or finger still fails. Verify the alternative with the pointer alone, keyboard untouched.
iOS
Swipe-to-delete on table rows is the headline case. The swipe itself is a dragging movement, so there must be another single-pointer route to the same action: an edit mode that exposes delete buttons, a visible button in the row, or an action available from a detail screen all count. The standard swipe actions are also operable through VoiceOver's actions rotor, which is valuable, but assistive-technology operability is not what this criterion asks for; a sighted pointer user who cannot drag needs a tap path too.
Reorder handles in edit mode are a common failure: if long-press-and-drag is the only way to change an item's position, the screen fails. Provide move up and move down actions, or a "move to position" affordance. Sliders (UISlider and custom equivalents) need tap-on-track support or accompanying steppers. Custom gestures built on pan recognisers (drag-to-dismiss sheets, drag-to-archive) each need a tappable equivalent, which usually already exists as a close button or menu item; the audit job is confirming it does.
Maps are settled, not a judgement call: the W3C's understanding material uses a map as its worked example, panning by drag paired with up, down, left, and right buttons that move the view. A draggable map with no button, search, or tap-based route to the same locations fails. The essential exception does not rescue free map exploration.
Android
The same inventory approach applies: swipe gestures on list items (swipe-to-dismiss, swipe-to-archive), drag handles in reorderable RecyclerView or Compose lists, and sliders all need single-pointer alternatives such as overflow-menu actions, move up and move down options, or steppers and direct value entry.
Bottom sheets are a distinctive Android case. A sheet that only expands or collapses by dragging its handle fails; a sheet whose handle or header also responds to a tap (tap to expand, tap to collapse) passes. Material bottom sheet components support tap-to-toggle states, but custom implementations frequently drop it, so test with taps rather than trusting the component name.
Pull-to-refresh is the judgement call auditors face most often. The gesture is a drag, but in most apps the same content refreshes through other routes: navigating away and back, an explicit refresh action in a menu, or automatic refresh on resume. Where a genuine alternative exists, the screen passes. Where pulling is the only way to load new content and the gesture is author-implemented rather than platform-provided, treat it as a failure and recommend a refresh button. The boundary comes from the W3C's own scoping, which excludes only gestures "enabled by the user agent": an author-wired gesture sits on the author's side of that line.
Pass and fail examples
Passes:
- A price range slider with plus and minus steppers and a numeric input beside each thumb: full single-pointer alternative.
- A kanban card that can be dragged between columns but also offers a "move to column" option in its menu.
- A swipe-to-delete row that also exposes a delete button in edit mode.
- A carousel that swipes but also has next and previous buttons reaching every slide.
- A bottom sheet whose header toggles between expanded and collapsed on a tap.
Fails:
- A sortable list where long-press-and-drag is the only way to reorder items.
- A volume slider that only responds to dragging the thumb, with no tap-on-track, steppers, or value entry.
- A file-upload area that accepts drag-and-drop only, with no browse button.
- A custom colour picker where the only way to choose a hue is dragging a marker around a wheel.
Not a fail under this criterion:
- A signature capture field: dragging is essential to producing a signature, so the exception applies.
- A freehand drawing or annotation canvas: the dragging is the function.
- Scrolling a page or list: scrolling is not "functionality that uses a dragging movement" in the sense of this criterion; it is user-agent behaviour, and swipe-scrolling content does not need a button alternative here.
- A drag interaction that is hard to perform because the handle is tiny: that is a target size question, not a dragging one (see below).
Commonly confused with
- Pointer Gestures, SC 2.5.1. 2.5.1 covers path-based and multipoint gestures (pinch to zoom, two-finger swipes, gestures that must follow a path); 2.5.7 covers dragging specifically. They often co-occur on the same component, but the evidence differs: 2.5.1 asks whether the gesture is complex, 2.5.7 asks whether the drag has a non-dragging alternative. A simple straight drag can pass 2.5.1 and still fail 2.5.7.
- Keyboard, SC 2.1.1. Making a drag interaction keyboard operable satisfies 2.1.1 and is required in its own right, but it does not satisfy 2.5.7. This criterion protects pointer users who cannot drag, so the alternative must itself be a single-pointer action.
- Target Size (Minimum), SC 2.5.8. Small drag handles and the small buttons you add as alternatives are both targets, so screens reviewed under 2.5.7 frequently earn separate findings under 2.5.8 Target Size (Minimum). Grade the two independently: one is about whether dragging is required, the other about whether the thing you press is big enough.
How AUDITSU tests this
AUDITSU's audit walkthrough includes dragging movements in its interaction checks for every screen you review. The walkthrough asks you to inventory each drag-operated interaction on the screen, then verify with a pointer alone that a single-pointer alternative reaches the same result, recording where the essential exception genuinely applies. Each question records a pass, fail, or not applicable result per screen, with the evidence attached, so the finding lands in your report tied to the exact screen and interaction.
Because EN 301 549 V3.2.1 does not yet include this criterion, AUDITSU tracks it under WCAG 2.2 conformance. When your audit targets the European Accessibility Act, the walkthrough treats 2.5.7 as forward guidance until the revised harmonised standard adopts WCAG 2.2.
For the full guided workflow, see the audit platform.