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:
- On drag: on all the drop targets add:
setAttribute('aria-dropeffect', 'copy')
- On drag: set the allowedEffect on the drag event:
event.dataTransfer.effectAllowed = 'copy';
- On drop: say what we’ll accept:
event.dataTransfer.dropEffect = 'move';
- 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…?!
16 Responses on the article “Accessibility & Native Drag and Drop”
Hi Remy!
Great job in making drag and drop work as it should! I think you can report a IE8 bug by submitting it here: https://connect.microsoft.com/IE/Feedback
Last I heard, you report a bug in IE by writing it on a piece of paper, ripping that paper up, and throwing it onto an open fire. The bug report will float up the chimney and the IE team will promise to fix the bug in the next version.
@Emil – cheers, looks like there’s a few hoops I’ll have to jump through to get the bug listed.
@Shaun – I think you just listed the hoops :-D
How does it work? In contrast to Gez Lemon’s example I can’t find anything to drag in Opera 9 and 10 in yours. Did I miss something?
@Remy – The comment on the WebKit bug is just an indication that they have the same bug filed in Apple’s internal bugtracker, radar (that’s what the ‘rdar:’ URL means).
I hope the browser vendors implement copy and paste for drag events soon; drag and drop on its own is a serious accessibility nightmare. I know people in their 20s who have no disabilities, went to Ivy league universities, and have used computers for years, who still cannot drag and drop (or at the very least don’t think of it when using an interface), but who can copy and paste. I implement interactive multimedia that had drag and drop activities for sorting items, and we discovered that our users (doctors and nurses) had serious problems with those activities, so most of them we changed to having our virtual mentor pick one item at a time, and the user clicks where it goes.
I hope that when copy and paste support is added to drag and drop in the browsers, users will also be able to select dragabble elements with their mouse, with a single click, just like you select items in a list or icons on the desktop. I have encountered users who do not know how to focus elements with a keyboard or copy and paste using keyboard, but instead do everything with the mouse.
@Thomas – the demo is using native drag and drop, whereas Gez’s example is pure/old school JavaScript. The obvious downside to the native version is it’s not supported in Opera 10. The article was more to show how to implement accessibility to the native version of drag and drop. This however, does beget an article showing you how you should fail down (though perhaps it’s just a case of testing to see if you can create a drag event, and if not, rely on the JavaScript driven DnD).
@Brian – Thanks for clarifying on the radar bug – does that mean that they had it already, or they’ve added it to their system?
@Remy – I can’t tell you that; it could mean either. You’d have to ask someone from Apple, who has access to Radar, to clarify that.
I’ve been reporting IE bugs here – https://connect.microsoft.com/IE/Feedback
Although I suspect Shaun’s method may be faster.
A nice article, but one concern I have is how the native support and scripted support should interact. When these are in conflict which one will win? Will the user lose? I put my thoughts down here: http://my.opera.com/jax/blog/can-html5-make-accessibility-usable
Hi remy,
very nice article, wich will improve the correct, accessible implementation of HTML 5.
Firefox 3.6 will also add ARIA-Semantics automaticly, if you use HTML5 draggable (https://bugzilla.mozilla.org/show_bug.cgi?id=477599).
i think, Firefox will make it right. if you only use a native browser-feature, you shouldn´t even have to add aria-semantics. aria should be used for features, wich are implemented by an author. if the browser vendor introduces a new feature (an HTML 5 element, DOM-Interface etc.), he is the first responsible to make it accessible.
regards
alex
Gez,
Nice article, but there are problems with this approach:
* It does not include drop by link (an HTML 5 feature).
* What if the application does not want to support a cut (which I would assume you would do in the case of a move)?
* It prevents the mobility impaired user from being able to see all the grabbed items (visible only with the mouse pointer).
The question I have is why the same script functions called in response to mouse activity could not be used for the keyboard implementer. If you were to take out the mouse pointer position information you virtually use the same HTML 5 utilities in the keyboard implementation.
[…] Accessibility & Native Drag and Drop […]
[…] Article attempting to add accessibility to native drag and drop Category: HTML5原著 | […]
[…] more on this topic. I guess everything can’t be included! For more on this topic, start with Accessibility & Native Drag and Drop by the HTML5 […]
[…] more on this topic. I guess everything can’t be included! For more on this topic, start with Accessibility & Native Drag and Drop by the HTML5 […]
[…] more on this topic. I guess everything can’t be included! For more on this topic, start with Accessibility & Native Drag and Drop by the HTML5 […]
Join the discussion.