W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > July to September 2002

RE: Invisible "Skip navigation" link

From: RUST Randal <RRust@COVANSYS.com>
Date: Wed, 24 Jul 2002 09:44:31 -0400
Message-ID: <37925254B67DD311876C009027B0FF92027FC4CA@cbscolex01.cbsinc.com>
To: "'WAI IG'" <w3c-wai-ig@w3.org>

Based on the results of this discussion, should I be marking all my INPUTS
as such:

<input type="submit" accesskey="a" id="add" name="add" title="Add Employee.
Access Key = a. " value="Add Employee" />

This is a lot more efficient that putting together a messy "help" document.


>-----Original Message-----
>From: Charles McCathieNevile [mailto:charles@w3.org]
>Sent: Wednesday, July 24, 2002 8:14 AM
>To: Steve Vosloo
>Cc: 'WAI IG'
>Subject: RE: Invisible "Skip navigation" link
>Well, one approach is to use XHTML, where it is OK to have 
>whitespace that is expected to be significant.
>Going against things specified as "should" should not  be done 
>lightly. You
>should ensure that if you do so, you are not breaking 
>anything. That seems to
>be the case here...
>On Wed, 24 Jul 2002, Steve Vosloo wrote:
>>It seems there are instances where guidelines clash with best
>>practices/workarounds, like the example here. You're damned if you do
>>and damned if you don't! This whole field is still working itself out
>>and there are bound to be these situations.
>>I reckon you simply have to choose a solution and make it consistent
>>across your site. Given the facts I have so far, I'm happy to put
>>trailing spaces on everything.
>>-----Original Message-----
>>From: w3c-wai-ig-request@w3.org [mailto:w3c-wai-ig-request@w3.org] On
>>Behalf Of Jukka Korpela
>>Sent: 24 July 2002 09:19 AM
>>To: 'WAI IG'
>>Subject: RE: Invisible "Skip navigation" link
>>Steve Vosloo wrote:
>>> To cover all bases it seems a good idea to always put a 
>space after a
>>> text description, and usually after some sort of punctuation:
>>> <a href="#content" title="Skip Navigation. Access key = 2. "> <img
>>> src="hello.gif" alt="Hello world. "> <frame src="banner.html"
>>> title="Frame banner. ">
>>In practice, I tend to agree, at least in situations where alt texts
>>would otherwise "run together".
>>But we have a problem here. The HTML 4 specification says that user
>>agents may ignore leading and trailing spaces in attributes 
>(e.g., treat
>>alt="foo " as equivalent to alt="foo") for "CDATA attributes" (such as
>>title, alt, and many others). This is specified in section 6.2 "SGML
>>basic types" (so you may easily miss it when using the 
>specification as
>>a reference): http://www.w3.org/TR/html4/types.html#h-6.2
>>And it even says in this context: "Authors should not declare 
>>values with leading or trailing white space." (Someone might interpret
>>this "only" as a strong way of saying that authors should not 
>_rely_ on
>>such space being preserved.)
>>XHTML is a different beast:
>>"Whitespace in attribute values is processed according to [XML]."
>>  http://www.w3.org/TR/html/#uaconf
>>And this means strict (and fairly complicated) normalization rules:
>>  http://www.w3.org/TR/REC-xml#AVNormalize
>>But those rules do not make stripping leading and trailing spaces
>>mandatory for CDATA attributes - though they _do_ require 
>such stripping
>>for other attributes! (And they require compression of 
>multiple spaces,
>>so that alt="foo  " is normalized to alt="foo ".)
>>It's difficult to say whether XHTML is intended to _allow_ 
>stripping of
>>leading and trailing spaces in CDATA attributes (as HTML 4 does).
>>Note that if such stripping is allowed, alt=" " can be treated as
>>identical to alt="", which would not be nice at all if e.g. 
>the image is
>>a separator between adjacent words.
>Charles McCathieNevile    http://www.w3.org/People/Charles  
>phone: +61 409 134 136
>W3C Web Accessibility Initiative     http://www.w3.org/WAI  
>fax: +33 4 92 38 78 22
>Location: 21 Mitchell street FOOTSCRAY Vic 3011, Australia
>(or W3C INRIA, Route des Lucioles, BP 93, 06902 Sophia 
>Antipolis Cedex, France)
Received on Wednesday, 24 July 2002 09:41:30 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:36:10 UTC