Auto linking in email: Feature or bug? 

Auto-linking in email is a great feature, until it isn’t.

Looking at a simple user-to-user message:

“Hey check out my new website example.com. Give me a call on 0123 456789 to talk it over. We’re having a launch party on 27th May, put it in your calendar”

Converting the website into a URL link, that phone number into a phone link, and the date into a calendar link creates handy shortcuts for the recipient to take action more easily.

However there are times where adding a link isn’t wanted:

“New virus detected at danger.example.com”

This is a dangerous link, so we don’t want anyone to click it.

”Order number: 0123456789”

This is an order number, not a phone number so we don’t want it to be treated as one.

”The legendary Bag O’Nail gig on 25th November”

This is a historical date, so it’s unlikely we want people to add it as a calendar event.

When sending marketing messages we want to keep control of the actions available. Keep the user focused on our messaging and avoiding any confusing links. There are also contrast issues that often come up. If your text is on a dark background, the default link color may not show up too well. And if you are using a blue background, it could disappear completely.

So how do we deal with this? There are a few options but none of them are perfect.

There is a meta tag created exactly for this purpose

However that is a non-standard Webkit only meta tag. It works in Safari but I’ve not had any luck with it in any email clients.

So it’s not really of any use currently, but I like to include it anyway to let email clients know that we want this feature.

Email clients won’t replace a link, so if there is something logical to link to already then you can add that in the code and prevent the auto-link.

You could link New virus detected at danger.example.com to a report about the issue.

You could link Order number: 0123456789 to the order.

You could link The legendary Bag O’Nail gig on 25th November to a page about the event.

You could visibly break up a link, danger[.]example[.]com not only does this stop the auto-linking it also shows the users that you are intentionally not including the link.

It is sometimes possible to style the links that are created. You could use this to fix any contrast issues the links create and make the links look intentional and on brand.

This also has the advantage of showing the content as a link when it’s possible to take action and as plain text when it’s not. Think phone number on your mobile device when you can click and call but text on a desktop.

It’s also quite common for people to set it so the links just look like regular text. This is a common snippet you might see specifically for targeting the links generated on iOS

There is a great GitHub repo with a list of these sorts of targeted resets.

However when resetting links style like this, the links are still present in the code. They are still clickable and focusable, but they no longer look like links. This means they can fail a number of WCAG accessibility criteria:

1.3.1 Info and Relationships

1.4.1 Use of Color

2.4.4 Link purpose

3.2.4 Consistent Identification

We can add a hidden character like a ​ (zero width space) into the text to stop it being seen as something the email client wants to link example​.com.

Visibly this still looks like the same content however there are a few drawbacks.

Hidden characters are carried over when copying and pasting, so could cause issues.

• In my testing, Chrome and Firefox will still direct to a URL that has been pasted into the address bar. Safari won’t but it will go to a search results page.
• Chrome and Safari will match a ‘find on page’ search however Firefox won’t.
• I found an email address copied and pasted into Gmail or outlook.com did send correctly, but I doubt that will be the case for every email client.
• Internal website search tools mostly don’t work. If you are using this on something like order numbers, or anything that might be copied and pasted it’s worth testing it in your website search.

In cases where pasting is likely, it could be a good option to link the content instead.

This is a hack and it’s not great for accessibility, however, we may sometimes need to use it to prevent worse accessibility issues. But it’s worth knowing where the issues lie to help make the correct call.

It’s hard to match this exactly to WCAG rules but it may fall under 1.3.1 Info and Relationships as what you see, isn’t what you get.

Doing some basic screen reader testing with JAWS, NVDA and VoiceOver. I found that neither ​ or ⁠ were read out directly, whereas some other hidden characters I tried were. However it’s worth noting that screen readers have settings around punctuation that could affect this, so the experience could be different for some users.

In some cases I found that adding the hidden characters changed how things were read out. For example in JAWS example​.com was read out correctly as ‘example dot com’, however using ⁠ would read as ‘example com’ mistaking the . as punctuation rather than part of a domain.

In my testing of NVDA shorthand dates written as 01-01-27 were announced as dates, but any interference from hidden characters would cause it to be read as numbers. Interestingly in my testing of NVDA 01/01/27 is not read as a date.

The copy/paste issues could also fall under accessibility as the expected outcome is changed.

When doing this it’s important to think about placement, I often see people place hidden characters randomly 1st Jan​uary that will cause some screen readers and text to speech tools to read the 2 parts of the word separately. In NVDA it even recognised Jan as an abbreviation and reads it incorrectly as ‘January 1st uary’.

For emails and URLs I recommend placing the character just before the . so it’s example​.com

For dates I recommend placing the character after the first part of the date so depending on how you format your dates that could look something like 01​-01-27, 1st​ January 2027, January​ 1st 2027

With numbers I found adding ​ before the last number or adding ⁠ after the last number give the best results.

From my testing ​ (zero-width space) and ⁠ (word joiner) are the most promising. For link blocking in my tests they are consistent apart from when placed after a number.

For screen readers they are consistent apart from when used on a date 1st​ is read out correctly but 1st⁠ is read as ‘one s t’.

​ allows for line breaks and ⁠ prevents line breaks. So if you want to avoid something dropping to a new line ⁠ may be better.

​ is a more common character so probably more predictable.

There is no one-size-fits-all simple answer. You have to make a compromise somewhere.

So if you are trying to deal with some unwanted auto-links, my order of preference would be:

1. Use an intentional link or style the auto-link: Using a link and making it look like a link. Content stays the same.
2. Visibly change the content: Demonstrating to all users that you are intentionally blocking auto-links.
3. Invisibly change the content: Adding a hidden character to block links, while being aware of the potential issues this can bring.
4. Remove link styles: This fails multiple accessibility criteria so it’s best avoided.