WebAIM - Web Accessibility In Mind

E-mail List Archives

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

for

Number of posts in this thread: 3 (In chronological order)

From: Don Hinshaw
Date: Wed, Apr 27 2005 2:17PM
Subject: advisability of putting instructions in a <select> menu
No previous message | Next message →

Hi there,
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?

Thanks,

--
Don Hinshaw
Hinshaw Design Group
http://www.hinshawdesign.com

From: Patrick H. Lauke
Date: Wed, Apr 27 2005 2:32PM
Subject: Re: advisability of putting instructions in a <select> menu
← Previous message | Next message →

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 tricky one...

P
--
Patrick H. Lauke
_____________________________________________________
re

From: Jukka K. Korpela
Date: Wed, Apr 27 2005 11:11PM
Subject: Re: advisability of putting instructions in a <select> menu
← Previous message | No next message

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
http://www.cs.tut.fi/~jkorpela/forms/choices.html
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.
http://www.iso.org/iso/en/prods-services/iso3166ma/02iso-3166-code-lists/list-en1-semic.txt
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/