This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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?
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?
Returning to NEEDSINFO per comment 10.
Bug triage sub-team thinks John Foliot is in a position to provide the requested information for this bug.
It appears the appropriate assignee might have been Gez, not John. Reassigning for the moment, will double-check with bug triage sub-team next week.
HTML A11Y TF has said we don't need to track drag and drop bugs because they were filed before an overhaul of that part of the spec, but will review that part of the spec again.