Telephone numbers

[govuk-design-system]

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

Contributors

• @edwardhorsford
• @quis
• @timpaul

[timpaul]

Hey @edwardhorsford. I'm developing this pattern (above) for telephone numbers. It's based on the guidance we have drafted in Dropbox Paper. There's nothing about validation yet though - is this anything you have knowledge of?

[edwardhorsford]

My sense is that validation depends on whether you accept international numbers or ones with area codes. If you don't, then it's easier to detect the right number of digits (after stripping formatting characters). If you do, you have to allow a pretty large range of digits.

In the UK I think you can reasonably easily detect mobile vs landline numbers - I don't think the same holds true for international numbers though (it definitely doesn't in the UK). Extensions also complicate the matter.

If helpful, here's a gist (I found on a blogpost somewhere) of various UK telephone formats - could be useful for unit testing.

[edwardhorsford]

@timpaul has asked for more comments.

Type

Suggest the input type should be tel - it's a perfect use case.

Scope of pattern

Is this about collecting phone numbers, display of phone numbers or both? If it's both, can examples of both be at the top?

Displaying the user's number as written

I'm unconvinced on the guidance to retain formatting - do we have evidence that this is important? I don't particularly mind it, but it may be quite a bit of extra work for teams to implement (storing one value but validating against another) - and it's ultimately not what's going to get stored in the database.

Services will be sanitising this data (removing whitespace / brackets, etc) - is it useful to display this sanitised value to the user?

Formatting other numbers

This is content in the content style guide - can we link out to that? Can we show some examples as well as describing it?

Other

It may be useful to call out some of the more challenging areas to think about - that we don't currently have patterns for. These include: country codes / internationalisation, extensions, weird numbers (sms shortcodes, etc).

Input masking

Rather than retaining the user's formatting, an alternative (would need to be tested) would be to swallow whitespace and special characters as they're typed and mask the input live to an agreed format. Done well, this can look really good (Stripe / Apple come to mind).

[timpaul]

Thanks for the comments above @edwardhorsford - I've updated the draft version accordingly. We've also piloting hypothes.is as a way of capturing feedback about draft guidance - feel free to use it (it's over on the right hand side of the draft).

Our content designer Amy will start writing up the finished guidance now. Would you like to review it once it's done?

[timpaul]

@quis from the GOV.UK Notify team has added extra spacing between numbers in telephone number fields, to help users read them: alphagov/notifications-admin#1545

[quis]

@edwardhorsford couple of points:

Displaying the user's number as written

This is a good idea.

On Notify we store the number in the database as the user gives it to us. We normalise it before we use it to send a text message, but on the frontend we play it back in the format it was provided. We’ve seen problems with people not recognising numbers played back in a different format.

Input masking

This is a bad idea, and I haven’t seen a need for it, even if it can be an ooh that’s nice moment.

It makes things harder for people typing a number in a certain way, eg typing spaces to help them keep track of their position. It makes it harder to transcribe or copy the number from another place and check that you’ve got it right.

[edwardhorsford]

@quis

Displaying as written

Interesting - we didn't observe that on passports. I think we stripped whitespace / brackets though, so perhaps they were still recognisable to users.

Input masking

I defer to your research here. Really interesting to hear.

[timpaul]

Yes, thanks @quis and @edwardhorsford. Here's a question - assuming we distill the above conversation into the published guidance, how would either of you feel about the comments above then being deleted?

We're trying to decide how aggressively we should maintain the backlog. Eg. is it a verbose record of every conversation ever had, or a succinct summary of the outstanding issues?

[edwardhorsford]

Undecided!

I like the idea of comments / discussion living on, but right now these comments will be the first thing people read. Might a system similar to wikipedia work? where comments get archived, and only the newest are shown?

In this case these particular comments probably aren't so valuable that they need keeping, but later other discussions might well be valuable to be kept.

[quis]

Loosely held opinion:

I would scope this discussion to being about adding the pattern for phone numbers.

Once the pattern is published this discussion should be closed (but not deleted). Then future revisions start as new backlog items. For example, someone could add ‘dealing with country codes’ as a new thing in the backlog. It might result in updates to the same pattern, but it’s a new discussion.

[timpaul]

Sounds good, and close to what we'd discussed as a team. The only variation was that we keep this issue in the backlog project as an index for all issues relating to this pattern - so we'd link to them all from the top comment. It's a bit manual, but it means we'd get a kind of threaded discussion out of it. We'll try a few approaches and see what works.

[govuk-design-system]

Design review

This proposal was reviewed by a panel of designers from GDS, HMRC, DWP and Home Office on 22 March 2018.

The panel agreed that the pattern should not be published in the GOV.UK Design System until the following changes have been made.

Recommendations

• Provide more examples of specific error types and messages
• Give guidance on how to handle international numbers
• Provide a list of safe example international telephone numbers
• Make sure the code uses the ‘tel’ attribute
• Apply a fixed-width class to the field (once GOV.UK Frontend supports this)

[timpaul]

In order to create an example of an international telephone number input we are likely to need to be able to add prefixes to form inputs. For example:

This enhancement has been proposed here

[timpaul]

OK, I've updated the pattern and examples and hopefully addressed the issues raised by the working group.

The new version:

• Provides more examples of specific error types and messages
• Gives guidance on how to handle international numbers
• Uses the ‘tel’ attribute
• Applies a fixed-width class to the field

The international telephone number example doesn't rely on the prefix component, so is no longer dependant on this being approved.

For validation we now reference Google's libphonenumber library rather than the GOV.UK Notify code, as this is a fully supported open source project that handles international numbers.

The only issue not addressed is 'Provide a list of safe example international telephone numbers'. As every country has it's own rules around telephone number formats there is no single example of an international telephone number. Desk research failed to find a reliable list of safe numbers for different countries.

[ignaciaorellana]

This proposal was reviewed by a panel of designers and frontend developers from GDS, HMRC, DWP, EA and Home Office on the 26 of April, 2018. It was reviewed against the criteria for implementation Thanks to the contributor @timpaul with the support of @edwardhorsford and @quis

Design review

The panel agreed that the pattern should be published in the GOV.UK Design System after implementing the following recommendations.

Recommendations

• Explain what 'input masking' is
• For ‘Always tell users when and how they’d be contacted’. I’d like to see an example of that before it was published.
• Consider explaining why we use type:tel?
• Make the scope clearer: what it cover and what it doesn’t
• Explain that there are known gaps that will need to be developed further (so people understand this)
• Revisit some of the content to make it shorter:
  • Remove negative contractions from the telephone guidance so we can follow our own advice.
  • Split "It’s also not necessary - most modern mobile browsers automatically detect telephone numbers and display them as links anyway." in to 2 sentences.
  • Is "If you need to mark up your telephone number as links to support a device that cannot auto-detect them, you must make sure they don’t display as links on devices that cannot make calls." necessary? It is largely the same as the heading.
  • "The GOV.UK Notify team has observed some users becoming confused when presented with a reformatted version of a telephone number that they provided, for example, with the +44 country code added." is a little long. How about "The GOV.UK Notify team observed some users becoming confused when presented with a reformatted version of a telephone number they provided. For example, this happened when we added the +44 country code to the number."

[timpaul]

I have implemented the recommendations from the design review above. You can preview the guidance here

[ghost]

As requested sharing international phone number pattern :)

