A few days before my native drag and drop article came out Gez Lemon wrote about accessibility in drag and drop, and touched on HTML 5.

I then promised to look at implementing accessibility with native drag and drop, and here’s my findings.

ARIA Support

This was quite easy to add, though only by following Gez’s article. Since I already had events for drag start, I just needed to add drag end to clean up and remove the ARIA effects.

I added the following to the dragstart event:

addEvent(dragItems, 'dragstart', function (event) {
  // via ARIA say the element has been grabbed
  this.setAttribute('aria-grabbed', 'true');
  // code continues...

The added a new dropend event:

addEvent(dragItems, 'dragend', function (event) {
  // remove the ARIA grab attibute when we're not dragging
  this.setAttribute('aria-grabbed', 'false');
});

The effectAllowed and dropEffect combo was difficult to work out at first, though probably because I was playing with link and reference, whereas I should have been playing with move or copy. That said, a note about move and copy, move is a type of copy, with a clean up function to delete afterwards. Once I had this combo correct, the drop effects worked.

The changes required were to:

1. On drag: on all the drop targets add: setAttribute('aria-dropeffect', 'copy')
2. On drag: set the allowedEffect on the drag event: event.dataTransfer.effectAllowed = 'copy';
3. On drop: say what we’ll accept: event.dataTransfer.dropEffect = 'move';
4. On dragend: remove the drop effect from the drop targets: removeAttribute('aria-dropeffect')

The big problem for me was that I couldn’t truely test this.

Update: between the time I had finished my code and writing this article, NVDA (the Windows open source screenreader) announced that they recieved support from Yahoo!, and that ARIA drag and drop support is in their development roadmap.

The full working version of native drag and drop with ARIA support is available here: native drag and drop with ARIA support (source code)

Keyboard Support

Keyboard, sadly, is a whole different story.

I was able to replicate a lot of the keyboard features that Gez included in his demo. This included setting the tabIndex = 0 to allow the elements to tab to (superb trick by the way), included highlighting the drop targets as we drag.

However, the problem was: I wanted the user to be able to start the drag operation using the keyboard. Initially looking at the spec I couldn’t see that it was supposed to be supported (which it turns out, it is).

I started going down the path of using the keyboard to trigger drag events. I was able to replicate the drag event being triggered from the keyboard (like space starts the event), however, and this is a biggie, I couldn’t replicate the dataTransfer object. I tried faking it. I tried giving it nothing. I tried all kinds of random attempts to trick the browser in to giving me the object. It’s a no goer.

As it turns out, there is keyboard support written in to the spec (though in my personally opinion it’s not completely obvious to an author reading). The drag and drop operations should work like a copy and paste operation.

This is very clever, and I like it. Tab round to the dragable element, copy using the keyboard, which triggers the dragstart event, which I can then add classes to the drop targets, and make them tabbable. The user then tabs round to the drop targets, and pastes. This triggers the drop event and we’re all good.

No browsers support this keyboard event model.

I’ve raised bug for Mozilla and Webkit. They’ve both had comments on, and in both cases I’m not 100% sure what the comments mean, but speaking to the people involved via IRC, they’ve both said if it’s in the spec, it should be in the browser.

Let’s hope they do something about it. Now, how do I report a bug in IE…?!