Skip to page content or skip to Accesskey List.
Search evolt.org
evolt.org login: or register

Work

Main Page Content

Accessible Interdependent Select Boxes

Rated 3.4 (Ratings: 11) (Add your rating)

Log in to add a comment
(25 comments so far)

Want more?

 
Picture of codepo8

Chris Heilmann

Member info | Full bio

User since: July 29, 2002

Last login: April 27, 2006

Articles written: 17

In the constant struggle to make web sites accessible to everyone, we sometimes have to reconsider some of the techniques we use in web development.

One of the main obstacles is to "de-script" forms. For years we have been spicing up forms with Javascript, and, if we didn't consider the consequences, didn't know better, or weren't allowed to elaborate due to tight deadlines, we made forms dependent on Javascript.

The classic interdependent select box

The classic example is interdependent select boxes. These are two or more select boxes, that allow the user to choose an option of one, and the content of the second gets automatically updated depending on the choice. A very neat way to filter search options or available options. Airlines use them a lot, as most flights from one airport go to a defined number of other airports.

The technique behind is to manipulate the options array of the select boxes, something that can only be done "on the fly" with Javascript.

Script, begone!

To offer a similar functionality, but make it independent of scripting, we have several options. One would be to shift all the logic to the backend, and reload the page every time you select an option of the first box. This'll be the safest way to do it, but it means another step for the user.

A nice way to work around is to rethink the concept of the interdependent select box, and make it work with normal form functionality:

Instead of using two select boxes and changing their options via Javascript we replace the first one with a row of radio buttons. Each radio button has a select box connected to it.

This is not really a 100% replacement, as the benefit of a select box — the same screen space for loads of options — is not given anymore, but it's a feasable option.

Via Javascript, we hide all the select boxes and only show the one connected to the radio button, once the radio button is selected.

Users without Javascript, or with an older browser that is not able to understand the DOM, will see all the select boxes.

HTML

<form id="mainform">
<p><input type="radio">

As the Javascript uses DOM to find the SPAN to hide and the P to highlight, all we need to do to add another select is to add it after the last one:

<p><input type="radio">

Notice we need to increment the counter for hide().

To hide all select boxes, we call the hide() function with an id of &#34;none&#34;.

&#60;body>Javascript


function hide(id){
if (document.getElementById && document.createTextNode){
spans=document.getElementById('mainform').getElementsByTagName('span');
m=document.getElementById('mainform');
for (i=0;i<spans.length;i++){
m.getElementsByTagName('span')[i].style.display='none';
m.getElementsByTagName('p')[i].style.background='#eee';
m.getElementsByTagName('p')[i].style.borderColor='#ccc';
}
if(id!='none'){
m.getElementsByTagName('span')[id].style.display='inline';
m.getElementsByTagName('p')[id].style.background='#ffc';
m.getElementsByTagName('p')[id].style.borderColor='#000';
}
}
}



The background and border colour change is just there to add some eye candy.



If there is more than one instance on the page, we need to turn 'mainform'
into a second variable added to ūcode˙hide()
.

Any other way?

Another solution would be to turn all the option of the first select into headlines with radio buttons for the dependent select boxes and hide and show the radio groups with DOM. How to show and hide them was explained in the Collapsible page elements with DOM article.

To see the code here in action, go to the Demo page.

Currently employed in London as a Lead Front End Developer, Chris has been bouncing around the globe working for several agencies and companies. A web enthusiast from 1997 on workplaces include Munich, London, Santa Monica and San Francisco. More of Chris' writings can be found at http://icant.co.uk and he blogs at http://wait-till-i.com

Doesn't work on Safari

Submitted by burchard on June 5, 2003 - 07:28.

