[Irl-dean] Creating accessible javascript

Gez Lemon gez.lemon at gmail.com
Fri Sep 29 15:42:30 IST 2006

Hi Dónal,

On 29/09/06, drice at nda.ie <drice at nda.ie> wrote:
>  > This means that advice that advocates doubling up on event handlers now
>  > results in them being executed twice when activated with the keyboard,
>  > as the click activated version must also be able to be activated by
>  > the keyboard, as per the UAAG requirement  (there are workarounds to
>  > this contradictory advice, but the advice and example on the NDA page
>  > makes no mention of them).
> Thanks for this.  I would appreciate a pointer to this advice or examples of
> workarounds.

Personally, I would advocate against doubling up on the click event
handler, as all modern browsers will activate the event using the
keyboard alone. Techniques are required for other mouse event
handlers, though.

The examples below add the event handlers with scripting to save
bloating the markup unnecessarily when JavaScript isn't available. The
same principles apply if the event handlers are specified inline.
Although I would not advocate doubling up on the click event, I'm
using click and keypress in the examples below for simplicity.

The simplest way of preventing a function being called twice is to use
a return value to cancel other actions. For example:

objAnchor.onclick = function(){return somefunction(this);};
objAnchor.onkeypress = function(){return somefunction(this);};

function somefunction(objElement)
	// Process script here ...

	return false;

If this was added to a link, then returning false would cancel any
further actions, including the browser fetching a new URL. Often, this
is the desired response, but it isn't suitable for scenarios where the
script is to be executed, and control then passed back to the event
chain for bubbling.

The keypress event should be activated by pressing any key except
modifier keys (shift, control, alt), including the tab key (keydown
and keyup events include modifier keys). As the tab key is used by
keyboard users to navigate through the page, returning false will
prevent keyboard navigation with all current browsers, except IE6 and
earlier. To get around this problem, the function should check if the
event is the keypress event (as the function is used by click and
keypress), and then only allow specific keys for activation. IE6 and
lower doesn't support the W3C event model, but this isn't important as
IE6 and lower doesn't work properly anyway. The following example
allows the event to run if the key pressed is either a space or return
(IE activates the event with return).

objAnchor.onclick = function(event){return somefunction(this, event);};
objAnchor.onkeypress = function(event){return somefunction(this, event);};

function somefunction(objElement, objEvent)
	var iKeyCode=0;

	// If keypress, get the code for the key
	// that was pressed
	if (objEvent && objEvent.type == 'keypress')
		if (objEvent.keyCode) {
			iKeyCode = objEvent.keyCode;
	else if (objEvent.which) {
		iKeyCode = objEvent.which;

	// If it's not the return key (13) or
	// the space key (13), pass control
	// back to the browser
	if (iKeyCode != 13 && iKeyCode != 32) {
		return true;
	// Process script here ...
	return false;

This all assumes the traditional event model, rather than the W3C's
event model. The w3C's model introduces more complexity in that it
uses methods to cancel bubbling, rather than returning true or false
from the function.

It's very difficult to suggest a single technique, as this is an area
where accessibility has obviously been included as an afterthought,
and conflicting advice makes something as simple as adding an event
hander quite a complicated process; particularly where bubbling is



Supplement your vitamins

More information about the CEUD-ICT mailing list