Re: 7-Day CFC: Put up CFC survey for members to put in a special case of option 3 that tells ATs to suppress the role when the role description has a null value and to move the text/static role to ARIA 2.0 or to accept option 3 and move the text/

Both also reflect moving the text role to ARIA 2.0.

Sent from my iPhone

> On Jul 8, 2016, at 8:18 PM, Matt King <a11ythinker@gmail.com> wrote:
> 
> For those who were not in the call, this CFC asks you to vote in a pole where you can express support for 2 different versions of the aria-roledescription text.
>  
> One version says that if the value of the roledescription property is empty, user agents should ignore the roledescription. This is similar to how attributes like aria-activedescendant work. The other version allows for one special case where the roledescription may be empty and still be mapped – if the role is image. This allows authors to create an image element that will be announced by screen readers as if it were plain text. That is, a screen reader will not say “image” or “graphic” when the element is read; only the image label will be announced.
>  
> While allowing empty role descriptions on images is not as bad as allowing empty role descriptions on any element, I still believe it creates an authoring technique that is damaging to ARIA. It encourages people to use ARIA to misrepresent what is on the page, which is exactly the opposite of the fundamentals of ARIA that we teach to engineers day in and day out.
>  
> Allowing empty role description on images is also more special case processing for browsers to achieve an outcome that has little or no benefit. In the case where the content of the element is an image the *author thinks* should be read as text, the result can be counterproductive for screen reader users. If the content of the element is not an image, there is some possibility the technique is beneficial to the end user. However, in these cases, there is always another, arguably more appropriate, way of achieving the same outcome without this special case hack, making the hack superfluous. Further, such circumstances where the hack could be beneficial are very rare.
>  
> In the end, allowing null role description on image is about adding special case processing to do one thing – give authors the ability to prevent screen readers from saying the word “image” or “graphic”. As a screen reader user, I do not think this is something authors should be doing with ARIA. As someone who is daily teaching engineers about how to use ARIA and serving as an editor for the ARIA authoring practices guide, I believe providing education and documentation about this special case hack would be distracting and confusing to students and readers, no matter how perfectly we do it.
>  
> Even though I am firmly convinced of the good intentions of everyone supporting this objective, I do not believe it is in the best interest of users or ARIA itself. So, I encourage people to vote against special casing and allow the discussions of how ARIA should further influence screen reader verbosity to be pushed off to ARIA 2.0.
>  
> Matt
> From: Rich Schwerdtfeger [mailto:richschwer@gmail.com] 
> Sent: Friday, July 8, 2016 6:44 AM
> To: ARIA Admin <public-aria-admin@w3.org>
> Subject: 7-Day CFC: Put up CFC survey for members to put in a special case of option 3 that tells ATs to suppress the the role when the role description has a null value and to move the text/static role to ARIA 2.0 or to accespt option 3 and move the text/stat
>  
> This is a Call for Consensus (CfC) to the Accessible Rich Internet 
> Applications (ARIA) Working Group regarding the following resolution of 
> the ARIA Working group:
>  
>     Put up CFC survey for members to put in a special case of option 3 that tells ATs to suppress the
>     the role when the role description has a null value and to move the text/static role to ARIA 2.0 or to accespt option 3 and move the text/static role to ARIA 2.0. The survey is here:
> https://www.w3.org/2002/09/wbs/83726/2016-07-07_roledescription_CfC/ 
>  
>  Background 
>  
>  This was approved by the participants of the 30 June 2016 teleconference, and further context is available in the minutes:
> 
>         https://www.w3.org/2016/07/07-aria-minutes.html
>  
> This CfC is now open for objection, comment, as well as statements of 
> support via email. Silence will be interpreted as support, though 
> messages of support are certainly welcome.
>  
> If you object to this proposal, or have comments concerning it, please 
> respond by replying on list to this message no later than 23:59 
> (midnight) Boston Time, Wednesday, 13 July 2016. For objections only, 
> please copy the main public-aria@w3.org list to allow technical discussion of 
> the objection to happen there.
>  
>  
>     Process
>  
> This CfC is conducted per the ARIA WG decision policy:
>  
>     https://www.w3.org/WAI/ARIA/decision-policy
>  
> I am issuing this CfC as acting chair, but Rich will record the formal 
> ratification if passed.
>  
> Rich Schwerdtfeger
>  
> — 
> Rich Schwerdtfeger,   Email: richschwer@gmail.com  
> CTO Accessibility IBM Software: 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
>