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

I will agree with deprecation as long as it’s not actually deleted from the spec until an equally viable solution is available for ATs to utilize through the Accessibility Tree.

I believe my reason for this is still valid.

Currently there is no alternative for conveying this state information in the Accessibility Tree for ATs, and using hacks like aria-label isn’t valid because it conflicts with legitimate naming mechanisms.

My personal circumstance is equally sound. The contracts that I referred to were the result of litigation by non-sighted employees who could not perform critical path job duties as a result of the inaccessibility of drag and drop components such as these, which matched the paradigm that I showed you for the jQuery UI Sortable List demo. The dev teams were limited to the present markup structures within those widgets.

I solved this by programming keyboard accessibility into the widget, and adding a simple keyboard mechanism for triggering the actions; none of which required use of the mouse; nor did it break the original markup and styling of the widget. No menu was needed, which would have added another level of complexity to the UI that would present additional issues.

The last problem remaining was to convey this information to screen reader users who could not see when grabbed items were highlighted, nor upon which other nodes it was valid to place them. The spec provided a solution to this by the use of these attributes, by updating the state information in the Accessibility Tree to reflect the dynamic changes that occurred when the user interacted with it. These attributes changed every time a user, regardless whether they were a sighted keyboard only user, a non-sighted screen reader user, or a sighted mouse user, and it worked accessibly for all of these user groups. It even worked using Dragon by recognizing spoken key commands.

Now, if these attributes are removed before an equally equivalent solution is available to take their place in the Accessibility Tree, all of this feedback for non-sighted screen reader users will be lost. I know this for a fact, because I tested it without these attributes present, and live regions are not enough to make up the difference for making such widgets intuitively accessible.

I have never said that the ARIA attributes should control the mouse or the UI in any way. I have been saying all along that these ARIA attributes are important within the Accessibility Tree for conveying needed state information to ATs, which is consistent with every other ARIA attribute in the spec, so I see no difference there. There are no ARIA attributes that change the UI nor user interactions like mouse behavior, and I have never said that it should.

So I still find this situation very frustrating, because it is negating a provably accessible model that is consistent with how the ARIA specification and its API mappings work within the Accessibility Tree.

If at some point HTML5 can provide the same functionality, then I will be happy to utilize that instead. Nobody has said how long the timeline for this is though, which I previously asked. So until this is actually implemented equally within browsers, I have no choice but to continue using these attributes to build provably accessible widgets, even if the W3C votes to ‘pull the rug out’ as was said.

Additionally, it must be formally noted that doing this without an equally accessible alternative available will have a negative impact on the employment of affected non-sighted screen reader users who are presently using currently implemented widgets such as these in the future.


From: James Craig [mailto:jcraig@apple.com]
Sent: Friday, September 18, 2015 1:22 AM
To: Richard Schwerdtfeger <schwer@us.ibm.com>
Cc: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com>; Chaals McCathie Nevile <chaals@yandex-team.ru>; 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 Sep 17, 2015, at 3:29 PM, Richard Schwerdtfeger <schwer@us.ibm.com<mailto:schwer@us.ibm.com>> wrote:

