Email addresses

[govuk-design-system]

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

[timpaul]

Here are the tests for valid and invalid email addresses, used by the GOV.UK Notify team: https://github.com/alphagov/notifications-utils/blob/e428bdd0ca82f7b97833e707eea95dae849713fb/tests/test_recipient_validation.py#L103-L149

[benilovj]

The code example for the input tag uses type="text":

<input class="govuk-input" id="email" name="email" type="text" aria-describedby="email-hint">

but the 'help users to enter a valid email address' section mentions:

"using the type=“email” attribute so that devices display the correct keyboard"

Is the inconsistency intentional?

[36degrees]

Nope – great spot!

I've raised a PR to fix it. Thanks.

[NickGrantX]

@timpaul we're using gov.uk Notify over at the ONS and we've been looking into the valid/invalid emails.

According to Wikipedia, the local part of the email supports a lot more weird and wonderful characters and things than Notify does: https://en.wikipedia.org/wiki/Email_address#Local-part

Specifically, the special characters !#$%&*/=?^{|}~ (and backticks too!) should be permissible.

Also, the example with the 2 consecutive dots which is "technically valid" according to the source link you pasted is actually invalid according to the Wiki article.

Confused about what we should implement in our UI. Any pointers gratefully received.

Cheers!

[sussexrick]

The recommendation of 30 characters as a field size limit seems a bit short. My email address is 32 characters and it's nothing unusual, just firstname.lastname@where-i-work.gov.uk

[leohemsted]

Hi @NickGrantONS, I'm a developer over on Gov.uk Notify. While being careful not to derail this conversation too much, a couple of points about the validation. We've tweaked our validation quite a bit since Tim commented with that link - check out the current version at https://github.com/alphagov/notifications-utils/blob/master/tests/test_recipient_validation.py#L104-L151 (the regexes used can be found at notification_utils/__init__.py)

Those special characters you listed are now valid, and the consecutive dots example is now correctly invalid. That said, we still don't allow some very unusual email addresses that are technically valid - notably emails with the local part wrapped in double quotes. We've never seen any of these emails in the wild, and it would greatly increase the complexity of our validation logic.

Our goal is simply "Have notify's validation match our own email provider's validation" (we currently use Amazon SES) - so that we can reject any invalid email addresses as soon as we receive them.

If you want to be sure we'll accept the email address, you could send a message to the supplied email address via notify using a test key - test keys don't actually send anything, and we'll tell you immediately if it's invalid.

[36degrees]

The recommendation of 30 characters as a field size limit seems a bit short. My email address is 32 characters and it's nothing unusual, just firstname.lastname@where-i-work.gov.uk

Good spot, thanks. I think this guidance is unclear as a couple of concepts have ended up muddled together since this was rewritten from the service manual.

I’ve raised a PR which should hopefully provide some clarification: https://github.com/alphagov/govuk-design-system/pull/464

[timpaul]

Here are 2 things that the GOV.UK Pay team have done to help users enter correct emails:

1) Play back the email address as users enter it, so they are more likely to spot an error

2) Spot common typos and warn the user when they submit the form

Doing this has reduced instances of users entering invalid emails by 33%

[matthew-shaw]

The guidance suggests:

"You should also set the autocompleteattribute to email."

Should that say set autocomplete to "on" instead? https://www.w3schools.com/tags/att_input_autocomplete.asp

[peteryates]

I think the MDN docs are clearer here. The autocomplete value suggests to the browser how the autocompletion should work. If it's set to on:

The browser is allowed to automatically complete the input. No guidance is provided as to the type of data expected in the field, so the browser may use its own judgement.

Whereas, if it's set to email the browser should be in a better position to provide useful autocompletion.

[matthew-shaw]

@peteryates Fair one, I hadn't seen the list of permissible values, I thought it was simply on or off. Thanks!

[mcheung-nhs]

Hi, I have a question regarding the recommended use of the autocomplete="email" attribute. We recently got this feedback on some pen testing that took place on one of our NHS services:

“The autocomplete feature was enabled within the application that stored sensitive user data. The autocomplete attribute, implemented by many popular browsers, allows a user the option of storing form field values so that the browser can automatically populate the same fields of a form later. Although this feature can be a convenience for users of the application, it creates a security risk, as sensitive user data such as authentication credentials is stored locally and may be recovered if an attacker is able to gain access to the workstation, or through exploitation of a cross-site scripting vulnerability.

