Yeah, but the idea is that the form is supposed to be designed for people who are not familiar with browsers. No offense, but what business do you guys have writing about and commenting on UI if you don’t even know that? Hmmm…

I’m not getting involved with my users’ decisions on whether it’s United Kingdom vs. Great Britain vs. the United Kingdom of Great Britain & Northern Ireland, USA vs. EEUU, how to spell Kampuchea vs. Cambodia, or the People’s Democratic/Socialist/Nihilist Republic of ____.

And I’m definitely not making screen readers wade through the United Nations roll call.

Unless you’re in the situation where you’ve got to branch off of the proper spelling of that and validate the postal code in accord with the laws of the sovereign nation in question, and I hope none of you ever are, why bother?

We don’t even do it with states here in the US, because there are still fifty of them, plus territories. That’s extra code you don’t need, and it’s still a slog with JAWS, Window-Eyes, or any other reader.

For that matter, what’s up with the $1000 price tag on said screen reader? Until Freedom Scientific or the others put that in a price range we can afford, say hello to us putting the alt tags and every other small thing just to satisfy Priority 1, and not even trying to simulate the JAWS/Window-Eyes/? experience.

Taking it from the top: Link, Home. Link, About. Link, …

I agree Henrik’s idea of some suggested defaults is excellent. Browser language doesn’t necessarily tell you where someone is however, just what they want to read a website in (though it’s a good guess of course).

IP lookups are from what I hear pretty reliable, but it may be considered overkill The additional server work may create an unacceptable lag. And maintaining a large list of IP addresses may be too much work for the average app.

Before reading this article my thoughts were let users enter the country in a simple text field. Get the server to match the name to a country, if there’s a match hurrah. If not, try to use soundex to catch similar words (i.e. soundex would match Farnce to France). The user can then be asked to confirm their choice, certainly useful if a few options are returned.

Synonyms are an interesting point. I understand what Sylvain says about being careful how you name things. In E-Commerce apps we’ve designed I’ve always used the standard ISO-3166 list of countries in a hope to keep things standard. This is also usually required to synch your country data with any payment provider you may use to process card payments.

So I guess synonyms would have to be used on a case-by-case basis.

and pr10n your email address is not there, so i can’t email you… my mail is: pietertje – at – mail [ dot ] com

Here’s the deal:

- give a dropdown to users with their 10 most used countries in transactions or operations in the site (by the way, you can use a cookie to keep those “prefered” countries)
- have a “link” in the dropdown to extend the choices to all ISO-3166 countries with a simulated dropdown loaded with an AJAX call
- the list of ISO-3166 countries is navigable with a rollodex-like interface
- in the list of those countries, we included synonyms and references to official ISO country names (ex: Yougoslavia refers to Serbia And Montenegro)

Users like to country selector. After only a few use, you get the countries you use directly in the small dropdown. For the rare occasions you have to select another country, there’s the list available with a simple interface and neat help from references and synonyms pointing you to the official names (as a banking website, you have to be careful with country name synonyms or references, you cannot have a political edge!)

I’m working on accessibility for the selector. It should work without the AJAX and Javascript stuff.