Re: additional sentence for 204

Hi Janina,

the discussion deemed the @for/@id relationship between <label> and 
<input> to be unsuitable as basis for revealing anything. This was 
based on a concrete evaluation, though it also contained some 
general/principle based arguments.

I agree that the @headers/@id relationship is OK. But for <map>, then I 
have pointed out a number of issues.[1] I personally would love to be 
able to include @usemap/@name in this mechanism. However I think the 
issues that I have pointed out, should be evaluated. May be they can be 
solved. Or may be you find my arguments invalid? Please have a look.

[1] 
http://www.w3.org/mid/20120918011221114332.35925f1d@xn--mlform-iua.no

Leif Halvard Silli

Janina Sajka, Tue, 18 Sep 2012 10:36:58 -0400:
> Hi, Leif:
> 
> The intention of the language we're looking for is to allow software to
> identify which hidden conten can be revealed to users at their request,
> and which content cannot. If the id and href approach is insufficient
> for that, then we would need a different approach. But, the approach
> must be one that software can reliably use to distinguish between the
> two use cases of hidden content.
> 
> Janina
> 
> 
> Leif Halvard Silli writes:
>> Leif Halvard Silli, Mon, 17 Sep 2012 22:40:25 +0200:
>> 
>>> ]]
>>>  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>
>>> [[
>> 
>> Hm - I am not satisfied with my own text there. Retry:
>> 
>> <zzz>
>> If an author would like to prevent all user-initiated viewing of 
>> hidden="" elements, a removal of the identifier (ID) or the hash-name 
>> reference would be necessary. But note that such a removal in some 
>> cases also has semantic side-effects for the element from which it is 
>> removed. For example if a @usemap attribute was removed, the 
>> <code>object</code> or <code>img</code> element from which it was 
>> removed, would change from interactive content to a normal graphic.
>> </zzz>
>> 
>> Leif H Silli
> 
> -- 
> 
> Janina Sajka,	Phone:	+1.443.300.2200
> 			sip:janina@asterisk.rednote.net
> 		Email:	janina@rednote.net
> 
> The Linux Foundation
> Chair, Open Accessibility:	http://a11y.org
> 
> The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI)
> Chair,	Protocols & Formats	http://www.w3.org/wai/pf
> 	Indie UI			http://www.w3.org/WAI/IndieUI/
>

Received on Tuesday, 18 September 2012 15:42:19 UTC