A classic example of trying too hard and making accessibility bloopers, can be found when web authors provide too many JavaScript event handlers in an effort to ensure device independence. This is the fifth in our series of articles on “too much accessibility“.
Ensuring that users can make JavaScript events work, regardless of the way that they access your web page is vital. Users should be able to activate JavaScript events whether they use a mouse, keyboard, pointing / switch device or any other means of navigation.
However, if two or more event handlers, designed to perform the same task are used, the effect can be the opposite of the one you intended.
The most common problem is where onClick is used, and authors, believing that this is a mouse dependent event handler, will add an onKeypress, or similar to make sure that keyboard and switch users aren’t left out.
The problem here is caused by the belief that onClick is always mouse dependent. If the event is attached to a link or form control, onClick is device independent.
In Internet Explorer there is no effect when onClick and onKeypress are used together; the second handler is ignored. No surprise there then.
However in Mozzilla Firefox and Opera, the web author is taken at his word, and using onClick with onKeypress will activate the link or button, when all the user is trying to do is navigate over and passed it..
This kindly meant, but flawed technique has been seen in the wild, on a search button, which was preceded only by a link to the home page and the search input field.
This meant that if navigating by using the [tab] key, there were only two pages available, Home and Search Results. The intrepid user could, of course, hold down the [shift] key while tabbing, which reverses the tab order, but would you walk backwards into a shop?
JackP | 20/11/2006 at 14:04 | Permalink
Talking of javascript - it’s offtopic slightly so I apologise and feel free to delete if you don’t feel it’s relevant - I produced a testcase for the use of the javascript postback in .NET (http://www.thepickards.co.uk/index.php/200610/javascript-testcase/) as under WCAG 1.0 you can’t rely on javascript, and I was simply seeking to determine whether or not the “postback” part of javascript is sufficiently supported by screenreaders and other AT as to be deemed “accessible”, even though it would obviously fail WCAG 1.0 if you relied on it.
The feedback I’ve had so far would seem to suggest that it does work as expected, but I thought there might be someone there who has sufficient screen reader experience to offer another opinion or further advice?
Martin Kliehm | 30/07/2007 at 15:28 | Permalink
You mean there was a simple inline onkeypress attribute bound to the search form? OK, that’s not so smart. But I can’t see any evil if the keypress event is bound to an element and checked which key has been pressed. Only if it’s the enter key (keycode 13) on a link or a button, or the space bar (keycode 32) on a checkbox or radio button, the intended function should be evoked.
Bim | 31/07/2007 at 8:38 | Permalink
The site I referred to also used both onClick and onKeyPress for its top level links. The same thing happened, trying to tab across them activated the first link with both event handlers. This only happened in Firefox. Are you saying that the browser handled it incorrectly?