Page style:

A Blue Perspective: Accessible JavaScript tip #43: onchange select menu

Accessible JavaScript tip #43: onchange select menu
19 October 2004

» An accessible onchange select menu «

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.

Although there were quite a few issues he mentioned when navigating web sites, there was one that stuck in my memory, mainly because it involved JavaScript (a technology which apparently everyone at Web Essentials considered beneath themselves, as I could tell by the silence following my "Woo! JavaScript!" during Dean Jackson's award winning WWWWF Smackdown presentation).

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.

Comments

1/26. 19 October 2004 @ 02:56, Malarkey wrote:

You BAD boy, keeping Messenger logs. Thank goodness I didn't tell you about my cross-dressing predelictions... whoooooops... ;)

In my defence, I was pointing to a particular instance where buttons would look out of place with the visual design ('orrible *was* what I said), but there are plenty of instances where they are not only advisable but can also be well integrated into the design.

I think that it comes down to the specific application.

Now, where is that email you sent me about that stack of magazines under your bed...

2/26. 19 October 2004 @ 11:53, chris holland wrote:

Hiya :) I've just tried in safari and firefox and OS X and it pretty much works :) In safari, you need to hit return to select then tab away. In firefox you just need to hit return.

cool stuff.

I've had pretty consistent luck with coding events capturing various keystrokes across Mac/PC so far.

3/26. 19 October 2004 @ 15:38, Lachlan Hardy wrote:

Looks great, Cam. It was working fine for me in Firefox 1.0PR. Seemed nice and quick too, so I'm pretty happy all round

And you know you weren't the only one cheering Javascript. Just before you nearly deafened me there was that one much, much quieter guy over in the corner who said "yeah".
And, THEN there was silence from the other 200+ people in the room...

4/26. 19 October 2004 @ 15:52, Dean Jackson wrote:

So *you* were the guy that yelled out. I must admit I was surprised at how the general web development community seems to avoid Javascript. If I wasn't on stage, I'd have been yelling "Javascript rocks!" with you. Javascript is not a dirty word!!!

5/26. 19 October 2004 @ 17:11, Andrew Krespanis wrote:

" Javascript is not a dirty word!!!"

Not when it's used like this it's not. Very nice work Cameron.


...smartass ;)


6/26. 19 October 2004 @ 18:18, Stefan Kremer wrote:

Looking 'orrible or not - without activated JavaScript (there are some good reasons for this - IE-URL-Spoofing etc.) you need a submit-button.

The results for the Mac (OS X and Classic OS) browsers:

KHTML-based:
- Safari: works well as mentioned above

- OmniWeb 5.0: doesn't work at all - neither the keyboard or the mouse input

- Konqueror 3.20 (not tested on Linux, but on KDEonDarwin - results on Linux may vary): works, but gives no feedback within the select-menu on keyboard-input which selection is made.

Gecko-based:
- Firefox (0.93-german): works, but I the pop-up comes up a second time when hitting return - same behavior on Mozilla 1.8a4

- Camino (0.81): When selected by keyboard the "ok" button in the pop-up makes the whole page hidden - it's there (you can see it in expose) but it's not shown in the foreground of the application.

NN7: works, but inaccebtable slow

Internet Explorer:
- IE 5 (OS X and 9): the script works fine, but not the layout. If the text "An example select menu" is selected (only IE allowed this) and up/down arrows are used - the popup comes up immediately.

Opera:
- Opera 7.5: keyboard selection works on all items, but not on option "1".

Unsupported
- iCab (2.97), Opera 6, NN4.75, IE4 - no keyboard support at all.

best regards Stefan

7/26. 19 October 2004 @ 18:44, The Man in Blue wrote:

Thanks Stefan.

Of course, you would only use something that requires JavaScript when it's written into the document using JavaScript. KIDS: USE JAVASCRIPT RESPONSIBLY.

Any issues with the pop-up or the layout don't really matter. It's just an example, and you'd normally not have an alert() function as the behaviour.

8/26. 19 October 2004 @ 22:07, Mark Wubben wrote:

Sweet idea. And JavaScript rocks.

9/26. 19 October 2004 @ 23:06, Jonathan Snook wrote:

For great looking submit buttons, whatever happened to <input type="image"> ?

Nice javascript, though. If I ever have a client that needs it, this'll be a good one to have.

10/26. 19 October 2004 @ 23:10, Jonathan Broome wrote:

Warning: This is nit-picking:

'Enter' seems more intuitive to me as a consent to go somewhere. I think 'tab' should be treated like 'escape' in this case.

For instance, you might have arrowed to the end of a long nav-select-list only to realize you don't want to go to any of them, and you DO want to fill out the form below. What do you hit to get there? Tab. But now, instead of getting to the form, you're escorted away faster than a protester in a GOP convention.

11/26. 19 October 2004 @ 23:18, Jonathan Broome wrote:

PS: I gripe because I care. I think this is pretty damn cool.

12/26. 20 October 2004 @ 00:17, name wrote:

