TL;DR: Regardless of what accessibility conformance level you target, do not arbitrarily open links in a new window or tab. If you are required to do so anyway, inform users in text.
Overview
Throughout this post I am going to use the terms browser window and tab interchangeably. While they are both windowing methods, tabs use a Multiple Document Interface (MDI) to restrict multiple web documents to one browser window instance at a time.
It is not hard to find arguments against opening content links in new windows by default. Usability and accessibility experts tend to agree it offers little or no benefit for users, and in many cases hurts the experience and perception of the site.
It is harder to find arguments in favor of opening content links in a new window.
Marketers and SEO professionals, and their forums, generally counsel people not to open links in a new window. Even in my efforts to find those in favor of new windows, I kept finding articles against new windows and community advice against new windows across SEO and marketing outlets.
Consistently across my searches the only ones who ever make the case for new windows are folks whose paycheck is dependent on hitting bounce rate or time-on-site goals in their site analytics.
Inclusive Design Principles
The Inclusive Design Principles are good set of guidelines for how to build user-first interfaces. Four of them can be applied here.
Be consistent
Generally you want to be consistent both with interfaces in general and within your own project. A default link does not open a new window. You probably do not open all links in new windows, and almost definitely not ones to other pages within the site. Arguably, you could create consistency by explicitly marking links that open new windows, consistently identifying those links throughout your site.
Give Control
When you force links to open new windows or tabs, you are taking away the user’s ability to make that decision. Some users open every link in a new tab. Some users prefer to go forward and backward in the same window, and some might not understand how to navigate across windows or tabs. By forcing any links to open a new window, you have removed the user’s ability to control the experience, and in some cases made it impossible to understand.
Offer Choice
By forcing links to open a new window or tab, and since browsers do not provide an override, you are depriving the user the ability to choose how to visit links. While an indicator of links that open new tabs can at least let users choose if they want to follow a link, it is a false choice.
Add Value
On the whole, forcing links to open new windows adds value for one audience — site owners who use it as a tactic to reduce bounce rates and increase time on site. Even users with lower technical skills are generally savvy enough to recognize when something that frustrates them is probably not actually meant for them, and they remember it.
Screen Reader Support
Developers who do not spend time testing with users of screen readers, or even just screen readers, often assume a screen reader will process the target attribute and inform users a link opens in a new window. The problem is, that isn’t true.
PowerMapper maintains a page of test results and as of its most recent writing (11 January 2020), this simple link:
<a href='http://www.example.com' target='_blank'>Example</a>…causes problems in 43 screen reader / browser combinations.
The problems were generally that screen readers did not announce a link would open a new window when encountering it, though some told the user after following the link. The only two that did not have a problem got by on a technicality — they did not warn the user, but they also allowed the Back button to go back to the page.
WCAG
In my post Target Size and 2.5.5 I make a case for using larger hit areas on controls even though the associated WCAG Success Criterion is at Level AAA — the level beyond the general industry compliance target of Level AA.
Similarly, WCAG talks about link targets at Level AAA and outlines best practices that make sense regardless of what WCAG level you target.
WCAG Link targets fall under Guideline 3.2: Predictable, and state that web pages must appear and operate in predictable ways. Specifically, Success Criterion 3.2.5: Change on Request states that changes of context (such as new pages or windows) must be initiated only by users and that users can disable them otherwise.
F22: Failure
F22: Failure of Success Criterion 3.2.5 due to opening windows that are not requested by the user outlines a scenario where a user is not informed a link opens a new window:
A user clicks on a link, and a new window appears. The original link has no associated text saying that it will open a new window.
In order to pass this, you would need to identify every link that opens a new window or tab. Note that this neither gives control nor choice to users, other than telling them to maybe not click the link if a new window is a problem for them.
H83: Sufficient Technique
H83: Using the target attribute to open a new window on user request and indicating this in link text is the converse of the failure. It essentially states that if you are opening a new window, tell the user. Do it in text.
Note that sufficient does not mean ideal. It is literally the bare minimum to meet the Success Criterion.
SCR24: Sufficient Technique
SCR24: Using progressive enhancement to open new windows on user request is another approach, this one addressing scripting techniques used to open a new window.
Essentially, if you use scripting to make a new window or tab open when activating a control, then you still need to tell the user in text. Chat window? Tell the user. Help pop-over? Tell the user. Again, this is still only sufficient, not ideal.
G200: Advisory Technique
G200: Opening new windows and tabs from a link only when necessary applies to Guideline 3.2: Predictable. The Guideline encompasses all Level A, Level AA, and Level AAA Success Criteria beneath it and should be treated as Level A best practice as a result.
To simplify, if you want to target any WCAG compliance, avoid opening links in new windows otherwise it makes your entire accessibility approach feel like you’re just making a minimum effort. This technique does outline a couple exceptions to that best practice:
- Opening a page containing context-sensitive information, such as help instructions, or an alternate means of completing a form, such as a calendar-based date picker, will significantly disrupt a multi-step workflow, such as filling in and submitting a form, if the page is opened in the same window or tab.
- The user is logged into a secured area of a site, and following a link to a page outside of the secured area would terminate the user’s logon. In this case opening external links in an external window allows the user to access such references while keeping their login active in the original window.
G201: Advisory Technique
G201: Giving users advanced warning when opening a new window builds on the previous technique by explicitly stating that you need to warn users.
The objective of this technique is to provide a warning before automatically opening a new window or tab. Opening new windows automatically when a link is activated can be disorienting for people who have difficulty perceiving visual content, and for some people with cognitive disabilities, if they are not warned in advance. Providing a warning allows the user to decide it they want to leave the current window, and the warning will help them find their way back, if they do decide they would like to go to the new window. It will help them understand that the “back” button will not work and that they have to return to the last window they had open, in order to find their previous location.
WCAG 1.0
Remember WCAG 1.0? Checkpoint 10.1 had both a hopeful and futile statement built into it: Until user agents allow users to turn off spawned windows…
Sadly, browsers have not provided the ability to completely disable windows spawned from links, which is why we are where we are today.
Security
Shortly after I posted this Catalin Rosu tweeted to remind me about the security risk with new windows. Without a rel="noopener" on the link, you are allowing those off-site links some access to the window that opened it.
Mathias Bynens provides an example of how a page can be compromised, demonstrating how you end up putting your users at risk. Ben Halpern explains in a 2016 post, The target="_blank" vulnerability by example. He also points out that the best coverage, to address by now tragically old Firefox installs, is to use rel="noopener noreferrer".
Some content management systems add part of this automagically. The classic WordPress editor, for example, adds rel="noopener" to any link you want to open in a new window. The Gutenberg editor adds rel="noopener noreferrer" to text links, but also adds aria-label="[ your link text] (opens in a new tab)", making for a whole other accessibility challenge (bug 20129 and fixed in PR 18742 on 13-Feb-2020). Image links get no rel at all (bug 20130).
If you (or your authors) do not know if your CMS is adding these attribute, then you should assume it is not until you review it. If you are adding links manually, then for the safest experience for your users the link should like like the following:
<a href="http://www.example.com" target="_blank" rel="noopener noreferrer">Example</a>The best and safest approach for your users is to not open links in new windows.
Best Practice
For over 20 years usability experts have warned against opening links in new windows.
In Nielsen Norman Group’s article The Top 10 Web Design Mistakes of 1999, Jakob Nielsen lists opening new browser windows as number two.
Designers open new browser windows on the theory that it keeps users on their site. But even disregarding the user-hostile message implied in taking over the user’s machine, the strategy is self-defeating since it disables the Back button which is the normal way users return to previous sites. Users often don’t notice that a new window has opened, especially if they are using a small monitor where the windows are maximized to fill the screen. So a user who tries to return to the origin will be confused by a grayed-out Back button.
While desktop browsers (generally) use tabs in a single window now, additional,tabs can be just as confusing (or invisible). For mobile users, it may be impossible to distinguish in some circumstances (too many tabs open for the browser to render, for example).
Mark Pilgrim’s 30 days of accessibility article Day 16: Not opening new windows from 2002 offers a list of who benefits (and how) along with steps for how to do it right:
- Don’t use
<a target="_blank">to force links to open in a new window.- If you absolutely must open a link in a new window, explicitly warn the reader. This is a non-optimal, compromise solution, usually brought about by business requirements of “not being associated” with external content. For example, CNN’s “related sites” page does this.
- If you have a “Links open new windows” checkbox, make sure it is off by default.
Gez Lemon wrote Opening Links in a New Window in 2004 and summarizes his position:
The best practice for opening external links is to open them in the same window, allowing the visitor to make a choice whether or not they want the link to open in the same window, a new window, or even a new tab. Deciding on their behalf is considered rude, and has usability implications.
WebAIM gives some context for how new windows affect users:
The accessibility issue is that some users can get confused with the new windows or tabs. Newer screen readers alert the user when a link opens a new window, though only after the user clicks on the link. Older screen readers do not alert the user at all. Sighted users can see the new window open, but users with cognitive disabilities may have difficulty interpreting what just happened. Then when the try to click on the Back button in the browser, nothing happens, because there is no previous link to go back to in a new window or tab.
The article notes that browsers continue to fail to provide a way for users to override the target attribute. It also points out that icons indicating new windows can be confused for icons indicating off-site links. The lack of a universal icon (such as one from the browser) complicates them.
Supporting it Anyway
Some practitioners offer techniques to follow when new window links happen anyway. As you read through these, note that the objectives have not changed much, but the approaches vary more than a little.
Nomensa’s 2011 article Opening links in a new window outlines some techniques to avoid when indicating links that open in a new window. AccessibilityOz’s 2014 article Links and accessibility also offers a technique with caution for others.
Scott Vinkle wrote Why let someone know when a link opens a new window? (on Medium, so be aware of the article limit and all-<h1> heading structure) outlining his technique to automatically add an accessible indicator to links that open a new window. Nicolas Steenhout outlines his preferred technique in How to Stop Opening Links in New Windows without Warning.
Continuing this theme, accessibility departments across organizations offer their own techniques to indicate link targets, such as NC State, Penn State, or Oxford, as examples
This variety of techniques can make it hard for a developer to identify which is the best to use in general, let alone for your audience. If anything, it supports the argument that you should simply avoid the challenge (and potential downside for users) by not making links open new windows.
CSS Hack
Using the following CSS generated content approach is a hack. It is code smell for developer-first decisions, not user-first decisions.
main a[target^="_"]::after {
content: " (opens in new window/tab)";
}As I discuss in Showing File Types in Links, this content may not auto-translate, will fail if the CSS fails, leaves little room for customization, and breaks the rhythm of the copy. In my opinion, it violates the W3C Priority of Constituencies, since using it means you are making it easier for authors at the expense of users.
If you already use CSS generated content to indicate files, then imagine you link to a PDF that must open in a new window. Which rule will win? Which rule should win? Why should only one rule win?
Even this straightforward automated technique has some big drawbacks. You have to ask if those are greater than getting authors to stop using the target attribute, tearing that feature out of your CMS altogether, or convincing them to manually write it into link text every time.
Exceptions
Of course there can be exceptions. Widgets that open controls in a pop-up window (like a calendar tool), help documentation that is meant to persist alongside content, pages that may destroy an active session in a page or application, media files the user may need to play in the browser, and so on.
Insufficient Exceptions
File links can be tricky depending on the file type and browser support. For a while files were a good case for opening in a new window or tab, particularly if they might risk a crash. With the HTML download attribute, that case has eroded just a bit. Now you can at least tell a browser to download a file instead of making it fire up its broken or chunky file viewer.
An exception that proves the rule…
This goes into more detail on a sample argument than most may care about, so I collapsed it.
From UX Movement: Why External Links Should Open in New Tabs
This captures all the wrong reasons (and users call the author out in the comments for it):
- Browser tabs have not changed anything; there are simply more icons in the browser window instead of the task bar.
- There is no such thing as
back button fatigue
, but users who don’t want to two-step every link tend to learn to control-click, right-click, or long-press. - Over-working the web site is not a thing; sites can handle the load and most content is reloaded from cache anyway.
- Kvetching over analytics is targeting numbers over users, and leads to other user-hostile actions (which I talk about in my post For Infinite Scroll, Bounce Rate Is a Vanity Stat); it also leads to the wrong conclusions on how your site is used.
- No testing was done, no research was done, and those who ask for supporting data in the comments are ignored.
Wrapping it Up
Barring some very specific reasons that clearly benefit users, opening content links in a new window is a poor user experience that prioritizes artificial goals above user goals, a message you may not want to convey. While there are exceptions, these should be thoughtfully justified on a case-by-case basis.
If the decision is out of your hands, all automated techniques to warn users have drawbacks. Inconsistency across the web, risks to understanding or translating the content, and lack of customization on a per-case basis makes them less than ideal.
Conversely, requiring or expecting content authors to manually insert plain text notifications for each link is hard to enforce and requires rigor to maintain a process. While a minor burden to authors, it is also just as easy to forget. Developing a technical way to force authors may only result in workarounds and wasted effort that could be avoided by removing the new window option altogether.
To reiterate, I have found the only ones who make a case for new windows are those whose paycheck is dependent on hitting arbitrary web site analytics goals, goals which are often imposed on them.
If you have arguments in favor of links in new windows, please offer them in the comments.
Update: 1 March 2020
Based on a conversation in the comments below, this tweet from Eric Eggert (from W3C WAI) and this tweet from Addy Osmani (from Google Chrome), I found an existing feature request for Firefox and added my 2 pence. I have to file one for Chromium next. Or you can do it.
