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

Thanks, I do see your point and that the metaphor isn't exact.

I think my question still stands as well though, if I don't use these attributes for this purpose, what option do I have in ARIA to accomplish providing the correct feedback for non-sighted AT users?

E.G I need to convey (1) When an element can be grabbed, (2) when an element is grabbed, and (3) which element or elements it is valid to move the grabbed element to.

I don't understand what you mean by "mark of action" and "confirm action".

How would I code a sortable Listbox widget for non-sighted AT users in such a way that I can provide simple sortability, even if I do include mouse draggability?

-----Original Message-----
From: James Craig [mailto:jcraig@apple.com] 
Sent: Friday, September 11, 2015 5:45 PM
To: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com>
Cc: Richard Schwerdtfeger <schwer@us.ibm.com>; 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

The key commands work now.

I think my point still stands though. This is not related to drag and drop and could be implemented a number of ways. You're using "grabbed" here to represent a keyboard selection that is completely unrelated to a "drop target"... I think the metaphor of "mark of action" and "confirm action" is more relevant to your usage.

AFAIK, the other facts also remain:

1. I've never seen an example that works with mouse-based drag & drop.
2. I've never seen usage (even an example) other than those authored as test cases by members of the PF working group.




> On Sep 11, 2015, at 5:30 PM, Bryan Garaventa <bryan.garaventa@ssbbartgroup.com> wrote:
> 
> Okay, I've pushed the updated code to
> http://whatsock.com/tsg/Coding%20Arena/ARIA%20Listboxes/Sortable/demo.

> htm
> 
> Can you please let me know if this now works on the Mac? I don't have one so I can't test this myself. It works in IE, FF, and Chrome on Windows. If yes, I'll push the fix out to all related projects on GitHub.
> 
> Also, in reading the latest DOM spec draft, I see that 'keypress' is actually deprecated, as is event.keyCode. Is this true? If yes, then what is the best way to get char codes across all browsers for key code detection?
> 
> What about this?
> 
> // within keyDown:
> var key = event.key || event.keyCode || event.which;
> 
> Thanks,
> Bryan
> 
> -----Original Message-----
> From: Bryan Garaventa [mailto:bryan.garaventa@ssbbartgroup.com]
> Sent: Friday, September 11, 2015 3:07 PM
> To: James Craig <jcraig@apple.com>
> Cc: Richard Schwerdtfeger <schwer@us.ibm.com>; 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
> 
>> You're not cancelling your key events properly, so it doesn't work on Mac OS X El Capitan, either.
> 
> Actually that's not the problem, I'm using event.preventDefault().
> 
> This is the problem:
> http://www.quirksmode.org/js/keys.html

> 
> Cross browser key support is a mess. When I wrote that in 2013 I used 'keypress' for several keystrokes which is likely what you are talking about. I'll move this into 'keydown' instead.
> 
> Regarding the ARIA attributes, this seems like a case of throwing the baby out with the bath water.
> 
> 
> 
> -----Original Message-----
> From: James Craig [mailto:jcraig@apple.com]
> Sent: Friday, September 11, 2015 10:29 AM
> To: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com>
> Cc: Richard Schwerdtfeger <schwer@us.ibm.com>; 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 11, 2015, at 9:25 AM, Bryan Garaventa <bryan.garaventa@ssbbartgroup.com> wrote:
>> 
>> 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.
> 
> To me, "grabbed" is an ambiguous variant of dragged. 
> 
>> I have a demo comparison that illustrates why this is useful at 
>> http://whatsock.com/tsg/Coding%20Arena/ARIA%20Listboxes/Sortable/demo.

>> htm
> 
> You're not cancelling your key events properly, so it doesn't work on Mac OS X El Capitan, either. 
> 
> Furthermore, ARIA grabbed/droptarget demos that do not work with drag&drop only serve to further confuse an already confused audience of web authors that legitimately want to make their interfaces accessible, but do not know how.
> 
>> From what I’m seeing, the only proposal being made is to deprecate 
>> the attributes,
> 
> That's correct.
> 
>> but nothing is being suggested to replace this with something else that provides equal accessibility.
> 
> That's also correct. In my opinion, accessible drag&drop on the web can only be reasonably solved by an HTML API, not an ARIA retrofit. HTML5's drag& drop API was lacking, but a future version may solve it.
> 
> James
>

Received on Saturday, 12 September 2015 01:04:51 UTC