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.
- Previous post: Poll results: 50.4% of respondents maximise windows
- Next post: Transcending CSS: The Fine Art of Web Design (Book review)
Information, sponsorship, and externals
About the author
Roger Johansson is a Swedish web professional specialising in web standards, accessibility, and usability. More about me and this site.
Latest articles
- Validation statistics from Nikita the Spider Comments off
- An analysis of the sites crawled by the bulk validation tool Nikita the Spider during March 2008.
- Authentic Jobs API and Affiliates program Comments off
- The Authentic Jobs job listing service now has a public API and an affiliate program.
- What does Acid3 mean to you and me? Comments off
- Opera and Apple have announced that their web browsers pass the Acid3 Browser Test, but how will that help web designers and developers?
- Designing Web Navigation (Book review) Comments off
- Learn the fundamentals of navigation design and design better navigation systems for large and small sites as well as for web based applications.
- DOMAssistant bundle for TextMate Comments off
- To save keystrokes and speed up development I have created a DOMAssistant bundle for TextMate.
- First impressions of Internet Explorer 8 Beta 1 Comments off
- My impressions after trying out Internet Explorer 8 Beta 1 for a couple of days.
Comments
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.
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 :)
I quickly cobbled together the solution for multi level connected select boxes and linked it on the post.
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 :-).
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.
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.
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.
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.
Typo, second paragraph, first line:
"There are usually two problem with this approach."
obviously should be
"There are usually two problems with this approach."
Lee: Thanks for catching that one.
Sorry, comments are closed for this post.