W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > July to September 2003

RE: onKeyPress activates link in Opera

From: Jon Hanna <jon@spin.ie>
Date: Fri, 4 Jul 2003 12:40:33 +0100
To: <w3c-wai-ig@w3.org>
Message-ID: <NDBBLCBLIMDOPKMOPHLHMEAJFFAA.jon@spin.ie>

> I asumed that the implementation of onclick is interpreted to
> mean activated
> in any way, but is it specified anywhere?

The User-Agent accesibility guideline 1.2
<http://www.w3.org/TR/UAAG10/guidelines.html#tech-device-independent-handler
s> states:

"Allow the user to activate, through keyboard input alone, all input device
event handlers that are explicitly associated with the element designated by
the content focus."

So this behaviour could be seen as an implementation of that point. Of
course you as an author are meant to take some measure to deal with failures
of user agents, but I think that pretty much all browsers with onclick
handlers react to direct (not via a menu) keyboard access of a link in this
manner.

I'm sure someone on this list would know of exceptions.

 If it is then I understand that
> there's no need for redundant event handlers. WCAG techniques say
> (http://www.w3.org/TR/WCAG10-HTML-TECHS/#directly-accessible-scripts)
>     Use "onclick" with "onkeypress"
> But this suggests that the technique is no longer necessary, because the
> browsers have overcome the probleam.

It is still necessary where onclick isn't over-riding a default behaviour.
For instance if you provide an onclick handler to a div you should make it
selectable and provide an onkeypress as such onclicks are literally "on
click".

> Opera doesn't use the tab key for link navigation. It uses A and
> Q instead.

Which would make it more important that you can't trigger the link by
pressing "A". An onkeypress handler should check which key was pressed.
Received on Friday, 4 July 2003 07:38:46 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 19 July 2011 18:14:10 GMT