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/

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 <mailto: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 <mailto: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