If Your Interface Needs Dragging, It Needs a Second Way In

Open a project board in almost any SaaS product and the interaction is the same. You press on a card, hold, drag it across the screen, and let go over a column. For many users that is quick. For others it is the one step that cannot be done.

Dragging asks for three things at once: pressing and holding, moving with precision, and releasing at the right point. People with tremors, limited hand strength or limited fine motor control can struggle with that combination. So can people using a trackball, a head pointer or eye-gaze software, where holding a button while moving is awkward or impossible. WCAG 2.2 added a success criterion for this.

What SC 2.5.7 says

Success Criterion 2.5.7, Dragging Movements, is Level AA in WCAG 2.2. In short: anything you can do by dragging must also be doable with a single pointer without dragging, unless dragging is essential or the behavior is determined by the browser or OS and not changed by the author.

“Single pointer” means one finger, one mouse or one stylus, operating by click or tap. Two points matter in practice. A keyboard alternative alone does not satisfy this criterion. Keyboard access is covered separately by SC 2.1.1, and 2.5.7 asks for a pointer-friendly path as well. And “essential” is narrow. A freehand drawing tool probably qualifies. Reordering a to-do list does not.

WCAG 2.2 is the current W3C Recommendation, but many policies and contracts still cite 2.1 AA. Check which version your obligations name. Meeting 2.5.7 is good practice either way.

Where dragging hides

Teams usually remember drag-and-drop lists. The criterion also reaches interactions that are less obvious:

• Kanban cards moved between columns.
• Sortable lists, such as ranking priorities or reordering playlist items.
• Slider handles that can only be dragged.
• File upload zones with no “Choose file” button.
• Maps and image croppers that pan only by dragging.
• Carousels that advance only by swiping or dragging.
• Resizable panels and column dividers.
• Custom dashboards where widgets are rearranged by dragging.

A quick audit habit: search your codebase for draggable, dragstart, pointermove and any library such as a sortable or board component. Each hit is a candidate.

Fixes that satisfy the criterion

The aim is simple. Give people a click or tap route to the same result. W3C’s examples show the pattern well.

For a sortable list, add Move up and Move down buttons to each row. For a kanban board, let users select a card and choose a destination, either from a “Move to” menu or with next and previous column buttons. For a slider, allow a click or tap on the track to set the value, and consider plus and minus buttons for fine adjustment. For an upload zone, include a visible button that opens the file picker. For a map, add directional buttons next to drag-to-pan. For a carousel, add previous and next buttons.

Here is a minimal sortable row. The drag behavior stays for people who like it, and the buttons provide the alternative:

html

<li id="task-3">
<span>Review pricing page copy</span>
<button type="button" aria-label="Move Review pricing page copy up">Up</button>
<button type="button" aria-label="Move Review pricing page copy down">Down</button>
</li>

Two details make this work better. First, put the task name in each button’s accessible name, as above, so a screen reader user hears which row a button belongs to when navigating by buttons. Second, after a move, tell the user the result. A polite live region such as “Review pricing page copy moved to position 2 of 6” confirms the action. Also keep focus on the button they just used, or on the moved item, so they can press again without hunting for their place.

Mind target size too. Small icon buttons are easy to miss. SC 2.5.8 Target Size (Minimum) asks for at least 24 by 24 CSS pixels for most targets, with some exceptions. Fitting a tidy row of small controls into a dense board is a common way to pass one criterion and fail another.

Do not forget the rest of the interaction

An alternative is only useful if the whole task can be completed. If a card moves by menu but the menu is hidden until hover, you have moved the barrier rather than removed it. Controls should be visible or reachable on focus and on touch, labelled, and operable by keyboard and screen reader as well. If you are already working on keeping focus visible in busy layouts, the same discipline applies. Our piece on sticky headers and cookie banners hiding keyboard focus covers one way a good control can still be unusable.

Overlays and pop-ups need the same care. If your “Move to” menu opens in a dialog, it has to manage focus properly. The guidance in building accessible exit-intent modal popups on focus handling transfers directly.

How to test it

A ten-minute routine catches most failures:

1. List every dragging interaction on the page, using the code search above and a manual walk-through.
2. For each one, try to finish the task using only single clicks or taps. No press-and-hold, no swipe.
3. Repeat with the keyboard alone, then with a screen reader such as NVDA or VoiceOver, to check names, focus and announcements.
4. Check the controls at 200 percent zoom and on a phone-sized viewport, where small buttons often crowd or overlap.
5. Record anything that fails against F108, the W3C failure for not providing a single pointer method without dragging, and note the fix as G219.

Automated scanners will not find this. A scanner can see that a button has a name, but it cannot tell that a board has no non-drag route. This is a manual check, and it belongs in your pre-launch review. Our guide to accessibility reviews before launch without experts is a reasonable starting checklist, and adding accessibility testing to CI/CD helps with the parts that can be automated, such as button names.

A practical order of work

If you have many drag interactions, start with those that block core tasks: moving work items, ordering priorities, uploading files and setting values. Then handle the decorative or optional ones. Fix the shared component first. A single sortable-list component with built-in move controls fixes every screen that uses it, and it stops the problem returning.

Where Wally can help

If you are unsure which parts of your product fall under 2.5.7, or you want a manual WCAG 2.2 assessment that covers interactions scanners miss, our team can audit a defined scope and help you remediate it. You can book a call with an accessibility expert to talk through your product.