Nice technically, but not sure how *usable* this is as it is slightly hidden behaviour.... a submit button would be more usable, imho.

13/26. 20 October 2004 @ 02:00, Unearthed Ruminator wrote:

I like to have submit buttons (you've got to do something for those people who've disabled javascript - and it is very easy to hide them via a stylesheet or the noscript tag), but making a keyboard accessible version like this is very cool.

14/26. 20 October 2004 @ 05:13, Jason G wrote:

You could always have a submit button that Javascript hides. This way, when the user does not have Javascript turned on, or is not using a Javascript enabled browser they can still use the menu. And if they have Javascript there won't be a "'orrible" looking button hanging around.

15/26. 20 October 2004 @ 05:42, chris holland wrote:

I'm liking Jasong G's idea.

I also think Jonathan Snooke as an interesting point. The image will trigger the form submission just as well, just catch the onsubmit event, and hey, change the form's action, or many other silly possible things.

16/26. 20 October 2004 @ 18:59, Richard Rutter wrote:

For the sake of those about to use JavaScript to hide the submit button, and to spell out what Unearthed Ruminator hinted at, try this:

<noscript>
<input type="submit">
</noscript>

The submit button will appear if JavaScript is not available, otherwise it will be hidden.

17/26. 21 October 2004 @ 22:13, Chris Bloom wrote:

Great article, and great comments too. Does anyone know if there is a "developers" version of JAWS? I've always been interested in testing my sites directly in a screen reader program but they are all pretty expensive to buy outright. It would probably help to promote accessibility standards if there was a free or nearly free bare-bones version that could be used for testing.

18/26. 21 October 2004 @ 23:29, Jeremy Keith wrote:

This is working well for keyboard navigation but unfortunately, it seems to break the mouse navigation in some browsers.

In Safari, the first time you select an option using the mouse, nothing happens. Select a different option, and the alert is triggered.

In IE5 Mac, the mouse navigation is simply disabled.... until you use the keyboard to navigate, at which point the mouse navigation begins to work.

Very odd... I'll see if I can figure out why this would be happening. I'm guessing that either the focus or click events aren't being triggered initially.

19/26. 22 October 2004 @ 17:04, Danny Tuppeny wrote:

Why not have a submit button in the page, and hide it with JavaScript, so anyone that needs it will see it, but those with JS, won't? :)

20/26. 22 October 2004 @ 17:28, The Man in Blue wrote:

This isn't about people with JavaScript vs. those that don't. JAWS (screen readers) users can have JavaScript and the standard practice doesn't work for them.

21/26. 23 October 2004 @ 03:21, Danny Tuppeny wrote:

I know that, I'm just trying to promote accessibility for devices without JavaScript too (like my toaster) :-(

22/26. 27 October 2004 @ 02:34, Brothercake wrote:

I have reservations about the usability of this solution - it changes the expected behavior of select-element navigation. Potentially it could confuse as many people as it helps.

But browsers already have a way of dealing with this, so a scripted solution isn't really necessary. If you Tab to a select element and then press "ALT + arrow key" it opens the menus and allows you to navigate with the arrow keys, not firing the onchange until you press Enter - which is exactly the desired solution in this case.

I tested this in IE5 and 6, Opera 7 and Firefox and they all have this behavior. Safari naturally does this when keyboard navigating a select element.

It would certainly worth publicising this method of navigation, but no scripted solution is necessary, and may potentially confuse.

23/26. 27 October 2004 @ 05:13, Danny Tuppeny wrote:

LOL! They do say the simple solutions are often the best!

Gez Lemon wrote an article about Invisible Form Prompts (http://dot-dot-com.com/articles/invisible-form-prompts.aspx), which shows a way you could add a text description about using the ALT key to be read by screen-readers, but not rendered by browsers :-)

24/26. 27 October 2004 @ 05:15, Danny Tuppeny wrote:

Whoops, it appears the link got munged because the brakets on the end!

A clickable link: http://dot-dot-com.com/articles/invisible-form-prompts.aspx

Though if Cameron wants to edit the original post and remove this one, it'll look tidier! :-)

25/26. 28 October 2004 @ 06:53, Joe Clark wrote:

Our dear friends at Web Essentials inconsistently (mis)spelled Bruce Maguire's name, which is written thus.

26/26. 28 January 2005 @ 04:44, Curt Griesel wrote:

Does anyone know if there is a "developers" version of JAWS?

You can download the full version of JAWS from www.freedomscientific.com It will run in "demo" mode at no cost, until you pay to have it authorized.  Demo mode is full function but only runs for 40 minutes then forces you to restart JAWS.  In my experience, demo mode is more than adequate to test some web pages I am developing.

I believe the demo expires in between 6 to 12 months from the time you install it, at which point you can re-install it and continue to run it in 40-minute mode for free.

Post your own comments

Fields marked with an asterisk* are mandatory. All HTML tags will be escaped. http:// strings in comments will be auto-linked.