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

> On Sep 17, 2015, at 8:49 AM, Richard Schwerdtfeger <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
> 
> 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
> 
> James Craig ---09/17/2015 02:45:27 AM---> On Sep 16, 2015, at 9:59 PM, Bryan Garaventa <bryan.garaventa@ssbbartgroup.com> wrote: >
> 
> From: James Craig <jcraig@apple.com>
> To: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com>
> Cc: Chaals McCathie Nevile <chaals@yandex-team.ru>, Richard Schwerdtfeger/Austin/IBM@IBMUS, Joanmarie Diggs <jdiggs@igalia.com>, "lwatson@paciellogroup.com" <lwatson@paciellogroup.com>, WAI Protocols & Formats <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> 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
> 
> 
>