WebAIM - Web Accessibility In Mind

E-mail List Archives

RE: State Abbreviations in Dropdown - Permitted?

for

From: Jukka K. Korpela
Date: Dec 2, 2005 10:20AM

On Fri, 2 Dec 2005, Andrew Kirkpatrick wrote:

> Unless you're coming up with your own state abbreviations, you're safe.
> Use the abbreviations - they are well known enough.

No, they aren't. Billions of people never heard of them. Even though the
page is presumably meant for US residents primarily, the potential users
might be immigrants, refugees, or other people who do not know the
customary abbreviations used in the US. This would be serious
discrimination.

On the other hand, a dropdown menu with 50 options is a serious obstacle
for many reasons. Would you like to hear 49 abbreviations read for you
before finally reaching your state? Moreover, such menus cause severe
technical complications in many browsers, and they aren't good for
useability, since the user typically needs to scroll down and make a
selection in a clumsy way.

If you expect the abbreviations to be known, use a text input field
instead. It's faster and simpler to type "MA" than the find "MA" in a long
list.

Even if you don't expect them to be known, and you shouldn't, you can use
a text input field. You could allow both abbreviations and names.
In any case, include (before the field) a link to an accessible page that
lists the states and their abbreviations. (Preferably, that page should
contain nothing but the list or table, with minimal metadata; even
http://www.usps.com/ncsc/lookups/abbr_state.txt
might do.)

> The question I'd think about is what order to put the state
> abbreviations.

That won't be a problem if you use text input. The linked page that lists
the abbreviations should apparently be alphabetic by name.

The objection that the user can enter anything in a text input field
is actually an argument in favor of the method. It makes it clear that
the user input must be checked server-side; using a dropdown, it is too
easy to forget such elementary security issues.

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