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

Good point. I am asking our product teams. Offhand, I don't know that
anyone is using it. Also, I don't see a whole lot of drag/drop on mobile.
Also, the browser's don't consistently handle drag drop either.
I
n Leon you were proposing an alternative vocabulary. If we don't see any
products impacted I don't see an issue with deprecating it and
reinvestigating in ARIA 2.0. We are going to do much more with web
applications in 2.0.

Rich


Rich Schwerdtfeger



From:	James Craig <jcraig@apple.com>
To:	WAI Protocols & Formats <public-pfwg@w3.org>
Date:	06/19/2015 04:43 AM
Subject:	ARIA 1.1: Deprecate @aria-grabbed and @aria-dropeffect



In an effort to reduce the author complexity of ARIA, I'd like to propose
the spec's first deprecations: @aria-grabbed and @aria-dropeffect.

The primary reason is that the API does not actually provide or even relate
to real drag/drop behavior, so the attributes aren't beneficial to the
author or end user. Even the best test cases I've seen do not provide any
augmented behavior related to drag/drop; the examples act merely as a
selection marker button. (E.g. Select this thing with a button; act on it
with another button.) We already have a button role that is *much* easier
to use.

Accessible drag & drop is a feature that may be better left to native
implementations. It could potentially be solved by some future version of
ARIA, but I do not believe @aria-grabbed and @aria-dropeffect do the job.
It's a bad API that should be culled from the 1.1 spec.

In case there is any objection: I could be convinced to drop the call for
deprecation if anyone can point to a single real-world web application (not
a test case) that works well in any browser+screenreader combo. The example
should use @aria-grabbed and @aria-dropeffect accurately in conjunction
with native or scripted drag and drop behavior.

James