On Mon, 28 Jan 2008 16:31:04 +0100, Mikko Rantalainen
<[EMAIL PROTECTED]> wrote:
Matthew Paul Thomas wrote:
Michael(tm) Smith wrote:
Jerason Banes <[EMAIL PROTECTED]>, 2008-01-25 23:41 -0600:
Long story short, accesskeys were an idea that worked better on paper
than
they did in practice. They inevitably interfered with normal browser
operation as well as other accessibility features in such a way as to
*
reduce* the accessibility of many web pages.
Another long story short: accesskey mark is already in use in a
significant amount of existing content, so leaving it unspec'ed
for implementors does not seem like a practical option -- not if
we care about trying to ensure that behavior of that content is
consistent/ interoperable across UAs.
But that's precisely the problem: accesskey= *can't* be consistent and
interoperable across UAs, or even across browsers, because browsers
compete (amongst other things) on their user interfaces, and therefore
they have different user interfaces, and therefore they conflict with
different values of accesskey=. If that problem had a good solution,
removing the attribute would not have been necessary.
It does. Just allow the UA to accept the key a a hint, but provide the
real binding itself. (And therefore require the UA and not the author to
provide dscoverability for things with accesskey. As envisioned by the
UAAG most of a decade ago).
The specification could include an explicit statement of the form "UAs
must ignore the accesskey= attribute", but any such statement would be
in the yet-to-be-written "Rendering" section.
Perhaps the accesskey should be kept but its meaning should be
transformed a bit. Instead of being a key (letter) it should be a
keyword for a behavior. A good accesskey values could be "home",
"index", "search", "contact". The user then could bind the "home"
accesskey to any "home" button of his selection. It could be CTRL+H or
perhaps F11 instead. Some keyboards have additional "multimedia" keys
that could easily be used for such behavior.
This functionality is already available via the rel attribute, and where
there are good common values it makes more sense to use those than
accesskey in the first place.
...
So my suggestion is to turn the "accesskey" to a tag of the behavior or
feature linked to the element. One could argue that instead the "rel"
attribute should be used for such behavior and I really cannot claim
otherwise...
No :) Accesskey is where there isn't something obvious - a function that
hasn't been common (send was once such a function on the web, before the
growth of web-based mail systems. Add to shopping basket is another. I am
sure there are new services we haven't developed yet...).
cheers
Chaals
--
Charles McCathieNevile Opera Software, Standards Group
je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals Try Opera 9.5: http://snapshot.opera.com
