Menu

Country select field testing: search, sort order and keyboard access

Country select field testing needs more than checking that the list appears. Search, sort order, aliases and keyboard access each fail in their own way.

Published

  • form controls
  • accessibility
  • test data

Country select field testing tends to stop at the first assertion that the list renders. The control looks trivial — a list of countries, a click, a value — and that appearance is exactly why its defects survive so long.

The control is a small interface over a large dataset, and every interesting failure lives in the interaction between the two. This article covers the shapes the control can take, the several kinds of search people expect from it, the sorting rules that are easy to get wrong, and the keyboard path that is usually the last thing anyone tests.

What shapes does the control take?

At least four, and they fail differently enough that a test written for one proves nothing about the others. There is the closed list that shows every option, the searchable list that filters as the user types, the hierarchical picker that asks for a region before a country, and the autocomplete that accepts free text and resolves it afterwards.

The last one is the important one. Once the control accepts free text, it is no longer a selector; it is a matching problem with an interface on top, and the failure modes change from “the option was not offered” to “the option was offered and something else got stored”.

Test each shape your product actually ships, and test the transition between them. A control that switches from a plain list to a searchable list above a certain number of options will only be exercised at the boundary by a test that intentionally lands on both sides of it.

What does search mean in this control?

Several different things, and users do not distinguish between them when they type.

What the user types What they expect What often happens
The first few letters of a name A filtered list, in the list’s own order Filtering works, ordering drifts
A code instead of a name The country with that code Codes are not searched at all
A familiar short form The country, once No alias exists, list is empty
A name with an accent typed without one The same country Comparison is byte-exact

Each row is a separate assertion. Search by name, search by code, search by alias, and search by a spelling that differs only in diacritics or capitalisation are four features, and shipping one of them is not evidence about the other three.

There is also the question of what happens when search finds nothing. An empty list with no explanation reads as a broken control, and the user’s next move is usually to retype the same thing slightly differently, which produces the same empty list.

Why is sort order so easy to get wrong?

Sorting a country list looks like an alphabetisation task until the list leaves the Latin script, and even within it the question of which article or particle leads a name changes the answer.

Three conventions compete. Sorting by a display name gives the order a reader expects for the names they can see. Sorting by an underlying code gives an order that is stable but meaningless to a user, which shows up as a list that appears shuffled near the top. Sorting by an internal identifier gives an order that shifts whenever the underlying data changes, which shows up as a list that behaves differently between releases without anyone touching the sort code.

Whichever you choose, the order has to be computed with the collation rules of the language being displayed, not with a default byte comparison. A list that is correct in one language and visibly wrong in another is the signature of a byte comparison wearing a sort label.

Two further details are worth an explicit test. The position of a country whose name begins with a character that has several valid orderings, and the position of a country that is usually discussed with a leading article. Both are the sort of case where an implementer’s assumption is invisible until someone from that market reads the list.

Do the options stay consistent when something else changes?

A country control is rarely alone on a form. It usually sits next to a language, a currency, a phone field or an address block, and those fields often depend on the country’s value.

The test that finds defects here is a recompute test. Change the country and check what happens to each dependent field: is it cleared, re-derived, left untouched, or validated against the new country? Each of those is a defensible choice and no two of them produce the same user experience, so the choice should be stated rather than discovered.

The harder case is a dependent field that was filled before the country was chosen. If the country changes afterwards, a value that was valid for the previous selection may now be invalid, and the control has to decide whether to keep it, flag it, or discard it. Filling the dependent field first and then changing the country is a two-step test that most suites never perform.

For developers: test the keyboard path as a first-class path

Mouse interaction covers the obvious cases and misses the ones that matter for anyone not using a mouse. A complete pass exercises typing into the control to filter, moving through results without leaving the field, and committing a choice from the keyboard alone.

Screen reader behaviour deserves its own check, because a list that is visually filtered and a list that is announced as filtered are different experiences. If the count of results is shown visually but not announced, the user has no way to tell a narrow filter from an empty one.

Then keep the test data honest. Alias tables, display names and typed input in a test suite should be obviously invented so that nobody later mistakes a fixture for a real entry, and the country and region directory is the better place to look when you want to see how names and codes are presented together. A single country page such as the Brazil entry is a useful reference for the level of detail a country carries outside the control.

Every option name, alias and typed example in this article is invented for illustration. The list entries used here are synthetic test material, not a real picklist, and no fixture shown should be treated as a country’s actual name or as evidence about how any particular product behaves.

Next steps

Write four tests, one per search kind, and run them against whichever shape of control you ship. Then repeat the whole pass with the mouse unplugged. The guide to country versus language explains which layer of a screen the control actually belongs to, and the guide to cross border address scenarios shows what happens when this control’s value is not the only country in the transaction.

Keep reading

Address & Identity Data Formats for 86 Countries guides