> The deal is merely that the word "click" triggers a Pavlovian response
Even that is questionable, but the real problem with "click" is its
use in the text of web pages (the ubiquitous "click here" "button").
Authors use it because they think that users are too stupid to understand
the concept of a hyperlink. However, it seems that only mouse or tracker
ball users are allowed to be stupid. Keyboard users have to be able to
generalise the literal instruction to a mouse user, even if mouse users
are assumed incapable of such abstractions.
This is a bit like the designers' rights line on accessibilty: that
a site is accessible if it is possible to use it using expensive software
whose operation you know inside out. Basically that means that things
only need to be accessible to those people whose level of intelligence
makes them employable in spite of their disabilities and by being
employed, can afford (or more likely have given) expensive tools.
(For a language called *Hypertext* Markup Language, modern commercial
pages using it are remarkably free of hypertext.)
I believe browsers that interpret keyboard operations as equivalent to
click are exceeding their terms of reference, even if the net effect
is desirable. Basically, author reliance[2] is based on a de facto
standard, reverse engineered from browser to browser, or introduced
as a work around for bad design practices[1], not on a W3C standard.
If the intention is that click should mean activate, the W3C standards
should have an errata added to that effect.
[1] From what I gather, a lot of the anomalous behaviour for popular
AT tools results from their being designed to work around bad accessibilty
in real life sites, rather than working best with sites that used the
accessibility features in the standards.
[2] If the truth be told, authors don't rely on this, because they don't
even consider the issue in the first place. I can't imagine many people
even include keyboard operation in their acceptance test plans.