Accessible JavaScript tip #43: onchange select menu

19 October 2004

26 comments

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

» 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.

Update 2013-12-13: Adam Yocum has made some updates and improvements to this script, which you can see at: http://adamyocum.com/accessible-onchange-select-menu/.

Categories

, ,

Comments

  1. 1/26

    Malarkey commented on 19 October 2004 @ 02:56

    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. 2/26

    chris holland commented on 19 October 2004 @ 11:53

    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. 3/26

    Lachlan Hardy commented on 19 October 2004 @ 15:38

    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. 4/26

    Dean Jackson commented on 19 October 2004 @ 15:52

    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. 5/26

    Andrew Krespanis commented on 19 October 2004 @ 17:11

    " Javascript is not a dirty word!!!"

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


    ...smartass ;)


  6. 6/26

    Stefan Kremer commented on 19 October 2004 @ 18:18

    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. 7/26

    The Man in Blue commented on 19 October 2004 @ 18:44

    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. 8/26

    Mark Wubben commented on 19 October 2004 @ 22:07

    Sweet idea. And JavaScript rocks.

  9. 9/26

    Jonathan Snook commented on 19 October 2004 @ 23:06

    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. 10/26

    Jonathan Broome commented on 19 October 2004 @ 23:10

    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. 11/26

    Jonathan Broome commented on 19 October 2004 @ 23:18

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

  12. 12/26

    name commented on 20 October 2004 @ 00:17

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

  13. 13/26

    Unearthed Ruminator commented on 20 October 2004 @ 02:00

    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. 14/26

    Jason G commented on 20 October 2004 @ 05:13

    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. 15/26

    chris holland commented on 20 October 2004 @ 05:42

    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. 16/26

    Richard Rutter commented on 20 October 2004 @ 18:59

    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. 17/26

    Chris Bloom commented on 21 October 2004 @ 22:13

    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. 18/26

    Jeremy Keith commented on 21 October 2004 @ 23:29

    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. 19/26

    Danny Tuppeny commented on 22 October 2004 @ 17:04

    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. 20/26

    The Man in Blue commented on 22 October 2004 @ 17:28

    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. 21/26

    Danny Tuppeny commented on 23 October 2004 @ 03:21

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

  22. 22/26

    Brothercake commented on 27 October 2004 @ 02:34

    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. 23/26

    Danny Tuppeny commented on 27 October 2004 @ 05:13

    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. 24/26

    Danny Tuppeny commented on 27 October 2004 @ 05:15

    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. 25/26

    Joe Clark commented on 28 October 2004 @ 06:53

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

  26. 26/26

    Curt Griesel commented on 28 January 2005 @ 04:44

    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.

  27. Leave your own comment

    Comments have been turned off on this entry to foil the demons from the lower pits of Spamzalot.

    If you've got some vitriol that just has to be spat, then contact me.

Follow me on Twitter

To hear smaller but more regular stuff from me, follow @themaninblue.

Monthly Archives

Popular Entries

My Book: Simply JavaScript

Simply JavaScript

Simply JavaScript is an enjoyable and easy-to-follow guide for beginners as they begin their journey into JavaScript. Separated into 9 logical chapters, it will take you all the way from the basics of the JavaScript language through to DOM manipulation and Ajax.

Step-by-step examples, rich illustrations and humourous commentary will teach you the right way to code JavaScript in both an unobtrusive and an accessible manner.

RSS feed