Re: additional sentence for 204

James Craig, Mon, 17 Sep 2012 09:13:38 -0700:
> On Sep 13, 2012, at 5:45 PM, Leif Halvard Silli:

>> [What about @name for <map>?]
> 
> Isn't that included by "valid hash name reference" in this next line?

All right.

>> 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. 

Hm. Your text emphasizes what authors may want to do. From what 
perspective? A <map> contains both <area> and - potentially - other 
content. What we talk about is using @hidden to hide content for 
(typically) sighted users but still revealing it to AT. But as of 
today, as long as there is a  @usemap is present, the <area> elements 
are revealed both by AT and to sighted uses regardless of hidden="" or 
not. (Probably because <area> is more part of the graphic while the 
rest of <map> is more independent.) But other content than that and 
that is kept inside <map> is, I think, not revealed to anyone, yet. So, 
for <map>, then Ted's spec text must relate to revealing non-<area> 
elements.

I would propose to formulate the text more as a warning that the only 
way to be certain that nothing is exposed might be by removing the 
@id/@hash name link, which in turn is likely to affect semantics. 
Because I think that the potential changes in semantics might make 
authors look for other methods than the removal of @usemap, @headers 
etc. I try change the second sentence to say what I mean:

]]
 Note: Only hidden="" elements that are referenced indirectly by a 
 unique identifier (ID) reference or valid hash-name reference may 
 have their structure and content exposed upon user request.<zzz>Note
 that  this functionality means that the only certain way to prevent 
 user-initiated viewing of hidden="" elements is to remove the 
 identifier (ID) or hash-name reference to the element in question.
 </zzz>
[[


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

See above.

>> 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? 

Don't understand the question. If <map> is referenced via @usemap, then 
- upon user request - its content *is* read, by default. (By the way, 
in terms of <map>, should we then expect that <area> is treated 
separate from the rest of the content of <map>? For example, when 
exposing an image map, then I suppose the <area> elements are not 
exposed "at user request" - rather they are exposed by default, when 
processing the image map.)

> 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.

To me the point seems to be what I tried to say above: Authors should 
be warned that they must not place other things inside hidden="" 
elements that are referenced via idref/hashrer than what they want to 
be exposed (at user request).

>> 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.

The preceding text, to which you want your sentences added, uses 
@usemap and @headers as examples. And, I too, used @longdesc as an 
example. The spec text also does not mention ARIA - however, you 
yourself nevertheless mentioned ARIA a few paragraphs above.

>> 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?

SVG is not HTML. What I meant was, again, that there might be 
situations where the author wants more fine grained control than simply 
the on/off button that the idref reference is. However, this might not 
be so important to explain.

>> 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.
-- 
leif h silli

Received on Monday, 17 September 2012 20:40:59 UTC