Status
This understanding document is part of the draft WCAG 2.2 content. It may change or be removed before the final WCAG 2.2 is published.
Intent
The intent of this Success Criterion is to ensure functionality that uses a dragging movement (e.g. sliders, drag-and-drop interfaces) has another single pointer mode of operation without the need for the dexterity required to drag elements.
Some people cannot perform dragging motions in a precise manner. Others use a specialized or adapted input device such as a head pointer, eye-gaze system, or speech-controlled mouse emulator, which makes dragging cumbersome, error-prone, or outright impossible.
When an interface implements functionality that uses dragging motions, some users can tap or click, but not accurately maintain contact whilst performing a dragging motion. An alternative method must be provided so that users with mobility impairments that use a pointer (mouse, pen, or touch contact) can use the functionality.
2.1.1 Keyboard and 2.1.3 Keyboard (No Exception) require dragging features to be keyboard accessible, however, it is possible to create an interface that works with dragging and keyboard controls that does not work using only clicks or taps.
A dragging movement is a pointer interaction where only the endpoints matter. Once the pointer engages with a target, the target (or a position mark related to the target) will follow the pointer regardless of the direction of the pointer movement. The target's movement may be constrained to one axis and often, to a particular range on that axis, but within those constraints, the x or y position of the target will mirror the corresponding x or y position of the pointer until the pointer disengages the target.
In contrast to dragging movements, path-based gestures involve at least an initial directionality of the pointer movement. This is defined by stating that the path has to go through at least one intermediate point to qualify as pointer gesture. The intermediate point defines the gesture as requiring a specific path, even if the complete path is not defined. For more details, refer to Understanding Success Criterion 2.5.1 Pointer Gestures.
Benefits
- Users who struggle with performing dragging motions can still operate an interface with a pointer interface.
Examples
- A sortable list of elements may, after focussing a list element, provide adjacent controls for moving the element up or down in the list by simply tapping/clicking on those controls.
- A kanban implementation may provide an additional pop-up menu for focused elements that can be activated by simple clicks/taps providing an option for moving the selected element to another kanban silo.
- A radial control widget where the value can be set by dragging includes a text field that presents the current value and offers the input of the desired value via a keyboard (including on-screen virtual keyboards).
- A map allows users to drag the view of the map around, and the map has up/down/left/right buttons to move the view as well.
Techniques
Each numbered item in this section represents a technique or combination of techniques that the WCAG Working Group deems sufficient for meeting this Success Criterion. However, it is not necessary to use these particular techniques. For information on using other techniques, see Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section.
Sufficient Techniques
Failures
The following are common mistakes that are considered failures of this Success Criterion by the WCAG Working Group.
Key Terms
an operation where the pointer engages with an element on the down event and the element (or a representation of its position) follows the pointer
The element could be, for example, a list item, a text element, or an image.
if removed, would fundamentally change the information or functionality of the content, and information and functionality cannot be achieved in another way that would conform