This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
HTML5 must fully support drag and drop operations with input devices other than a mouse, particularly using only a keyboard or keyboard emulator. While it is discussed, it is not clear whether all the required aspects are covered. Note that letting the user move a mouse pointer and buttons using the keyboard ("MouseKeys") is NOT sufficient; instead the user must be able to carry out the drag and drop operations using keyboard commands in conjunction with keyboard navigation techniques. The goal is that the functionality should be as fully-featured and as close as possible to being as convenient and efficient for keyboard users as it is for mouse users. Note that drag and drop is in some cases better than cut/copy and paste. For example: (a) cut and paste is a risky way to move information because if the sequence is interrupted the information can be lost. In this sense drag and drop is equivalent to the "select and copy/move" interaction model. (b) Drag and drop can allow a target to limit the operation to either copying or moving, whereas with cut/copy and paste the user has to choose an option at the beginning that may not be supported by the target. (c) Drag and drop allows copying or moving things without affecting the existing state and contents of the clipboard. (d) Users can modify drag and drop operations in ways that are rarely supported with cut/copy and paste, such as dragging with a modifier key to drop in a non-default format. All of these advantages should be as available to keyboard users as they are to mouse users. Use case: June is using interacting with Web page that uses HTML5's drag and drop facilities. For users like June who can't use a mouse, the web browser provides a keyboard mechanism that lets her carry out all the drag and drop operations using only the keyboard, including not only the normal drag and drop but also the behavior of drag and drop modified by various modifier keys. June presses the tab key until the focus is on the element she wants to drag (and she may have had to turn on a special mode to add drag sources to the tab order), and from its shortcut menu chooses the "Drag and drop" submenu, then "Select for Shift + drag and drop". She then presses the tab or an access key to move the focus to the drag target, and from its shortcut menu chooses the "Drag and drop" submenu, then "Drop". The browser sends the proper commands to the page's script to simulate all stages of the process, including triggering dragstart, ondrag, ondragenter, ondrop, etc. events.
mass-move component to LC1
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: Did Not Understand Request Change Description: no spec change Rationale: What about if the only input device on the computer is a mouse?
Agreed with Editor. We cannot 'require' keyboard interaction, as not all devices have keyboard.
It appears this was closed because reviewers misinterpreted the simplified wording of the bug's title. I thought the actual bug report made clear that the goal was not requiring content authors to provide keyboard UI (which would be WCAG territory) but rather than the HTML 5 spec should provide sufficient infrastructure to allow user agents to--should they choose to do so--provide UI for drag and drop for users of keyboards and keyboard emulators, just as they do for users of pointing devices. It should not be difficult for user agents to add this extra use method without the content authors having to take any extra steps beyond what they normally do for mouse users. This bug was a placeholder for more in-depth analysis. Has a11ytf reviewed HTML5's drag and drop architecture to the point where they feel this has been sufficiently addressed?
(In reply to comment #4 from Greg) > Has a11ytf reviewed HTML5's drag and drop > architecture to the point where they feel this has been sufficiently addressed? Yes, we have. Gez is the TF member who took the lead on reviewing that part of the spec and reporting back on it, and his assessment was, "as far as I'm concerned the issue with keyboard accessibility is resolved." http://lists.w3.org/Archives/Public/public-html-a11y/2011Jan/0298.html
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: The spec provides infrastructure for implementing what it calls "drag and drop" using any input device that can specify a way to pick something, whether that be a keyboard, a motion detector, a pose detector, a telepathic interface, a microphone, or anything else. It's completely input-device independent.