Re: 7-Day CFC - Modification to aria-details

Hi Matt,

If you would like to make a branch with the changes that would be fine - as long as these changes are editorial. If you are able to have a branch proposal by Thursday we will discuss it on the call as part of the CFC review. 

One request that I have is that we don’t turn this into a word smithing session on the call. :-)

Thank you for your thoughtful comments.

Best,

Rich

Rich Schwerdtfeger




> On Aug 8, 2016, at 3:10 PM, Matt King <a11ythinker@gmail.com> wrote:
> 
> I will post a note with support for this CFC to the admin list, but I would like to request some editorial revisions to clarify three issues with aria-details.
>  
> Issue #1: The following paragraph is difficult to understand, especially the second sentence. 
>  
> > The aria-details attribute references a single element 
> > that provides more detailed information than would normally be provided by aria-describedby. 
> > Unlike aria-describedby, authors should ensure the content is not hidden 
> > and is included in a container that exposes the content to the user 
> > as it is expected that the assistive technology user navigate to the content to access it. 
> > This is often because converting the contents to a string results in either aloss of information 
> > or a decreased understanding of the object being described. 
> > Consequently, aria-details does not participate in either the Accessible Name Computation
> > or the Accessible Description Computation 
> > as defined in the Accessible Name and Description specification [ACCNAME-AAM].
>  
> Partly because the sentence including the normative statement is also providing rationale for the requirement, the sentence is complex and difficult to parse. I believe normative statements should be as simple and clear as possible.
>  
> It also seems to include more words than needed. For instance, is there a difference between "not hidden" and "included in a container that exposes the content to the user"?
>  
> Finally, some may interpret the normative sentence as implying that elements referenced by aria-describedby are normally hidden or not exposed to the user.  
>  
> I believe I may understand what the above paragraph is intending to communicate, and I am willing to attempt to draft appropriate editorial revisions if there is agreement they are needed.
>  
> Issue #2: The following paragraph makes a statement that sounds very consequential but does not state the consequence. It is also missing a comma.
>  
> > When both aria-describedby and aria-details are provided on an element 
> > aria-details takes precedence.
>  
> What is the consequence of taking precedence? Do user agents ignore the aria-describedby attribute? Should assistive technologies ignore it? Something else? 
>  
> Issue #3: The examples seem to imply that referring to a link will result in a different experience. If aria-details in example 18 referred to the paragraph containing the link (as shown below) instead of referring to the link, is it expected there would be a difference in user agent or assistive technology behavior?
>  
> EXAMPLE 18
> <!-- Provision of an extended description -->
> <img src="pythagorean.jpg" alt="Pythagorean Theorem" aria-details="det">
> <p id="det">
>   See an <a href="http://foo.com/pt.html <http://foo.com/pt.html>">Application of the Pythagorean Theorem</a>.
> </p>
>  
> Thanks,
> Matt King
>  
> From: Rich Schwerdtfeger [mailto:richschwer@gmail.com] 
> Sent: Thursday, August 4, 2016 1:30 PM
> To: ARIA Admin <public-aria-admin@w3.org>
> Subject: 7-Day CFC - Modification to aria-details
>  
> 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:
>  
>     Modify aria-details text such that authors SHOULD ensure content referenced by aria-details is not hidden vs. an authors MUST. The branch can be found here: https://rawgit.com/w3c/aria/action2106/aria/aria.html#aria-details <https://rawgit.com/w3c/aria/action2106/aria/aria.html#aria-details> with a comparison of the changes here: https://github.com/w3c/aria/compare/action2106 <https://github.com/w3c/aria/compare/action2106>. 
>  
>  Background 
>  
>  This was approved by the participants of the 4 August 2016 teleconference, and further context is available in the minutes:
>         https://www.w3.org/2016/08/04-aria-minutes.html <https://www.w3.org/2016/08/04-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, 10 August 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 <https://www.w3.org/WAI/ARIA/decision-policy>
>  
>  
> Rich Schwerdtfeger
>  
> — 
> 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 <https://www.w3.org/WAI/ARIA>
>  
> Rich Schwerdtfeger
>