WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: advisability of putting instructions in a <select> menu


From: Jukka K. Korpela
Date: Apr 27, 2005 11:11PM

On Wed, 27 Apr 2005, Patrick H. Lauke wrote:

>> Don Hinshaw wrote:
>>> > One often sees the first item of a <select> menu being something like
>>> > this --Select a Country--. While this may provide additional clues for a
>>> > sighted person, it seems to me to add extra noise for a person hearing
>>> > the page read. If the menu is labeled correctly shouldn't these be avoided?
>> To me, the problem is twofold. Yes, if you use a proper LABEL, having an
>> option to serve as instruction is useless. However, if the selection is
>> optional, you still need to provide a neutral default option, which in
>> turn need *some* text in it to give the user enough clues as to its
>> nature...

A <select> menu should _always_ a neutral default option, since otherwise
it is more or less undefined and browser-dependent what happens when the
user makes no choice. If you have a list of countries, you cannot know
whether the user selected Alfghanistan or made no choice, since browsers
may imply initial pre-selection of the first option. This is explained at
which also explains why using a set of radio buttons has the same problem,
though there it can be handled more easily.

This is one of the reasons why <select> menus are often problematic.
Especially if a menu contains _all_ countries (about 200), the usability
of the menu is questionable. Using a text input field and asking the user
to type a two-character country code may work much better. Alas, there are
several systems of country codes. On the other hand, the most common one,
ISO 3166, mostly coincides with country codes used in top-level Internet
domain names (.ch, .fr, .jp, etc.), so they are widely known to WWW users.
And you could have a link to e.g.
which is an official list of country codes in plain text.

Naturally, form processing should then check that the two-character field
contains one of the country codes, and (if needed) map it to a country
name when echoing data back to the user. The need for a check is actually
a good thing. It forces you to do checks that you would probably omit if
you used <select> (naively assuming that data is always sent to your form
handler through your form).

For a short menu of countries, using radio buttons is probably best.
You would have alternatives like

( ) Monaco
( ) San Marino
( ) some other country
(x) unspecified

But for menus with more options, the idea of predefined alternatives
isn't as good as it might seem. Scanning through a list of 200 options
isn't comfortable even if you know what you are looking for (e.g., you
have the same idea as the form designer on the name of the United Kingdom
or FYROM).

-- Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/