"Click" (Re: onclick behaviour also triggered by keyboard ?)

On Sat, 13 Mar 2004, David Woolley wrote:

> > 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").

We've switched topic here.  But since you're responding to my little
friday-night rant, let's pursue it.

"Click Here" is indeed widely misused.  But I wouldn't accept that it
is *automatically* wrong.  Indeed, the fact that it has entered common
parlance on the web might itself be seen as a justification for it:
this is a familiar idiom, and as such serves usability.

I wonder if there's a valid analogy to use of language here. I have a
gut-level aversion to the split infinitive.  Not everyone shares it.
So some people express themselves in a manner that grates with me,
and vice versa.  Perhaps use or active avoidance of "Click Here"
could be seen as broadly similar?

> Authors use it because they think that users are too stupid to understand
> the concept of a hyperlink.

I think you may be over-rationalising a process.

>	  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.

It's more a matter of history than stupidity.  "Click here" has
been with us significantly longer than W3C or WAI.

> 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.

This seems to me to be turned on its head.  As you know, I am strongly
and consistently critical of that line (in contrast to, for example,
RNIB, whose Julie Howell was on Radio 4's "In touch" program earlier
this year saying she would only support blind users if they *were*
using the most up-to-date and expensive technologies).

The client issue here is support for Javascript, and the accessibility
issue is provision of a valid alternative.  No more, no less.

Let me assert that "client support for Javascript events implies
client support for onclick()", and challenge anyone to find a
counterexample.

> (For a language called *Hypertext* Markup Language, modern commercial
> pages using it are remarkably free of hypertext.)

Indeed, no argument there, except that it's scarcely a new observation.

> I believe browsers that interpret keyboard operations as equivalent to
> click are exceeding their terms of reference, even if the net effect
> is desirable.

Once again I have to disagree.  It would be manifestly wrong for a
browser to (claim to) support Javascript yet fail to support the
core onclick() event on dogmatic grounds.

>	  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.

Maybe they should, but browser developers appear to share my view and
regard it as self-evident.

Let's consider the relevant DTD fragment:

<!ENTITY % events
 "onclick     %Script;       #IMPLIED
  ondblclick  %Script;       #IMPLIED
  onmousedown %Script;       #IMPLIED
  onmouseup   %Script;       #IMPLIED
  onmouseover %Script;       #IMPLIED
  onmousemove %Script;       #IMPLIED
  onmouseout  %Script;       #IMPLIED
  onkeypress  %Script;       #IMPLIED
  onkeydown   %Script;       #IMPLIED
  onkeyup     %Script;       #IMPLIED"
  >

If we take onclick as a mouse-only event, then there is no valid
alternative for other devices (onkeypress being *more* device-
dependent, due to the additional information associated with a key).
So the only rational course for a browser to take is to implement
it in whatever manner is appropriate to the browser's UI.

> [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.

I'm not sure I quite follow that.

> [2] If the truth be told, authors don't rely on this, because they don't
> even consider the issue in the first place.

Counterexample: me.

-- 
Nick Kew

Received on Sunday, 14 March 2004 19:31:23 UTC