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

You do have to navigate to something with the keyboard to do a drop.
Keyboard users would do that.

So, I disagree with you that multiple options are redundant. 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. Here is why, what if your menu that gets popped provides an
option that is not yet supported at any of the targets? 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 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 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.

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.

We just can't pull the rug out under people because there might be a better
solution in the future. Unless you can make one materialize in all the
browsers there is no reason to delete it from the spec. I do agree that we
should indicate clearly that an alternative solution that is more robust is
being seeked.

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."

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.

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



From: James Craig <jcraig@apple.com>
To: Richard Schwerdtfeger/Austin/IBM@IBMUS
Cc: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com>, Chaals
            McCathie Nevile <chaals@yandex-team.ru>, Joanmarie Diggs
            <jdiggs@igalia.com>, "lwatson@paciellogroup.com"
            <lwatson@paciellogroup.com>, WAI Protocols & Formats
            <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




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

      Inactive hide details for James Craig ---09/17/2015 02:45:27 AM--->
      On Sep 16, 2015, at 9:59 PM, Bryan Garaventa <bryan.garavenJames
      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