KanbanBoard With Real Keyboard Drag-and-Drop

Most accessibility problems are about using the wrong element or forgetting an attribute. Drag-and-drop is different: the HTML5 drag-and-drop API has no keyboard equivalent whatsoever. Not a partial one, not an awkward one — there is no key combination that initiates a native drag.

So a Kanban board built purely on the native API is not partially accessible, it is completely unusable without a pointing device. That includes keyboard-only users, screen reader users, and anyone using switch access or voice control.

The fix is not to make dragging keyboard-friendly, because you cannot. It is to implement a second, complete interaction path that achieves the same outcome: pick up a card with a key, move it with arrows, drop it with another key, cancel with Escape.

That means the board has two full implementations of 'move this card from here to there' running side by side, sharing the same state. It is genuinely twice the work, and it is why so few free boards do it.

When you drag a card with a mouse, you see it lift, you see the column highlight, you see it land. A keyboard user perceives none of that unless it is announced, so every step needs a live-region message: picked up, moved to a position, dropped, or cancelled.

The messages must carry the information the visuals convey — which card, which column, which position within it. 'Moved' is useless. 'Design review moved to In Progress, position 2 of 5' is the equivalent of what a sighted user got from watching it happen.

Live-region politeness matters as much as wording. These announcements belong in a polite region: a card move is informational, and an assertive region would interrupt whatever the user was already listening to on every single keystroke of a multi-step move.

Escape must abort a move in progress and return the card to where it started. This matters more for keyboard users than mouse users because a multi-key operation is easier to start accidentally, and because there is no equivalent of simply releasing the mouse outside a valid target.

The state model needs to hold the original position for the whole duration of a move so cancellation can restore it. Implementations that mutate as they go cannot cancel correctly, and that shows up as a card silently landing in the wrong column.

The first failure is focus after a drop. If focus is lost when the card moves, a keyboard user is thrown back to the top of the document and has to navigate all the way back. Focus should follow the card to its new position.

The second is reduced motion. A card animating across the board is pleasant for most people and genuinely unpleasant for some. Every animation in the library respects `prefers-reduced-motion`, which is a one-line media query and is skipped constantly.

If your board is an internal tool used by three people you know, you can make a considered decision to skip it. If it is a product, or anything touched by the public sector or an employer with accessibility obligations, an unusable-without-a-mouse board is a legal and ethical problem rather than a missing feature.

The general test applies here too: open any Kanban library's demo, put your mouse away, and try to move a card. The answer arrives within about ten seconds and it is usually the same answer.