Keyboard-Accessible Drag and Drop

This is an example of keyboard-accessible drag and drop functionality.

It's not accessible to screen readers, because the semantic attributes to describe it were deprecated in ARIA 1.1 (Accessible Rich Internet Applications, Version 1.1), and were never fully implemented anyway. Therefore an alternative interface would still be required, to provide full accessibility for screen readers and other assistive technologies which cannot interact with an interface such as this. An alternative interface would not need to be dynamic in the same way, it would simply needed to provide a means of achieving the same end result.

  1. Item 0
  2. Item 1
  3. Item 2
  4. Item 3
  1. Item 4
  2. Item 5
  1. Item 6
  2. Item 7
  1. Item 8

Notes about this example

The keyboard controls are: Tab for navigation, Space for selection, Enter to drop items into a target container, or Esc to cancel selections. The target containers are only in the Tab order when selections have been made (at which point, items within those target containers are not in the Tab order, which reduces the number of keystrokes required to reach the desired target). Multiple selections can be made by using Ctrl or Cmd or Shift, along with Space or click (supporting a choice of modifiers gives the best cross-platform support in line with user expectations). These controls provide conformance with 2.1.1 Keyboard.

Mouse dragging works as expected, but the script also supports point-and-click interaction, i.e. click an item to select it, then click a target container to drop it there, without the need to drag. This provides conformance with 2.5.7 Dragging Movements in WCAG 2.2, and also provides support for touch interaction (via native emulated mouse input). The click-drop action itself is bound to mouseup rather than mousedown, so it conforms to 2.5.2 Pointer Cancellation (although that may not be strictly necessary if the action is reversible, but there are many potential applications in which actions triggered by an interface such as this are not reversible, so this approach is the safest).

The styles for selection and target availability use border changes in addition to color changes, so they're still discernible to Windows High Contrast users. For other users with reduced or no color vision, the contrast difference between states will still be apparent. This ensures conformance with 1.4.1 Use of Color, while the colors themselves conform to 1.4.3 Contrast (Minimum) and 1.4.11 Non-text Contrast.