RE: Finalizing an Issue-204 CP

John, 
Benjamin makes a good point.  The flattened text is put in the accessible description whether or not the referenced content is visible.  Does this concern you?  Does having the authoring advice associated with @hidden make sense?  I'm ok with either way on this.

I like this proposed text, but don't want to destabilize our agreement.  Is this ok with you?

All HTML elements may have the hidden content attribute set. The hidden attribute is a boolean attribute. When specified on an element, it indicates that the element is not yet, or is no longer, visible or interactive. <del/>@hidden is equivalent to the CSS display:none construct.</del> User agents should not render elements that have the hidden attribute specified.
 
<del>Elements that are not hidden should generally not link to or refer to elements that are hidden.</del>
<ins> Elements that are not themselves hidden must not hyperlink to elements that are hidden.  Aria-flowto and aria-owns attributes on elements that are not themselves hidden, similarly, must not reference hidden elements.</ins>
 
For example, it would be incorrect to use the href attribute to link to a section marked with the hidden attribute. Since the content is not rendered, linking to it</del> would have unpredictable behavior</del><ins>would result in behavior the user does not expect</ins> , either dropping the user at a location with no rendered content, or failing to navigate.
 
<del>It would similarly be incorrect to use the ARIA aria-flowto or aria-owns attributes to refer to descriptions that are themselves hidden, as these elements are not available to the user.</del>
 
However, hidden elements may be used to provide descriptive strings, using aria-describedby and aria-labelledby and the <label> element.
 
<p class="note">Any structure in the referenced element, including headings, links, tables, paragraphs, and form elements, will be lost. The text children of the element will be flattened to a string. As such, authors should only use this technique <del>for string content</del> </ins>where such flattened content will provide a good user experience</ins>. At the time of this writing, some screen reader products will read both the accessible name and accessible description, so authors should take care with the length of text provided via this method.</p>


-----Original Message-----
From: Benjamin Hawkes-Lewis [mailto:bhawkeslewis@googlemail.com] 
Sent: Friday, April 20, 2012 2:32 AM
To: Cynthia Shelly
Cc: Laura Carlson; Janina Sajka; HTML Accessibility Task Force; John Foliot; Joshue O Connor; Judy Brewer; david100@sympatico.ca; Richard Schwerdtfeger; James Nurthen; Leif Halvard Silli; Jonas Sicking (jonas@sicking.cc)
Subject: Re: Finalizing an Issue-204 CP

On Fri, Apr 20, 2012 at 12:25 AM, Cynthia Shelly <cyns@microsoft.com> wrote:

http://www.w3.org/html/wg/wiki/Correct_Hidden_Attribute_Section_v2#Accessibility_API_mappings


I have a lot of doubts about the general intent of the CP, but in this email I just want to give some feedback on the proposed text for the spec.

Proposed text:

"@hidden is equivalent to the CSS display:none construct."

This isn't good normative text. What does "equivalent" mean here? For instance, does it mean @hidden is an authorial presentational suggestion rather than semantic markup critical to the meaning of the content?

Proposed text:

"For example, it would be incorrect to use the href attribute to link to a section marked with the hidden attribute."

The WHATWG text establishes the authoring conformance requirements much more clearly:

"Elements that are not themselves hidden must not hyperlink to elements that are hidden. The for attributes of label and output elements that are not themselves hidden must similarly not refer to elements that are hidden."

I suggest adopting that language wholesale, modulo the label element if we want to allow that.

"It would similarly be incorrect to use the ARIA aria-flowto or aria-owns attributes to refer to descriptions that are themselves hidden, as these elements are not available to the user."

This suffers from the same unclear language ("incorrect" rather than "must not"). Also, shouldn't this be defined by normative text in ARIA not HTML5 - authors should not set the targets of these properties to elements with the aria-hidden property?

Proposed text:

"Since the content is not rendered, linking to it would have unpredicatble behavior, either dropping the user at a location with no rendered content, or failing to navigate."

"unpredictble" is misspelled.

Specifications make the behavior predictable, invalidating this rationale. HTML and CSSOMView currently define that a navigation action occurs (history changes etc.) but the viewport is not scrolled:

http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#scroll-to-fragid


http://dev.w3.org/csswg/cssom-view/#element-scrolling-members


Perhaps what you mean is that this behavior is unexpected by the user?

Proposed text:

"Any structure in the referenced element, including headings, links, tables, paragraphs, and form elements, will be lost. The text children of the element will be flattened to a string. As such, authors should only use this technique for string content. At the time of this writing, some screen reader products will read both the accessible name and accessible description, so authors should take care with the length of text provided via this method."

These drawbacks apply to @aria-labelledby and @aria-describedby for non-@hidden content too, so this text doesn't belong in guidance for @hidden. (You could perhaps note that @hidden makes navigation to labelling and describing elements impossible.)

What does "authors should only use this technique for string content"
mean?  e.g. Is this supposed to discourage marking up descriptions with microdata, for example? Why is it a "should" not a "must"? What we want is for the accessible name and description calculated from the markup to be good names and descriptions. That's not the same as avoiding semantic markup (e.g. RDFa, microdata, language change indications).

--
Benjamin Hawkes-Lewis

Received on Friday, 20 April 2012 21:36:54 UTC