The Road to Accessible Drag and Drop (Part 1)

Welcome to the first in a mini-series of articles, published over three days, where I’ll be exploring solutions for truly accessible drag and drop.

This implies a good deal more than simply, keyboard accessible.

It should also be fully accessible and understandable for screen reader users, with strong semantics and state information that fit the interaction model. It should work with voice control, or with any assistive technology that generates simulated pointer input, or virtual keystrokes. It may need to accommodate gesture navigation that’s used with mobile screen readers. And it must conform to 2.5.7 Dragging Movements.

There’s no established best-practice here, with a lot of stuff to consider.

But for now, let’s start by asking a fundamental question:

What actually is drag and drop?

The term “drag and drop” is rather ambiguous, since it can refer to at least three different kinds of interaction:

• Moving items between containers (e.g., file managers and project boards).
• Arranging items within a single container (sortable lists).
• Moving items freely within a canvas (application windows and toolbars).

I would say that the first use-case is the one most strongly associated with the term. But even that can have multiple variations, for example:

• Items in a linear order, like a list. In this implementation, the visual layout is essentially arbitrary, and moved items don’t need to have a specific layout position. They can be added to the end of the list, or inserted between items, and there’s no implied limit on how many items the list can have.
• Items in a two-dimensional structure, like a table or grid. Here the visual layout mirrors the structural layout, and the layout position of items is significant. Each grid cell might only accommodate a single item, so dropping into that position would have to swap or remove anything that’s already there (like taking pieces in a chess game).

Drag and drop on the web also has two environmental variations:

• Those which interact with the native system, such as file uploaders.
• Those which only interact with the web application.

How much of that is possible?

I’ve spent the last few weeks investigating that question.

But I figured it wouldn’t be realistic to try and support all these use-cases with a single script. Because the more you have to satisfy, the more complicated it becomes, and that tends to manifest in increasingly complex user interfaces. Drag and drop is hard enough to understand at the best of times.

So I took a view on what seemed to be the most relevant and achievable use-case, and focused only on that:

1. Items in a linear order,
2. That can be moved between containers,
3. And don’t interact with the file system.

Then I came up with a kind of wishlist of capabilities and features, divided into three categories in order of priority:

Drag and drop wishlist

Must have

• Full support for keyboard, mouse, and touch interaction.
• All structural and state information is conveyed to screen readers.
• All functionality is operable with single pointer actions, without the need for dragging movements.
• Virtual pointer input is also supported (like voice control or eye-tracking).
• Visual states are clearly conveyed in forced-color modes (like Windows high contrast).
• Multiple items can be moved at the same time.
• Full i18n support (internationalization for generated text content).

Should have

• Interaction hints for screen reader users (for non-standard actions like dropping items).
• Keyboard interactions should nonetheless be intuitive and guessable without user instructions (although instructions should still be provided as well).
• State information should be programmatically determinable (i.e., represented by state attributes, not just described in text).
• Some kind of sort functionality, either by having movable insertion points (to drop items in-between others), or the ability to re-order items within a single container.
• Support for multiple instances that don’t conflict with each other.

Would be nice

• Don’t use ARIA live regions. Live regions are not entirely reliable, with no guarantee they’ll be announced when expected, or announced at all. If it’s the only way to convey certain information, then fair enough, but try to avoid this if possible.
• No inner buttons or drag handles. Ideally, each draggable item should be a single interactive control, since that’s the most representable and coherent for keyboard and screen reader users.
• No brittle hacks.

How much of that was achievable?

Notable Success Criteria

There are many WCAG Success Criteria (SC) that apply to drag and drop, including ubiquitous concerns like Use of Color, Reflow, and Focus Visible.

But the following SCs are of particular interest:

• 1.3.1 Info and Relationships
• 2.1.1 Keyboard
• 2.3.3 Animation from Interactions
• 2.5.2 Pointer Cancellation
• 2.5.3 Label in Name
• 2.5.6 Concurrent Input Mechanisms
• 2.5.7 Dragging Movements
• 2.5.8 Target Size (Minimum)
• 3.3.2 Labels or Instructions
• 4.1.2 Name, Role, Value

Further reading

• Taming the dragon: Accessible drag and drop (React Spectrum)
• Designing a reorderable list component
• 4 Major Patterns for Accessible Drag and Drop
• Screen readers and drag-and-drop, part 1: draggable elements

Image credit: ucumari photography.