What else to handle when external links in articles open in a new tab

Source links in technical articles often take readers to another site. In the behavior recorded here on October 25, 2026, this site opened external HTTP(S) links in article bodies in a new window or tab, while links to articles on the same site stayed in the current tab. That is a choice about the reading flow, not a rule every website has to follow.

Adding target="_blank" handles only part of the decision. There are still questions about what counts as external, whether to keep an opener relationship, whether to send referrer information, and whether readers can know what will happen before activating the link.

The explanation below draws on the article-body script and local DOM observations from that date. The rules apply only to article bodies, not to every link across the site.

An external link is defined by its resolved origin

The script first found links with an href inside [data-note-body] and resolved each address as a URL. It added the new-window settings only when the protocol was http: or https: and the origin differed from the current page’s.

This is more accurate than checking whether a string starts with a slash. A same-site URL can be written as a full absolute URL; a different protocol, host, or port can also put two otherwise similar-looking URLs on different origins.

Under those rules, links fall into the cases below. The table describes branches in the code, not a set of examples that were all found and exercised in real articles.

Link scenario	What the article-body script does
A same-origin article URL	Does not add new-window attributes
A fragment link on the same page	Does not add new-window attributes
An HTTP(S) URL on a different origin	Adds target, rel, and a name with a warning when the conditions are met
Non-HTTP(S) protocols such as mailto:	Skips the link rather than applying the external-page opening behavior

Not adding attributes does not mean actively clearing existing ones. If a link already has its own target, the skip branch does not remove it. The fact that ordinary internal links had no target does not prove that the script corrects every exception.

target and rel decide different things

For qualifying links, the script set target="_blank" and wrote rel="noopener noreferrer".

noopener governs the opener relationship between the newly opened page and the original one. The HTML specification says that the corresponding new window does not receive that opener reference. noreferrer asks for referrer information not to be sent with the link and also includes noopener behavior.[2]

These are not two independent layers that make a link completely safe when both are added. Writing both explicitly makes the intent easier to see, but noreferrer also means the destination will not receive that referrer information from this navigation. A site that needs particular referral tracking must consider this trade-off rather than treating the setting as a purely visual choice.

Nor do these attributes verify that the external site is trustworthy or provide anonymous browsing. Sources still need to be checked. How a link opens and the quality of the source it cites are separate questions.

Give the warning before activation

For an external link with text content and no existing aria-label, the script built an accessible name containing both the link text and a warning about opening a new window. The Traditional Chinese version added “另開新視窗” (“opens in a new window”); the English and Japanese versions used their own localized messages.

Keeping the original link text matters. If every name says only “另開新視窗”, readers lose the information about where the link leads. The warning should supplement the destination, not replace it.

If the link already had an aria-label, the script left it unchanged. That also means the script did not guarantee that every external link’s existing name included a new-window warning; the author of the link still needs to check whether its name is complete. A link containing only an image and no text content cannot get a suitable name from this text-concatenation logic either.

W3C’s G201 technique recommends warning users before they activate a link or button whose ordinary activation opens a new window. The document explicitly classifies the technique as advisory, so it should not be presented as a mandatory requirement of a success criterion.[3]

An accessible name is not a visible warning

The script changed attributes; it did not insert visible “opens in a new window” text or an icon into the article body. An aria-label does not automatically appear beside a link for someone reading the page visually.

G201’s examples include visible text, or a visible icon paired with a description for assistive technology.[3] I therefore would not treat an aria-label in the DOM as evidence that every reader had enough advance warning, nor would I treat this script as proof of accessibility compliance across the site.

There is a gap here worth keeping explicit: the warning names could be checked in three languages, but that did not amount to a complete design for visible warnings. To address it, the site would need separate decisions about how icons or text should look, whether they interrupt reading, and how to keep existing names consistent. Those decisions should not become an incidental site-wide change made while writing an article.

Without scripts, keep the link a link

The href in an article body was already present in the HTML rendered from Markdown; the browser script added the new-window settings afterward. After I disabled the page scripts and reloaded an article, the external sources were still ordinary links with destinations, just without those added opening attributes and supplementary names.

This fallback preserves basic navigation, not identical behavior with and without JavaScript. Readers can still use the browser’s native link operations. A site should not hide source URLs behind controls that only a click handler can activate just to standardize how links open.

Those local checks used the three language versions of the HTML semantics article. Each version had two external source links and one internal further-reading link. After the script ran, the external links’ target, rel, and localized warnings matched the settings, while the internal link had no new-window target. With scripts disabled, the external sources were ordinary links again.

These were observations of attributes and the DOM without scripts. I did not open external sites to measure window.opener, HTTP Referer, or destination behavior, and I did not test with a screen reader. The specification supports what the attributes mean; the checks support the settings on the selected pages. The two kinds of evidence need not be stretched into a broader claim that everything is safe.

Looking like a button does not mean it should be a <button> first addresses the basic semantics of links. For external links, I ask a further question: while keeping the reader’s place in the current article, does the design also tell them where the next action will lead?

Sources

[2] https://html.spec.whatwg.org/multipage/links.html [3] https://www.w3.org/WAI/WCAG22/Techniques/general/G201