Re: additional sentence for 204

On Sep 13, 2012, at 5:45 PM, Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no> wrote:

> Comments on James's variant of the text.
> 
> ]]
> Note: Only hidden="" elements that are referenced indirectly by a 
> unique identifier (ID) reference
> 
> [What about @name for <map>?]

Isn't that included by "valid hash name reference" in this next line?

> or valid hash-name reference may 
> have their structure and content exposed upon user request. Authors 
> desiring to prevent user-initiated viewing of hidden="" elements 
> should remove identifier (ID) or hash-name references to the element.
> [[
> 
> So now I want to defend HTML: This sounds much too ARIA like in its 
> logic.
> 
> When it comes to aria-describedby/-labelledby then they do not imply a 
> particular semantic relationship between the two connected elements: 
> labelledby could refer to a <caption> but it could also refer to a 
> <div> - even a <script>.  By contrast, take for instance the @usemap 
> attribute. If you remove it, then you remove the entire image map 
> functionality. For all users. Even AT users.

According to the proposed language, the only time it should be removed is when you did not want it exposed to any user, so it seems to me like the wording is in line with the scenario you've just outlined. 

> For the @headers attribute your logic could seem simpler to accept as a 
> hidden <th> element does not affect anyone. However: It would be 
> possible to use @headers to create some CSS or JavaScript that 
> highlights the referenced headers. And @headers do define which the 
> connected header cells are *even if they are hidden*. So by removing 
> @headers, one would be changing the semantics of the table.

Removing headers would, yes. But we're talking about hiding headers, so it's no entirely the same.

An example is in the Mac OS X "Stocks" Dashboard widget, where hidden headers exist for Symbol, Value, and Change percentage, even though they are not visible in the sighted user interface, because the contextual view makes those headers redundant.

See attached screen shot:

> I am of course not opposed to *inform* the spec readers that hidden 
> elements are not revealed to anyone if either the referenced attributes 
> ( @id, @name) or the referencing attributes (@headers, @usemap and 
> others) are removed. But I am opposed to "informing" readers that this 
> is a method they can use in order to prevent hidden text from being 
> read. To say that, is a much too simplistic.

So you want hidden text to be read by default? The thing that prevents text from being read is the fact that it is hidden. This wording is just defining a very special case where, referencing an hidden element by ID (in an attribute as defined by the spec like like ARIA or HTML), may allow a user to unhide it upon request, if so supported by the user agent and assistive technology.

> Ultimately, what you say here is that if someone uses @longdesc to 
> point to somewhere in the same page, then the spec should inform 
> authors that they can prevent the referenced text from being presented 
> by removing the @longdesc. Is there really a point in saying such a 
> thing?

Well no, but it's not for the reason you mention. It's because this isn't talking about longdesc at all.

> I am afraid that we cannot 100% solve this dilemma without counting on 
> ARIA. For example, imagine that the <map> element contained some ASCII 
> art. Then, remember that we are talking about a situations where the 
> "full semantics" are present. So then it would be possible to use 
> role=img on the child element containing the ASCII art. One could also, 
> I suppose use aria-hidden="true" inside e.g. a <map>. If the text "must 
> not" talk about this, then it should say that "HTML has no means for 
> hiding such content, but that authors may use ARIA attributes, see 
> ARIA". 

Why couldn't you present ASCII art in an SVG element? Wouldn't that count as an HTML-only, ARIA-free approach to the problem?

> I am not sure that we even need to talk about id references - it sounds 
> like language that has been placed there to prevent something in the 
> future or whatever. But what about the <object> element. Or <canvas> ? 
> Is the fallback/subdom of <canvas> considered hidden? If you add 
> hidden="" to an element inside <canvas>, does that change anything? If 
> that change anything, then I agree that the subdom of <canvas> is not 
> hidden and as such falls outside the subject. But what about <object>? 
> Remember that <object> can be image maps. And that the <map hidden="" 
> name="map" > element then can be placed as child of <object>. Is it 
> only when <object usmap="map"> contains a <map> that its fallback will 
> be rendered with full semantics?

Potentially, if referenced by one of these special attributes (usemap, headers, etc.) defined to do so, yes. But not if it's just referenced by any other means.

James