RECOMMENDATION To prevent browsers from storing credentials entered into HTML forms, include the attribute autocomplete=“off” within the FORM tag (to protect all form fields) and within the relevant INPUT tags (to protect specific individual fields). Please note that modern web browsers may ignore this directive.”

So, do people think it is a security issue and therefore we should not be using it? Thanks.

[anevins12]

I'm jumping in here with no background of other tickets, so apologies if you're raising this in another ticket.

The reasoning to use the autocomplete attribute should also touch on how useful it is for people with a variety of impairments, as part of WCAG 1.3.5 (AA) Identify Input Purpose.

I couldn't phrase this better so I'm taking it from the 'understanding' document of 1.3.5:

People with language and memory related disabilities or disabilities that affects executive function and decision-making benefit from the browser auto-filling personal information (such as name or address) when the autocomplete attribute is used to meet this Success Criterion, which means information does not need to be remembered by the user.

People with cerebral palsy, stroke, head injury, motor neuron disease or learning disability sometimes prefer images for communication. They can employ assistive technology which adds icons to input fields to communicate the purpose of the fields visually.

People with motor impairments also benefit from reducing the need for manual input when filling out forms.

[matthewford]

@mcheung-nhs its a risk that would need to be either accepted or fixed depending on the situation. If it’s related to login forms NCSC has guidance that’s says you should allow users to paste/use password managers.

If it’s search field, then if there is a chance the computer could be shared then there is a data leak risk.

[sdh100shaun]

We implemented a version of https://github.com/alphagov/govuk-design-system-backlog/issues/45#issuecomment-414999110 in a recent service - after engaging with the gov.uk pay team ... as soon as our research / analysis of the difference it made is finalised will post it

[a184studio]

Is there any updates/insights with regards this pattern? @sdh100shaun You said you were implementing this, how did it go?

[sdh100shaun]

@a184studio we are still doing overall analysis I will see with our performance analyst where it has got to

[cristina-agramunt]

Here are 2 things that the GOV.UK Pay team have done to help users enter correct emails:

1. Play back the email address as users enter it, so they are more likely to spot an error

2. Spot common typos and warn the user when they submit the form

Doing this has reduced instances of users entering invalid emails by 33%

Hi Tim Paul,

I was looking for some examples of email validation and I came across your screenshots. At the Apply for a Nino we noticed that there's a small percentage of applicants that do enter their emails with some sort of typo which is not being picked up by the system. We are looking to introduce a validation, like the one you've attached, to our screens, but we would like to know how these options have been performing - has there been any UR done to these patterns?

I've seen the post is from 2018, so not sure if you are still involved or have access to the documentation :(

Would you, or anybody else in the chat, have examples of re-playing the email address backed up with UR please?

Thank you!! Cristina

[a184studio]

@cristina-agramunt I can help with this one. This what we [Pension Credit] implemented along with the measure and outcome.

We didn't do the predictive element, just the "you need to do this again field" MM.

[cristina-agramunt]

@cristina-agramunt I can help with this one. This what we [Pension Credit] implemented along with the measure and outcome.

We didn't do the predictive element, just the "you need to do this again field" MM.

Hi Mark, Thank you so much for your quick reply!

That's exactly what I was looking for!! I will share the findings with my team. It looks like a fairly (hopefully) easy change to implement, so hopefully we can get that one done soon!

Thank you again for your help!!

Cristina

[RichardBradley]

How is everyone translating this error message into Welsh?

Enter an email address in the correct format, like name@example.com

Our translators have given us this, but I'm unsure about the email address:

Rhowch gyfeiriad e-bost yn y fformat cywir, fel enw@enghraifft.com

While it's true that example.com may not mean anything to a Welsh speaker, it is based on RFC2606 and there is explanatory text at http://example.com if someone looks it up. Whereas "enghraifft.com" is non-standard and (at the time of writing) unregistered.

[querkmachine]

@RichardBradley I agree with your reckon here. example.com is a reserved domain specifically for uses like this one, and as there is no non-English equivalent, it should probably be used regardless of the surrounding language.