Drag-and-drop accessible alternatives

Drag-and-drop accessible alternatives is adding to drag functions an equivalent way to do the same action without a mouse: keyboard control (select an item, move with arrows, confirm) and/or clear buttons/menus ('move up/down', 'add to…'), with a correct state announcement to the screen reader. Honestly about the essence, this is key: drag-and-drop by itself is inherently NOT accessible to keyboard and screen reader — mouse dragging cannot be 'made accessible' as is. So the correct WCAG solution is to provide an ALTERNATIVE way that does EXACTLY THE SAME (not a trimmed one). We do not imitate accessibility, but add a really working mouse-free path. Honestly about completeness: the alternative must cover ALL drag scenarios (if drag can sort, group and delete — the alternative must also do all of it), otherwise it is pseudo-accessibility. Honestly about dependency: the scope depends on how your DnD component is built (your own or third-party). A third-party one may not provide a convenient point for the alternative — then we rework or replace; someone else's ready-made widget cannot be guaranteed. Honestly about coverage: this is about a specific function (DnD), not all of site accessibility. Honestly about the effect: the function becomes accessible without a mouse; we do not guarantee direct sales growth. Honestly about access: access to the component code is needed. An important boundary: this is a DnD alternative; keyboard navigation in general is 806, focus is 807. Picture this: instead of 'dragging works only by mouse, without it the function is inaccessible' — the same action from the keyboard and buttons. The base price starts from 18,000 ₽ (depends on the component complexity).

• Dragging works only by mouse — without it the function is inaccessible.
• A keyboard/screen-reader user cannot perform drag-and-drop.
• A ready-made DnD widget provides no mouse-free alternative.
• There is a 'pseudo-alternative' that cannot do everything dragging does.

• Keyboard control of the function (select/move/confirm)
• Clear buttons/menus as an alternative to dragging
• Announcing state and result to the screen reader
• Full coverage of all DnD scenarios (not a trimmed alternative)
• Reworking/replacing an inaccessible third-party DnD component
• Indicating boundaries (DnD is inherently inaccessible → an alternative is needed)
• A link with keyboard (806) and focus (807)
• Handover and review with you

• The same action is doable without a mouse (keyboard/buttons)
• The function is accessible to keyboard and screen-reader users
• The alternative covers all dragging scenarios
• Real function accessibility (not an imitation)

• We figure out exactly what your drag-and-drop does; collect access
• We design and implement an equivalent mouse-free alternative
• We check coverage of all scenarios with screen reader/keyboard, review with you

• Can't dragging itself just be made accessible?

  No, and that is honest: classic mouse drag-and-drop is inherently inaccessible to keyboard and screen reader — it cannot be 'voiced' as is. The correct WCAG solution is to give an equivalent alternative (keyboard/buttons) that does exactly the same. We add a really working mouse-free path, not an imitation.

• Will the alternative do everything dragging does?

  It must — otherwise it is pseudo-accessibility. If drag can sort, group, delete — the alternative must also do all of it. We cover ALL scenarios, not part. If you have a complex DnD, we will honestly estimate the scope so the alternative is full, not a 'checkbox'.

• We have a third-party DnD widget — can you handle it?

  It depends on the widget. Some ready-made components provide no convenient point for the alternative — then we rework or propose replacing with an accessible solution. The behavior of someone else's ready-made widget 'as is' cannot be guaranteed; we will honestly mark what is required.