19 October 2004
The thing about accessibility issues is you can't really predict when one's going to occur. It's only when someone who's affected tells you directly – "hey, I can only do things this way, and you're not letting me do it" – that you realise your error and hopefully strive to correct it.
Bruce Macguire's presentation of how he – a blind user – browses the Web was one of the best experiences of Web Essentials 04. It materialised those intangible theories that web developers like to push around when they're coding "accessible" web sites and gave me actual insight into how a real user interacts with the JAWS screen reader.
This particular accessibility hiccup occured on select menus that used the onchange event handler. You see, most blind people use a Windows/Internet Explorer combination because of usability factors. They also use the keyboard to navigate their way around web pages/applications. The only problem is, when you use the keyboard to explore the options in a select menu (using cursor keys) it triggers the onchange event handler (in IE). So, if you have any actions that rely on that handler, they'll probably be executed before the user has time to listen to all the options in the select menu. It'll also mean they'll probably only ever be able to access the first item.
Bruce's solution was to get rid of the onchange altogether and use a submit button to let the user tell the browser when they've selected what they want. Problem solved then. Until, of course, you mention it to Andy Clarke and he says "That would look 'orrible!" (And yes, I have the Messenger log to prove it :o] )
Here is a fine example of the classic battle between form and function. The whole reason for introducing the onchange in the first place was to remove the submit button, because everyone hates making space for – and styling – form buttons. So, you want a select menu without a submit button, but you want it accessible to keyboard users? Here it is.
The event handling code isn't two lines, so it might make you think twice about deleting that submit button, but this is certainly a more accessible option when you just have to have that svelte, streamlined select menu.
Arrow keys do not trigger an onchange event, so the user is free to go through the options in the list without hurrying and a change is only registered when they hit enter or tab off the element. I also added some behaviour that was standard to Firefox but not to IE – hitting escape returns the select to its original value. All mouse activity remains as normal.
This has been tested and passed in IE 5+ (Windows), Firefox 0.8 (Windows) and Opera 7.5 (Windows). I have distant reservations about its compatibility with Mac (or other OSs), as it relies on keycodes to detect keystrokes, which may be different on non-Windows systems. A quick test would be handy if you have the time. Much to my chagrin I also haven't run it through the exact applications it's meant to be benefitting, so if you're a bit handy with JAWS et al, give it a whirl.
Follow me on Twitter
To hear smaller but more regular stuff from me, follow @themaninblue.
- Resolution dependent layout update
- footerStickAlt: A more robust method of positioning a footer
- widgEditor: A simple, standards-compliant WYSIWYG HTML editor
- Accessible, stylish form layout