WCAG 2.5.7: Dragging Movements

What This Rule Means

WCAG 2.5.7 — Dragging Movements (Level AA, introduced in WCAG 2.2) states that all functionality that uses a dragging movement for operation must be achievable through a single pointer action without dragging, except where the dragging movement is essential to the functionality and no alternative mechanism exists.

A dragging movement is defined as an interaction where the pointer is pressed, held, and moved to a new position before being released. Common examples include: sorting list items by drag-and-drop, resizing panels by dragging a splitter handle, using a slider by grabbing and pulling the thumb, drawing on a canvas, and reordering kanban cards. All of these patterns must have an equivalent single-pointer alternative — a mechanism the user can activate without needing to keep the pointer button held while moving.

The single pointer constraint is important. The alternative does not need to be a keyboard shortcut; it can be a mouse click, a tap, or any other action that involves only one point of contact and does not require sustained movement while pressed. For example, a slider that lets users click directly on the track to jump to a value satisfies the criterion because clicking the track is a single-pointer action with no dragging.

What counts as a pass: A draggable list that also offers up/down arrow buttons or a move-to-position dialog; a range slider that accepts clicks anywhere on the track; a resizable panel that also has a numeric input or double-click-to-collapse affordance; a map that can be panned by clicking navigation arrows as well as by dragging.

What counts as a fail: A sortable list where the only way to reorder items is to drag them; a split-pane resizer with no alternative affordance; a file upload that only accepts drag-and-drop with no button fallback; a color picker where the only way to select a hue is to drag across a gradient strip with no numeric or text input alternative.

Official exception: The criterion explicitly allows dragging-only interfaces when dragging is essential — meaning removing it would fundamentally change or invalidate the activity. A gesture-drawing application or a signature-capture widget is a canonical example. However, this exception is intentionally narrow; most everyday UI patterns (sliders, sortable lists, resizable columns) are not considered essential-dragging scenarios.

Why It Matters

Motor impairments affect a significant portion of the global population. According to the World Health Organization, over 1.3 billion people worldwide — roughly 16% of the global population — live with some form of disability, and motor or physical impairments are among the most common categories. Conditions such as essential tremor, Parkinson's disease, repetitive strain injury, hemiplegia, spinal cord injuries, and limb differences all make it difficult or impossible to hold a pointer button down while simultaneously moving the pointer with accuracy.

For a user with hand tremors, dragging a slider thumb from one end of a track to the other is not just inconvenient — it can be entirely unreliable. The pointer may slip, the drag may be cancelled mid-operation, or the precision required simply exceeds what tremor-affected hands can deliver. These users often rely on click-based alternatives, keyboard navigation, or switch access devices. If the only path to a feature is a drag gesture, the entire feature is effectively inaccessible to them.

Concrete scenario: Consider an e-commerce product page with a price-range filter implemented as a dual-handle range slider. A user with limited fine motor control tries to narrow the price range but cannot reliably drag either handle to the target position — the pointer drifts, the handle snaps to wrong values, and the frustration causes them to abandon the task. If the same filter exposed a pair of numeric text inputs alongside the slider, that user could simply type the desired minimum and maximum prices and submit. That single addition transforms an inaccessible feature into a fully accessible one at minimal development cost.

Beyond motor impairments, users on touchscreens in challenging environments — holding a handrail on public transport, wearing gloves, or using a stylus — benefit from single-pointer alternatives. Cognitive accessibility also plays a role: simpler, click-based interactions reduce cognitive load compared to drag-and-drop operations that require understanding a spatial metaphor while maintaining physical precision.

From a usability and SEO standpoint, ensuring that interactive controls are reachable via simple pointer actions tends to produce cleaner component architecture with better semantic markup, which in turn improves discoverability by assistive technologies and search engine crawlers alike.

Related Axe-core Rules

WCAG 2.5.7 is a manual testing criterion. At the time of writing, axe-core does not include an automated rule that can definitively flag violations of this criterion. The reason is fundamental to how the criterion works: automated tools can detect that a drag event listener exists on an element, but they cannot determine with certainty whether a non-dragging alternative is available, whether that alternative covers the same functionality, or whether the dragging is essential. That judgment requires human evaluation of the interaction design.

• Manual audit — drag-and-drop affordances: Testers must identify every component in the page that responds to mousedown/mousemove/mouseup sequences or touch equivalents (touchstart/touchmove/touchend) and verify that each one exposes an alternative mechanism operable via a single pointer press without dragging. Testers should also check for the HTML5 draggable attribute and associated dragstart/drop event listeners as signals of drag-dependent functionality.
• Manual audit — pointer event inspection: Using browser DevTools event listener inspection or accessibility auditing tools like Accessibility Insights for Web (which includes a manual checklist for 2.5.7), testers should inspect components for pointer event handlers and confirm that the component's full value range or repositioning capability is reachable without sustained pointer movement.
• Why automation cannot catch this: An automated scanner can flag that a <div> has a dragstart listener, but it cannot know whether clicking a nearby button labeled "Move up" provides a compliant alternative. This requires understanding the relationship between UI elements and their functional equivalence — a task that currently exceeds the capability of static or runtime DOM analysis tools.