It may not be the most popular, or standards based, browser in the world (isn't even out of beta). But thought I'd mention the selection boxes in your accessible example do not show at all in Safari 1.0b2(v74).

login or register to post comments

Can't test on Safari

Submitted by codepo8 on June 5, 2003 - 08:50.

But I had loads of feedback of this or that DHTML not working on it. Is the whole form hidden or does the browser hide the select boxes, but not show them? just FYI, I got most of our Mac Users here to use the latest Opera instead.

login or register to post comments

Re: Can't test on Safari

Submitted by burchard on June 5, 2003 - 09:04.

In the right hand table column labeled "Accessible example" the bottom cell contains the radio buttons and labels, but no selection box shows up regardless which radio button is selected. I placed a screen shot on my server in case it helps. This might just be something on Apple's end, in which case I'd be happy to report it to them.

login or register to post comments

Best way to do this...

Submitted by tapir on June 6, 2003 - 06:06.

I ran into the same challenge a few weeks ago and decided to do it this way.

(1) Put in the (non-DHTML) Javascript for interdependent select boxes that modifies the second select box on the fly.

(2) Put some error handling code on the server side. If the second box doesn't contain a selection that's appropriate for the first box, we go back to the original form and fill the second box with the options that the Javascript should have filled in.

This has the advantages that: (a) the Javascript will be fully functional on the widest range of browsers (Netscape 3, Konquerer-derived browsers, etc.) and (b) people with no javascript can't put bad data into the system because there is server side validation. The Javascript that controls the second select box is very simple and doesn't have cross-browser issues the way any kind of DHTML scripting does.

login or register to post comments

Doesnt work well in IE

Submitted by dapsycho on June 6, 2003 - 06:36.

I tried your demo but encountred a problem using IE 6 of all browsers... If you select one of the radio buttons the select box does show but I then scrolled the page down and selected another radio button and the select box didnt appear where expected, it either appeared below or above the area it should have been in...

In opera it shows all select boxes on the right anyway...

Mozilla/Netscape it works a treat!!!!

login or register to post comments

Fixed for IE6

Submitted by codepo8 on June 6, 2003 - 07:19.

I just changed the display changes from display:none/inline to visibiliy:hidden/visible and that now works a charm on IE6, too.

Safari is still not working though, but it is a beta product, maybe it has the same teething problems, Opera had (supporting DOM functions, but not showing them properly), or the onfocus handler is not supported...

Tapir:A Server solution is the best, agreed, but the interdependent Javascript "on the fly" is still dependent on a mouse, unless you add buttons to submit them.

login or register to post comments

I missed the point..

Submitted by shanx24 on June 12, 2003 - 18:22.

..but why is this more accessible? I think the "classic example" clearly SHOWS me the options right away instead of a drop down on every select, which is

  1. much clearer in terms of options I have
  2. thus makes my choice more visual and convenient
  3. makes my keyboard movements quite easy -- on the left hand side, I simply to use up and down arrow keys and I see the contextual options. Where as in your example I need to use tabs to traverse through radio buttons and then, another tab to get to the next drop down and then up/down arrow keys to see the options. If I wish to see other options I need to use another soup of tabs and up/down.

I thought this'd be great if somehow JS was unnecessary but this approach requires JS as well. I am sure I am missing something but I prefer the "Classic example".

login or register to post comments

Accessible or not?

Submitted by bearwalk on June 13, 2003 - 01:58.

I'm not sure if it's really more accessible, but it's definately more backwards-compatible to non-JS users. However, IBM Home Page Reader 3 has a habit of alerting the user that "page content has changed" when something like this switch is done, and begins reading the entire page from the beginning again.

Here's an idea to those who want to conserve screen real estate: Position (with javascript) the select boxes on the exactly the same place and then toggle visibility as in the demo page. Then you won't have to use the radio buttons. A possible drawback is that these select boxes will not be as clearly associated with the first one, since they will not appear next to it in the flow.

dapsycho: Were you using Opera 6? In Opera 7.1 it worked very well.

login or register to post comments

Added advantage

Submitted by branko on June 13, 2003 - 07:11.

An added advantage of your method is that one's choices are remembered by the browser (I guess in theory this depends on the browser, and I did not try it with more than Phoenix/Win).

login or register to post comments

Not sure

Submitted by shanx24 on June 13, 2003 - 07:16.

I don't see that happening automatically based on the code here. What did you mean by browser remembering the choices? If I reload the page, or if I simply come "Back" to it from the next page? Regardless, this should be trivial with use of cookies in both the classic as well this code sample.

login or register to post comments

It is not dependent on Javascript

Submitted by codepo8 on June 13, 2003 - 07:49.

That is the point. Javascript is used to hide and show the dropdown next to the radio button. If you don't have JavaScript enabled you get all the dropdowns. As for your example of easier navigation, that only works when you have javascript enabled (and thus getting the other options) and you SEE the dropdowns.

login or register to post comments

That makes sense, but..

Submitted by shanx24 on June 13, 2003 - 16:14.

codepo8, yep, in this demo example, what you say makes sense. But this is a decent alternative if the number of left hand side alternatives you have is limited (e.g., 5 in this example). However, if you have 15 or 50 or 100 (which is quite easily possible) then this new suggested method will take up a whole lot of real estate without adding any real benefit. In fact it may make navigation is a lot more difficult. Still honestly looking for a reason to do it this way.

login or register to post comments

explanation

Submitted by branko on June 14, 2003 - 01:18.

shanx: I don't see that happening automatically based on the code here. What did you mean by browser remembering the choices?

With JS enabled, in the inaccessible example, when you click on the first main option, select a suboption, switch to the next main option, then go back to the first main option, the suboption you selected is no longer selected, at least in my browser. Without looking at the code, I would guess this is because the JS needs to reinitialize the suboptions listview. In the accessible example, all the suboption listviews are already there, the only thing the JS needs to do is to hide and show them.

It's not really important though. The only situation I can think of is when a user almost makes a decision, choosing a 'departure airport' and 'arrival airport', decides to see if there's an alternative and then decides to go back to their first choice.

login or register to post comments

re: I missed the point..

Submitted by branko on June 14, 2003 - 01:26.

shanx: why is this more accessible?

Shanx, I fear your mixing up accessibility and usability. Often they overlap, sometimes (basically whenever you need to roll your own interface--which, btw, is almost always a bad idea) they are at opposites. Accessibility means that your web site can be used by anybody, using any browser. Usability means that it can be used optimally by the largest possible group of users, but not necessarily all users. Of course, in this specific example, this means that the menus are more accessible to the large majority of users; however, in the context of web design, accessibility has a specific meaning that Chris uses here.

login or register to post comments

DOH!

Submitted by dapsycho on June 19, 2003 - 03:06.

bearwalk, I was using 6... I thought it was the latest one but obviously not... However 6 is still quite recent!

login or register to post comments

Re: DOH!

Submitted by bearwalk on June 21, 2003 - 09:53.

Quite true. Opera 7 only came out 6 or 7 months ago.

login or register to post comments

Re: It is not dependent on Javascript

Submitted by ragnaar on June 29, 2003 - 23:18.

In the article, one of the Paragraph Headers is titled: Script, begone!

Whereupon, Javascript is worked into the solution. The way I see it, you should either create a solution that is cross-browser compatible using Javascript, or one with no Javascript at all. On the usability side of things I have to agree with Shanks' comment about the potential number of options making this un-readable... I frequently have to deal with select boxes that contain upwards of 100 items. Also, how would this solution deal with Select box interdependency when more than two boxes are involved? Radio buttons, by definition, are not select boxes - therefore it seems as though the title of the article has been contradicted by the solution provided..

login or register to post comments

Agreed, however...

Submitted by codepo8 on July 4, 2003 - 08:27.

The solution provided would not need ANY Javascript, and still is usable. The script added at the end is simply there to enrich the user experience. Turn off Javascript in the example and you still will be able to use the form. Use a normal interdependent select box and you are stuck. This is what this whole article is about.

It is NOT meant as a perfect replacement, as there is none, except for reloading the pages.

As stated: "To offer a similar functionality, but make it independent of scripting, we have several options. One would be to shift all the logic to the backend, and reload the page every time you select an option of the first box. This'll be the safest way to do it, but it means another step for the user. "

Noone stops you from doing that.

Personally, I consider the idea of usability and select boxes with over 100 options rather an academic discussion. Even with optgroups it is quite a pain to select one option from 100 different ones.

A better solution for something like that would be a search function to drill down and then start the dependent select boxes with lesser options.

login or register to post comments

Nope..

Submitted by shanx24 on July 4, 2003 - 14:33.

Actually most of the places where I have seen such select boxes used has way many more than 20-30 options, even more than 100 is a regular thing. As I write, I have a window open with one example -- a project related selection on our intranet. The number of projects is a lot more than a 100, and no the search function is not needed because all our employees know that when they enter the first letter of an intended project, the selection marker automatically selects the first project whose name begins with that letter. This is typical OS functionality...and is conveniently indicated just below the first selection list. Of course, there is a search AS WELL, but this traditional select box works just fine.

As you have outlined, yes there may be situations where somehow very few options in a box suffice, and where JS is _most likely_ going to be turned off - and in that case this alternative mechanism may merit a pretty good consideration. But, as you do, assuming that this is a very useful alternative for most situations (although you did throw in 'not a perfect replacement') and relegating everything else to a search based or server side drill down is not correct.

Come to think of it, if cascading lists were to be implemented most adeptly, you could check for JS and if enabled, use the old style select boxes (which are VERY convenient for reasons I mentioned in my first post on this topic, viz. easier tabbing through them), or if JS is disabled just use a server side solution.

This article is good food for thought, and actually an interesting exercise in escaping the requisites of JS, but not very practical imho. As usual, YMMV.

login or register to post comments

100 options = 100 pushups

Submitted by mcombs on July 7, 2003 - 08:11.

Whether in a web page or not, drop down boxes and popup menus with more than about 15 options are a hassle to use. Very large and scrolling popups are a disaster, yet I see them used routinely to select country.

Making them hierarchical helps and hurts. Often, hierarchical menus on the web don't support moving the mouse diagonally to to submenu item, which makes the menu a chore to use. But this is still better than a giant scrolling list.

Canon has a pretty good solution for countries; first they require the user to select a region (Americas, EMEA, Asia, Oceania, Japan), then select the country. They do it in two pages. One page would be better, of course.

I think the solution Chris has presented here might be great for solving this common problem. Order forms, especially, need to be accessible and convenient.

Oh, in case the title wasn't clear enough, I'd like to introduce the popup pushup rule. The number of options on a popup menu should be less than the number of pushups you're willing to do. (In my case, popup menus have no more than 3 options.)

login or register to post comments

Can do

Submitted by shanx24 on July 7, 2003 - 17:56.

I am stepping into subjective opinionating here, but actually I dislike the Canon/Logitech/HP menus from the point of usability because they require me to --

(1) Process a form of information that I need to 'think' about (Oceania? etc) (2) Two steps in selecting a country

Most users that I know of KNOW that on a huge country dropdown, all you need to do is select the drop down and then select the letter you are working with.

E.g., in the case of Japan I select the drop down and press J twice. Almost always gets me to Japan (the first is Jamaica). If you are worried that most people dont know this 'feature' then I'd think it is a much better idea to insert a helpful 'tip' message below the drop-down instead of redesigning the whole interface. Sometimes, doing what is commonly done (even if not the most optimal) is most user-friendly because it doesn't require users to process anything unusual.

100 pushups? Can manage that even in my sleep (as I often do) :-)

