If your Monthly Audit report flagged a Dragging Movement issue, it means your website includes features that require users to click, hold, and move a pointer to complete an action. Dragging can be difficult or impossible for many people. WCAG 2.2 requires an equivalent option that works with a simple click or tap.

This issue can’t be fixed automatically by accessWidget, but there are clear ways your team can address it.

What is Dragging Movements?

WCAG 2.2 introduced Level AA success criterion 2.5.7 Dragging Movements.

In short:

If an action on your site requires dragging (drag and drop, sliding, scrubbing, etc.), users must also be able to perform the same action with a simple single-pointer operation (for example, a single click or tap) without dragging, unless dragging is essential or controlled entirely by the browser or operating system.

This criterion is closely related to, but distinct from:

• 2.5.1 Pointer Gestures (Level A): Focused on complex gestures (pinch, multi-finger, path-based).
• 2.1.1 Keyboard / 2.1.3 Keyboard (No Exception): Focused on keyboard operation for all functionality.

Why it matters

Dragging may seem simple, but it can be a barrier for:

• Users with motor impairments who can’t easily click, hold, move, and release at the right spot.
• Users on small touch screens who lose precision when dragging.
• Users of switch / alternative input devices that don’t support continuous dragging.
• Low-vision users who zoom in and lose the full context of the drag path.

From a legal/compliance perspective, 2.5.7 is Level AA, and part of the standard expectations when conforming to WCAG 2.2 AA.

Where this shows up on websites

Dragging movements commonly appear in:

• Sliders and range controls: Volume, brightness, price range, rating sliders, media scrubbers
• Carousels / content sliders: Swipe/drag only carousels that don’t provide buttons
• Drag-and-drop interfaces: Reordering lists, Kanban boards, file uploads
• Interactive maps or canvases: Drag to pan, drag to select a region

Any interaction that requires holding down the pointer and moving it to complete an action falls under this criterion.

What the guidelines require

If an action can only be completed by dragging, provide a way to complete it with a simple pointer action that doesn’t involve continuous movement.

Exceptions:

• Dragging is essential to the activity (e.g., free-hand drawing), or
• The behavior is fully controlled by the user agent (for example, the browser’s native scrolling).

Technical implications:

• Actions must be doable via discrete clicks/taps, not only via continuous drag.
• Controls must still meet keyboard and ARIA requirements (focusable, keyboard operable, correct roles and properties). 
• For sliders:
  • Use role="slider" (or native <input type="range">),
  • Include aria-valuemin, aria-valuemax, aria-valuenow,and aria-valuetext when needed,
  • Support arrow keys, Page Up/Down, Home/End for keyboard control.

How you can mitigate Dragging Movement issues

1. Identify components that rely on dragging

Ask your dev/design team to review any features that rely on dragging:

• Sliders (volume, price, ratings, timelines)
• Carousels / image sliders
• Drag-and-drop lists or cards
• Custom map or canvas interactions

Each must have a non-drag alternative.

2. Provide simple pointer alternatives

Sliders and ranges

• Add +/- buttons next to the slider thumb to adjust the value in defined steps (e.g., +-1 or +-5).
• Allow clicking/tapping the track to jump or move the thumb to that position.
• Provide an editable numeric input linked to the slider (users can type an exact value instead of dragging).

Carousels and content sliders

• Add Next / Previous buttons that:
  • are keyboard-focusable
  • can be activated with Enter/Space
  • work with a single click/tap instead of requiring swipe/drag
• Announce slide changes (via ARIA) if critical to context.

Drag-and-drop lists

• Add Move Up / Move Down buttons for each item.
• Add a ‘Move to position’ menu or dialog where users can choose the new index or section.

Maps & canvases

• Add pan controls (arrow buttons).
• Offer search and ‘go to location’ options instead of requiring drag to reach an area.

3. Make alternatives visible for critical tasks

If the action is essential to the user journey (checkout flow, core product actions), the non-drag option should be clearly visible and equally functional, not hidden.

Developer guidance

• Use native controls where possible (e.g. <input type="range">). They often have keyboard and pointer behavior built in.
• When building custom sliders, follow the WAI-ARIA Slider Pattern and examples:
  • WAI-ARIA Authoring Practices: Slider Pattern and examples (color picker, temperature, rating, media seek sliders). 
• Ensure:
  • The thumb is focusable.
  • The slider responds to keyboard events (arrow keys, Page Up/Down, Home/End).
  • Pointer events support both dragging and simple clicks/taps (e.g., clicking the track changes the value).
  • Values are exposed via ARIA (aria-valuemin/max/now, optional aria-valuetext for human-friendly labels).
• Test with:
  • Keyboard only navigation
  • Screen readers
  • Touch devices using assistive technology like VoiceOver, TalkBack