This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Background: http://www.w3.org/WAI/PF/aria/#dragdrop http://lists.w3.org/Archives/Public/wai-xtech/2009May/0008.html Note: At the time of this bug I don't think any browser has coalesced HTML5 draggable with ARIA semantics. We need to figure out if there is any other work required on the browser side. What events and semantics would we map to on the desktop? (I mean apart from exposing in object attributes). Probably none for now.
More info: http://lists.w3.org/Archives/Member/w3c-wai-pf/2009AprJun/0424.html
We need to reconcile ARIA dnd with HTML5 dnd: http://www.w3.org/WAI/PF/aria/states_and_properties#attrs_dragdrop http://www.whatwg.org/specs/web-apps/current-work/multipage/dnd.html#dnd ARIA: aria-dropeffect: copy|move|link|execute|popup|none aria-grabbed: true|false|undefined Note: these attributes are to be used descriptively where the web developer has already implemented the mechanism (and any messaging/events) required to render the drag and drop behaviour. HTML5: aria-dropeffect: copy|move|link|none draggable: if present, this node can be dragged. Note: the browser also fires events dragenter, dragover, drop I prefer the reduced set of dropeffects described in HTML5. Reassigning to Cynthia for task force followup.
From Gregory: in the HTML specification, event names are defined in a device independent way so they SHOULD be able to be made accessible to keyboard only users, but the subject/topic/mechanism for controlling the drag and drop processing model defined in the HTML5 specification at: http://dev.w3.org/html5/spec/dnd.html#drag-and-drop-processing-model is not currently keyboard accessible in any known browser implementation. the HTML5 drag and drop mechanism defines seven events: * dragstart (initiate the drag and drop operation) * drag (continue drag and drop operation) * dragenter (determine if accepted) * dragleave (leaving a target) * dragover (provide feedback to user) * drop (complete the operation) * dragend (tidy up) according to gez lemon's research for the HTML A11y Task Force, however, these seven events cannot currently be activated using the keyboard alone in user agents. gez and mike smith (co-chair of the HTML A11y TF) made multiple attempts to solicit implementor feedback on whether the HTML5 drag and drop model can be performed from the keyboard, eric carlson of apple replied, in an emessage archived at: http://lists.w3.org/Archives/Public/public-html-a11y/2010Jun/0137.html QUOTE You can't do this in WebKit today, but I can't think of any reason it couldn't be made to work UNQUOTE maciej stachowiak, also of apple, in a post archived at: http://lists.w3.org/Archives/Public/public-html-a11y/2010Jun/0261.html wrote: QUOTE I will add that there is no system-wide convention for this on Mac OS X, as far as I know. It's something we'd want to discuss with Apple's accessibility people. UNQUOTE in response to (the frankly paltry) implementor response to both gez' and mike smith's requests for implementor feedback, gez, in a post archived at: http://lists.w3.org/Archives/Public/public-html-a11y/2010Jul/0056.html QUOTE I don't think the specification [HTML5] would need changing if it's possible to activate the events using the keyboard alone, as the specification makes it clear at the start and throughout that the drag and drop mechanism should be device independent. My concern is whether it is possible to create the chain of events required to complete the drag and drop operation using the keyboard alone. The WAI-ARIA Authoring Practices document outlines the following workflow for accessible drag and drop [1]: 1: Identify draggable objects 2: Allow the user to initiate the appropriate drag operation using the keyboard 3: Mark the drop targets 4: Implement keyboard functionality to assist the user and AT with executing the drop 5: Allow the process to be cancelled at any point 6: Tidy up after the drag and drop operation HTML5 defines attributes to make that workflow possible, but I have reservations that the chain of events could be triggered in a device independent manner. HTML5 defines the following events: * dragstart * drag * dragenter * dragleave * dragover * drop * dragend It's difficult to imagine how some of these events get fired using the keyboard alone against the accessible workflow defined in the WAI-ARIA Authoring Practices document. For example, the dragover event implies a similar mode of operation to mouseover. This can obviously be triggered by any pointing device, but how would that be triggered by the user agent when the user is using a keyboard? The specification states that user agents must process these events according to a particular sequence [2]. Part of that sequence defines where dragover should be fired, and that's the point that the dropEffect property value is conveyed to the user (for example, "copy", "link", "move", or "none"). It's not immediately obvious to me how this can be implemented using the keyboard alone so that essential information is conveyed to the user. [1] http://www.w3.org/TR/wai-aria-practices/#dragdrop [2] http://dev.w3.org/html5/spec/dnd.html#drag-and-drop-processing-model UNQUOTE like gez, i can't find any mention of a "copy and paste API" in the HTML5 specification, although one used to be listed at: http://dev.w3.org/html5/spec/Overview.html#copy-and-paste that section doesn't appear to exist anymore. the only mention of copy and paste i could find in the same document in dev.w3.org/html5 is an example included in the introduction to the MENU element http://dev.w3.org/html5/spec/interactive-elements.html#menus-intro which illustrates how to use the MENU element to create a toolbar styled as buttons with drop-down menues, in which the "Edit" button contains a "Copy" and a "Paste" item, controlled by javascript to make drag and drop accessible with HTML5, therefore, what is required is that HTML5 adequately define what can be achieved via copy and paste using drag and drop, then it could be recommended that HTML5 define a copy and paste API in their current work. if that is not a viable solution, then the HTML5 drag and drop API MUST be amended to allow the workflow suggested for drag and drop in the WAI-ARIA Authoring Practices document: http://www.w3.org/TR/wai-aria-practices/#dragdrop this solution has been suggested by gez to the HTML5 A11y Task Force and is awaiting further discussion in that forum what do i need to do with this information for the implementor's guide?
From Gez: Hi Gregory, Thank you so much for picking up this issue. I think it's clear that although the HTML5 specification states that the drag and drop mechanism should be device independent, it's reverse engineered from a mouse-based implementation, and the order of states required to complete a drag and drop implementation couldn't possibly completed using the keyboard alone. Like you, I would like to see the current drag and drop mechanism altered so that it can be implemented in a device independent way. If the copy and paste API is required to make this work, it will need to be amended so that it fits with the workflow defined in the WAI-ARIA authoring practices document - for example, identifying draggable objects and explaining the effect of dropping the source on a target.
From David: If the UAIG is still scoped to ARIA I don't think there is more to add regarding aria-grabbed and aria-dropeffect. The success of device independence for ARIA drag and drop is really up to the web developer. My spidey sense tells me there is potential for user agent assisted device independence with HTML5 drag and drop (which isn't purely descriptive markup) -- but I don't have the cycles to dive into this.