- From: Nick Kew <nick@webthing.com>
- Date: Sat, 13 Mar 2004 14:52:49 +0000 (GMT)
- To: David Woolley <david@djwhome.demon.co.uk>
- Cc: w3c-wai-ig@w3.org
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