Currently, drag and drop features are not fully keyboard accessible. While the
current specification would indicate that you can do a cut, copy, and a paste
at the target using the keyboard this is a partial implementation of HTML 5's
drag and drop capability and therefore inconsistent with what the user is
intending to do. 

Here are some of the problems:

- What the cut/copy/paste solution lacks is the fact that, although you can
copy to a target, it does not allow you to copy with a reference or link to the
source, meaning that the current specification only allows for a move or a
copy. 

- You are doing a cut, copy, and paste operations and not a drag and drop
operation. Basically this is saying that people with disabilities are operating
off the clipboard and not doing a drag and drop - this is confusing. 

- Some applications may trigger script when the drop operation occurs such that
the drop causes something to execute. The current design does not allow the
user to choose the drop operation that occurs. It is also confusing to have a
paste perform a function which causes something to execute. 

- Once you have selected items for cut or copy you can navigate around the web
page with the keyboard but you cannot see the items you have grabbed unlike
with drag and drop. The user may be mobility impaired, and not blind, and this
information has been removed from their UI. The mobility impaired sited user
should be able to see what they have grabbed as they navigate with they
keyboard.

In short the user is only provided partial access to HTML 5 drag and drop
functions and usability was not addressed for a person with a disability. 

What I would recommend is that the functions that are execute as a result of
mouse events be executable without having to provide the mouse information to
the JavaScript methods. This way a person keyboard enabling drag and drop can
use all the functionality of the functions executed during mouse drag and drop.
When integrated with WAI-ARIA the full semantics of the drag and drop may be
provided in the content for the user. The user should be able to see the
grabbed items follow the keyboard focus as the navigate the page to the drop
target. 

This would be less of an impact to the spec. than an entire rewrite.

As long as the author makes the target drop zone focusable using tabindex="", I
don't see why the model in the spec wouldn't be keyboard accessible. The spec
is written in an input-device-neutral fashion; you don't have to use a mouse or
anything to use the mechanism. It could be exposed as copy/paste, or as some
other mechanism like a modal drag/focus/drop operation. It really seems to be
an implementation issue to me.

Could you elaborate on what in the spec is incompatible with a keyboard-only
implementation?

I looked into this a bit more.

Regarding the concern about drag operations exposed via drag & drop: I believe
many native applications provide the ability to paste a link via a "paste link"
or "paste special" command. In theory, browsers could add such a menu command
that performs a drop with an effect of 'link'.

Regarding paste executing a script: this is already possible in existing
browsers with the "paste" and "beforepaste" events - which also allow altering
the contents of what is pasted. So this is not a new issue.

What Ian says is also true - the spec does not specify the exact interactions
that would cause drag and drop behavior. Nothing precludes a keyboard-driven
way to do it other than copy/paste.

Are there specific spec changes that would help ensure that implementations are
properly accessible via the keyboard?

Sure. 

Here is an example of a functions you cannot access if you are using the
keyboard that are only available in the DataTransfer attribute of the DragEvent
which is a mouse event:

- setDragImage(). It would be nice to give the mobility impaired user visual
feedback that that have grabbed something during their tabbing to the drop
target

So, the whole visual feedback piece is not there for keyboard users who do not
have a sight impairment or at least it is not apparent to me. Like a sighted
user, the sighted mobility impaired user will want to know where they are in a
drag/drop operation as they navigate elements with the keyboard to the drop
target. I don't see how this is possible with copy/paste.

The second concern is the use of effectEffect that needs to be cleared up.
Currently those properties are set during drag events. Essentially, in a drag
operation the keyboard (blind or mobility impaired) will want the drop targets
marked with the aria-dropeffect and HTML 5 dropeffect attributes at the start
of the drag operation. If you select a copy operation what event notification
will the author get to set these content attributes? This is not clear to me in
the specification. 

Third, once the user gets to the drop target how do the choose the drop
operation when all they have is a paste option? ... could be that the drop
target supports multiple types: copy, move, etc. 

Fourth, I think this is a general use case not addressed by HTML 5 but, there
may be a situation (we addressed this in ARIA) where the drop executes or
performs an action like begin a search of the dropped text. The user will want
to know that. What we suggested in ARIA is that the keyboard user be given a
popup menu to choose the options for drop. 

Fifth, how does one abort a copy, like you could a drag, and move the user back
to the grabbed object?

Sure. 

Here is an example of a functions you cannot access if you are using the
keyboard that are only available in the DataTransfer attribute of the DragEvent
which is a mouse event:

- setDragImage(). It would be nice to give the mobility impaired user visual
feedback that that have grabbed something during their tabbing to the drop
target

So, the whole visual feedback piece is not there for keyboard users who do not
have a sight impairment or at least it is not apparent to me. Like a sighted
user, the sighted mobility impaired user will want to know where they are in a
drag/drop operation as they navigate elements with the keyboard to the drop
target. I don't see how this is possible with copy/paste.

The second concern is the use of effectEffect that needs to be cleared up.
Currently those properties are set during drag events. Essentially, in a drag
operation the keyboard (blind or mobility impaired) will want the drop targets
marked with the aria-dropeffect and HTML 5 dropeffect attributes at the start
of the drag operation. If you select a copy operation what event notification
will the author get to set these content attributes? This is not clear to me in
the specification. 

Third, once the user gets to the drop target how do the choose the drop
operation when all they have is a paste option? ... could be that the drop
target supports multiple types: copy, move, etc. 

