Understanding Success Criterion 2.5.7: Dragging Movements

Success Criterion 2.5.7 Dragging Movements (Level AA): 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.

This requirement applies to web content that interprets pointer actions (i.e. this does not apply to actions that are required to operate the user agent or assistive technology).

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 movements 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 movements, users perform four discrete actions:

  1. tap or click to establish a starting point, then
  2. press and hold that contact while...
  3. performing a repositioning of the pointer, before...
  4. releasing the pointer at the end point.

Not all users can accurately press and hold that contact while also repositioning the pointer. An alternative method must be provided so that users with mobility impairments who use a pointer (mouse, pen, or touch contact) can use the functionality.

Relationship to other requirements

Success Criteria 2.1.1 Keyboard and 2.1.3 Keyboard (No Exception) require dragging features to be keyboard accessible. However, achieving keyboard equivalence for a dragging operation does not automatically meet this Success Criterion; it is possible to create an interface that works with dragging and keyboard controls that does not work using only clicks or taps. While many designs can be created for a dragging alternative which address both keyboard accessibility and operability by single pointer operation, the two requirements should be assessed independently.

This Success Criterion applies to dragging movements as opposed to pointer gestures, which are covered in Success Criterion 2.5.1 Pointer Gestures. Pointer gestures include directional path-based as well as multi-point gestures. In contrast, for dragging movements, only the start and end point of the movement matters, not the actual path.

Additional examples are selection rectangles that set the first x/y rectangle coordinate at the pointer position via a pointer down-event, and the second x/y coordinate, after a dragging movement, at the next up-event. A similar example is a connecting line drawn between two different items on the screen, as in an allocation test where users are required to draw a line between questions and corresponding answers. In these cases, the dragging movement requires an alternative way to accomplish the same action that does not rely on the dragging movement. For example, two separate single tap or click actions may define the rectangle coordinates or the start and end points of a connecting line.

Alternatives for dragging movements on the same page

Where functionality can be executed via dragging movements and an equivalent option exists that allows for single-pointer access without dragging, this Success Criterion is passed. It does not have to be the same component, so long as the functionality is equivalent. An example is a color wheel where a color can be changed by dragging an indicator. In addition, text fields for the numerical input of color values allow the definition of a color without requiring dragging movements. (Note that a text input is considered device agnostic; although the purpose is to enter characters, text entry can take place through voice, pointer or keyboard.)

Distinguishing dragging movements from path-based pointer gestures

Dragging movements covered in this Success Criterion are pointer interactions where only the start- and endpoints matter. Once the pointer engages with a target, the direction of the dragging movement does not factor into the interaction until the pointer disengages the target. Since the dragging movement does not have an intermediate point, the dragging movement can go in any direction. Path-based gestures are covered in Success Criterion 2.5.1 Pointer Gestures. For more details, refer to Understanding Success Criterion 2.5.1 Pointer Gestures

Benefits

Examples

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

  1. G219: Ensuring that a single pointer alternative is available for dragging movements that operate on content

Failures

The following are common mistakes that are considered failures of this Success Criterion by the WCAG Working Group.

Key Terms

dragging movement

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 until an up event

Note

Examples of draggable elements include list items, text elements, and images.

essential

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

single pointer

pointer input that operates with one point of contact with the screen, including single taps and clicks, double-taps and clicks, long presses, and path-based gestures