Bug 114643 – WebKit does not expose HTML5 drag/drop status

• Component: Accessibility
• Status: NEW

[James Craig]

Load attached test case. WebKit exposes AXGrabbed and AXDropEffects on the ARIA example but not the plain HTML5 example. Note: there is no DOM indicator for drop targets in the plain HTML5 example, so WebKit may have to monitor just based on the 'drop' event listener. There is a "dropzone" attribute, but it's not required, and it's mainly just used for limiting the type of data that can be "dropped" on the element.

[Radar WebKit Bug Importer]

<rdar://problem/13657288>

[James Craig]

Created attachment 198192 [details]
test case

[James Craig]

Looks like the Twitter image refs are no longer valid, so the demo doesn't work. E.g.

[title="brucel"] { background-image: url(http://twitter.com/api/users/profile_image/brucel); }

[Pranav Malewadkar]

Hi James,

I'm trying to fix the bug here, could you explain it to me in more detail? I'm new to WebKit. Also, will just fixing the image refs make the demo work again? Thanks!

[chris fleizach]

(In reply to comment #4)
> Hi James,
> 
> I'm trying to fix the bug here, could you explain it to me in more detail?
> I'm new to WebKit. Also, will just fixing the image refs make the demo work
> again? Thanks!

HTML notes that drag and drop items have attributes like "draggable" on them (see test case). We need to recognize those exist and augment the existing methods that expose draggable information (through ARIA properties like aria-dragged) to also include the HTML versions

[Don]

Hi Pranav,

Its possible to at least get the drag and drop aspect of the demo working by changing the background-image urls.

I grabbed a copy of the testcase, and edited it just now to use a different URL. I changed the title lines in the style section as follows, pointing to a Google image instead of the twitter images. With this change, at least now you can visually see something (corner of the Google logo) that's draggable.

[title="remy"]        { background-image: url(https://www.google.com/images/srpr/logo11w.png); }
[title="brucel"]      { background-image: url(https://www.google.com/images/srpr/logo11w.png); }
[title="Rich_Clark"]  { background-image: url(https://www.google.com/images/srpr/logo11w.png); }
[title="leads"]       { background-image: url(https://www.google.com/images/srpr/logo11w.png); }
[title="akamike"]     { background-image: url(https://www.google.com/images/srpr/logo11w.png); }
[title="jackosborne"] { background-image: url(https://www.google.com/images/srpr/logo11w.png); }

In fact, even prior to this change, I could still get drag and drop aspect of the demo to work in Firefox and Safari, just by mousing over where the images would show up if the url's were valid I found the elements are still there...just because the URL is invalid and the browser cannot render/show the image, doesn't mean there still isn't a draggable <li> element there, its just not visible is all. Anyway, the above makes it a little easier to spot the images.

Per Chris's append on 02-23, and reading between the lines a bit:

My guess what needs to happen here is that the existing webkit methods (that Chris mentions) that expose draggable information, are only looking at webkit-specific properties like -webkit-user-drag. We need to modify those methods (Chris, please feel free to correct me if I am wrong) to *additionally* look at the new HTML-5 attributes (such as 'draggable'), and effectively treat those the same way as the original equivalent webkit properties

Does that sound about right to you Chris?

[Pranav Malewadkar]

Thanks for the clarifications Chris and Don, that helped a lot. I did manage to get the demo working before (replaced the image URL's). I also had to set draggable to true, before the drag and drop worked in Safari.

[James Craig]

(In reply to comment #6)

> I grabbed a copy of the testcase, and edited it just now to use a different
> URL. I changed the title lines in the style section as follows, pointing to
> a Google image instead of the twitter images. 

Thanks! Please go ahead and re-upload your updated test case as an attachment.

[Don]

Created attachment 247494 [details]
modified original testcase such that demo works

Similar to original testcase posted by James.

Whats changed includes
1. background-image URLs no longer reference some obsolete twitter headshots, instead they now simply reference a logo image commonly presented on www.google.com's main search page. (Only a corner of it gets displayed in our testcase, but thats enough to see something draggable). The new URL is (and its the same for all 5 <li> elements, sorry) 
https://www.google.com/images/srpr/logo11w.png

2. I tweaked the Javascript slightly where the <li> elements were being iterated over and the HTML 5 'draggable' attribute was being set. The original testcase was setting 'draggable' to '' (empty string). However, the value must be one of 'true', 'false', or 'auto' (at least according to the W3 Schools folks at http://www.w3schools.com/tags/att_global_draggable.asp)

Basically, I changed a line from
    item.setAttribute('draggable', ''); // make it draggable
to
    item.setAttribute('draggable', 'true'); // make it draggable

[Don]

I also dug around the source code a little bit. 

I'm still trying to understand how it all works, but it seems that there are AccessibilityObjects that 'shadow' the original HTML Objects, which makes sense given a lot of what Accessibility is all about is exposing a 'subtree' of accessible elements from the original HTML DOM tree. 

In particular, I found a few methods that seem like they may be relevant:
These are methods on the AccessibilityRenderObject, defined in the file webkit/Source/WebCore/accessibility/AccessibilityRenderObject.{h,cpp}

Here, the AccessibilityRenderObject declares its support for ARIA Dropping and Dragging via some ARIA attributes per the methods below. Conceivably these are the specific methods James indicated need to be modified to cater for the HTML 5 "draggable" attribute, etc.

bool AccessibilityRenderObject::supportsARIADropping() const
{
    const AtomicString& dropEffect = getAttribute(aria_dropeffectAttr);
    return !dropEffect.isEmpty();
}

bool AccessibilityRenderObject::supportsARIADragging() const
{
    const AtomicString& grabbed = getAttribute(aria_grabbedAttr);
    return equalIgnoringCase(grabbed, "true") || equalIgnoringCase(grabbed, "false");
}

bool AccessibilityRenderObject::isARIAGrabbed()
{
    return elementAttributeValue(aria_grabbedAttr);
}

[James Craig]

(In reply to comment #6)

> My guess what needs to happen here is that the existing webkit methods (that
> Chris mentions) that expose draggable information, are only looking at
> webkit-specific properties like -webkit-user-drag. We need to modify those
> methods (Chris, please feel free to correct me if I am wrong) to
> *additionally* look at the new HTML-5 attributes (such as 'draggable'), and
> effectively treat those the same way as the original equivalent webkit
> properties

You might try looking at the implementation for aria-grabbed as defined in the latest editor's draft of ARIA, and comparing those states to the HTML attributes such as @draggable.

http://rawgit.com/w3c/aria/master/aria/aria.html#aria-grabbed

Points of note: VoiceOver drag drop will not work yet because neither the ARIA nor the HTML implementation of drag/drop is complete. HTML is lacking any indication of drop targets, and ARIA does not provide any way to confirm a drop target action was completed. 

This bug is only about getting the properties exposed to the AX APIs, which you can review with Accessibility Inspector.