Re: additional sentence for 204

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 14:37:43 UTC