Drag and Drop Accessibility: A Practical Guide to WCAG 2.5.7

Drag and drop is accessible when every action it performs can also be completed with a single click, tap, or keypress, and no one has to press, hold, and move a pointer to get the job done. That is the core of WCAG 2.2 Success Criterion 2.5.7, Dragging Movements, a Level AA requirement. This guide explains what it asks for, which alternatives pass, how to build and test them, and where the legal picture in the U.S. fits in.

TL;DR

• WCAG 2.5.7 (Level AA) requires that any functionality using a dragging movement can also be done with a single pointer without dragging, unless dragging is essential.

• The simplest fixes are ordinary controls: move up/down buttons, a select menu for choosing a destination, or click-to-pick then click-to-place.

• Keyboard support is related but not the same thing. Ask “can this be done without any dragging?” first, then confirm it works from the keyboard too.

• Automated scans cannot reliably judge this criterion. A person has to try the interface with a keyboard, a touch screen, and a screen reader.

Table of Contents

• What WCAG 2.5.7 actually requires

• Where drag and drop hides on real websites

• The two exceptions, read carefully

• Patterns that pass: choose the simplest one

• Start by asking whether you need drag and drop at all

• Keyboard access is a separate question

• What screen reader users need to hear

• Touch screens count too

• A worked example: reordering a menu

• How to test drag and drop accessibility

• What automated scanning can and cannot tell you

• The U.S. legal context

• Our perspective: fix the design, then document the fix

• Put it into practice with AccessWiser

• FAQ

• Sources

What WCAG 2.5.7 actually requires

WCAG 2.2 added 2.5.7 to make it easier to operate functionality through inputs other than a precise mouse drag. W3C’s own summary of the criterion says it plainly: for any action that involves dragging, provide a simple pointer alternative.

A dragging movement has several parts: the user presses on an item, holds, moves along a path, and releases. That sequence is hard or impossible for people with tremors, limited hand dexterity, or fatigue. It is also difficult for people who use a head pointer, a trackball, a mouth stick, or voice control software that issues clicks rather than continuous movements.

The criterion asks for a single pointer alternative. A single pointer means one point of contact: a mouse click, a finger tap, a stylus touch. The alternative must not require a path or a hold. A tap on a button qualifies. A two-finger swipe does not.

Two exceptions exist. The requirement does not apply when dragging is essential to the function, and it does not apply to dragging that the browser or operating system controls rather than your page. Both exceptions are narrower than they sound, as we cover below.

Where drag and drop hides on real websites

Most teams know about the obvious cases. The less obvious ones are where audits find failures. Look for these:

• Reordering lists. Menu items in a restaurant ordering dashboard, product order in a store catalog, or steps in a booking flow.

• Kanban boards and task lists. Cards moved between columns.

• File upload zones. A “drop files here” area with no visible “browse” button.

• Page builders and block editors. Moving a block, section, or image within a layout.

• Sliders with draggable handles. Price range filters on e-commerce category pages are a frequent culprit.

• Image croppers and photo galleries. Repositioning or resizing a crop frame.

• Calendars and schedulers. Dragging an appointment to a new time slot, common in salon and clinic booking tools.

• Quizzes and e-learning exercises. Matching and sorting activities.

If you run a Shopify, WordPress, Wix, Squarespace, or Webflow site, some of these live in third-party apps and plugins, not your own theme. The criterion still applies to what your visitors or staff see. Check your plugins as carefully as your templates.

The two exceptions, read carefully

Essential dragging. W3C treats dragging as essential when removing it would change what the function is. Freehand drawing is the standard example. Reordering a list is not essential: the goal is a new order, and there are many ways to reach it. If you can describe the outcome without the word “drag”, dragging is probably not essential.

User agent controlled. If the browser handles the dragging, such as selecting text or dragging a native scrollbar thumb, you are not responsible for providing an alternative, provided you have not modified the behavior.

When in doubt, build the alternative. It costs little and it removes the argument.

Patterns that pass: choose the simplest one

W3C’s technique G219 describes the approach: ensure an alternative is available for dragging movements that operate on content. The failure technique F108 describes the opposite, not providing a single pointer method that avoids dragging. Between them, they give you a clear target.

The table compares the alternatives we see most often.

The common thread: each alternative uses a standard control that already works with a keyboard, touch, voice control, and screen readers.

Start by asking whether you need drag and drop at all

Drag and drop is usually a design preference, not a requirement. If a native select menu, a radio group, or a pair of buttons does the job, the accessible answer may be to ship that and skip the custom widget. That is also the faster build and the lighter maintenance burden.

