- From: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com>
- Date: Tue, 15 Sep 2015 20:25:09 +0000
- To: Richard Schwerdtfeger <schwer@us.ibm.com>, James Craig <jcraig@apple.com>
- CC: Joanmarie Diggs <jdiggs@igalia.com>, "lwatson@paciellogroup.com" <lwatson@paciellogroup.com>, WAI Protocols & Formats <public-pfwg@w3.org>
- Message-ID: <BLUPR03MB1507625FE51F67D5DC85AC08985C0@BLUPR03MB1507.namprd03.prod.outlook.com>
> Bryan, please weigh in on the number of customers you have that are using it and the size of these companies. Are they federal agencies? What? I know of four instances that I've worked with personally in the last three years. I can't name names due to NDA, but one is a mainstream financial institution, two are within help desk applications, and another is from a public sector agency. They do have user bases that equate to millions. I've also trained those I work with over the years to use the same technique I've demonstrated to ensure the accessibility of not just Option nodes, but also Tabs, Treeitems, and Gridcells and Rows within sortable Grids. I don't know to what extent these have propagated outward in that time. The problem with removing aria-grabbed and aria-dropeffect from the API mappings, is that it will render all instances of these widgets suddenly inaccessible for those users, and the state information provided by their inclusion cannot be replaced by anything else if they are removed. For this reason, I agree that the spec text is confusing and needs to be changed or removed, but at the same time there needs to be an equivalent that can provide this critical state information when needed; otherwise we are driving the specification backwards and not forwards by not allowing a means for developers to use currently existing mappings to make such widgets accessible in the future wherever ARIA is supported. Since these attributes already exist and the mappings can already be proven to work accessibly on supporting platforms, it seems logical to utilize what we already have that works and remove the verbiage that doesn't so we can maximize the two without impairing current technologies that already take advantage of these features accessibly. From: Richard Schwerdtfeger [mailto:schwer@us.ibm.com] Sent: Tuesday, September 15, 2015 1:03 PM To: James Craig <jcraig@apple.com> Cc: Bryan Garaventa <bryan.garaventa@ssbbartgroup.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 We cannot bank on one Widget library doing this. jQueryUI only has 4% market share: http://www.perfectleads.com/marketshare/angular-js There is strong indication that its use is dropping. Also, regarding HTML5, that group is so fragmented right now. I look at the Web Platforms Group and I see not leadership from either Apple or Google. I also don't see drag and drop on any of their priority lists. There was also a comment about using aria-selected early. aria-selected is used in widgets for selection within the widget and not necessarily and not necessarily for drag and drop. This is why aria-grabbed was used. In fact, we have selection models in different platform APIs that this would mess up. Ditching it for nothing is a bad idea. I would support deprecating it with the meaning "we intend to replace this with a better solution in the future and to not plan on it being there." IBM does not use it but if Bryan has customers that are using it then we should not throw it completely out the door if we don't have a working alternative. Why would we do harm to people who are currently depending on it to do their work. That makes no sense. Bryan, please weigh in on the number of customers you have that are using it and the size of these companies. Are they federal agencies? What? Rich Rich Schwerdtfeger [Inactive hide details for James Craig ---09/14/2015 01:15:44 AM---> On Sep 13, 2015, at 5:36 PM, Bryan Garaventa <bryan.garaven]James Craig ---09/14/2015 01:15:44 AM---> On Sep 13, 2015, at 5:36 PM, Bryan Garaventa <bryan.garaventa@ssbbartgroup.com<mailto:bryan.garaventa@ssbbartgroup.com>> wrote: > From: James Craig <jcraig@apple.com<mailto:jcraig@apple.com>> To: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com<mailto:bryan.garaventa@ssbbartgroup.com>> Cc: Richard Schwerdtfeger/Austin/IBM@IBMUS, Joanmarie Diggs <jdiggs@igalia.com<mailto:jdiggs@igalia.com>>, "lwatson@paciellogroup.com<mailto:lwatson@paciellogroup.com>" <lwatson@paciellogroup.com<mailto:lwatson@paciellogroup.com>>, WAI Protocols & Formats <public-pfwg@w3.org<mailto:public-pfwg@w3.org>> Date: 09/14/2015 01:15 AM Subject: Re: ARIA 1.1: Deprecate @aria-grabbed and @aria-dropeffect ________________________________ > On Sep 13, 2015, at 5:36 PM, Bryan Garaventa <bryan.garaventa@ssbbartgroup.com<mailto:bryan.garaventa@ssbbartgroup.com>> wrote: > > If you propose to the jQuery UI guys to completely revamp this widget to make it accessible like this, it will never happen. No. I'm proposing that when natively accessible drag&drop is available, the jQuery UI implementation will update to use the native, accessible version in capable browsers, leaving the current implementation as a fallback polyfill. This assumption is consistent with the project's history. jQuery and other well-maintained libraries update to include the most performant native HTML features when they become available. James
Attachments
- image/gif attachment: image001.gif
Received on Tuesday, 15 September 2015 20:25:45 UTC