More efficient still, of course, would be if your browser provided you with
an automatically generated index of access keys and what they activated - if
necessary changing the keys suggested by the author to something available to
the user.
Then you could have
<input type="submit" accesskey="a" id="add" name="add" title="Add Employee"
value="Add Employee" />
and know that your users would be able to work out how to get to it quickly
(given that you have given it an accesskey to make sure there is a a direct
access method).
You might like to look over the User Agent Accessibility Guidelines -
http://www.w3.org/TR/UAAG - or Common User Agent Problems -
http://www.w3.org/TR/CUAP - for other things you should be asking your
browser maker to fix which would make the lives of both authors and readers
easier.
Cheers
Chaals
On Wed, 24 Jul 2002, 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
>
>>-----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)
>>
>
--
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)