Dragging movements require users to press, hold, move, and release a pointer in a continuous action. For many users, this combination of sustained contact and precise movement is difficult or impossible. As a result, interfaces that rely solely on dragging can block users from completing essential tasks.
WCAG 2.5.7 ensures that dragging is not a mandatory interaction.
What Is a Dragging Movement
A dragging movement is a pointer interaction where the user:
- Activates a target (pointer down),
- Maintains contact while moving the pointer, and
- Releases the pointer to complete the action.
For the purposes of this success criterion, only the start point and end point matter.
If an interaction depends on a specific path or direction, it is not considered a dragging movement and is instead covered by SC 2.5.1 Pointer Gestures.
WCAG Success Criterion
2.5.7 Dragging Movements (Level AA)
All functionality that uses a dragging movement for operation can be achieved without dragging, unless:
- Dragging is essential, or
- The functionality is determined by the user agent and not modified by the author.
Note:
This requirement applies only to author-provided content that interprets pointer actions. It does not apply to interactions required to operate the user agent or assistive technologies.
Intent of the Success Criterion
This criterion intends to ensure that functionality implemented using dragging movements can also be operated without requiring press-and-hold pointer movement.
Some users:
- Cannot maintain steady pressure while moving a pointer
- Use alternative pointing devices such as trackballs, head pointers, or eye-gaze systems
- Find dragging slow, fatiguing, or error-prone
These users must still be able to perform the same actions using simpler interactions.
Why Dragging Is a Barrier
Dragging requires four coordinated actions:
- Accurate pointer placement
- Sustained contact
- Continuous movement
- Timed release
Many users cannot reliably perform all four steps. Even small interruptions can cause the action to fail or behave unpredictably.
This criterion prevents dragging from being the only way to complete an action.
What This Criterion Requires
If functionality can be performed using a dragging movement, users must also be able to perform the same functionality without dragging.
Acceptable alternatives include:
- Tap or click controls
- Increment/decrement buttons
- Menus or dialogues
- Selecting a destination instead of dragging to it
- Text input fields for precise values
The alternative does not need to be the same component, but it must be:
- Functionally equivalent
- Discoverable
- Operable without dragging or complex gestures
Providing a hidden or hard-to-find alternative does not satisfy the intent of the criterion.
Dragging vs Keyboard Access
This requirement is separate from keyboard accessibility.
Providing keyboard controls alone does not satisfy this criterion because:
- Many touch-screen users do not use a physical keyboard
- Keyboard interaction may not be available or discoverable in mobile contexts
A non-dragging alternative must exist for pointer users, regardless of keyboard support.
Dragging vs Pointer Gestures
Dragging movements covered by this criterion:
- Depend only on start and end points
- Do not require a specific direction or path
Pointer gestures (SC 2.5.1):
- Require directional movement, specific paths, or multiple points
These are distinct interaction types and must be evaluated independently.
User Agent–Controlled Dragging
This criterion does not apply to dragging behaviours implemented entirely by the user agent, such as:
- Scrolling a page
- Scrolling content using native browser behaviour
If authors implement custom dragging logic, the requirement applies.
Common Failure Patterns
In practice, failures most often occur in:
- Sortable lists
- Sliders and range controls
- Task boards and kanban interfaces
- Custom canvas-based interactions
These failures are usually accidental, caused by custom input handling that assumes dragging is universally usable.
Common Failures of SC 2.5.7
Drag-only reordering
Items can only be reordered by dragging with no alternative controls.
Drag-only sliders
Values can only be set by dragging the thumb.
Canvas-based interactions with no fallback
Dragging is required to connect, allocate, or select items.
These fail because the functionality cannot be completed without dragging.
Essential Dragging Exception
Dragging is allowed when it is essential to the activity.
Examples:
- Free-form drawing or sketching
- Signature input
- Activities where dragging itself is the purpose
This exception is narrow and should not be applied for convenience or visual preference.
Relationship to Other WCAG Criteria
- 2.1.1 Keyboard and 2.1.3 Keyboard (No Exception) require keyboard access
- 2.5.1 Pointer Gestures covers path-based and multi-point gestures
Passing those criteria does not automatically satisfy 2.5.7.
How to Test for Dragging Dependence
- Attempt to complete the task using only taps or clicks
- Look for visible controls that replace dragging
- Verify the task can be completed without press-and-hold interaction
- Confirm the alternative is discoverable without instructions
If dragging is required to complete the task, the criterion is not met.
Benefits
This success criterion benefits:
- Users with limited motor control
- Users of alternative pointing devices
- Touch-screen users who struggle with press-and-hold interactions
- Users who find dragging tiring or error-prone
Wrapping Up
WCAG 2.5.7 ensures that dragging movements are optional, not mandatory. If users can perform an action by dragging, they must also be able to perform it without dragging, using simpler pointer interactions.
Most failures occur unintentionally in custom components. Designing with clear, discoverable alternatives prevents exclusion and improves reliability for all users.
