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

Well, aria-dropeffect is actually not just for clickable elements.
Although, that is certainly one implementation. When you drop things you
don't always have to click on them. You would probably want to use keyboard
keys in some scenarios.

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 and if there are multiple options you can provide a popup.
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 Schwerdtfeger



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