This lines up with W3C’s ARIA guidance, which stresses that robust accessibility starts with semantic HTML. Its sortable table example is built on real table markup, with ARIA used only where the native elements fall short.

If your design genuinely benefits from drag and drop, keep it for mouse and touch users who like it, and add the alternative beside it. Both paths should produce the same result.

Keyboard access is a separate question

Dragging Movements is about pointers. Keyboard operability falls under Success Criterion 2.1.1, which asks that all functionality be reachable from the keyboard. The two overlap, and a drag-only interface usually fails both.

A common mistake is to bolt keyboard events onto a drag script, so that arrow keys simulate mouse movement. That approach tends to produce fragile interfaces that nobody can discover. A better question for the team: can a person do this with no pointer movement at all? If the answer is a set of real buttons and menus, you get keyboard support, single pointer support, and voice control support from the same markup.

For the controls themselves:

• Use native button and select elements so Tab, Enter, and Space work without extra code.

• Put controls in a logical focus order, next to the item they affect.

• Give every control a name that includes the item, such as “Move Margherita pizza up”, not just “Up”.

Our guide to form accessibility with H44 and H71 covers labeling patterns that apply directly to these controls.

What screen reader users need to hear

A visual drag gives sighted users constant feedback. Screen reader users need the equivalent in words. After any move, announce the result: the item name, its new position, and the total, for example “Margherita pizza moved to position 3 of 8.”

Use a polite live region for this message. Do not rely on the old aria-grabbed and aria-dropeffect attributes. They were part of earlier ARIA drafts, and support has been poor, so robust focus management and live region announcements are the safer route.

Focus is the other half. The most common failure we see after an item moves is lost focus: the element is re-rendered, the focus indicator vanishes, and the user has no idea where they are. After every move, return focus to the same item, or to the next logical control, and make sure the indicator is visible. WCAG 2.2 sets concrete expectations here, which we break down in our article on meeting the 2.4.13 focus appearance requirement.

If your alternative uses a custom dropdown rather than a native select, test it with real assistive technology. Our notes on combobox accessibility across JAWS, NVDA, and VoiceOver show what to check.

Touch screens count too

Teams often test only with a keyboard and mouse. But touch is a pointer input, and the criterion applies to it. A long press followed by a drag on a phone is the same hard gesture. Make sure the single-tap alternative works at mobile sizes, with targets large enough to hit comfortably, and that it does not disappear in a responsive layout.

A worked example: reordering a menu

Take a restaurant owner who manages a digital menu with a drag-to-reorder admin screen. Here is a path to compliance.

1. Inventory. The menu editor has one drag interaction: reordering dishes within a category.

2. Pick the pattern. Move up and move down buttons beside each dish fit the job.

3. Build with native elements. Two button elements per row, each labeled with the dish name.

4. Handle edges. Remove or disable “up” on the first dish and “down” on the last.

5. Announce and keep focus. After a move, update a live region with the new position and keep focus on the button the user just pressed, or its nearest equivalent if the edge removed it.

6. Keep drag as a bonus. Mouse users can still drag. The result is identical.

7. Test. Reorder the whole category with only the keyboard, then with a screen reader, then on a phone.

That is a small change, and it covers 2.5.7, 2.1.1, and the focus requirements together.

How to test drag and drop accessibility

The interface can look perfect and still fail a user with limited dexterity. Run this quick routine on every drag interaction:

1. Find it. List every place where something can be dragged, including plugins and embedded tools.

2. Use only the keyboard. Tab to the item. Can you move it, place it, and undo it?

3. Try single taps. Using a mouse, can you complete the task with clicks only, never holding the button?

4. Try a touch device. Complete the same task with taps, no long presses.

5. Run a screen reader. Confirm that the controls have names, the result is announced, and focus lands somewhere sensible.

6. Zoom to 200 percent. Check that the alternative controls do not overlap or vanish.

For a broader process, see our developer guide to WCAG 2.2 AA testing and the WCAG 2.2 checklist with a 90 day remediation plan.

What automated scanning can and cannot tell you

A scanner can flag many code-level problems: missing names on buttons, low contrast, broken label associations, absent focus styles. It can often spot a draggable element. What it cannot do reliably is decide whether dragging is essential or whether a working alternative exists elsewhere on the page. That is a judgment about function, and it needs a person.

This matches the ADA’s own framing of accessibility as a matter of people being able to use the web, not of passing a tool. A scan is a strong first filter and a regression guard. It is not a verdict on 2.5.7.

The U.S. legal context