How to Test

1. Automated scan baseline: Run axe DevTools or Lighthouse against the page to surface any related pointer or input modality issues. While no axe rule maps directly to 2.5.7, reviewing flagged issues under 2.5.x rules provides useful context. Note any components that axe flags as having insufficient keyboard support, as these often overlap with drag-only patterns.
2. Identify all draggable components: Open Chrome DevTools, navigate to the Elements panel, and use the Event Listeners tab to look for dragstart, drag, drop, pointermove, mousemove, and touchmove handlers. Alternatively, search the page source for the draggable attribute and for JavaScript patterns like .addEventListener('dragstart'. List every component that requires dragging.
3. Test each draggable component for alternatives: For each identified component, attempt to achieve the same outcome using only single-pointer clicks or taps — no dragging. For a slider, click directly on the track at the desired position. For a sortable list, look for move buttons or context menu options. For a resizable panel, look for double-click or click-based controls. If no alternative exists, the criterion is failed.
4. Keyboard navigation check (secondary signal): Test all draggable components with keyboard alone (Tab to focus, arrow keys, Enter/Space). While keyboard support is covered by WCAG 2.1.1, the presence of robust keyboard support often correlates with the existence of non-drag alternatives, making this a useful confirmatory step. Use NVDA + Firefox, VoiceOver + Safari (macOS/iOS), or JAWS + Chrome and verify that the component's full functionality is operable without a pointing device.
5. Touch device verification: On a mobile device or using Chrome DevTools device emulation in touch mode, attempt to complete the same tasks using tap gestures (no swipe-and-hold). Confirm that single taps or tap-on-target interactions are sufficient for all functionality.
6. Document results: For each component tested, record whether a compliant single-pointer alternative exists, whether it covers the full range of functionality, and whether the dragging operation might be considered essential. Use the Accessibility Insights for Web manual test checklist for WCAG 2.5.7 as a structured guide.

How to Fix

Range Slider with No Click-on-Track Support — Incorrect

<!-- Slider that only responds to drag on the thumb;
     clicking the track does nothing -->
<div class='slider-container'>
  <div class='slider-track'>
    <div class='slider-thumb'
         id='priceSlider'
         onmousedown='startDrag(event)'>
    </div>
  </div>
</div>

Range Slider with Click-on-Track and Numeric Input — Correct

<!-- Native <input type='range'> provides drag, click-on-track,
     and keyboard support natively. A numeric input offers an
     additional single-pointer alternative. -->
<label for='priceRange'>Maximum price: <span id='priceValue'>500</span> TL</label>
<input type='range'
       id='priceRange'
       name='priceRange'
       min='0'
       max='1000'
       value='500'
       step='10'
       aria-valuemin='0'
       aria-valuemax='1000'
       aria-valuenow='500'
       oninput='document.getElementById("priceValue").textContent = this.value;
                document.getElementById("priceNumber").value = this.value;'>
<label for='priceNumber'>Or enter a value:</label>
<input type='number'
       id='priceNumber'
       name='priceNumber'
       min='0'
       max='1000'
       value='500'>

Drag-and-Drop Sortable List with No Alternative — Incorrect

<!-- Items can only be reordered by dragging.
     No move buttons or keyboard reordering exist. -->
<ul id='taskList'>
  <li draggable='true' ondragstart='handleDrag(event)' id='item1'>Task One</li>
  <li draggable='true' ondragstart='handleDrag(event)' id='item2'>Task Two</li>
  <li draggable='true' ondragstart='handleDrag(event)' id='item3'>Task Three</li>
</ul>

Drag-and-Drop Sortable List with Move Buttons — Correct

<!-- Drag-and-drop is preserved for users who can use it.
     Move Up / Move Down buttons provide a single-pointer
     (and keyboard-accessible) alternative for every item. -->
<ul id='taskList' aria-label='Sortable task list'>
  <li draggable='true'
      ondragstart='handleDrag(event)'
      id='item1'>
    <span>Task One</span>
    <button type='button'
            onclick='moveItem("item1", -1)'
            aria-label='Move Task One up'>
      &uarr; Move Up
    </button>
    <button type='button'
            onclick='moveItem("item1", 1)'
            aria-label='Move Task One down'>
      &darr; Move Down
    </button>
  </li>
  <li draggable='true'
      ondragstart='handleDrag(event)'
      id='item2'>
    <span>Task Two</span>
    <button type='button'
            onclick='moveItem("item2", -1)'
            aria-label='Move Task Two up'>
      &uarr; Move Up
    </button>
    <button type='button'
            onclick='moveItem("item2", 1)'
            aria-label='Move Task Two down'>
      &darr; Move Down
    </button>
  </li>
</ul>

Resizable Split Pane with No Alternative — Incorrect

<!-- The divider can only be repositioned by dragging.
     No percentage input or preset-size buttons exist. -->
<div class='split-pane'>
  <div class='pane pane-left' id='leftPane'>Content A</div>
  <div class='divider'
       onmousedown='startResize(event)'
       aria-hidden='true'></div>
  <div class='pane pane-right' id='rightPane'>Content B</div>
</div>

Resizable Split Pane with Preset Size Buttons — Correct

<!-- The divider still supports dragging, but preset-layout
     buttons allow single-pointer repositioning. The divider
     is also keyboard-focusable with arrow-key support. -->
<div class='split-pane-wrapper'>
  <div class='split-controls' role='group' aria-label='Panel size presets'>
    <button type='button' onclick='setSplit(25)'>25 / 75</button>
    <button type='button' onclick='setsplit(50)'>50 / 50</button>
    <button type='button' onclick='setSplit(75)'>75 / 25</button>
  </div>
  <div class='split-pane'>
    <div class='pane pane-left' id='leftPane'>Content A</div>
    <div class='divider'
         role='separator'
         tabindex='0'
         aria-label='Resize panels'
         aria-valuenow='50'
         aria-valuemin='10'
         aria-valuemax='90'
         onmousedown='startResize(event)'
         onkeydown='resizeWithKeys(event)'>
    </div>
    <div class='pane pane-right' id='rightPane'>Content B</div>
  </div>
</div>

Common Mistakes

• Implementing sliders as custom <div>-based components without click-on-track support, relying entirely on dragging the thumb element and not handling click events on the track element itself to jump the value to the clicked position.
• Assuming drag-and-drop file upload is the only upload mechanism needed, without providing a visible, clickable file browse button (<input type='file'>) as a mandatory fallback alongside the drop zone.
• Applying the essentialness exception too broadly — for example, treating a sortable to-do list or a kanban board as "essential drag" when Move Up/Down buttons would fully satisfy user needs without any loss of functionality.
• Providing keyboard alternatives but not single-pointer alternatives, misreading WCAG 2.5.7 as satisfied by keyboard support alone. The criterion specifically requires a single-pointer path; keyboard-only solutions address 2.1.1, not 2.5.7.
• Hiding move buttons or numeric inputs behind hover states or secondary menus that themselves require drag interactions or complex pointer sequences to reveal, effectively negating the accessibility of the alternative.
• Neglecting touch devices by only testing drag alternatives with a desktop mouse, then deploying to users on touchscreens where the drag gesture behavior and its alternatives may differ significantly from the desktop implementation.
• Using pointer-events: none on the slider track in CSS to prevent accidental clicks during drag, which inadvertently blocks the click-on-track alternative that 2.5.7 requires.
• Not providing an alternative for map pan/drag interactions on embedded maps or custom canvas-based visualizations, where clicking directional arrow buttons or entering coordinates would be a sufficient single-pointer alternative.
• Implementing the single-pointer alternative as a drag-and-drop target itself — for example, creating a "drop here" zone that still requires a drag to use — rather than a genuinely different interaction model such as a button or a text input.
• Forgetting to test alternatives at the full value range of a draggable component. A slider that lets users click only a few preset positions on the track, but not any arbitrary position, does not offer a full alternative if the dragging version supports continuous values.

Relation to Turkey's Accessibility Regulations

Turkey's Presidential Circular 2025/10, published in the Official Gazette No. 32933 on June 21, 2025, establishes a comprehensive national accessibility framework for digital services. The circular requires covered entities to conform to the Web Content Accessibility Guidelines and specifically references Level AA conformance as the standard for earning the Erişilebilirlik Logosu (Accessibility Logo), the official certification mark issued by the Ministry of Family and Social Services (Aile ve Sosyal Hizmetler Bakanlığı).

WCAG 2.5.7, as a Level AA criterion introduced in WCAG 2.2, falls within the scope of the requirements necessary to obtain and maintain the Accessibility Logo. For organizations that rely on drag-and-drop interactions — such as e-commerce platforms with product filtering sliders or sortable wishlists, banking applications with portfolio management dashboards, or travel agency booking tools with date-range selectors — non-compliance with 2.5.7 would constitute a direct barrier to certification.

The entities covered by Presidential Circular 2025/10 include a broad cross-section of the Turkish digital economy: public institutions and government bodies at central and local levels; banks and financial service providers regulated under the Banking Regulation and Supervision Agency (BDDK); e-commerce platforms operating in Turkey; hospitals and private health service providers; telecommunications operators with 200,000 or more subscribers; travel agencies and private transport companies; and private schools authorized by the Ministry of National Education (Milli Eğitim Bakanlığı — MoNE).

For these organizations, failing to provide single-pointer alternatives to drag interactions is not merely a technical shortcoming — it is a compliance gap that may prevent certification, expose the organization to regulatory scrutiny, and exclude a significant segment of users with motor impairments. Turkey's disability statistics mirror global trends: millions of residents live with conditions affecting fine motor control, and digital services that rely exclusively on drag gestures erect unnecessary barriers for this population.

Practically speaking, organizations pursuing the Erişilebilirlik Logosu should include WCAG 2.5.7 in their accessibility audit checklists, ensure that all interactive components built with drag functionality are reviewed for compliant alternatives, and document their conformance decisions — including any claims of the essentialness exception — as part of their Accessibility Statement (Erişilebilirlik Beyanı), which the circular requires covered entities to publish and keep current.