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

I would be perfectly happy if drag and drop just automatically worked with the addition of these attributes, that would save me a lot of headaches.

> The accessibility tree should be built from HTML, where that is what is there. It makes much more sense to use the same attributes as the rest of HTML (and presumably other languages like SVG that decide to implement the API and markup for drag and drop) than it does to have a "separate-but-equal" set...

Okay, that makes sense for drag and drop. I can see where it states in the 5.1 spec the different actions such as the list of possible effects and how this relates to user agents, which correlates with the ARIA attributes. So, if these do update the Accessibility Tree accordingly, then I could see the value in deprecating and removing these from the ARIA spec.

My opposition goes back to what James originally stated in an answer to my first questions about this, when I asked what would be replaced by the removal of these attributes, and the answer was nothing.

If the HTML5 drag and drop API can be proven to work accessibly and it does update the Accessibility Tree accordingly, I will support deprecation and removal of the ARIA drag and drop attributes.

However, I still oppose removal of these attributes and how they are mapped in the Accessibility APIs prior to the implementing and support of the HTML5 drag and drop API though, because if this is done before there is a viable replacement, there will be nothing for ATs to fall back on in the meantime.

It would also be important to reference the HTML5 drag and drop API including a link to this in the deprecation statement for the ARIA drag and drop attributes to make it clear what is intended to replace these in the future.

From: Chaals McCathie Nevile [mailto:chaals@yandex-team.ru]
Sent: Wednesday, September 16, 2015 6:19 PM
To: Richard Schwerdtfeger <schwer@us.ibm.com>; James Craig <jcraig@apple.com>; Bryan Garaventa <bryan.garaventa@ssbbartgroup.com>
Cc: 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

On Wed, 16 Sep 2015 21:17:55 +0200, Bryan Garaventa <bryan.garaventa@ssbbartgroup.com<mailto:bryan.garaventa@ssbbartgroup.com>> wrote:
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.”

This introduction is just badly written...


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?

The accessibility tree should be built from HTML, where that is what is there. It makes much more sense to use the same attributes as the rest of HTML (and presumably other languages like SVG that decide to implement the API and markup for drag and drop) than it does to have a "separate-but-equal" set...


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

Yes. But what ARIA doesn't do is *work*. Unlike HTML, which allows authors to make things draggable and droppable, you have to do *everything* yourself as an author.

In addition to having to make drag and drop work in HTML anyway, unless you have a very odd approach to development.

That path seems like a perfect recipe for failure.

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.

No, the accessibility tree needs to pick up the native behaviour, and I don't see where in the spec it suggests that it is the author's responsibility. Whereas ARIA explicitly requires authors to reimplement the mechanism for themselves.

cheers




From: Richard Schwerdtfeger [mailto:schwer@us.ibm.com]
Sent: Wednesday, September 16, 2015 10:44 AM
To: James Craig <jcraig@apple.com<mailto:jcraig@apple.com>>
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>; WAI Protocols & Formats <public-pfwg@w3.org<mailto: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



--
Charles McCathie Nevile - web standards - CTO Office, Yandex
chaals@yandex-team.ru<mailto:chaals@yandex-team.ru> - - - Find more at http://yandex.com