Accessible drag and drop using WAI-ARIA

Accessible drag and drop using WAI-ARIA

There is increasing interest in, and importance being laid upon, making modern dynamic web applications more accessible. New specifications such as WAI-ARIA and HTML 5 provide the means by which to do this; in this article Gez Lemon presents a solution for implementing accessible drag and drop functionality using JavaScript and WAI-ARIA. Some discussion of HTML 5 drag and drop features is also included for good measure.

( Read the article )

Originally posted by Article:

li.draggable {
  cursor: move;
}

Can be done using

li[draggable]

These two rules not targetting the same elements. li[draggable] targets elements with the draggable attribute:

<li draggable="draggable"></li>

However the first rule refers to list items with the class of draggable.

Interesting article. I'm working on a similar application for my current client, involving a source and a destination list. Rather than tabbing through the items in each list, I use the <a href="http://www.w3.org/TR/2009/WD-wai-aria-practices-20090224/#kbd_general_within">roving tabindex</a> technique: Tab/Shift-Tab moves focus back and forth between the two lists, with the Cursor Up and Cursor Down keys used to navigate through the items within a list. This has the advantage that the user can rapidly move focus between the two lists, each time landing in the position they were last at, rather than having to tab through the whole list.

Of course, I won't know for sure if this is a good idea until we do user testing, but I've found it works well for me. I was just wondering if you had any particular reason for not utilising roving tabindex in your example?

There was no particular reason I didn't use a roving tabindex on this example, but I will be explaining the roving tabindex technique in the next WAI-ARIA article about creating accessible menus.

Dead link in this page

http://devfiles.myopera.com/articles/735/example.html

The link "Back to the accessible drag and drop article." should point to

http://dev.opera.com/articles/view/accessible-drag-and-drop/

instead of

http://devfiles.myopera.com/articles/dragdrop.html

An excellent article, and I am looking forward to your next one, but <a href="http://my.opera.com/jax/blog/2009/07/09/keyboard-drag-and-drop-html-and-accessibility">my cover of it</a> led to another discussion. For an accessibility-oriented web developer this is highly interesting, but what the HTML5 spec doesn't seem to cover is how this should interact with the user agent if it too supports keyboard drag and drop, as it should.

Thank you for your kind words.

Originally posted by jax:

For an accessibility-oriented web developer this is highly interesting, but what the HTML5 spec doesn't seem to cover is how this should interact with the user agent if it too supports keyboard drag and drop, as it should.

Remy Sharp's accessibility and native drag and drop article covers implementing keyboard drag and drop in HTML5.

Nice. I hope the UI people at Opera keep in synch with how it is implemented in other browsers, and vice versa.

Neither article addresses my concern though. When an accessibility feature is implemented natively and is also exposed for web developers to take advantage of in their applications, the interaction between the two always starts out undefined. Should the native implementation take precedence, or the application, should they be integrated, or should you just hope for the best?

As I said in my entry I like the cascading model, user overrides overrides the web application overrides the native implementation. This means that in the default case the browser does it, the app developer may enhance that, and the user can override that if the app (or indeed the browser) makes the page/app unusable.

I think it will be useful, at least conceptually, to discern between <i>baseline drag and drop</i> (essentially implementing d&d for browsers that don't support it properly, or adjusting for bugs) and <i>enhanced drag and drop</i> (for use when the application developer has knowledge the browser can't have and thus can make the application run smoother).

In principle, if the browser does its job, coding baseline d&d shouldn't be necessary. This would be done reliably and consistently for all draggable elements by the browser. A clever user agent, browser or assistive tool, may also do more of enhanced services, but mostly this would be domain of the application developer.

I see accessibility as a subcategory of usability. In the past people have been satisfied with having an alternative presentation of the content in a document, but we can and should do better. We shouldn't just make drag and drop accessible, we should make it usable. There should be indications that something is draggable, that the dragging has started, what targets are available for dropping, that the dragging has succeeded or been cancelled. These indications, easily available from the HTML5 interface, should be configurable by the user agent. Drag and drop should be undoable. In other words, not only experts on accessibility should look at drag and drop but usability experts as well.

Disappointed that my <a href="http://www.brothercake.com/site/resources/scripts/dbx/">dbx library</a> didn't get a mention, since it was the first ever implementation of keyboard-accessible drag and drop, released back in March 2006, when most people snorted at the idea. Still, I couldn't expect you to know that - even I didn't know for sure until I checked the internet archive!

Anyway, what I did with that library, which diverges from most drag and drop scripting, is limit the availability of drop targets. You can't pick objects up and put them just anywhere - you can only swap them with other objects that are defined as drag objects. The advantage of this approach is that it significantly improves usability for keyboard users since it's immediately clear what kind of actions are available - you know which directions you can move in, and therefore which arrow keys to press. And you get a transition animation to accompany that move, which is not just to be shiny, it serves that usability function of showing you what action has occurred in case you missed the discreet swap.

But - and here's my real point - the reason it has such good keybaord accessibility is that is was designed like that from the start. It didn't have accessibility tacked on afterwards, it was designed to be accessible from the very beginning. It has accessibility "baked in" - a concept which still seems alien to the HTML 5 group.