login or register to post comments

Drop down delimas

Submitted by mcombs on July 7, 2003 - 18:30.

Here are just a few problems with large popup menus, especially for country use:

  • Pressing the first letter of your choice doesn't work in some user interfaces. Try it on a Macintosh or a Palm Pilot.
  • The first keystroke shortcut often doesn't make sense. When selecting the year 2003, I have to press 222. Why not just type "2003"? It's only one more keystroke. Next year, I'll have to type 2222 for the year 2004. For month, I type 11 for 10 and 111 for 11. Just shoot me.
  • Not all drop down menus use the first keystroke shortcut method. Sometimes, you can type the first few letters of your choice. Typing uni will trigger autocomplete of "United States". This is the way that the URL drop down menu works in many browsers.
  • Arranging entries to work with the first keystroke shortcut puts the United States waaaay down the list. Alphabetical order may be fair, but does it make sense if 90% of your site visitors are from the US, 8% from the UK, and 2% from elsewhere? Mouse users are severely penalized. The usability penalty is worse if your page layout puts this field at the bottom of the screen, since scrolling will be needed to even see these entries.
  • I'll bet you lunch that most users don't know about the first keystroke shortcut. Most don't even know about tabbing between fields. I've seen this in dozens of usability tests. Of course, this will depend on your audience. I would expect 100% of eVolt users to know this shortcut.