[amyhupe]

Dropbox Paper audit

On 12 February 2019 the Design System team reviewed a Dropbox Paper document discussing the Telephone numbers pattern.

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

Below is a record of the outcomes of that review.

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

Research and examples from Dropbox Paper

The following examples were taken from the original Dropbox Paper file:

Example of handling international phone numbers from Google

Google uses a select-list combined with a country icon. It will likely introduce other problems for people who struggle with select lists. Having a default, like "UK" appears to work well and makes it obvious which it is, and how to change it.

Example of handling international phone numbers from Amazon

[robinwhittleton]

One of the things I remember seeing in a research presentation at GDS was deaf / hard of hearing users filling in telephone number fields that were marked as required with “Please do not call me, I’m deaf”. How does that fit into these validation plans, or should there be a note to never make telephone fields mandatory? Or a requirement to request alternative ways of realtime communication if phone calls don’t work for people?

[edwardhorsford]

@robinwhittleton I'd suggest more the latter - that services should offer people a range of methods to communicate with. With that said - that's a tricky one to mandate.

[jonathaninch]

Genuine question - do many people still refer to 'telephones' as opposed to just 'phones'? Feels a bit old fashioned to be asking for the former to me.

[joelanman]

Google Trends seems to show 'phone' being the main term:

[jonathaninch]

Google Trends seems to show 'phone' being the main term:

Cheers Joe - hadn't thought about trying GT.

Maybe worth considering changing the content for the (tele)phone pattern?

[36degrees]

It'd probably make sense to keep this in sync with the content style guide which currently uses 'telephone number'?

[jonathaninch]

It'd probably make sense to keep this in sync with the content style guide which currently uses 'telephone number'?

Interesting that a quick search on GOV.UK shows nearly 13k references to 'telephone' but still a considerable 9k+ references to 'phone'.

[terrysimpson99]

Google ngram viewer searches books. It shows 'phone' dominant in US books but subdominant in UK books (although reaching parity). I'm glad this topic came up here because we use both terms and I'd like guidance on which one to choose (my vote would be for 'phone').

[jonathaninch]

Google ngram viewer searches books. It shows 'phone' dominant in US books but subdominant in UK books (although reaching parity). I'm glad this topic came up here because we use both terms and I'd like guidance on which one to choose (my vote would be for 'phone').

