Investigate possible improvements to the address pattern

[timpaul]

What

Investigate whether there are improvements we can make to the address pattern.

Why

We've had a couple of questions from users about our address pattern recently. It's been a while since we reviewed it and it's a very popular guide.

More detail

This card is to do a 2 day investigation into the following:

1. whether or not the 'county' field can safely be removed in all cases
2. whether we could provide a coded example of a postcode lookup
3. whether there's any other useful feedback on the backlog for this pattern

The following are a good starting point for the investigation:

• the postcode-lookup backlog item
• the address backlog item - in particular this comment
• this PR with suggested improvements and reasoning

Who needs to know

Chris T

[adamliptrot-oc]

I'd like to see all the address lines to have visible labels. Visible labels are especially important to users of voice control assistive technology as it means they can go directly to an input. Additionally as quite often beyond the first line, address line fields are optional, they require this information to be exposed as part of a visible label. Currently the pattern has visibly hidden address fields and this causes confusioin in teams implementing this pattern.

I'd suggest updating this pattern to show the second address line marked as optional, but all having visible labels.

[terrysimpson99]

We use: 'Address line 1' 'Address line 2' 'Address line 3 (optional)' 'Address line 4 (optional)' 'Postcode'

This has several advantages:

• Each field has a label
• Eliminates the need to provide a different UI for screenreader
• Eliminates debates about the purpose of each field and what can/cannot go in each ('building', 'house name', 'house number', 'town', 'county', etc)
• Scalable
• Simple guidance and simple to audit

[lyndsp]

Could this exploration include improvements to capturing non-UK / international addresses please? (I've already reviewed the thread at https://github.com/alphagov/govuk-design-system-backlog/issues/31). My team at HMRC are exploring options on using third party APIs to improve the quality/consistency of non-UK / international addresses. Thanks

[terrysimpson99]

One of the advantages of the above 'Address line 1' format is it works equally well for UK and non-UK addresses. The only issue is with the postcode field. You have the choice of:

• make it mandatory for UK users
• omit it for non-UK users
• make it optional if you want a single field that works for both (we do this on one service) Does that make sense?

[peteryates]

Forgive me if this is a ridiculous solution, but what's the disadvantage in just using a <textarea> for this?

I'd still lean towards asking for the postcode (and country, if required) separately as they'll probably undergo validation.

Edit

While thinking about this, autocompletion seemed like it might be problematic but it's actually covered by autocomplete='street_address', which is described by MDN as:

A street address. This can be multiple lines of text, and should fully identify the location of the address within its second administrative level (typically a city or town), but should not include the city name, ZIP or postal code, or country name.

[edwardhorsford]

I'm leaning towards using a similar pattern to that suggested by @peteryates above.

Our current pattern:

---

Our users are admins entering the addresses of trainees. Unlike users entering their own addresses, they're entering addresses that are already written down - copying from one system to another. We're finding that the majority of their other systems store the address as a single block with postcode. So to put in to separate fields as the design system recommend means many more copy and paste operations. Alternately they paste the entire address in to street line 1 - and then either cut bits out of it, or don't notice, and then things go wrong with the data.

[jonathaninch]

It's really frustrating that there is no workable address capture when you don't know where the user lives in the world. It's all well and good offering a postcode lookup for UK users, but an overseas user is faced with either a multiple field entry asking for county and postcode (?!?), or a textarea which then doesn't allow you to target and use any part of the address later in a service, such as sending data to Notify.

On a past project we've used the postcode lookup pattern with a 'Enter your address manually' or 'Enter an overseas address' link which takes you to an address capture page with simple multiple text entries e.g. Line 1, Line 2, Line 3, Line 4, Line 5, Postcode (if UK), Country (if not UK) to try and cover all bases and still allow the data to be manipulated if necessary. There's other examples of services that have had to try and work round this issue with their own design. Surely we can come up with some sort of standard pattern that ends us having to use sometimes contradictory and often unworkable existing patterns?