You do have to navigate to something with the keyboard to do a drop.
This is not a correct assumption. Accessible drag&drop does not require keyboard navigation to the drop target on iOS, or for certain operations on OS X. I expect other touchscreen and trackpad-enabled screen readers may provide similar functionality currently or in the future.
Keyboard users would do that.
Most keyboard users would not attempt drag&drop, and if they didn't they'd likely use mouse keys. (Note: I'm talking about sighted keyboard users here. AT users have other functionality in the AT that can allow mouse emulation without the necessity for vision.)
So, I disagree with you that multiple options are redundant.
The redundancy is not that the options exist. It's that they are represented in multiple places.

Authors have to show a menu to make drop effects accessible now. This menu could be presented as select list, radios, etc. Because the options are represented in this UI control, there is no need to *also* put them in an @aria-dropeffect attribute...

Hopefully that clarifies my point about redundancy.
The use cases provided are common use case for desktop applications. Also, some objects may NOT support the specific drop effects, like move or execute. In Windows you have multiple drop effects that you can choose from based on the use cases you have. For example, if you hold the control key and a click (it has been a while since I used Windows for this) and then you drag It results in a move vs. a copy. A user should not have to pop up a menu to figure out which operation is supported "peak" unless there are multiple options. It is the drop target that determines what function is supported on the drop.
The drop target does not determine anything. It's just an event target DOM node. The business logic of the web application (e.g. the JavaScript view controller) determines the functionality.
Here is why, what if your menu that gets popped provides an option that is not yet supported at any of the targets?
I think you assume I'm proposing something that I'm not. I'm not suggesting a web app provide UI that it can't support. I'm not sure what gave you that impression, but it wasn't my intention.
What if the determination of what can be dropped on a target is based on a whole collection of times leading up to initializing the drag?
The JavaScript controller determines that behavior in real time.
The ARIA information is to convey semantics to an assistive technology. If you were using the keyboard you don't need all those events as you are moving through your UI with the keyboard. It is certainly better to have the events
I'm saying I don't think accessible drag&drop can work *without* the events, so ARIA's solution will never be a viable option. As responsible maintainer of ARIA, we should recognize this and deprecate @aria-grabbed and @aria-dropeffect.
and I agree that it would be better to have this ALL handled by the user agent. However, the HTML working group failed to deliver a solution and I do not see one on the horizon. So, I will tell you that both browsers and HTML are far more woefully incomplete at this time. My experience with those meetings was a lot of grandstanding that they had developed a drag and drop solution and they let it all fall on the floor like a number of things that happened in that group.
You'll get no argument from me that some aspects of W3C Working Groups are dysfunctional. ;-)

HTML's drag&drop is salvageable though, and lot more much complete than ARIA's.
So, until the browsers get a solution that really works and addresses the use cases that exist in drag and drop today we should not shoot the people who are currently using the aria drag and drop work because it is accessible to them. Also, Bryan went and did those jobs on contracts. When you leave a contract you just don't stroll in later on and say all that software I put in that you are finding useful is now broken and pay me to fix it.
With all due respect to Bryan and his contracts, our goal as spec writers is to make the best web API possible.

It's okay to disagree if you think my proposed API change does not improve the state of ARIA.
It's not okay to disagree just because someone has been paid to do it the old way.
We just can't pull the rug out under people because there might be a better solution in the future.
We can—and should—if we believe the change is necessary.
Unless you can make one materialize in all the browsers there is no reason to delete it from the spec.
I don't think we should delete it. I want to mark it as deprecated.
I do agree that we should indicate clearly that an alternative solution that is more robust is being seeked.
Sounds like we're in agreement that it should be marked as deprecated and left in the spec.
Most importantly, this has already been coded and implemented on at least some sites. We have to give some runway and "we are sorry, we deleted it because we might see something better down the road."
Deprecating it isn't going to make it stop working. I think it should still validate, too.
I am sure Apple, like IBM, and Microsoft has things that they end up doing better in the future but we typically don't just haul things out like APIs over night on people without a real plan for a replacement.
Seems like somewhere you got the impression I wanted to delete all reference to the attributes. That is not my intention.

The subject line includes "deprecate" which, within the W3C context means ~"mark as deprecated but leave in." I may have referenced the verb "remove" but it was used in the context of deprecation, not deletion.

So, have we agreed that @aria-grabbed and @aria-dropeffect should be deprecated?

Thanks,
James


This was meant to be a complement and had nothing to do with ARIA:

It would actually be very cool to be able to use this to leverage the new Apple 3D touch to generate those menus in the future if multiple options were available.

Rich






Rich Schwerdtfeger

[Inactive hide details for James Craig ---09/17/2015 11:10:53 AM---> On Sep 17, 2015, at 8:49 AM, Richard Schwerdtfeger <schwer@]James Craig ---09/17/2015 11:10:53 AM---> On Sep 17, 2015, at 8:49 AM, Richard Schwerdtfeger <schwer@us.ibm.com<mailto:schwer@us.ibm.com>> wrote: >

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>>, Chaals McCathie Nevile <chaals@yandex-team.ru<mailto:chaals@yandex-team.ru>>, 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/17/2015 11:10 AM
Subject: Re: ARIA 1.1: Deprecate @aria-grabbed and @aria-dropeffect
Sent by: jcraig@apple.com<mailto:jcraig@apple.com>
________________________________




On Sep 17, 2015, at 8:49 AM, Richard Schwerdtfeger <schwer@us.ibm.com<mailto:schwer@us.ibm.com>> wrote:

Well, aria-dropeffect is actually not just for clickable elements.

The specification of aria-dropeffect now is that you navigate to a focusable element and press a key. Whether the elements take a 'click' event or a 'keyup' event, the end result is that the user "presses" it.

Although, that is certainly one implementation. When you drop things you don't always have to click on them.

With real drag&drop you don’t. With ARIA dropeffect, you have to navigate to something and click a key.

You would probably want to use keyboard keys in some scenarios.

Is you are talking about mainstream full keyboard access… I agree, but that’s unrelated to drag/drop.

https://rawgit.com/w3c/aria/master/aria/aria.html#aria-dropeffect<https://urldefense.proofpoint.com/v2/url?u=https-3A__rawgit.com_w3c_aria_master_aria_aria.html-23aria-2Ddropeffect&d=BQMFAg&c=eEvniauFctOgLOKGJOplqw&r=_CJHAxKW6RlD1Am-_BoB7w&m=xCYzhhNv2EU7oJIDbOQHx7LZnxuRn9Vg7E7VOpj9wm4&s=Zjfc0v0ig231ha9vLpUGlxbzHUPsX-MSWHOdEs76HUQ&e=>

It is for indicating which elements are able to receive a drop after a selection based on the sources selected. It also tells you what type of drop it supports

It supports no “drops” at all. All it does is indicate the action that will be taken when you press or click to trigger the functionality. A button label allows the same functionality <button>copy</button>

and if there are multiple options you can provide a popup.

You don’t do that with aria-dropeffect. For multiple options, drop effect is entirely redundant. You choose your selection in the resulting author-provided menu. User presses a "drop target" button; author focuses a new pop up menu (no longer on the drop target), user chooses option, e.g. Copy, move, etc.

It would actually be very cool to be able to use this to leverage the new Apple 3D touch to generate those menus in the future if multiple options were available.

The ARIA spec does not provide any event model for doing this or notifying the author that it’s happened. The ARIA drag/drop specification is woefully incomplete and should be deprecated.

Also, ARIA is not supposed to affect mainstream UI, and your suggestion breaks that pattern.

James


Rich Schwerdtfeger

[Inactive hide details for James Craig ---09/17/2015 02:45:27 AM---> On Sep 16, 2015, at 9:59 PM, Bryan Garaventa <bryan.garaven]James Craig ---09/17/2015 02:45:27 AM---> On Sep 16, 2015, at 9:59 PM, Bryan Garaventa <bryan.garaventa@ssbbartgroup.com<mailto:bryan.garaventa@ssbbartgroup.com>> wrote: >

From: James Craig <jcraig@apple.com<mailto:jcraig@apple.com>>
To: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com<mailto:bryan.garaventa@ssbbartgroup.com>>
Cc: Chaals McCathie Nevile <chaals@yandex-team.ru<mailto:chaals@yandex-team.ru>>, Richard Schwerdtfeger/Austin/IBM@IBMUS, 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/17/2015 02:45 AM
Subject: Re: ARIA 1.1: Deprecate @aria-grabbed and @aria-dropeffect

________________________________




> On Sep 16, 2015, at 9:59 PM, Bryan Garaventa <bryan.garaventa@ssbbartgroup.com<mailto:bryan.garaventa@ssbbartgroup.com>> wrote:
>
> 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.

My answer was that several other existing features already do a better job at providing the same or better functionality. Since @aria-grabbed and @aria-dropeffect are just markers for clickable UI elements, you can already do the exact same thing with two <button> elements. Or ARIA buttons. Or checkboxes. For example:

When you press this button.
<button aria-label="Item 1 (Mark to reorder)">Item 1</button>

It changes to:
<button aria-label="Item 1 (Reordering, Next select the new location)">Item 1</button>

And then you press another button to move it it there.
<button aria-label="Item 2 (Move Item 1 after Item 2)">Item 2</button>

Since @aria-grabbed and @aria-dropeffect are just markers for clickable UI elements, there is no need for a replacement, and no need to hold the attrs around until native drag&drop is accessible, because that's an unrelated problem.

James