Decide what the selection actually changes
A region selector can mean several different things: the delivery destination for one order, the market whose catalogue is displayed, the language of the interface, or the currency used to show prices. Those are not interchangeable. Before designing the control, write down which data changes, which data is retained and whether the customer will leave the current page. A shop that silently uses one dropdown for all four decisions risks changing a customer's cart or apparent price while they think they are choosing only a delivery area. Give each choice a label that describes its actual scope. This article is about predictability of the interaction, not a recommendation to support a particular market.
W3C WCAG 2.2 success criterion 3.2.2 addresses controls whose setting changes. Selecting an option, checking a box or typing into a field changes the control's setting. Such a change must not automatically cause a change of context unless the user has been advised of that behavior before using the component. A change of context can include navigating to another page, opening a new window, moving focus or a major change of content that changes the meaning of the page. The criterion is narrower than a blanket ban on dynamic updates: updating a delivery estimate in the same place is not automatically a context change, though it still needs to be understandable.
Do not confuse choosing a value with activating a clearly named button or link. A button labelled 'Apply region' can give customers a deliberate moment to review the choice before navigation. W3C's explanation distinguishes a form control's changed setting from activating a button that submits or navigates. That makes an Apply button a straightforward design when selecting a region could reset a basket or replace the whole catalogue. The button must still accurately describe its effect, and the shop must decide what happens to existing items rather than relying on the button to hide a destructive change.
Choose a predictable interaction
If region only changes a small displayed result, consider keeping the customer on the page. For example, choosing a Hong Kong delivery district may update eligible methods and a delivery estimate beside the selector. Preserve the selected value, show the new result in text and make sure the rest of the form remains available. If the result is still being calculated, say so rather than presenting the old estimate as current. This option reduces disorientation, but it does not excuse misleading charges: final delivery costs still have to be confirmed at the appropriate checkout step.
If the selection changes the whole market or language, a page navigation may be appropriate. The simplest route is a selector followed by a button such as 'Switch to Singapore store' or 'Change language'. Show a short statement before the controls if a basket, saved form or availability will change. If automatic navigation is genuinely useful, W3C technique G13 gives a different route: tell users before they reach the selector that choosing an option will immediately change the page. Put that warning in reading order before the selector and, where possible, programmatically associate it with the field. A note revealed only after the jump is too late.
The warning should describe the real effect, not merely say 'page may refresh'. Compare 'Selecting a market immediately opens that market's catalogue; items unavailable there will stay in your current basket until you review them' with a vague 'results may vary'. The first sentence gives the customer a decision; the second leaves all consequences unknown. Make the statement truthful for every option, including the currently selected one. If product, currency and delivery rules differ by market, name those differences separately where they affect the purchase. Do not promise retention of a basket unless the implemented system actually preserves it.
Work through a customer change
Imagine a customer has selected a product and begins checkout with Hong Kong as the delivery area. They change the area to an overseas destination. In a safe design, the region control states that it affects delivery eligibility and estimated costs, not the interface language. If the system can recalculate in place, it shows the new eligible methods and explains any unavailable item. If a different storefront is required, the control warns before selection and either asks the customer to activate a switch button or clearly states that selecting the destination will navigate immediately. This is a worked design example, not a claim about a live shop.
Now test interruption. The customer may have typed an address or applied a gift message before changing the region. Decide whether those values survive, are discarded, or need correction. If leaving the page will discard data, warn before the action and offer a chance to stay. A silent navigation can cause the customer to repeat work and can make the order summary look inconsistent. Also test browser Back: returning to the old page should not show an obsolete delivery estimate as if it were final. The business rule and visible explanation must agree at each step, including after a network error.
Review both language editions as behavior descriptions, not literal translations. An English hint may say 'changes this page' while Chinese says 'opens a new page'; only one can reflect the implementation. Check labels, warning position and spoken field description in each language. A translated option may be longer and wrap, but it should remain connected to the correct control. Include the warning in the same component used on desktop and mobile, rather than placing it in a desktop-only sidebar. People using touch, keyboard or screen readers should encounter the same consequence before they make the selection.
Prove the choice is predictable
For acceptance, start with a customer who does not know how the selector was built. Ask them what will change before they choose a different value; compare the answer with the actual destination, retained data, prices and availability. Test selection by keyboard and pointer, then try the same flow with a screen reader. Watch for a jump on merely tabbing into the field: W3C's separate On Focus criterion says receiving focus must not initiate a change of context. A selector should allow a customer to inspect options without losing their place unexpectedly. Record the exact option and state that causes a mismatch.
Release only when the label, pre-selection explanation and actual behavior agree. The shop may choose in-place updates, a confirm button or an advised automatic switch; each can serve a different customer task. What matters is that a setting change does not take the customer somewhere unexpected, and that any effect on the current purchase is stated before it happens. Recheck after adding a new market or delivery method, because a once harmless selector can become a navigation control when the underlying catalogue changes. Keep the decision with the product and content owners so copy and implementation move together.
Test the boundary cases that reveal hidden navigation. Select the current region again; choose an unsupported destination; change from a delivery region to a collection-only region; and return with the browser Back control after switching storefronts. For each case, note whether focus stays on the control, whether a message appears, and whether order totals are recalculated or left pending confirmation. If a region is unavailable, a clear explanation and a way to choose another option are more useful than an unexplained jump back. These checks expose differences between the intended design and the actual form behavior without assuming that every dynamic update is a WCAG failure.
Before you proceed
- The selector label says what its setting changes.
- Any automatic navigation is explained before selection.
- Cart, entered data and price effects match the warning in both languages.
