Addresses

[govuk-design-system]

Ask users for addresses

Use this issue to discuss this pattern in the GOV.UK Design System.

[dashouse]

For some time (pre Design System) our recommended multi-input pattern for entering an address has contained two inputs for "Building and street", with the second input having a visually hidden label (as well as visually hidden 1 of 2 and 2 of 2).

This second input is to support users that need to enter a Company name, building name, floor, department as well as their street address.

We are wondering if anyone who has tested this pattern has seen any issues with visually hiding the second label?

[nubz]

I am struggling too with the hidden label concept - when there is an error in that field we are trying out error messages that reference Building and street (line 2 of 2) as the field descriptor in the message.

Also quite challenging is how to communicate that the second line is optional? (In our service line 1 and postcode are the only required fields).

[MahmoodAkhtar]

If the 2nd field in the address (address line 2) is an optional field then you could have "Optional" as hint text above it perhaps?

JSFiddle example

[timpaul]

Dropbox Paper audit

The research below was taken from a Dropbox Paper document, which was reviewed and archived On 8 Jan 2019 by the Design System team.

The aim was to reduce the number of places containing guidance and code by:

• migrating relevant, useful content into the Design System itself
• recording important research findings in the community backlog
• removing the original Dropbox Paper page

If you need to, you can see the original Dropbox Paper content in the internet archive.

Research

Open Address UK did some address entry user research  - qualitative testing (9 users) of free text box (which they describe as 'one single address field') against multiple fields. The results were mixed: some users preferred free text box, others preferred multiple fields. Users were faster with free text box, but ended up with more errors in the address. They made more mistakes to start with on multiple fields, corrected them as they moved address elements around, and ended up with fewer errors in the end.

The forms they used had some usability errors such as use of placeholders for example text, so those usability errors may have influenced the results.

Related links

http://www.formsthatwork.com/internationaladdresses
http://www.royalmail.com/personal/help-and-support/How-do-I-address-my-mail-correctly
http://www.uxmatters.com/mt/archives/2008/06/international-address-fields-in-web-forms.php
http://www.bitboost.com/ref/international-address-formats.html#Formats

[danielle-allen]

I have a question around examples of overseas postal or zip codes. I'm looking to add an example that isn't UK as our users shouldn't have a UK address but there isn't anything that I can find in the design system giving an overseas example that we can use.

[terrysimpson99]

Try the Universal Postal Union:
http://www.upu.int/en/activities/addressing/postal-addressing-systems-in-member-countries.html

and select "Guide to the headings used in country sheets"

Hope that helps

[danielle-allen]

This is really helpful, thanks! It's great for checking if our validation for field length stands up. It still leaves a bit of a question mark around examples we can use though.

[terrysimpson99]

I'd like to create a pull request add text to https://design-system.service.gov.uk/patterns/addresses/
The text would describe how to handle input to a postcode field. I'm aware of issue #5976

Does anybody object?

[hannalaakso]

Hi @terrysimpson99 thanks for your message. Would you mind expanding a little bit on what the PR would contain? Would it be a hint text for the user, or some documentation for the service team on how to validate postcode input?

[terrysimpson99]

Hi @hannalaakso
The latter. I'd like to add guidance about validation. Inspirations for good validation include:
https://www.gov.uk/find-local-council
https://courttribunalfinder.service.gov.uk/search/postcode
https://www.royalmail.com/find-a-postcode

Those services accept characters that aren't part of a postcode. For example: "ch1-1aa", (hyphen) "ch1 1aa" (extra space within code), "ch1 1aa" (space before code), "ch1 1aa,"(comma), " ch1 1aa." (period). In addition, some services have a limit on input characters that turn "ch1 1aa" into "ch1 1a" and then tell the user it's invalid.

Anyone that received an email or text message with those examples would accept them as postcodes and wouldn't send a message back to the user saying they hadn't provided a valid postcode.

I won't name examples of unnecessary rejection but there are sufficient to make it worth mentioning.

Hope that helps.

[hannalaakso]

Thanks @terrysimpson99 we've discussed your proposal with the team.

It would be great if you could submit a pull request as this will give us an opportunity to review the changes and discuss them with other teams.

It's hard for us to say whether this will work as guidance in a wider government context without seeing the actual changes.