Fourth, I think this is a general use case not addressed by HTML 5 but, there
may be a situation (we addressed this in ARIA) where the drop executes or
performs an action like begin a search of the dropped text. The user will want
to know that. What we suggested in ARIA is that the keyboard user be given a
popup menu to choose the options for drop. 

Fifth, how does one abort a copy, like you could a drag, and move the user back
to the grabbed object?

What I think is needed is:

- a way to show visual indication (setdragImage) on focusable elements during a
keyboard activated drag operation. This could be provided on the source element
and the effect would be that any object receiving focus would render the image.
a drage cancel would 
- A keyboard way to trigger the drag so that author script code could be
activated to mark all the possible drop targets with a drop effect. (perhaps a
start drag event on the source element for keyboard users)
- A menu activation utility that would render the possible
aria-dropeffects/dropeffects that could be formed at the time of the drop. 
- A device independent way to cancel a drag which would include clearing the
drag images.

The drag and drop model doesn't have to be exposed to the mouse-deficient user
as copy/paste. It can be exposed as any model the UA wants to expose it as. I
don't see why any of the things you list wouldn't be possible. There's nothing
mouse-specific about the drag-and-drop model.

The problem you seem to be missing is that to keyboard enable the functions I
am suggesting the author needs to write their own script methods to reproduce
the functionality. For example, to do a setDragImage I cannot use the standard
function that is provided ONLY in MOUSE events. That means I have to do
additional, non-standard work adding additional cost to developers. If we took
this approach and follow it to its logical conclusion we would not need
drag/drop at all in HTML 5 and everyone could continue to roll their own code. 

What I want to see is for the HTML 5 specification provide equivalent support
to developers who need to support keyboard drag and drop.

There should be a standard handler that gets triggered (without using the
mouse) to notify a developer that the author has selected items for drag (the
user agent can define the key sequence) without the author having to write
extra script. 

If you think these are addressed point to me where and how in the specification
this is possible. Nowhere in the spec does it show how this functionality be
exposed to the keyboard user. 

One of the nice things about HTML 5 spec. is it has been much more prescriptive
as to how the mark up MUST be processed by the user agent. This is not the case
here.

(In reply to comment #7)
> The problem you seem to be missing is that to keyboard enable the functions I
> am suggesting the author needs to write their own script methods to reproduce
> the functionality.

No, this is incorrect. The browser can support keyboard-based drag and drop.
There's nothing in HTML5 that implies the user agent has to have mouse support
to do drag and drop. It doesn't even require a visual media UA -- you could
implement drag and drop in a speech browser, and still be compliant per the
HTML5 spec.


> For example, to do a setDragImage I cannot use the standard
> function that is provided ONLY in MOUSE events.

I have no idea what you mean here. setDragImage() is available on the
'dragstart' event, which is a DragEvent, not a MouseEvent. It fires
irrespective of the input device used to trigger drag and drop. That's entirely
up to the UA. It could be triggered by foot pedal, that would be just as
spec-compliant.


> What I want to see is for the HTML 5 specification provide equivalent support
> to developers who need to support keyboard drag and drop.

The drag and drop feature is media- and device- independent.


> There should be a standard handler that gets triggered (without using the
> mouse) to notify a developer that the author has selected items for drag (the

I assume you mean user here, not author.

> user agent can define the key sequence) without the author having to write
> extra script. 

There is. All the events in the drag and drop model work like this.


> If you think these are addressed point to me where and how in the specification
> this is possible. Nowhere in the spec does it show how this functionality be
> exposed to the keyboard user.

Nowhere in the the spec does it show how this functionality is exposed to the
mouse user either. The spec is input-device agnostic. It allows the user agent
to implement the interface however it likes.

PFWG is interested in Drag and Drop.

Rich Schwerdtfeger has been volunteered to submit a change proposal under the
auspices of the HTML Accessibility Task Force. He plans to submit this by 18
December 2009.

EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are
satisfied with this response, please change the state of this bug to CLOSED. If
you have additional information and would like the editor to reconsider, please
reopen this bug. If you would like to escalate the issue to the full HTML
Working Group, please add the TrackerRequest keyword to this bug, and suggest
title and text for the tracker issue; or you may create a tracker issue
yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Rejected
Change Description: no spec change
Rationale: It is unclear what change is being requested at this time.

Removing myself from cc list, default on bug edits is to add, but I'm only
acting on behalf of HTML A11Y TF which is already cc'd.

The HTML Accessibility Task Force intends to track these issues, per the
proposal at
http://lists.w3.org/Archives/Public/public-html-a11y/2010Jan/0245.html.

This bug predates the HTML Working Group Decision Policy.

If you are satisfied with the resolution of this bug, please change the state
of this bug to CLOSED. If you have additional information and would like the
editor to reconsider, please reopen this bug. If you would like to escalate the
issue to the full HTML Working Group, please add the TrackerRequest keyword to
this bug, and suggest title and text for the tracker issue; or you may create a
tracker issue yourself, if you are able to do so. For more details, see this
document:
  http://dev.w3.org/html5/decision-policy/decision-policy.html

This bug is now being moved to VERIFIED. Please respond within two weeks. If
this bug is not closed, reopened or escalated within two weeks, it may be
marked as NoReply and will no longer be considered a pending comment.

Reopened per discussion on 2010-03-18 a11y TF telcon

Since this was originally resolved as NEEDSINFO, is anyone going to provide the
requested info?