- From: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com>
- Date: Thu, 18 Feb 2016 19:47:31 +0000
- To: Richard Schwerdtfeger <richschwer@gmail.com>, "public-aria-admin@w3.org" <public-aria-admin@w3.org>
- Message-ID: <SN1PR0301MB1981C6BDAEAB69CE7BED055098AF0@SN1PR0301MB1981.namprd03.prod.outlook.>
Apologies, I replied to the wrong message. From: Bryan Garaventa [mailto:bryan.garaventa@ssbbartgroup.com] Sent: Thursday, February 18, 2016 11:44 AM To: Matt King <a11ythinker@gmail.com>; 'Richard Schwerdtfeger' <richschwer@gmail.com>; 'ARIA Working Group' <public-aria@w3.org> Subject: Comments regarding Combobox in the ARIA Caucus meeting Hi, I wished to bring this up here since it allowed me to read the minutes first, and also due to the time restriction. I don't have any problem with supporting the alternative method for role=combobox that was proposed, as a secondary option to the way people have been doing it for years. I still don't understand what is so intrinsically inaccessible about how people have been constructing these widgets as I've mentioned however, that necessitates a paradigm shift and the statement that this new alternative method is "preferred" according to the spec. So far the only statement I see regarding this is the following: MK: That particular structure is in ARIA and the web world. ... But the screen reader developers are rejecting. ... The engjineers are aware of the XAML structure, but do not like it. My concern is this, we have been providing this provably accessible construct of input+type='text'+role='combobox'+aria-expanded='false'+aria-autocomplete='list'+aria-controls='listbox'+aria-activedescendant='optionId' literally for years. This has been incorporated into client sites in all sectors and industries, including online banking, the entertainment industry, the travel industry, the healthcare industry, amongst many others including government agencies. Saying that this new way of doing things is "preferred" according to the spec simply for the reason that developers don't like it, is very dangerous, and has the potential to negatively impact millions of daily users across countless sites where these components are currently implemented accessibly. It concerns me that screen reader vendors are hot and bothered about a new way of doing something, which increases the likelihood that the old, supposedly 'not preferred' method of doing this, will be quietly dropped between the cracks and no longer supported without any consideration of this. I have already observed that some screen reader venders will do this. From: Richard Schwerdtfeger [mailto:richschwer@gmail.com] Sent: Thursday, February 18, 2016 11:28 AM To: public-aria-admin@w3.org Subject: 7 Day Call for Consensus February 18, 2016 ARIA Working Group Resolutions This is a Call for Consensus (CfC) to the Accessible Rich Internet Applications (ARIA) Working Group on the following resolutions: 1. Accept the proposed addition of aria-details and the removal of aria-describedat from the ARIA specification pertaining to Issue1009: https://rawgit.com/w3c/aria/issue1009/aria/aria.html#aria-details Here is a link to the minutes of the meeting minutes: https://www.w3.org/2016/02/18-aria-minutes.html If you object to these proposed resolutions, or have comments concerning them, please respond by replying on list to this message no later than 23:59 (Midnight) Boston Time, Thursday 25 February, 2016. Rich Schwerdtfeger, Email: richschwer@gmail.com<mailto:richschwer@gmail.com> CTO Accessibility IBM Software http://www.ibm.com/able <http://www.ibm.com/able> The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI) Chair, Accessible Rich Internet Applications https://www.w3.org/WAI/ARIA/
Received on Thursday, 18 February 2016 19:48:08 UTC