RE: AccessKeys and what to use - possible alternative HTML

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