In the U.S., there is no single federal technical standard written into the ADA for private business websites. The Department of Justice’s web accessibility guidance explains that the ADA applies to the services of businesses open to the public and describes common barriers. Businesses that serve the public are covered under ADA Title III, which includes a duty to communicate effectively with people with disabilities. In practice, WCAG 2.1 or 2.2 Level AA is the benchmark most organizations, courts, and plaintiffs’ lawyers point to.

For state and local governments, the rules are more specific: the DOJ’s small entity compliance guide names WCAG 2.1 Level AA as the technical standard under Title II. Because 2.5.7 is new in 2.2, it is not a written requirement under that rule, but meeting it is good practice and keeps you ahead of the standard.

If you want a plain explanation of how the ADA and WCAG relate, read our piece on four steps to defensible ADA compliance.

This is general information, not legal advice. If you have received a demand letter, talk to an attorney who handles ADA matters.

Our perspective: fix the design, then document the fix

We see the same pattern again and again. A team hears “drag and drop must be accessible” and sets out to make a complicated widget keyboard-driven with layers of ARIA. It takes weeks, it breaks on the next library update, and nobody on the team can say for sure whether it works.

We think the better path is simpler. Offer a plain alternative built from native controls, fix it in the site’s own code, and keep it there. That is why AccessWiser focuses on permanent, code-level remediation rather than runtime patches. A patch that hides a problem for visitors does not change what the code does for the next person who tries to reorder a list.

We are also candid about automation. Our scans map findings to WCAG 2.2 AA, Section 508, and EN 301 549, and tie each to the element and criterion it affects. But a scan cannot prove that a drag alternative works for a person with a tremor. We pair automated checks with scheduled re-checks to catch regressions, and we encourage teams to add manual keyboard and touch tests for interactions like this one.

Finally, we believe in keeping a record. Dated notes on what was found, what was fixed, and when show a good-faith, ongoing effort, which is what a thoughtful compliance program looks like.

— The AccessWiser Team

Put it into practice with AccessWiser

If you manage a site with sortable lists, sliders, upload zones, or scheduling tools, start by seeing what the code shows. AccessWiser scans against WCAG 2.2 AA, gives plain-language guidance for each issue, re-checks on a schedule, and keeps dated records and an accessibility statement you can publish. Plans start at $24 per month (Starter), with Basic at $49 per month and Pro at $119 per month, and every subscription begins with a 7-day free trial. See the details on our pricing page, or browse solutions for different kinds of websites.

FAQ

Is drag and drop accessible?

Not by default. A drag-only interface fails WCAG 2.5.7 and usually 2.1.1 as well. It becomes accessible when you add an alternative that needs no dragging, such as move buttons or a destination menu, and make sure it works with a keyboard and screen reader.

What does WCAG 2.5.7 Dragging Movements require?

It requires that functionality using a dragging movement be achievable with a single pointer without dragging, unless dragging is essential or controlled by the browser. It is a Level AA criterion introduced in WCAG 2.2. A single click or tap on a control is enough to satisfy it.

Do I need keyboard support for drag and drop?

Yes, though through a different criterion. Success Criterion 2.1.1 requires keyboard operability for all functionality. The easiest way to meet both is to provide native buttons or menus, which work with keyboards, taps, and voice control alike.

Can an automated scan check drag and drop accessibility?

Only in part. Scanners can catch missing names, contrast, and focus problems on the controls, but they cannot judge whether dragging is essential or whether the alternative really works. Pair scans with manual keyboard, touch, and screen reader testing.

Sources

• Understanding Success Criterion 2.5.7: Dragging Movements (W3C WAI)

• What’s New in WCAG 2.2 (W3C WAI)

• G219: Ensuring that an alternative is available for dragging movements (W3C WAI)

• F108: Failure of Success Criterion 2.5.7 (W3C WAI)

• Sortable Table Example (W3C ARIA Authoring Practices)

• Guidance on Web Accessibility and the ADA (ADA.gov)

• Businesses That Are Open to the Public (ADA.gov)

• Small Entity Compliance Guide for State and Local Governments (ADA.gov)

Recommended

• 6 Keyboard First Steps to Dropdown Accessibility for Developers

• Ship Fixes Fast: WCAG 2.2 AA Accessibility Testing for Developers

• Fix Tooltip Accessibility: Standards First Code and 5 Tests for Dev Teams

• Meet WCAG 2.4.13: 2px/3:1 Focus State Accessibility for Devs

Articles on this blog are general information about web accessibility, not legal advice. Laws change and their application depends on your specific situation — for decisions with legal consequences, consult a qualified legal professional.