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

I understand the confusion, and I agree that drag/drop is misleading, but what I’m referring to is a feedback issue that matches visual equivalents.

For example, the ARIA attribute aria-grabbed indicates only that an item has been ‘grabbed’, not ‘dragged’, which to me conveys a difference that doesn’t necessarily require the use of a mouse drag/drop action.

I have a demo comparison that illustrates why this is useful at
http://whatsock.com/tsg/Coding%20Arena/ARIA%20Listboxes/Sortable/demo.htm


JAWS16 + IE11 has broken these attributes, and you can try this demo out there to see what this sounds like when these attributes are not supported. It makes no sense at all.

In contrast, try the same demo using JAWS16 + Firefox, and these attributes are supported, and all of a sudden it makes total sense.

My point is, visually an item may be indicated for sighted users as being ‘grabbed’, but there needs to be a way to convey this to non-sighted screen reader users as well.

From what I’m seeing, the only proposal being made is to deprecate the attributes, but nothing is being suggested to replace this with something else that provides equal accessibility.




From: James Craig [mailto:jcraig@apple.com]
Sent: Friday, September 11, 2015 12:37 AM
To: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com>; Richard Schwerdtfeger <schwer@us.ibm.com>; Joanmarie Diggs <jdiggs@igalia.com>
Cc: lwatson@paciellogroup.com; WAI Protocols & Formats <public-pfwg@w3.org>
Subject: Re: ARIA 1.1: Deprecate @aria-grabbed and @aria-dropeffect

Restarting the thread since ARIA drag/drop hasn't been deprecated yet.

Replying to one question by Bryan:

If these attributes were no longer supported, how would a non-sighted user know when an item was ‘grabbed’, and where within the tree a focusable element was enabled for being ‘droppable’?

I think you're asking the wrong question, Bryan. Even if a web author did add the ARIA drag/drop attributes and a screen reader user knew they were drag or drop targets, the drag/drop functionality would not magically start working with a screen reader. The only recommended authoring pattern conflates drag attributes with a defaultAction-based selection model (e.g. press-to-select or drop) that is totally unrelated to actual drag/drop functionality. As a inverse case in point, none of Jon Gunderson's ARIA drag/drop examples work by using mouse-based drag/drop.

This is why ARIA drag/drop is a non-starter and needs to be deprecated.

James



On Jun 21, 2015, at 4:09 PM, Bryan Garaventa <bryan.garaventa@ssbbartgroup.com<mailto:bryan.garaventa@ssbbartgroup.com>> wrote:

I agree that the way that drag and drop is worded is problematic, but I would like to ask about the value of providing textual equivalent feedback using these attributes.

I have never seen the value of using the ARIA drag and drop attributes as indicated in the spec for implementing behavior, because that is confusingly worded.

However, when there is drag and drop functionality attached to a particular widget or element, these attributes are useful for conveying that this functionality exists for non-sighted screen reader users. This is more in the sense of a textual equivalent.

E.G Within GWT, there is a tree component. You can do many things with this, and one of the options is to drag and drop tree leaf nodes from one place to another.

If these attributes were no longer supported, how would a non-sighted user know when an item was ‘grabbed’, and where within the tree a focusable element was enabled for being ‘droppable’?

From: Richard Schwerdtfeger [mailto:schwer@us.ibm.com]
Sent: Friday, June 19, 2015 11:03 AM
To: lwatson@paciellogroup.com<mailto:lwatson@paciellogroup.com>
Cc: 'James Craig'; 'WAI Protocols & Formats'
Subject: RE: ARIA 1.1: Deprecate @aria-grabbed and @aria-dropeffect

Just to be clear HTML5 tried to get common drag and drop done and it bombed. Perhaps the new web applications group can do a better job.


Rich Schwerdtfeger

[cid:image001.gif@01D0EC73.BE718810]Léonie Watson ---06/19/2015 06:46:57 AM---> From: James Craig [mailto:jcraig@apple.com] > Sent: 19 June 2015 10:43

From: Léonie Watson <lwatson@paciellogroup.com<mailto:lwatson@paciellogroup.com>>
To: "'James Craig'" <jcraig@apple.com<mailto:jcraig@apple.com>>, "'WAI Protocols & Formats'" <public-pfwg@w3.org<mailto:public-pfwg@w3.org>>
Date: 06/19/2015 06:46 AM
Subject: RE: ARIA 1.1: Deprecate @aria-grabbed and @aria-dropeffect
________________________________



> From: James Craig [mailto:jcraig@apple.com]
> Sent: 19 June 2015 10:43
> 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.

+1

[...]

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


Do you think it would be worth proposing an HTML5 extension for this?
>
> 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.


Even in test cases using ARIA to spec, I haven't yet found an example that
works reliably across all (or even most) browser/AT combinations.


Léonie.

--
Léonie Watson - Senior accessibility engineer
@LeonieWatson @PacielloGroup PacielloGroup.com<http://paciellogroup.com/>