Right now, go try moving a card on your own kanban board using nothing but Tab and the arrow keys. Or reorder an item in your priority list. Or nudge a slider. Unplug the mouse if you have to — really do it. If nothing moves, you haven't found an edge case. You've found a documented, named, AA-level WCAG failure, and it's sitting on production.
The good news: this is one of the cheapest "quick fix" categories in the whole spec, because the criterion doesn't ask you to redesign your drag interaction. It just asks you to make sure dragging isn't the only way in.
The Stat: WCAG 2.2 SC 2.5.7 Dragging Movements (Level AA) requires that all functionality using a dragging movement for operation also be achievable by a single pointer without dragging — for example, tap-to-select-then-tap-to-place, or explicit move buttons — unless dragging is essential to the function or the movement is controlled by the user agent, like native browser scrolling. (Source: WCAG 2.2)
Why This Criterion Exists
Drag-based interactions used to live in a gray zone. Keyboard-only users (people with motor disabilities, tremor, limited fine motor control, or simply anyone whose mouse or trackpad broke that day) couldn't operate them, but older versions of WCAG didn't call it out by name. WCAG 2.2 closed that gap. WCAG 2.2's Dragging Movements criterion is explicit: if a feature only works by clicking, holding, and moving the pointer while held, it fails Level AA unless dragging is essential (there aren't many cases where it truly is) or the movement is something the browser itself handles, like scrolling a page.
That "essential" carve-out is narrow on purpose. A freehand signature pad, where the actual path you draw is the content, might qualify. A kanban board, a reorderable list, an image gallery, or a slider almost never does — there's always a non-dragging way to achieve the same outcome, and the criterion exists precisely to make you build it.
What a Compliant Alternative Actually Looks Like
You don't have to invent this from scratch. The pattern is well-established and shows up across production libraries:
- Focus the item. The draggable element needs to be reachable by Tab like any other interactive control, with a visible focus indicator.
- Pick it up without a mouse. Space or Enter marks the item as "selected for moving."
- Move it with arrow keys. Once picked up, arrow keys shift the item's position — left/right for horizontal reordering, up/down for a vertical list or between columns.
- Drop it. Space or Enter again commits the move.
- Cancel cleanly. Escape returns the item to its original position, no move applied.
- Offer an explicit alternative control too. A "Move to..." button or menu (as shown in the diagram above) gives an even more direct, no-timing-required path for anyone who finds press-and-hold sequences difficult, including some switch-device and voice-control users.
This isn't theoretical. dnd-kit's own accessibility documentation describes exactly this behavior as a built-in Keyboard sensor: once a draggable item has focus, Space or Enter picks it up, arrow keys move it, Space or Enter again drops it, and Escape cancels. If you're already using a modern drag-and-drop library, there's a real chance the keyboard path is one configuration flag away from working rather than a from-scratch build.
A Quick Audit Checklist
Before you assume your drag-and-drop widget is fine, walk through this with a mouse unplugged (or just resist the urge to touch it):
- Can you Tab to the draggable item at all?
- Once focused, is there a visible way to see it's "picked up" (outline, color change, aria-live announcement)?
- Do arrow keys move it to a new position or a new column/list?
- Is there a way to confirm the move (Enter/Space) and a way to cancel it (Escape)?
- Is there also a non-drag, non-arrow-key path — a "Move to..." button, a numeric position field, cut/paste-style actions — for people who can't reliably chain a pick-up-move-drop keyboard sequence?
- Does a screen reader announce the new position after the move completes?
| Interaction | Drag-only (fails 2.5.7) | Compliant alternative |
|---|---|---|
| Reorder a list item | Click and hold, drag to new spot | Focus item, Space to pick up, arrow keys to move, Space to drop |
| Move a kanban card | Click and hold, drag across columns | Keyboard sequence above, plus a "Move to..." button/menu |
| Adjust a range slider | Click and drag the handle | Focus the handle, arrow keys increment/decrement the value |
| Resize a panel | Drag a resize handle | Keyboard shortcut or +/- buttons to adjust size in steps |
If you want a broader refresher on keyboard operability beyond drag interactions specifically — focus order, visible focus, avoiding keyboard traps — WebAIM's guide to keyboard accessibility is a solid, practical reference to test against.
Who Actually Hits This Wall
It's easy to file "keyboard-only" under a niche edge case, but the population is bigger and more varied than most teams assume. Someone with a tremor or limited fine motor control may be able to press a key precisely but struggle to hold a mouse button down while steering a cursor at the same time — dragging combines two demands (sustained pressure and precise movement) that a single key press doesn't. Someone using a switch device or voice-control software to navigate a page often can't perform a drag gesture at all; their input model maps far more naturally onto discrete actions like "select," "move," and "confirm" than onto a continuous motion. And then there's the simple, mundane case: a trackpad that mis-registers a long drag, a mouse that's temporarily unplugged, a laptop in a mode where the pointer just isn't reliable that day. None of these are rare hardware configurations. They're a normal cross-section of how real people interact with a browser, which is exactly why the criterion is Level AA rather than an optional enhancement.
The Part Teams Usually Get Wrong
The most common mistake isn't skipping the keyboard alternative entirely — it's building a half-version that technically responds to key presses but never actually confirms success. Arrow keys visually nudge the card, but nothing is announced to a screen reader, so a non-sighted keyboard user has no idea whether the move actually landed until they tab away and back to check. Treat the "announce the result" step as just as mandatory as the "respond to the key press" step. A silent success is functionally the same as a failure for anyone who can't see the screen.
The other frequent gap: teams add the keyboard alternative to the desktop kanban board and forget the mobile card-sort widget, the touch-based image reordering tool, or the slider in the settings panel. SC 2.5.7 applies to every drag-based interaction on the site, not just the flagship one that got user-tested.
Fix It This Sprint
None of this requires a redesign. If you're on an existing drag-and-drop library, check whether it already ships a keyboard sensor (many do) and simply enable and test it. If you built something custom, the checklist above is close to a full spec on its own. Either way, this is squarely a "test it, find it, fix it" category rather than an architecture problem — which is exactly the kind of barrier a proper audit is built to surface before a user (or a demand letter) finds it first. If you're not sure how many drag interactions are hiding on your site, get a free scan that flags keyboard-only barriers across your site and see what's actually reachable without a mouse.