My preference too. We're trying 'phone' in UR sessions and will examine what users think.

[jonathaninch]

Searching 'phone' v 'telephone' but looking beyond 2000 (2008 seems to be as far as it will go), Google Books Ngram Viewer shows a big divergence from 2001 or so onwards, with the preference being 'phone'.

[terrysimpson99]

Can we update the guidance to recommend the use of 'phone' rather than 'telephone'? Can we update the examples to match that?

[CSTDev]

On Do not display telephone numbers as links on devices that cannot make calls

We've found that Chrome on Android and iOS do not detect phone numbers and make them links, which is a large portion of the market. Also a number of users do have applications that can make phone calls from desktops. Not having the link seems to be more of a hindrance than the popup asking which application to use for users who don't have means to call from their devices.

[rachel-robson]

Hello,

I have seen some designers struggling with this piece of guidance in the pattern:
"Explain why you need a telephone number
Tell users why you might contact them and when."

The pattern isn't clear where this information should be on a page asking for a telephone number.

It doesn't seem right that it's part of the hint text, as the hint needs to be direct reference to what the user is entering into the input field.

Would it be best if information on how the phone number will be used was it's own paragraph, separate to the hint text and input field?

Could there be some elaboration on that within the pattern guidance?

Thanks.

[terrysimpson99]

The guidance proposes hint text of: ‘Enter a telephone number, like 01632 960 001, 07700 900 982 or +44 0808 157 0192’. The format '+44 0808 157 0192' is wrong. This is explained in ITU E123 (https://www.itu.int/rec/T-REC-E.123-200102-I/en) which is the relevant standard.

A UK number with a zero can be shown as either '0808 157 0192' or '+44 808 157 0192'. The zero has to be dropped otherwise it won't work.

British Telecom explains it as follows:

---

https://www.thephonebook.bt.com/DiallingCodes/UkAreaCodeSearch/?AreaIdentifier=london

1. Dial the international access code
2. Enter the UK country code (44)
3. Dial the local 020 London Greater, without the first zero
4. Enter the remaining telephone number

---

Please can somebody replace '+44 0808 157 0192’ with '+44 808 157 0192’?

[frankieroberto]

The Request basic criminal record check service uses this pattern, where the country of the mobile number is asked for first (using an autocomplete) followed by the mobile number. As you type the mobile number it is replayed as text below, along with some guidance text if the number does not look like it is valid. (The leading zero is required)

[steve-oconnor]

Obviously I don't know what was tested so my comment may be moot, but it seems overly complex in two ways:

1. The second ask - "... without the country code"
2. Not allowing for the initial 0

Would it be simpler to do it this way?

As I say, I have no idea what was tested in research so...

[EoinShaughnessy]

We've had some really interesting user feedback about this pattern. I'll share it here so folks on this discussion can say whether it echoes their own views:

Telephone numbers should be links

Current guidance:

It might also not be necessary - some modern mobile browsers automatically detect telephone numbers and display them as links anyway.

We should not rely on a user agent to automatically identify unlinked phone numbers as telephone numbers. This behaviour is not part of any web standard for a browser to do this, and phone number formats vary greatly from region to region.

Some screen reader users will struggle to copy-paste a telephone number into their VoIP and it's simply much easier to have it as a link.

Current guidance:

When you look at your service's user journey, remember that telephone numbers as links might behave in unexpected ways for the user. For example, unless the user sets a default app to handle tel: links, some browsers and operating systems will automatically start a setup process.

I can sympathise with this argument, but once a user knows a telephone number presented as a link will try to open up their VoIP client, if they don't want this behaviour in the future, then they can just not click it in the future.

Current guidance:

However, doing this will style telephone numbers as links, which is confusing on devices that do not support telephone calls.

If you do need to mark up your telephone numbers as links, for example, to support a device that cannot automatically detect them, make sure they do not display as links on devices that cannot make calls.

Most devices are capable of making phone calls, including desktop devices via Skype, Teams, etc. I would struggle to find a device that is incapable of making phone calls.

Do not use aria-label

i.e. <a href="tel:7035551212" aria-label="7 0 3. 5 5 5. 1 2 1 2.">(703) 555-1212</a>

This issue is somewhat separate to this thread but still interesting. We should not use aria-label on telephone numbers to 'improve' their pronounciation by screen readers because:

• Aria labels should not be used to correct pronouciation of text
• Screen reader users know how their screen readers work over time
• An aria label may prevent users from navigating correctly through the document character by character to read the phone number themselves
• The aria label may not match the visible phone number (by mistake)

[stevenjmesser]

We have removed the 'Experimental' tag from components, patterns, and guidance in the Design System. 😌

The tag was being used on the Telephone numbers pattern to raise awareness that more research is needed to validate it. However, we recently published new guidance on how to share findings from users which we hope will make it easier to collect and format more information about how the Design System is being used across services.

If your team has used this component please let us know. 💪