Dragging Movements
This criterion is new in WCAG 2.2. Anything achieved by dragging has to be achievable with a single pointer that does not drag. A dragging movement has four parts. You establish a start point, you press and hold, you move the pointer somewhere else, and you release. Once you have hold of the thing, the route between the two ends does not matter here, and that is the main difference from 2.5.1, where the path is the point. One interaction can be both, though. A slider that drops your grip the moment you stray off its track is a drag and a path-based gesture at once, and W3C says plainly that it can fail both rules together. Two exceptions apply. Dragging that is genuinely essential is out of scope, and so is any dragging the browser provides that you have not modified, which takes ordinary scrolling, scrollbars, pull-to-refresh and overflow containers out entirely. Suppress the browser's own scrolling and write your own, and it all comes straight back in.
Why it matters
Dragging asks a person to press, hold, move and release without slipping once, and to keep that up for the length of the movement. For somebody with a tremor, limited strength or fatigue, it is the hardest common interaction on the web. Somebody using a trackball, a head pointer, an eye-gaze system or a speech-controlled mouse emulator has a harder time still, because holding a press while travelling is exactly what those devices are worst at. The rule does not ban dragging. It says the same result has to be reachable the easy way too, and W3C's own answer to the objection is that the easy way can be a few taps in a row rather than a whole second interface.
Who this rule protects
This affects people with limited dexterity, tremors or fatigue-related conditions, people using a trackball, head pointer, eye-gaze system or speech-controlled mouse emulator, and anyone using a site one-handed on a moving train.
How to check it yourself
- Inventory every drag interaction, including sliders, sortable lists, kanban boards, colour pickers, selection rectangles and anything you pan.
- Rule out the browser's own dragging first. A panel that scrolls because of CSS overflow is the browser's job rather than yours.
- Do the same job with taps only. The alternative can be a sequence, such as tapping the item, opening a menu and choosing a destination, and it counts as long as no step is a drag.
- Check the alternative is not a swipe. Replacing a drag with a flick moves the failure to 2.5.1.
- Look elsewhere on the page before raising a finding. The alternative does not have to be the same component, so numeric fields beside a colour wheel are a valid answer for the colour wheel.
Failures we see most often
- A price range set only by dragging two small handles to exact positions.
- Kanban cards that move between columns only by drag and drop, with no menu and no arrow buttons.
- A sortable list where the only way to reorder is to pick an item up and put it down somewhere else.
- A custom scroll implementation that replaces the browser's own, which pulls panning and swiping back inside a rule that native scrolling sits outside.
Who this one is for
Read from this rule's own note above, so the grouping and the note cannot disagree.
- Motor and keyboard-onlypeople who cannot use a mouse, or cannot use one precisely
- Voice controlpeople who operate the page by speaking to it
How to fix it
- Make the slider track tappable. Tapping a point on the track moves the thumb there, and it is the cheapest fix in this rule.
- Pair sliders with numeric fields as well. Typing counts as a single-pointer alternative, because the on-screen keyboard that appears on a touchscreen is itself operated by pointer.
- For an ordered list, put an editable position number beside each item. Type 3 and the list reorders, which is faster than dragging for everybody.
- For a board, offer a 'Move to' menu after a single tap on the card. The arrows or the menu do not have to be visible until the item is selected, so the resting design stays clean.
- For a radial or circular control, let a tap anywhere on the dial set the value. That is the same shape of answer as the tappable track, and it discharges 2.5.1 at the same time for a control that enforces its path.
Step-by-step fix guides (2)
Passes vs. fails
Passes
Min and max fields sit beside the slider and the track takes a tap, so 50 to 100 takes seconds either way.
Fails
Filtering by price means dragging two tiny handles to exact positions on a track.
In audits and lawsuits
This is a WCAG 2.2 addition, so it is missing from every conformance claim written against 2.1, and no automated rule exists for it. A fast way to find what is in scope is to search the stylesheets for touch-action, because content that has claimed a gesture from the browser has almost always set it. Price sliders on filter panels are the finding we raise most often. Two boundaries are worth settling before an argument starts. Keyboard support does not satisfy this rule, because the people it protects are often on a touchscreen with no keyboard in reach. And a file drop zone is a separate question, since the drag starts in the operating system rather than on your page, and W3C publishes no example putting it inside this rule. Give it a Browse button regardless, because a keyboard user cannot drag a file in and 2.1.1 has already asked for one.