Dragging movements: WCAG 2.5.7 explained

WCAG 2.2 success criterion 2.5.7, Dragging Movements, says that anything you can do by dragging must also work with a single pointer without dragging, such as a click or a tap.

There are two exceptions: dragging that is essential, and dragging that the browser itself provides and the page has not changed. It is a Level AA criterion, new in WCAG 2.2.

Our checklist has a failing and a passing example for 2.5.7.

What 2.5.7 requires

In full, the criterion reads: “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.”

A dragging movement, in the W3C’s words, is one where “the element (or a representation of its position) follows the pointer until an up-event”: you press on something, move while holding it, and let go at the end point. The direction does not matter.

Some people cannot drag precisely, or cannot hold a button down while they move. Others use a trackball, a head pointer, an eye-gaze system or a speech-controlled mouse emulator, which makes dragging cumbersome and error-prone. A click or a tap at the start and the end works for them.

Two things fall outside the criterion: actions needed to operate the browser or assistive technology, and scrolling or dragging the browser provides itself, such as dragging a scrollbar or scrolling an area with CSS overflow. If the page blocks the browser’s own scrolling, or builds its own, the criterion applies to it. See 2.5.7 among the other WCAG 2.2 additions.

Keyboard support is not enough

A common wrong assumption is that a keyboard alternative meets 2.5.7. The W3C says “achieving keyboard equivalence for a dragging operation does not automatically meet this success criterion”, unless the keyboard alternative’s controls can also be clicked or tapped. Keyboard access and pointer access are separate requirements, evaluated independently: someone on a touch screen may not use a physical keyboard.

A sortable list you can reorder with the arrow keys passes 2.1.1 Keyboard, but someone using a head pointer still has to drag. The alternative has to work with a single pointer: buttons, a menu, or a click on the destination. An alternative that relies only on a swipe does not count either: a swipe is a path-based gesture, and relying on it would fail 2.5.1 Pointer Gestures.

2.5.7, 2.5.1 and 2.1.1

A swipe that has to be fast and roughly straight is a path-based gesture, under 2.5.1. Dragging a card anywhere on a board is a dragging movement, under 2.5.7. One component can fall under all three.

Three components, fixed

Sortable list

<ul class="sortable">  <li draggable="true">Delivery</li>  <li draggable="true">Payment</li>  <li draggable="true">Review</li></ul>

<li>  Delivery  <button type="button"          aria-label="Move Delivery up">    Up  </button>  <button type="button"          aria-label="Move Delivery down">    Down  </button></li><!-- each item: buttons named for it -->

Dragging can stay for people who like it; the buttons are the single-pointer way to do the same thing. Each button’s name says which item it moves. Keep both buttons on every item and keep focus on the pressed button after the move; at the top or bottom of the list a button can do nothing, or say the item is already first. If you remove or disable a button instead, move focus to the other one first, or focus can be lost. Announcing the new position helps screen-reader users know the move worked.

Each of these buttons, and each alternative below, is a target in its own right, so it also needs to be at least 24 by 24 CSS pixels, or spaced well.

Range slider

A custom slider whose value only changes when you drag its thumb fails. The W3C’s example of a fix is letting a click or tap anywhere on the track move the thumb to that point. Here bar is the track, thumb the handle, min the lowest value and range the size of the range, and update() sets the value, rounded to the slider’s step, and moves the thumb:

bar.addEventListener("click", (e) => {  if (thumb.contains(e.target)) return;  const r = bar.getBoundingClientRect();  const left = e.clientX - r.left;  const x = Math.min(1, Math.max(0,    left / r.width));  update(min + x * range);});

A number field next to the slider, or buttons that step the value up and down, also give a single-pointer way to set it. The track itself is a target, so it needs enough height, and a custom slider still needs a slider role, its values and keyboard support for the other criteria.

Map

<div role="group" aria-label="Pan map">  <button type="button">North</button>  <button type="button">West</button>  <button type="button">East</button>  <button type="button">South</button></div>

Without such buttons, a map that only pans by dragging fails. If the map zooms by pinching or by dragging a box, add zoom in and zoom out buttons too, and moving a marker or drawing a shape needs its own alternative. The same idea fixes a kanban board (select a card, then a “Move to” button or menu) and a colour picker (click a point, or type the value).

How to test it

1. List every interaction on the page that uses a drag: reordering, sliders, maps, carousels, drawing, file drop zones (check for a Browse button) and custom resizable panels (a CSS resize handle is the browser’s own).
2. For each, use a mouse, then a touch screen, without the keyboard, and try to do the same thing with clicks or taps alone. Look for alternatives that appear only on hover or after selecting an item.
3. Check that the alternative needs no swipe, no press-and-move and no precise path.
4. Check that the result is the same: the same order, the same value, the same view.

Automated tools cannot tell you whether a single-pointer alternative exists. A tool can find draggable elements, and through the browser’s debugging interface, drag and pointer listeners, but deciding whether another control does the same job needs a person.