… starting from the point where the story stopped.
Concluding the journey: my decisions on handling external links based on best practices
Time to bring this three-part series to a close. In doing so, let’s solidify our understanding with insights from authoritative sources. Specifically, I will provide several quotes from the Google Developer Documentation Style Guide, a highly regarded resource that covers all the points we’ve discussed.
Don’t force links to open in a new tab or window. Let the reader decide how to open links.Google developer documentation style guide
After another round of thorough research for this article (see the first part), I am confident in the decision I made six years ago: external links, like internal ones, should open in the same tab or window. The only exception, as explained in the W3C article “G200: Opening new windows and tabs from a link only when necessary,” is when accessibility considerations make it preferable.
There is generally one good reason to open a page in a new window, and that is that the user will need to refer to that content in order to complete a task in another window.Jakob Nielsen and Anna Kaley
Had I relied solely on trendy articles rather than conducting thorough research, I might have replaced rel="external" (my current method for handling external links) with rel="noopener noreferrer". However, this would be incorrect! Since I do not open my external links in a new tab, the security issue associated with target="_blank" is irrelevant, making noopener unnecessary 1. However, noreferrer is crucial for preventing both privacy and security risks, regardless of whether the links open in a new tab or not.
Therefore, I chose to use rel="external noreferrer" because it is the correct approach. This practice aligns well with modern coding standards and addresses accessibility, privacy, security, and SEO concerns. Naturally, target="_blank" is nowhere to be found in my code:
<a href="https://example.com/" rel="external noreferrer">External Link</a>Another important topic about external links frequently discussed, especially in accessibility articles, is the need for advance warnings when links open in new tabs or windows. According to the aforementioned W3C article, it is recommended that when links are opened to a new window, there is advance warning.
In the rare situation that a link needs to open in a new tab or window, let the reader know that the link opens differently than expected.
Recommended:
<a href="/style/accessibility" target="_blank">Accessible content (opens in a new tab)</a>
Not recommended:
<a href="/style/accessibility" target="_blank">Accessible content</a>
“You don’t need that; you don’t open links in a new window!”
“Indeed, I don’t 2. But I believe it’s important to adhere to this accessibility standard regardless.”
A good way to inform users that a link is external is indeed to provide clear visual and textual cues. You might be familiar with the small arrow pointing out of a square—a common graphic displayed next to links to indicate they will lead to a different website. As you might imagine, I was so mesmerized by this professional-looking external link icon that I immediately fell down the rabbit hole, getting distracted and spending much more time on it than planned.
To make a long story short, I quickly realized that most tutorials on implementing icons next to external links rely on third-party sources for free icons, which wasn’t ideal for me. I initially thought I could bypass this issue by using a dedicated HTML character, but I couldn’t find a suitable one. Creating the graphic myself with Inkscape was an option, but driven by laziness—wrong choice!—I looked for another workaround. That’s when I considered using the title attribute.
As some of you might know, the title attribute can provide additional information about an element, displaying a tooltip when you hover over a link. However, this method has significant accessibility issues. Screen readers do not consistently recognize the title attribute, and it often fails to convey meaningful information to users with disabilities. After careful consideration, I decided against using it to signal that a link was external.
Recognizing the significant accessibility issues associated with this approach brought me back to the main focus: ensuring all users have a seamless experience.
Don’t use an external link icon to indicate that the link goes to a different domain or server. If you think it’s important to inform the reader that they’re leaving a Google domain, mention it in the text and don’t rely on an icon.Google developer documentation style guide
This brings me to the conclusion of this three-part article. While I could have extended it to a four-part series to delve into the code for implementing external link icons, the above realization made my life a lot easier:
<a href="https://example.com/" rel="external noreferrer">External Link (external link)</a>
“Are you done?”
“Not just yet.”
While I did reject the use of the title attribute for the use case described above, I didn’t throw the baby out with the bathwater. As explained in the Creating Hyperlinks article from Mozilla Developer Network: The title contains additional information about the link, such as which kind of information the page contains, or things to be aware of on the website.
Therefore, I decided to use it to:
- provide such kind of information, and
- add an extra tip for some non-techy users.
<a href="https://example.com/" rel="external noreferrer" title="additional information about the link destination">External Link <span title="Right-click or tap and hold the link to open it in a new tab or window.">(external link)</span></a>Last but not least, in line with the best practice of linking to authoritative, high-quality, and well-trusted websites, I will remove unnecessary external links.
Make sure that any site that you link to is high quality, reliable, and respectable.Google developer documentation style guide
Coming Next: Internal links
1 Besides, noreferrer already covers the security concerns by preventing the referrer information from being passed and inherently includes the noopener behavior. ^
2 With one exception: the link to my Terms of Use in my comment form. ^
3 You might recall that using rel="external" was often erroneously suggested for such a task—instead of using the class attribute. If you decide to use rel="external" anyway, be aware that this will only work if external is the only rel value,
as explained in this StackOverflow entry. ^