RE: Invisible "Skip navigation" link

At 09:44 AM 2002-07-24, RUST Randal wrote:

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

Please review for me the reasoning on the 'id' value, please?  I understand
why 'id' and 'name' may be set the same on anchors, but I don't think there
is any risk of browsers using the 'name' on an 'input' as the navigation
destination label.

I would have thought id="doAddNewEmployee372"  so that a #fragment hyperlink
for direct navigation would provide 

1) a fully qualified identification of this destination within the page 
-- within the recognition capability of the user (recall not required,
that is provided by the accessKey)

but also allow for 

2) garbage uniquifying characters at the end as well 

.. to allow a pattern of use which is mnemonic in prefix and allows enough 
opaque suffix to ensure uniqueness.  Compare with AOL screen names.

Note that there is a 'do' in the anchor name because the bare

#addNewEmployee362 reference leads one to the top of this form.

You could also safely reduce the 'value' to "Employee" IMHO as the name=value
structure already has the 'add' in the name.

The form data processor does not need the repetitive reminder of context that
the user needs.

Al


>>-----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 
>>leading/trailing
>>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...
>>
>>Cheers
>>
>>Chaals
>>
>>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.
>>>
>>>Steve
>>>
>>>
>>>
>>>
>>>-----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 
>>attribute
>>>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 10:30:02 UTC