And to respond directly to your confusion about Oceania, I suspect that if you live there, it's not as confusing to you. Perhaps. I don't live there, so I don't know. Canon reduces confusion by graphically illustrating the geographical region on mouseover, which was a great touch. But my suggestion is actually not to copy Canon, but to adopt the technique here to provide the country selection with two hierarchically related drop down boxes.

login or register to post comments

Some thoughts..

Submitted by shanx24 on July 7, 2003 - 21:25.

Arranging entries to work with the first keystroke shortcut puts the United States waaaay down the list. Alphabetical order may be fair, but does it make sense if 90% of your site visitors are from the US, 8% from the UK, and 2% from elsewhere? Mouse users are severely penalized.
It is quite common to have the menu choices as follows in this case--
  1. USA (Could be selected by default)
  2. UK
  3. Japan

  4. ----
  5. Algeria
  6. Andorra
  7. ...etc...
Which is actually quite a common-sensical way of doing it. It could be taken one step further, and the IP of the user could be checked for country and the 'suggested' country be automatically selected. Have seen this done, and found it very convenient.
Not all drop down menus use the first keystroke shortcut method....Typing uni will trigger autocomplete of "United States"
Which, I imagine, should make the case of drop-downs stronger?
The usability penalty is worse if your page layout puts this field at the bottom of the screen, since scrolling will be needed to even see these entries.
Not sure what you mean. Drop downs on most OSes will unfurl according to screen space and positioning.
I'll bet you lunch that most users don't know about the first keystroke shortcut. Most don't even know about tabbing between fields. I've seen this in dozens of usability tests.
Precisely why I have suggested (thrice, I might add) that a minor tip be added to forms. I could bet you a sushi dinner too that even the slowest of users would try out this suggestion of typing the first letter for all the drop-downs they encounter in the future (because it is SO convenient). It is better to educate, especially if so simple, than to look for kludges.
When selecting the year 2003, I have to press 222. Why not just type "2003"? It's only one more keystroke. Next year, I'll have to type 2222 for the year 2004. For month, I type 11 for 10 and 111 for 11. Just shoot me.
Firstly, I can imagine year drop-downs being useful as opposed to free form text input boxes for several reasons, including:
  1. To restrict the values that users can input, as a free form text input box (for typing the year) would lend itself easily to junk.
  2. To clearly show the user what options are available.
  3. To show a long list of years (e.g. in a birthday) where the years dont all begin with 20 but with 19 as well. In some cases, I have seen people only include years until 1999 (because 4 year olds are quite unlikely to use their website) in which case, they type the 19 before the form, and leave you with a much smaller list to run through. Not 'futuristic' if one were to be a purist, but very very useful.