Sorry if that's not too helpful! We're really grateful for your offer to help us improve the Design System 🙌

[terrysimpson99]

Thanks. I'll submit a pull request.

[jonathaninch]

Hi all - is there any reason we don't have hint text (and a more specific error message) for postcodes? With email and phone numbers we are giving examples in hint text and in error messages (e.g. "Enter an email address in the correct format, like name@example.com" or "Enter a telephone number, like 01632 960 001, 07700 900 982 or +44 0808 157 0192"), but the best we're offering users for postcodes is "Enter a real postcode" with no guidance as to what a 'real' postcode looks like, what they might have incorrectly entered, etc?

[jonathaninch]

What is the recommendation for capturing addresses which may or may not be non-UK (e.g. if we ask for a contact address and there's no guarantee it will be in the UK)?

The address standards says we should use (a) address lookup (but this doesn't usually work with non-UK addresses), (b) multiple text inputs (but this isn't recommended for non-UK addresses where we don't know the country and therefore the format) or (c) textarea (which we can't use if we need to use separate elements of the address at a later point).

That doesn't seem to leave any useable option for capturing a non-UK address?

[terrysimpson99]

If you look at https://design-system.service.gov.uk/patterns/addresses/
you'll see some guidance such as "Address lookups generally only work for UK addresses. Use a manual option such as multiple text inputs or a textarea when you are collecting mostly or only international addresses". There's more if you look further down.

[fred-jackson]

Please can we publish an international version of the address page so that I don't have to keep telling designers that it should be Postal code rather than Post code.

[CharlotteDowns]

We've just added some guidance on how to 'share findings about your users' with us 📝. This will help us learn more about how your users enter addresses within your service.

[PhiSolirius]

I've been accessibility testing services and this seems to be an issue that comes up quite often:

The drop-down list for the address field doesn’t zoom properly on certain browsers and tablet and mobile devices. When zooming in, the main content zooms correctly, but the list of places in the drop-down remains small, making it difficult to read for users with visual impairments. This is not an issue when zoomed in on desktop devices.

Is this something that is fixed from GDS team?

[stevenjmesser]

Also if this is the govt standard for location should this guidance be part of the design system? https://www.gov.uk/guidance/access-free-address-data-using-addressbase

Yes, I think this should be part of the guidance for addresses. I'm now working at MHCLG so I'd be happy partnering with some people to write the guidance, proposing a content change to the design system when ready.

[tekin]

Is there a reason why the autocomplete attribute is not set for county? According to MDM it should be set as address-level1.

We had a bug raised recently because some users data was being submitted with the first and second lines of their address set in the county field. We eventually traced this down to Safari's autofill feature: it was auto-filling "County" with the first and second lines even when a value for "County" was saved against the contact. Setting autcomplete="address-level1" resolves the issue for us.

[CaddickA]

Has anyone done any research into the start typing your address type service pattern that's quite common in other sectors?

We keep finding some issues on the postcode selector where people pick the wrong number (e.g., number 6 rather than number 5) and either don't notice or subsequently manually changing the number, but we've already pulled additional information from OS that the user doesn't see (e.g., UPRN etc) which cause some data inconsistencies.

[martinwake]

Has anyone done any research into the start typing your address type service pattern that's quite common in other sectors?

We keep finding some issues on the postcode selector where people pick the wrong number (e.g., number 6 rather than number 5) and either don't notice or subsequently manually changing the number, but we've already pulled additional information from OS that the user doesn't see (e.g., UPRN etc) which cause some data inconsistencies.

We looked at this for the DWP Design System's Find an address pattern. The short version is that we couldn't find a typeahead that worked without JavaScript, which meant we didn't include it in our out-of-the-box pattern because of the accessibility challenges. However we left it open as an option for teams to implement as an enhancement.

The Office for National Statistics used a typeahead (see the link above for a link to their research) but the non-JS version is a standard postcode search and select journey.

We considered the x-gov "accessible autocomplete" solution but it's really designed for selecting from a relatively short list of values that can be built into the code, not for live querying an API/database of several million addresses.

Typeahead does seem on the face of it like an enhanced user experience and we would like to see ways of doing it accessibly.

[Larry-des]

Where can guidance be found for International (non-UK) address input?

[joelanman]

@martinwake just to say the Autocomplete component does not have to have all the options on the page - the source parameter can be an array or a function. So you can use a function and query an API. This should be enhancing a server-side form submit that does the same search.

https://github.com/alphagov/accessible-autocomplete?tab=readme-ov-file#source

[martinwake]

@martinwake just to say the Autocomplete component does not have to have all the options on the page - the source parameter can be an array or a function. So you can use a function and query an API. This should be enhancing a server-side form submit that does the same search.

Thanks @joelanman -- we asked when we were building our pattern and the answer (from one of the developers of the component I think) was "it's not really designed for such usage and i’m not sure it would be good". I think there was also a concern that it might require multiple repeated API calls to refresh the list after each keystroke?

Perhaps I didn't distinguish carefully enough from objections to address lookups in general, which included:

• they’re expensive to develop
• cost money per search
• aren’t good where addresses are missing
• may not even be faster than manual entry

Is the assumption that it requires JS to work still correct?

[joelanman]

@martinwake

I'm not an expert in the area but I believe Addressbase is free for public sector use:

https://www.gov.uk/guidance/access-free-address-data-using-addressbase

Accessible autocomplete requires js itself, but can and should be set up to progressively enhance a non js approach - this is what I meant in my post where I said it could be a form submission to search which is then enhanced. Alternatively you just have a manual address input form, which again is enhanced with js search.

I think for the majority of people, a lookup will work, and should save them time

[martinwake]

@joelanman yes thanks, that idea of progressive enhancement is what we recommend in our pattern. We have an internal address lookup API so cost isn't directly an issue but resource usage might be if there were a very high number of calls. Obviously any design of front end query will involve some calls to the API.

By "a form submission to search which is then enhanced" I guess you mean a standard address lookup where you enter part of the address and are then presented with a list of validated results to choose from? I don't think I understand where the typeahead element fits in that example.

EDIT: I understand now - the JS enhanced version uses typeahead, with manual entry or simple search as a fallback if JS not available.

[Jon-Rowe-HMRC]

HMRC have published further addresses guidance for our department:
https://design.tax.service.gov.uk/hmrc-design-patterns/addresses/

Our supplemental pattern includes additional examples for:

• Country selection
• Postcode lookup
• Search results
• Review and confirm
• Errors

[RichardBradley]

I was using the "Change the address on your vehicle log book" service today (great work, if you're reading this) and I noticed that a couple of their text inputs, including the Postcode input, were marked up with text-transform: uppercase;

I found this very helpful as a user, as it clearly indicated to me that the inputs were case insensitive, and that I didn't need to bother typing in my postcode in upper case. It also made my lowercase input look nice.

i.e. I entered in lowercase like "sw1a 1aa" but the page automatically made it appear uppercase "SW1A 1AA".

I can't see any mention of this pattern on the "Ask users for Addresses pattern" nor the "Text input component" pages in gov-design system.

Should this good idea be promoted on those two pages?

[matteason]

@selfthinker and I discussed the use of autocomplete="street-address" in the Textarea address pattern - recording here for posterity.

The Design System uses autocomplete="street-address" on a single textarea which is meant to contain all parts of the address.

The spec for street-address says that it's only meant for the street address (so excluding city/county/state/postcode/zip code etc). MDN says the same thing. There's no correct autocomplete value for the full address.

There are arguments both for and against including autocomplete="street-address" when asking for the full address in one textarea:

• It might be useful even if it's semantically incorrect because it allows the user to autofill at least the street part of their address, and they can manually enter the rest
• However users might not notice that only part of their address has been filled in, which could cause problems down the line
• We could end up polluting the user's autocomplete values for other websites - if they enter their full address in a textarea on a GOV.UK service, that could end up in the browser's autocomplete cache, and on other sites which use street-address purely for the street address they might end up with their whole address in that field

There's a WHATWG discussion on some of the shortcomings of address autocomplete values, and a proposal to add a full-address value.

Even though the Design System says it should be included, there's an argument that it wouldn't be a failure of WCAG SC 1.3.5 Identify Input Purpose if individual services chose to exclude it because the SC says:

The purpose of each input field [...] can be [...] determined when:
The input field serves a purpose identified in the Input Purposes for user interface components section [...]

...but there is no purpose identified in that section that is the equivalent of a full address.