WebAIM - Web Accessibility In Mind

E-mail List Archives

RE: State Abbreviations in Dropdown - Permitted?

for

From: Andrew Kirkpatrick
Date: Dec 2, 2005 9:00AM

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

I think that "serious discrimination" is a stretch. The page is
probably in English (we'll put aside whether that is a more or less
serious issue for now) so the user needs to have a basic understanding
of the language. They get to a drop down list that is probably preceded
by "state:". I would think that it's pretty clear that these 2-letter
codes clearly must represent the list of states in the US since the user
is typing in a US mailing address.

The mapping between the codes and the state names is readily available
and in U.S. English are very common usage. Someone outside the country
or new to the country may not have heard of "Rhode Island" or "RI", but
if one wants to send mail there it is not unreasonable to expect that
they will learn this. We also expect that the user puts in a zip code,
for which there is no expanded version - is that also 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.

I find that they are highly usable. I don't listen to 49 options, I
type "m" to get to the m's and then move to MA. If I want to scan the
list I can use pageup/down to page through the list. If I am looking
for Zaire in a list of countries I can hit 'end' to move to the bottom
of the list.

What technical complications do you mean?

Lists are also good for users who are bad spellers or who have mobility
impairments - they can save typing (although not much in a list of state
abbreviations) and ensure accuracy.

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

I don't agree. "M" happens to be one of the more common state letters.
Want Montana? Hit "m" a few times until montana appears.

Of course, the reason to use the list is for accuracy of data. You've
never seen a page return an error saying "sorry, you entered a state
that doesn't exist" when there is a dropdown, right?

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

Sure. I don't personally find this very compelling of a case, but
that's me.

> 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.)

A fine idea.

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

But it is a detail that is dealt with because people do, and will
continue to, use drop downs for simple predictable data.

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

I think that you're mixing the issues here. We should not use drop
downs because we're more likely to remember to think about security if
forced to use straight text inputs? I think that a developer is either
going to attend to security or they won't, without regard to the control
type.

AWK