Unobtrusive and keyboard accessible connected select boxes

Any web developer who has created a reasonably complex form is probably aware of the concept of multiple select elements that are connected – choosing something from one select box either makes a new select box appear or changes the options of one that is already visible.

There are usually two problems with this approach. One is that most implementations are completely dependent on JavaScript being available. Often there either is no submit button at all, or there is a submit button but without JavaScript there is no way to access the options that appear only as a result of changing the first select box. The other problem is that in some browsers, using the cursor keys to change the selected option triggers the onchange event immediately, so you can never get past the first option unless you know how to use your keyboard to display all options.

I normally work around these problems by requiring users to submit the form to get the next set of options from the server. Obviously that isn’t an ideal solution either. So what other options do we have? One option that looks promising is described by Christian Heilmann in Unobtrusive connected select boxes - yet another solution approach. It involves using optgroup elements to create a two-level select box, which is then split into two separate select boxes if JavaScript is available. Neat.

The solution Chris describes solves (or at least mitigates) the keyboard access problem since it doesn’t reload the page when the onchange event is triggered. And if JavaScript is unavailable, there is a single select box with option groups.

The catch is that nested optgroup elements are not allowed in current versions of HTML, so this will not work when more than two connected select boxes are needed. Nested optgroup elements are allowed in the current Web Forms 2.0 Working Draft, so I guess there is a reasonable chance of that change making it into HTML 5.

Posted on April 18, 2007 in Accessibility, JavaScript, Quicklinks

Comments

  1. April 18, 2007 by Koen "Grubolsch" Eelen

    Why don’t use much more simple approach, based on the principles of Unobtrusive JS? The invisible selects, are made invisible by javascript self when the page loads. In that way, if JS is disabled or unavaible, it will show all the selects. If it’s avaible, you get the better GUI.

  2. Oh darn, now you blogged this. I have a solution that allows for several levels by using nested lists with radio buttons, but it is dirty, so let me clean it up and blog about it once it is done :)

  3. I quickly cobbled together the solution for multi level connected select boxes and linked it on the post.

  4. April 19, 2007 by Roger Johansson (Author comment)

    Koen: Because that way the second won’t change its content based on the choice you make in the first one. Or am I misunderstanding you?

    Chris: Ah, nice update :-).

  5. I would go for a list of RADIO buttons. In each LI there would be a nested list with more RADIOs. This I would transform into a relational set of SELECTs, using JavaScript.

    This works fine for relatively small lists, but if there are a lot of options one better go look for an alternative, like a two-step form. transformed into one.

  6. April 19, 2007 by Seraphim

    I’m currently using this for my case involving 3 inter-connected comboboxes.

    Not sure if there’s any major drawback compared to Christian’s method.

  7. I’ve been using a combination of onclick and onblur events - mouse users click on an option, and it activates, while keyboard users hit tab when they have selected, and the blur event kicks in. Obviously, this only really works when you have multiple form elements (else why would the keyboard users tab to the next control), but when you want to populate the next based on the contents of the first, you’re just using natural behaviour.

  8. My solution was to create some Javascript that set the class of the container based on the selection and then hiding some of the options using CSS.

    Unfortunately I realised that IE doesn’t permit options to be hidden but the script works for other things like showing or hiding entire dropdown boxes of sections of form.

  9. Typo, second paragraph, first line:

    “There are usually two problem with this approach.”

    obviously should be

    “There are usually two problems with this approach.”

  10. May 9, 2007 by Roger Johansson (Author comment)

    Lee: Thanks for catching that one.

Comments are disabled for this post (read why), but if you have spotted an error or have additional info that you think should be in this post, feel free to contact me.