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

James,

The browser keyboard support in iOS is a sore subject for IBM and it is the
only browser I am aware of that does not fully support a keyboard for all
the UI elements - although I have not evaluated iOS9 yet. I don't think
this the place to debate that however.

Bryan has told you that the he used the ARIA properties in his engagements
and they worked fine. We agree that they are not the right longer term
goal. ARIA cannot define the actual events. This needs to be defined and
handled by the host language. Unfortunately, I don't see this any time
soon.

Regardless, we are not debating that a better solution is needed. The issue
here is we don't have an alternative. Until we do we should leave what we
have deprecated vs. removing it.

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/18/2015 03:22 AM
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
      > 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> wrote: >

      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