F108: When Drag-Only UIs Lock Out Motor-Impaired Users

When touch interfaces exploded in popularity after 2007, designers discovered something delightful: dragging things felt natural. Intuitive. Almost physical. Drag-to-reorder lists, swipe-to-dismiss cards, Kanban boards where tasks slide between columns — these patterns became staples of modern UI design. What the industry largely failed to ask was: natural for whom?

For users with motor impairments — tremors, limited grip strength, paralysis, or conditions like Parkinson's disease — a drag operation is not intuitive. It can be impossible. WCAG 2.2 Success Criterion 2.5.7 Dragging Movements (opens in new window) exists precisely to address this gap, and Failure F108 (opens in new window) documents the specific pattern that violates it: providing only a drag-based method to actuate a function, with no single-pointer alternative.

The Failure

F108 describes two canonical examples that most development teams will recognize immediately.

The first is a drag-to-reorder list. Items can be picked up and repositioned vertically. Other elements shift dynamically to show where the dragged item will land. There is no alternative — no button, no menu, no keyboard shortcut — to change the order without dragging.

The second is a Kanban board. Tasks move horizontally across status columns by dragging. Moving a card from "In Progress" to "Completed" requires a sustained drag gesture across the board. Again, no single-pointer alternative exists.

The code pattern underlying both failures looks something like this:

// Failure pattern: drag-only implementation
item.addEventListener('dragstart', handleDragStart);
item.addEventListener('dragover', handleDragOver);
item.addEventListener('drop', handleDrop);
// No click-based alternative. No keyboard handler.
// No menu. Nothing.

The failure condition is precise: the function is only achievable through a dragging movement. If a single-pointer alternative exists — even a multi-step one — F108 does not apply.

Why This Matters

A drag operation requires the user to press, hold, and move simultaneously. That's a compound motor action. For someone using a switch device, a head pointer, eye-gaze technology, or a touchscreen with limited fine motor control, "press and hold while moving" may be physically unachievable.

Screen reader users face a related problem. Drag-and-drop interactions built on HTML5 drag events are often completely invisible to assistive technology. A list that looks reorderable has no semantic signal that reordering is possible, no announced state changes, and no operable mechanism — because the only mechanism is a mouse gesture.

Cognitive load compounds the issue. Even users who can physically drag may find the spatial reasoning required — "where do I drop this to get it between items 3 and 4?" — significantly harder than selecting from a numbered list or a dropdown menu.

The populations affected are not small. Motor impairments affect tens of millions of people in the United States alone, and the prevalence increases with age. As the user base of enterprise software ages, drag-only interfaces become progressively more exclusionary.

The Fix

The standard does not prohibit drag interactions. It requires that a single-pointer alternative also exist. The alternative can be multi-step — that's explicitly acknowledged in the F108 description. What matters is that each step requires only a single pointer action (tap, click) rather than a compound gesture.

For the list reorder case, a workable pattern:

<!-- Each list item gets a move control -->
<li>
  <span class="item-content">Task name</span>
  <button aria-label="Move Task name" aria-haspopup="listbox">
    ↕
  </button>
  <!-- Dropdown opens with position options -->
  <ul role="listbox" aria-label="Move to position">
    <li role="option">Position 1</li>
    <li role="option">Position 2</li>
    <li role="option">Position 3</li>
  </ul>
</li>

For the Kanban board:

<!-- Each card gets a status change control -->
<div class="kanban-card">
  <h3>Task name</h3>
  <label for="status-task-1">Move to column:</label>
  <select id="status-task-1">
    <option>Backlog</option>
    <option selected>In Progress</option>
    <option>Review</option>
    <option>Completed</option>
  </select>
</div>

These aren't elegant design solutions — they're functional accessibility floors. Teams that want to preserve the visual richness of drag interactions can keep them while adding these alternatives. The drag experience stays for users who can use it; the alternative exists for those who cannot.

For keyboard support specifically, the ARIA Authoring Practices Guide on listbox patterns (opens in new window) and the drag-and-drop pattern guidance (opens in new window) provide implementation details for making reorderable lists fully keyboard-operable.

Applying This

In code review, flag any component that registers dragstart, dragover, or drop event listeners. The question to ask: is there a click-based path to the same outcome? If the answer is no, the component fails 2.5.7.

In automated testing, F108 is largely undetectable by tools. Automated scanners can identify the presence of drag events, but they cannot determine whether an alternative exists — that requires human judgment. This is exactly the gap documented in our research on why automated testing misses critical barriers. Manual audit checklists should include a specific line item: "Does every drag interaction have a single-pointer alternative?"

In design review, catch this before implementation. When a designer proposes a drag-to-reorder pattern, the design spec should show both the drag interaction and the alternative. If the alternative isn't in the spec, it won't get built.

For component libraries and design systems, this is where the leverage is. If your shared <SortableList> or <KanbanBoard> component ships with a built-in single-pointer alternative, every team using it gets the fix automatically. One fix, organization-wide benefit.

Language access intersects here in ways that practitioners often miss. A dropdown-based reorder alternative is only useful if its labels are meaningful — and those labels need to be translated for users who don't read the site's primary language. A tool like idioma.chat (opens in new window) translates not just visible text but the full accessibility layer: ARIA labels, dropdown option text, button labels, and dynamically loaded content. A Kanban status selector that reads "Completed" in English but remains untranslated for a Spanish-speaking user with motor impairments has failed twice over.

Data Table: F108 at a Glance

CORS Perspective

From an operational capacity standpoint, F108 is a component-level problem with a component-level solution. The highest-leverage fix for most teams isn't auditing every page — it's auditing the shared component library. If a SortableList or KanbanBoard component ships with a built-in alternative, the fix propagates automatically. That's the 80/20 move: one well-scoped remediation effort, organization-wide coverage. The compliance framework research we've published shows that teams paralyzed by the breadth of WCAG often miss exactly this kind of targeted, high-leverage intervention — the kind that solves a systemic pattern rather than chasing individual page failures.