RE: ARIA 1.1: Deprecate @aria-grabbed and @aria-dropeffect

I understand the need for a native drag and drop solution, and I've read the spec starting at
http://www.w3.org/TR/html51/editing.html#dnd

Where it states:

"When using an input modality other than a pointing device, users would probably have to   explicitly indicate their intention to perform a drag-and-drop operation, stating what they wish   to drag and where they wish to drop it, respectively."

So this brings up a couple of questions for me.


1.       How does this translate to the Accessibility Tree, where the state of such element interactions can be interfaced properly by ATs?

2.       Doesn't this need sound remarkably similar to what aria-grabbed and aria-dropeffect actually do in the Accessibility Tree?

I would understand deprecating and removing these attributes if the native drag and drop interaction somehow was conveyed directly in the Accessibility Tree as described here, but the HTML5.1 spec appears to be saying this is up to the author, and what option will an author have to do this if these attributes are removed? The 'selection' model by itself isn't sufficient to meet this need.



From: Richard Schwerdtfeger [mailto:schwer@us.ibm.com]
Sent: Wednesday, September 16, 2015 10:44 AM
To: James Craig <jcraig@apple.com>
Cc: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com>; Joanmarie Diggs <jdiggs@igalia.com>; lwatson@paciellogroup.com; WAI Protocols & Formats <public-pfwg@w3.org>
Subject: Re: ARIA 1.1: Deprecate @aria-grabbed and @aria-dropeffect


I am not convinced that HTML has enough there yet although I agree that a native solution would be far better and it needs to encompass SVG as well.

I think some strongly worded text, on the order of: "This ARIA feature is planned for removal in a future release when more robust alternatives are made available."

We have to make sure we have this alternative solution. When we pushed for the JavaScript and CSS restriction to be removed in WCAG 2.0 from WCAG 1 we had to prove that we could produce something that worked. I think that is only fair to end users.

Rich

Rich Schwerdtfeger

[Inactive hide details for James Craig ---09/15/2015 06:03:18 PM---On Sep 15, 2015, at 1:02 PM, Richard Schwerdtfeger <schwer@us]James Craig ---09/15/2015 06:03:18 PM---On Sep 15, 2015, at 1:02 PM, Richard Schwerdtfeger <schwer@us.ibm.com<mailto:schwer@us.ibm.com>> wrote: > We cannot bank on on

From: James Craig <jcraig@apple.com<mailto:jcraig@apple.com>>
To: Richard Schwerdtfeger/Austin/IBM@IBMUS
Cc: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com<mailto:bryan.garaventa@ssbbartgroup.com>>, Joanmarie Diggs <jdiggs@igalia.com<mailto:jdiggs@igalia.com>>, "lwatson@paciellogroup.com<mailto:lwatson@paciellogroup.com>" <lwatson@paciellogroup.com<mailto:lwatson@paciellogroup.com>>, WAI Protocols & Formats <public-pfwg@w3.org<mailto:public-pfwg@w3.org>>
Date: 09/15/2015 06:03 PM
Subject: Re: ARIA 1.1: Deprecate @aria-grabbed and @aria-dropeffect

________________________________



On Sep 15, 2015, at 1:02 PM, Richard Schwerdtfeger <schwer@us.ibm.com<mailto:schwer@us.ibm.com>> wrote:

> We cannot bank on one Widget library doing this. jQueryUI only has 4% market share: http://www.perfectleads.com/marketshare/angular-js
>
> There is strong indication that its use is dropping.

jQuery was just an example because Bryan mentioned it. My comment was:

>> jQuery *and other well-maintained libraries* update to include the most performant native HTML features when they become available.

Certainly the fact that there are ~1000 JavaScript frameworks on the Web is evidence that a native implementation is more desirable than putting the onus on the framework developers.

I think there may be enough in the HTML 5.1 spec to make native HTML drag&drag accessible. I know that there is not enough in the ARIA spec to make drag&drop accessible on all platforms. We could let it limp along, or we could deprecate it. I think the responsible decision is to deprecate it and focus on the good parts of ARIA.

James