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

I think we still have a disconnect about who this functionality is useful to.

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

I know, that's when I pointed out the jQuery UI example and said that they wouldn't rewrite it just to make it accessible like this.

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

I disagree, native drag  and drop by it's very nature is totally inaccessible to keyboard only users, and in order to make it accessible, this has to be manually programmed by the developer, and there also needs to be something in the Accessibility Tree to indicate this information to non-sighted AT users; which is what aria-grabbed and aria-dropeffect currently provide.

We can't just delete ARIA attributes that provide this information currently and say it doesn't matter.

-----Original Message-----
From: James Craig [mailto:jcraig@apple.com] 
Sent: Thursday, September 17, 2015 12:45 AM
To: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com>
Cc: Chaals McCathie Nevile <chaals@yandex-team.ru>; 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 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

Received on Thursday, 17 September 2015 16:19:58 UTC