Dragging Movements (WCAG 2.2)

Dragging Movements is a WCAG 2.2 success criterion (2.5.7) at Level AA that requires all functionality operated through dragging to also be achievable through a single-pointer alternative that does not require dragging. Dragging involves pressing and holding a pointer while moving it to a new position, a complex motor action that many users cannot perform. This criterion was introduced in WCAG 2.2, published in October 2023, to address a significant gap in the previous guidelines. While WCAG 2.1 addressed some pointer input issues (like multipoint gestures in 2.5.1), it did not specifically address dragging. Drag-and-drop interfaces had become common on the web, from reorderable lists and Kanban boards to image croppers and layout editors, creating barriers for users who cannot execute drag operations. The criterion does not prohibit drag interactions. It requires that an alternative method exists. Dragging can remain available for users who prefer it, but everyone must be able to accomplish the same task through simpler pointer actions like clicks, taps, or single-point gestures.

Dragging is one of the most physically demanding pointer interactions. It requires pressing down, maintaining pressure while moving the pointer potentially across a significant distance, and then releasing at a precise location. This compound action is impossible or extremely difficult for several user groups. People with tremors or involuntary movements struggle to maintain the steady, continuous motion dragging requires. People with limited grip strength may be unable to sustain the press-and-hold action. People using head pointers, mouth sticks, or eye-tracking systems typically cannot perform drag operations at all. People using switch access or voice control may have no mechanism for dragging. People with certain forms of arthritis find the sustained press-and-move action painful. Drag-and-drop interfaces have proliferated across web applications. Project management tools use drag to reorder tasks. E-commerce sites use drag to rearrange wishlists. Content management systems use drag to build page layouts. File managers use drag to organize documents. Without alternatives, all of these tools exclude significant user populations.

The core requirement is simple: for every drag-based interaction, provide an equivalent non-drag interaction. The specific alternative depends on the type of drag interaction: **Reorderable lists (drag to sort):** Provide up/down arrow buttons for each item, or a number input to set position: ```html <li> <span>Task: Review proposal</span> <button aria-label="Move Review proposal up">&#9650;</button> <button aria-label="Move Review proposal down">&#9660;</button> </li> ``` **Slider controls (drag to set value):** Ensure the slider can be operated with arrow keys (native `<input type="range">` does this) and optionally provide a text input for direct value entry: ```html <label for="brightness">Brightness</label> <input type="range" id="brightness" min="0" max="100" value="50"> <input type="number" id="brightness-value" min="0" max="100" value="50" aria-label="Brightness value"> ``` **Kanban boards (drag to move between columns):** Provide a dropdown menu or action buttons that allow moving an item to a different column: ```html <div class="card"> <h3>Design review</h3> <select aria-label="Move card to column"> <option>To Do</option> <option selected>In Progress</option> <option>Done</option> </select> </div> ``` **Image cropping (drag to select region):** Provide text inputs for crop dimensions and position, or use handles that can be repositioned with keyboard arrow keys. **File or item rearrangement (drag to reorganize):** Provide a selection mechanism and a "Move to" action, or numbered position inputs. **Exceptions to the criterion:** - **Essential dragging.** Activities where the dragging path itself is the function, such as freeform drawing, signature capture, or painting, are exempt. The act of dragging is not merely a means to an end; it is the end itself. - **User agent controlled.** Functionality determined entirely by the browser, not modified by the author, is exempt. **Implementation best practices:** - Design the non-dragging alternative as a first-class feature, not an afterthought. It should be equally discoverable and efficient. - Ensure the alternative provides the same capabilities. If dragging allows precise positioning, the alternative should too. - Keyboard accessibility is related but distinct. A keyboard alternative (using arrow keys) satisfies keyboard accessibility requirements, while a click-based alternative satisfies the dragging movements criterion. Ideally, provide both. - Test with pointer-only input (no keyboard) to verify the non-dragging alternative works through click/tap alone.