Secondly, I don't see how the techniques illustrated in this article would be any more convenient in your example.

Thirdly, ask a modem user from Indonesia or Slovenia whether she prefers to type 111 or wait for a second page to load.

Fourthly, several 'auto-fill' solutions are out there these days, including Google's latest bar, or others such as Gator. Of course a vast chunk of users will probably never use this, but it is worth a mention because such solutions would make long drop-downs moot -- however, two pages for simple selections such as country would be painful anyway.

Canon reduces confusion by graphically illustrating the geographical region on mouseover, which was a great touch.
Nice touch I am sure, but I am surprised one would be comparing a Flash/image-map based solution with two pages (however cool it looks), to a simple drop down menu which achieves the same thing in ONE step, with minor education for the user. Just ask users from slow speed connections, or the other end of the spectrum -- high end users who'd rather just select a country with their well known tricks ONCE than wait for all the engaging frills.

login or register to post comments

Some clarifications

Submitted by mcombs on July 7, 2003 - 22:13.

You misunderstood a couple of my points, so I'm going to elaborate a bit and point to some examples. I'm not going to debate the points where we disagreed -- we'll never come to agreement here, especially over issues like typing 2222 when entering 2004.

Some drop down menus use the first keystroke to move you to a matching entry. Others, like the address bar in many browsers, use an auto-fill mechanism. It isn't immediately clear to the user if they should type "uuuuu" or "united s" for United States. (Safari doesn't allow keystrokes. IE Mac uses auto-fill. Since Mozilla is the same code-base for all platforms, I assume it uses the first keystroke.) As long as a user sticks with one browser, they'll come to learn the mechanism and all is okay. Or is it? Drop-down menus are sometimes written in JavaScript or Flash, making it harder for the user to predict how the interface works.

