A drag is four separate actions, not one. Tap or click to set a start point. Press and hold that contact. Move the pointer while still holding. Release at the end point. The middle two are where it comes apart, because holding a contact steady while moving it is a different skill from either holding or moving.
W3C names who that costs, and its list is more useful than the one people usually reach for. Somebody using a trackball, a head pointer, an eye-gaze system, or a speech-controlled mouse emulator. Those are the four devices in the standard's own words, and dragging is cumbersome and error-prone on every one of them.
So WCAG 2.2 added 2.5.7 Dragging Movements at Level AA. Where a function uses a dragging movement, there has to be a way to do the same thing with a single pointer and no drag.
What Counts as an Alternative
A single pointer means taps and clicks. A keyboard route does not satisfy this criterion, and that is stated rather than implied. The keyboard rules already require dragging features to be keyboard operable, at Level A and again with no exception at Level AAA, and W3C says achieving keyboard equivalence does not automatically meet this one unless the equivalent controls can also be clicked or tapped. The two are evaluated independently, so a team that adds arrow-key handling has satisfied a different rule and still fails this one.
Two freedoms in the criterion are worth knowing, because both make the design problem smaller than it looks.
- The alternative does not have to be the same control. W3C's own example is a color wheel where you drag an indicator, answered by numeric text fields for the color values somewhere else on the page. As long as the functionality is equivalent, it can live anywhere.
- A text input counts. Entering a precise value in a field beside a slider is an accepted single-pointer alternative, because a text field is device agnostic and a touch user gets an on-screen keyboard to fill it. That is the least obvious of the routes and often the cheapest.
One thing the alternative cannot be. Another gesture. A swipe or a flick replacing a drag fails 2.5.1 Pointer Gestures instead, so you have moved the finding rather than fixed it.
- Click to select, click to place. The pattern that generalizes best.
- Move buttons. Up, down, top, bottom on each item in a reorderable list. Unfashionable and completely effective, and the usual objection has a published answer. W3C says the buttons can be visible, as large arrow icons, or visually hidden and still operable with a pointer. So a design with no room for them still has a route.
- A destination menu. Tap the item, choose the column or list to move it to. This is the answer for a task board.
- A number field for position, which is the text-input route above.
- For a slider, let a click anywhere on the track move the thumb there. W3C names this first among its examples and it fixes an entire category in one line.
Our fix guides cover the alternatives to dragging, single-point slider activation, and the failure itself, which is the number an auditor writes.
The two exceptions
The rule does not apply where dragging is genuinely essential, such as drawing a freehand line, and it does not apply where the functionality is the browser's rather than yours. That second one is broader than most people expect. Scrolling by dragging a scrollbar, dragging the page on a touchscreen, drag to refresh, and a section made scrollable with CSS overflow are all outside the criterion, because the browser is doing the scrolling. Suppress the browser's scrolling and implement your own and you are back inside it. What is not an exception is a path carrying meaning. An interaction that is both a drag and a path-based gesture, such as a slider you lose your grip on if you stray off the track, can fail this criterion and the pointer gestures one at the same time.
The Keyboard Route as Well
Separate rule, separate work, and you owe both. Make each draggable item focusable, use Space or Enter to pick it up, arrow keys to move it, Space or Enter to drop it, and Escape to cancel.
Worth saying plainly where that pattern comes from, because a developer will go looking. There is no published W3C pattern for drag and drop. The Authoring Practices Guide covers thirty patterns and this is not one of them. The ARIA attributes somebody will find while searching, aria-grabbed and aria-dropeffect, were deprecated in ARIA 1.1 and are not recommended. So the keyboard model above is field convention rather than a specification, and knowing that is the difference between building it deliberately and assuming somebody already settled it.
Announce the move as it happens. Moved to position 3 of 8, through a live region, because without it the item silently changes place and nobody who cannot see it knows whether anything happened. That is 4.1.3 Status Messages, since it reports the result of an action and takes no focus.
Where Drag Interfaces Fail Most
- Kanban boards. Cards that can only be dragged between columns. A pop-up menu on each card offering move to, with the columns listed, is W3C's own worked answer.
- Reorderable lists. Priorities, playlists, form builders. Move buttons on each row, or a numeric position field.
- Sliders and range pickers. Often built drag-only, and the fix is one line. Let a click anywhere on the track move the thumb to that point. A text input beside it is the belt and braces.
- Carousels driven by a horizontal drag. W3C's own example, answered with forward and back buttons that may be visible arrows or visually hidden and still clickable.
- Map panning. A map you drag to move, with no directional buttons. Add up, down, left and right controls. Note that pinch to zoom on the same map is a multipoint gesture, so it belongs to 2.5.1 rather than to this criterion. Both need alternatives and they are different findings.
- File upload drop zones. Always give a visible button that opens the file picker rather than revealing one on hover. Whether the dragging criterion reaches this case is arguable, because the drag begins in the operating system rather than in your page, and the remedy is the same either way. The upload guide has the detail.
The Target Under Your Finger
Drag handles tend to be small, and small handles packed into a list run into 2.5.8 Target Size, which wants 24 by 24 CSS pixels. Before you redesign the list, know that the criterion has five exceptions and two of them regularly rescue exactly this case.
- Spacing. An undersized target passes if a 24-pixel-diameter circle centered on it does not intersect another target or another undersized target's circle. That is a geometry test rather than an allowance you add to the box, so two 20-pixel handles need 24 pixels between their centers rather than 4 pixels of margin.
- User agent control. A target whose size the browser decides and you have not modified is excepted, which covers the thumb of a native
rangeinput. - Equivalent. The same function reachable through a different control on the same page that does meet the size. Which is exactly what the move buttons you added above are.
There is one more pointer rule in the same neighborhood and it is usually cited in half. 2.5.2 Pointer Cancellation is satisfied by any one of four things, not only by firing on release. No action on the down-event, an abort or undo mechanism, a reversal on the up-event, or the down-event being essential. For a drag interaction the first one is impossible, because a drag begins with a press by definition, so the route that applies to you is abort or undo. Escape cancelling a drag in progress, and a way to put a dropped item back.