- From: Charles McCathieNevile <charles@w3.org>
- Date: Wed, 22 Aug 2001 08:14:46 -0400 (EDT)
- To: Jon Hanna <jon@spinsol.com>
- cc: <w3c-wai-ig@w3.org>
Actually I think that the HTML model is already better than this. There is an attribute called 'rel' that you can put on a link, which is sadly under-used. It takes values which describe the relationship of the thing linked to - for example the Authoring Tool Accessibility Guidelines have the glossary links defined with rel="glossary". There are other values defined by the HTML 4 specification including "next", "previous", "index", "table of contents", etc. This same feature can be used for the link element, which is used to specify a relationship between two pages. Lynx, iCab, and some other browsers readily present link elements - iCab uses them to construct a toolbar. I am not aware of any browsers that have done useful things with rel attributes in inline links, but semantic web applications use them to extract meaning and automatically build information, and they can be used for CSS styling. My personal feeling with accesskeys is that it makes sense for a character to be specified by the author as a preferred character - where the function of the link isn't already well known from teh rel attribute it is just as good to have a hint that might remind people of something. But becuase there are about 50 000 characters, and most browsers only make a handful available (between about 3 and a couple of hundred) the browser should be able to override this choice (this should also be possible for the user to instruct the browser) and so it should be responsible for presenting the accesskeys available, either as a list, or inline. Please note that this issue is in fact one of those discussed by the WAI's Protocols and Formats working group as part of their work in improving accessibility in XHTML 2.0 (the next generation of HTML). More information about that group can be found at http://www.w3.org/WAI/PF but it is a member-private group - some archives are not available to the public, unlike this list. cheers Charles McCathieNevile On Wed, 22 Aug 2001, Jon Hanna wrote: Haven't thought this through, just throwing the idea in to see what people think. Maybe a better method for defining access keys would be something like: <a href="whatever.html" keytype="normal">blah</a> keytype could be one of a defined list of common uses for a focus-able element (e.g. "home", "up", "contact" for links, "name", "password" for input elements) or "normal" to mean it is outside of that list. Browsers could then mark elements up as best they could to match the access keys already defined by the browser and underlying OS, a list of repeated access keys that users of the browser would become familiar with, and finally assigning the remaining keys as best it can. It would be a lot of work for the browser, but seems a sensible enough method at this stage ("this stage" meaning between cup of coffee no. 1 and no. 2). ---------------------------------------------------------------------- gpg: Warning: using insecure memory! gpg: Signature made Wed Aug 22 06:29:48 2001 EDT using DSA key ID F532BD18 gpg: Can't check signature: public key not found ---------------------------------------------------------------------- -- Charles McCathieNevile http://www.w3.org/People/Charles phone: +61 409 134 136 W3C Web Accessibility Initiative http://www.w3.org/WAI fax: +1 617 258 5999 Location: 21 Mitchell street FOOTSCRAY Vic 3011, Australia (or W3C INRIA, Route des Lucioles, BP 93, 06902 Sophia Antipolis Cedex, France)
Received on Wednesday, 22 August 2001 08:14:48 UTC