Long drop-downs, especially if the selection has to be made by mouse, are harder to use when they scroll. If the default selection is at the top of the list, when the drop down opens and is large enough to fill the screen from top to bottom, the top half will be blank, while the bottom half can only be reached by scrolling. Cutting down the list size is a good thing.

For what it's worth, I went to Amazon.com to explore this. If you edit your address book, you can see these long menus in action. It was interesting to note that you can select USA or United States. This was a nice touch, since I could make my selection by typing US, or Un and then pressing down arrow a few times. Amazon also puts the default entry, or your last entry, at the top of the list.

I simply think that the solution on this page gives webmasters a chance to cut down on the size of the drop-down menu on a single page. First, use a radio button to select region, then use a drop-down to select country. And don't forget the accessibility bonus. Aural users could skip having countries from other regions read to them. That's got to get old.

login or register to post comments

Some food for thought

Submitted by codepo8 on July 15, 2003 - 08:16.

Just because a technique is commonly used doesn't make it a good solution. A lot of webdesign decisions especially in bigger companies are more related to marketing or "because the CEO likes it" than real usability testing. And let's not forget that it is really easy to pull all the countries from one database and write one select box to let the user deal with the problem than thinking about it properly. The argument "but this or that big website uses it" is useless, as it is not a hard task to show 20 other huge companies who do things horribly wrong (badly implemented dhtml dropdowns without fallback anyone?). From an accessibility and accessible usability point of view we are FAR from a good solution in common webdev. Now that the flashy bouncy backgroundmusicy dotcom world died we have the opportunity to rethink some of the concepts designers with a more aesthetic than useful eye came up. Let's also not forget that an internet web site and an intranet site are two different animals, so what floats the boat in one could be a desaster in the other.

login or register to post comments

The access keys for this page are: ALT (Control on a Mac) plus:

evolt.orgEvolt.org is an all-volunteer resource for web developers made up of a discussion list, a browser archive, and member-submitted articles. This article is the property of its author, please do not redistribute or use elsewhere without checking with the author.