Address Form Testing in 2026: A 40-Point QA Checklist

Start by writing down every field, its purpose, its storage limit, and whether it is required. Half of the defects in this checklist are impossible to evaluate without that table, because "the form rejected my address" is not actionable until you know which field rejected it and why.

Constraints should be per country, not global. A single postal max length of 10 works for most countries and breaks for Ireland at 8 characters with a space, and a global city max of 30 truncates plenty of real names. Set generous limits and validate the country pattern rather than a length that was chosen for one market.

Changing the country must reset the region, relabel the postal field, change the keyboard and the pattern, and clear any stale validation state. The classic bug is a Canadian province left selected after switching to the United States, which submits a valid-looking form with an impossible pair of values.

Hong Kong and the United Arab Emirates have no postal codes, so the field must become optional and the label should say so. Japan reverses the address order, and the form should either present fields in the local order or make clear that the Western order is expected. Test the switch in both directions and test a country switch after a validation error has already been shown.

Validate format on blur, validate required fields on submit, and clear an error as soon as the value becomes valid. Validating on every keystroke punishes a user who is halfway through typing a postal code, and validating only on submit means the user discovers six errors at once with no guidance.

Never disable the submit button as a substitute for validation. A disabled button with no explanation is the most common accessibility complaint in address forms, because the user cannot tell what is missing and a screen reader may not announce the change. Keep the button enabled, submit, and show a summary with links to each field.

An error message must say which field is wrong, what the accepted format is, and how to fix it. "Invalid address" fails all three. "Postal code must be 5 digits, for example 97205" passes. For countries whose format is unusual, include an example rather than a pattern, because users do not read regexes.

Place the error next to the field and also in a summary at the top of the form when the form is long. Associate it with aria-describedby and set aria-invalid on the input. Move focus to the first invalid field on submit, or to the summary if the summary is interactive. Test with a screen reader, not just visually.

Paste is where formatting bugs surface. A user pastes "K1A 0B1" with a non-breaking space, or a full address into line 1. The form should trim, normalize known separators, and preserve internal spaces. It should not strip hyphens from a ZIP+4 or from a Dutch code, and it should not uppercase a city name that is legitimately mixed case.

Autofill depends on the correct token names. Use address-line1, address-line2, address-level2 for city, address-level1 for region, postal-code, and country, and do not reuse street-address on a single-line field unless it really is a multiline street block. On mobile, numeric keyboards usually lack a hyphen, so a ZIP+4 or a Dutch code entered with inputmode="numeric" becomes impossible to complete. Use inputmode="text" where the pattern allows separators.

Test the boundary and one character past it for every field. Truncation is worse than rejection, because the user sees a successful submit and the stored value is wrong. If the database column is 50 characters and the form allows 100, the defect appears only on long inputs, which is exactly what hand-written fixtures never contain.

Test non-ASCII characters: accented letters, the apostrophe in O Connell, the hyphen in a French street name, the sharp s in a German street, and right-to-left scripts. Check that the value round-trips through the API, the database, the CSV export, and the printed label. Encoding bugs often appear only at the export step, which is the step nobody tests.

Every field needs a visible label programmatically associated with the input. Placeholder text is not a label: it disappears on input and is inconsistently announced. Group the address fields in a fieldset with a legend, and make the country and region selects operable by keyboard with a type-ahead.

For right-to-left locales, set dir on the container and not on individual inputs, so the punctuation and the error icon stay in the right place. Check that translated labels do not overflow at 200 percent zoom, and that the error summary is announced when it appears. These are cheap checks that catch the defects accessibility audits charge for.

Turn the checklist into a small automated pack that runs on every change. Twenty cases cover the failure set: one valid and one invalid case for the primary market, one case each for Canada, the UK, Germany, Japan, Brazil, Hong Kong, and the UAE, plus boundary lengths, a non-ASCII city, a pasted value with a non-breaking space, and a country switch after an error.

Keep each case independent and seeded. Assert on the shape of the result rather than a literal string, and assert on the visible error text for the invalid cases, because error copy regressions are real regressions. A pack this size runs in seconds and catches the majority of the defects described above.