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

using

http://jqueryui.com/sortable/

on mobile devices, ipad android tablet whatsoever also yields that HTML5 based D&D has not been given some love by mobile browser developers too:

http://caniuse.com/#feat=dragndrop

Just a comment. If that would be the only possibility to reorder things in an UI it would be a clear miss in terms of functionality. Therefore, having e.g. a two-button alternative for reordering is a must have here (that itsself is possibly accessible, too).

Stefan


Sent from my iPad

On 14.09.2015, at 02:37, Bryan Garaventa <bryan.garaventa@ssbbartgroup.com<mailto:bryan.garaventa@ssbbartgroup.com>> wrote:

Thanks, as I've said, I do understand the points. I'm not saying that the spec text is right and that it should stay around, what I'm saying is that there are legitimate and current uses for the API mappings, and those should not just be deleted at the same time; which will make it impossible to achieve accessible mouse-related widgets in the future.

We all agree that ARIA Drag and Drop doesn't make sense, but I don't see why these attributes can't be repurposed into a section of the spec that does make sense so as not to lose this functionality for the foreseeable future.

Here is an example of why this is important.

This is the jQuery UI Sortable List demo:
http://jqueryui.com/sortable/

This is totally 100% inaccessible to all screen reader and keyboard only users, but you can use the mouse on it. It's good for a sighted mouse user, but it sucks if you are blind and this is included within business class software that your job depends on to interact with.

If you propose to the jQuery UI guys to completely revamp this widget to make it accessible like this, it will never happen.

If you look at the markup structure, you can see that it is very similar to the one that I built however, and if these API mappings are available to be used for this purpose, it actually is possible for the jQuery team to make this widget accessible by doing something similar with what they already have built. This is much more likely going to result in an accessible widget that telling them to just do something different for disabled people.

If these API mappings are deleted for so-called lack of interest however, making a widget such as the one above accessible using its present markup structure will literally be impossible to achieve.

So if I can counter propose, why can't we delete the spec text for Drag and Drop which doesn't make any sense, and write a new section around the valuable aspects of what these attributes provide in the accessibility API instead?

This way you get rid of a confusing section that misleadingly implies mouse drag and drop activity, while at the same time adding clearer guidance where attributes such as these are actually of value for AT users.




-----Original Message-----
From: James Craig [mailto:jcraig@apple.com]
Sent: Sunday, September 13, 2015 4:27 AM
To: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com<mailto:bryan.garaventa@ssbbartgroup.com>>
Cc: Richard Schwerdtfeger <schwer@us.ibm.com<mailto:schwer@us.ibm.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


On Sep 12, 2015, at 1:24 PM, Bryan Garaventa <bryan.garaventa@ssbbartgroup.com<mailto:bryan.garaventa@ssbbartgroup.com>> wrote:

What I don't understand about this whole argument is this, if what I've already built is accessible, which you can verify by testing it on desktop and touch devices, what is so inaccessible about it that requires a total functionality redesign?

I'm not arguing that you've built something inaccessible.

I'm arguing a few points about @aria-grabbed and @aria-dropeffect:

1. The attributes were never capable of solving the drag&drop problem they were intended to solve. Instead they created yet another way to simulate selection+action, and we already have numerous ways to do that in HTML and ARIA. For example, using two <button> elements is a much simpler way of accomplishing the same thing.

2. Because the API implies that it's somehow related to drag&drop, it's harmful to keep around, because it only serves to confuse authors.

3. We have evidence that no one inside the working group has built an example that works alongside real drag&drop, so there is no working example for the confused web authors to reference, just more confusing examples that don't clarify how this API is related to drag&drop.

4. We have little or no evidence that anyone outside the W3C working group has used these features at all, so the web authoring community is unlikely to miss them, or even notice that they've been deprecated.

Keep in mind, we are not just talking about Apple devices, but all platforms like Windows using JAWS and NVDA.

:-/

I always keep that in mind. I work on the Web.

James