Search topics
Drag-and-drop boards that only a mouse can use
Cards move between columns only by dragging, have no focusable control, and the move is never announced.
<li draggable="true"> The problem
People who can't drag, or can't see where they are dropping, can't move a card at all.
A task board has three columns: To do, Doing and Done. With a mouse, you press on a card, move it across and let go over another column, and it lands there. Press Tab and focus jumps straight past the board: the cards are not in the Tab order, and nothing on them can be pressed. On a phone, the same press starts a scroll instead of a drag. When a card does move, the board changes silently.
The board offers one way to move a card: a drag, which needs a press held down while the pointer travels. WCAG 2.5.7 asks for a way to do the same with single clicks or taps, unless dragging is essential, and it isn't for moving a card to a column. The cards are list items with no focusable control, so nothing works from the keyboard either (2.1.1). And the move changes the page without a status message, so screen reader users are not told it happened (4.1.3).
Some people can drag but slowly or unreliably: a long board, a scrolling column or a small drop zone turns a short move into a long one. A board is often the only place where work changes state, so a drag-only board shuts these people out of the whole workflow, not one page.
5 of 10 groups affected
- No vision (affected)
- Low vision (affected)
- Colour vision (not affected)
- No hearing (not affected)
- Hard of hearing (not affected)
- No speech (not affected)
- Motor (affected)
- Reach, strength (affected)
- Cognitive (affected)
- Seizures (not affected)
- Limited manipulation Keyboard, switch and voice control users can't press and hold while moving, and the cards aren't in the Tab order, so no card can be moved at all.
- Without vision Screen reader users can't see the columns to aim at, and when a card does move, nothing tells them where it went.
- Limited reach and strength People with tremors or weak hands lose their grip halfway, or let go over the wrong column, and have to start again.
- Limited vision With a magnifier, the target column is often off screen while the card is held, so the drop is a guess.
- Limited language, cognitive and learning abilities Nothing on a card says it can be moved, so people who don't guess that it drags never find the action, and with no message after a drop they can't confirm where it went.
Scanners read the markup, and nothing in it is wrong: list items need no name, and draggable="true" is valid HTML. Whether a card can move without dragging only shows when someone tries. Drag libraries that use pointer events add no attribute at all. Asked to make the board accessible, AI tools often add tabindex="0" and role="button" to the cards, which puts them in the Tab order without giving the keyboard anything to do.
Try it
Drag “Write release notes” to Done. Then put the mouse aside and try it with Tab.
The panel shows what a screen reader announces. Can you move the card without dragging, and do you hear where it went?
Broken Can you fix this?
To do
- Write release notes
- Update the pricing page
Doing
Done
Screen reader says:
(Tab to a card, or drag one)
The fix
Keep the drag, add a control that moves each card with a click or a key, and say where it went.
- 1Every card moves to every column with single clicks or taps, no dragging.
- 2The same control works from the keyboard, and focus stays with the card after it moves.
- 3A status region that is already on the page says which card moved and where.
<section class="column" data-column="todo"> <h2>To do</h2> <ul> <li draggable="true" data-card="notes">Write release notes</li> <li draggable="true" data-card="pricing">Update the pricing page</li> </ul></section><!-- Doing and Done are the same: a heading over a list of cards -->Move buttons on each card
<li data-card="notes" draggable="true"> <span id="card-notes">Write release notes</span> <button type="button" data-to="doing" aria-describedby="card-notes">Move to Doing</button> <button type="button" data-to="done" aria-describedby="card-notes">Move to Done</button></li>…<p role="status" class="board-status"></p>The only way to move a card is to drag it. A list item can't take focus or be pressed, and when the drop handler moves it, nothing is said.
Keep the drag for people who like it, and give each card a button for each column it can go to. The board has a status region from the start, and the script fills it in after every move, by drag or by button.
Each button moves the card with one click, tap or key press, and voice control users can say "Click Move to Done". The card's title is read as the button's description, so a screen reader says which card the button moves without changing its visible name. After the move, focus goes to the card in its new place, and the status line says where it went. This suits a board with a few columns: with more than three or four, the buttons crowd the card.
Both the move buttons and the Move to list pass on their own, for keyboard, pointer and screen reader users. Move buttons take one press and are the easiest to find, but they add a button per column to every card, so they suit boards with three or four columns. The Move to list takes two steps, but stays the same size however many columns there are, and can offer a position as well; choose it for larger boards. Keyboard dragging is worth adding when keyboard users ask for a faster way, but only beside one of the others.
Keep the drag. A drag is fast for people who can do it, and 2.5.7 asks for an alternative, not a replacement. Keep the drag on the card and the controls inside it, so a press on a button never starts a drag.
The controls can sit on the card all the time, or appear in a menu from a single "Move" button. A menu is tidier, but it is a second pattern to build and test; make sure it opens on click and from the keyboard, not on hover.
Focus needs care, because moving a card moves its markup.
- Re-rendered cards: frameworks often destroy the card and create a new one in the new column, so focus falls to the body. Focus the new card's first control yourself after the move.
- The last column: when a card reaches Done, the button it was focused on may no longer exist. Focus the card's first remaining control, not a button for a column it is already in.
- Undo: if a move can be undone, put the Undo control in the card or in the status line, where focus already is.
Write one status message per move, short and in the same words as the columns: "Write release notes moved to Done." Don't announce while a card is being dragged with the mouse; announce the result.
Fixing this with an AI coding assistant? Get this guide as Markdown
Verify the fix
5 checks.
Test with: Keyboard, Mouse, Touch, Screen reader
Record the OS, browser and assistive-technology versions, the build, the date, and the actual result of each step. Repeat after the board component or its drag library changes.
Limits
This is a starting pattern, not a guarantee for every application. Reordering cards within a column, nested boards and moves that need confirmation have their own needs, and are not covered here. Drag libraries differ in how they handle focus and announcements: test the complete journey with your target assistive technology.
This is a recreated teaching example, not a finding about a named client. The code is a starting pattern: test it in your own product. No completed assistive-technology test is claimed here.
Keep this fixed as your code changes.
Turn guides like this into rules your coding agents and CI follow, then have the result retested with a keyboard and screen readers.