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

Bryan,

I trust you and support your position. We do have to make it clear though
that deprecation means we will be looking for an alternative solution.

As soon as we get by the "feed" discussion we can get agreement on the call
and put it up for a straw poll. I think it will require that. I will tell
you that I personally do not want to be responsible for doing harm to
disabled people by pulling the rug out from under them, even if there are
only a few cases that we are aware of where that occurs. I believe that is
what I believe would happen if we don't wait until a viable alternative is
engineered into the browser.

I think it will take a long time to see an alternative in the browser
though. With the move to mobile I see a lot less need for drag and drop.
That may change as real estate in mobile devices get larger. There are a
lot higher priorities than drag and drop underway: web components, SVG,
device independent interaction, etc.

Rich


Rich Schwerdtfeger



From: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com>
To: James Craig <jcraig@apple.com>, Richard
            Schwerdtfeger/Austin/IBM@IBMUS
Cc: 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 12:21 PM
Subject: 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
      > 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