Link Targets and 3.2.5
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 visible 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 look 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, link destinations 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 generally 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.
Update: 1 October 2020
Nielsen Norman Group has revisited its advice on opening links in new tabs/windows:
For the most part, always open links in the same browser tab or window. However, if you hypothesize that opening a new tab or window may help users in their task, don’t base this decision on the type of link or content alone. Rely on observational research methods, like usability testing, contextual inquiry, and field studies to help you make the right call.
[…]
Don’t go overboard with opening links in new browser tabs or windows simply because you think users might need them to display that way for certain cases.
In short, this is a usability challenge regardless of your take on WCAG.
24 Comments
Reply Another exception I believe for opening link in new tab is: If a form contains a link to explain some field, it should open in new tab, so the data filled by user is not lost.
In response to . Reply Yup, a good example. A hybrid of the help docs and not destroying session data (just without a session) that I cite above.
In response to . Reply Unless the form has a timeout, and the user might miss the timeout notification in the form window while they’re off reading the new tab. That would be a 2.2.6 violation…a timeout warning is no use if they never get the warning. In that situation, I would recommend a disclosure/expansion or a modal, or just redesigning the flow.
Reply I have a course which has links to external webpages. I took the decision to open them in new tabs. I wanted my learners to be able to follow any path they wanted from the link, but still be able to quickly get back to where they were in the course.
In response to . Reply Was this backed by any surveys or testing with users? You say what you want, but the whole point of the post is letting users have a say. If your users said that new windows are ideal, then there you go.
Reply Thank you for writing this up! I’ve had to argue against links that forcefully open in new windows so many times over the years. Next time I can just point them at this post! :-D
Reply I completely disagree. I expect websites to open external links in a new tab/window and hate it when they don’t. Not opening the external link in a new tab goes against expected behavior for the last 20+ years. Why do you think you have to fight so hard to get people to change this behavior.
When a new link opens often I navigate around the website and hate having to guess the 20 back button presses to get back to the original page. Sure if you plan to only read the single page that opens, then not opening a new tab seems reasonable, but that seems like a really big assumption.
Standard blog reading for myself, open article, read article, click on referenced articles, read those articles and often click on referenced articles in the referenced article. Trying to remember all paths in a single window and trying to get back to the original article is painful. Or cross referencing one article to the other, which is often the point is impossible in a single window. Being a smart user I often force a new tab open, but I know many that don’t know how to do that. I would argue that there are far more people that know how to close a tab than to open a web link in a new tab. And then of course every once in a while I forget, then I have to do the back button mess.
Not everyone uses the back button frequently or easily and making that assumption is just as wrong as making the assumption that the user doesn’t want a new tab or that the user knows how to open a web link in a new tab.
You touch on the real issue multiple times. The user should have the ability to override the developer’s choice. How? At the browser level. We currently have a way to force a link into a new tab and a new window. We don’t have the ability to force the link into the same window. This should be added. There reasonably should be a setting to do this globally for all links, so the user doesn’t have to remember to do it and they can make this decision once. Browser setting, Always open external links in the same window/new tab/new window. Done. Plus of course the command overrides at any time.
Also clicking back on a tab that was opened by another tab could easily close that tab and go back to the opening tab and place focus on the original link, so if that was a mistake it can easily be reopened. Seems completely reasonable. This can only be controlled on the browser level and that’s where it should be.
When an issue can be solved by the browser that’s where it should be solved.
Further, for security the browser should change the behavior and require the link to give permission to the opening window rather than forcing to turn it off. 99.9% of windows opened don’t need permission to access the opener. Yes this will change backwards compatibility, but that’s the burden of the developer rather than risking the user, where the least burden should be.
Another issue mentioned about form inputs. There are forms on almost every web page now-a-days. Not making links external makes the assumption that the user hasn’t started to fill it out. However, most browsers have solved this problem by saving the input entries in the back history. Why? Because this was a common issue that the browser could solve for the user. So they did.
In response to . Reply I appreciate that you left a comment. I do not agree with the bulk of it (as evidenced by this post), however.
Not opening the external link in a new tab goes against expected behavior for the last 20+ years. Why do you think you have to fight so hard to get people to change this behavior.
In many cases the behavior is a mis-learned habit, often enforced by authoring tools and used by content authors who are not developers (most users of a WYSIWYG CMS).
Being a smart user I often force a new tab open, but I know many that don’t know how to do that. I would argue that there are far more people that know how to close a tab than to open a web link in a new tab. And then of course every once in a while I forget, then I have to do the back button mess.
That makes you a skilled or trained user. In my testing with less skilled users, closing a tab is not immediately apparent and instead I watch users close the entire browser. This is often after the back button has no effect.
Not everyone uses the back button frequently or easily and making that assumption is just as wrong as making the assumption that the user doesn’t want a new tab or that the user knows how to open a web link in a new tab.
It is not an assumption; I have tested this with users across skill levels. Unskilled users struggle with all these, but only one approach requires one-step training (keeping links from opening in a new tab).
The user should have the ability to override the developer’s choice. How? At the browser level. We currently have a way to force a link into a new tab and a new window. We don’t have the ability to force the link into the same window.
Not using
targethonors the user’s choice today — let the link open in the same window, with the advantage that a user can override it.When an issue can be solved by the browser that’s where it should be solved.
In the 21 years since WCAG 1.0 considered this an accessibility failure, browsers have not offered that feature. If it takes them another 21 years then we still have to help users in the short term.
However, most browsers have solved this problem by saving the input entries in the back history. Why? Because this was a common issue that the browser could solve for the user. So they did.
Except they didn’t really. Forms with session information, forms on secure connections, do not always save the user-entered data. Regardless, I cite that use case in the exceptions above.
In response to . Reply I have to disagree again here:
In many cases the behavior is a mis-learned habit, often enforced by authoring tools and used by content authors who are not developers (most users of a WYSIWYG CMS).
This is both wrong and a huge assumption. I am a web developer and WordPress the largest CMS (30+%) is on your side and has actively discouraged opening new tabs/windows and done everything to discourage this behavior except removing the option entirely. And yet it’s still the more common behavior.
I can see your point here and generally agree that the difference between closing a tab and a window isn’t always obvious:
That makes you a skilled or trained user. In my testing with less skilled users, closing a tab is not immediately apparent and instead I watch users close the entire browser. This is often after the back button has no effect.
However, the solution again is to allow the back button to close a window when it was opened by a previous window.
Browsers often don’t implement features such as this until it is requested. Maybe it has taken 21 years because there hasn’t been a consensus on the appropriate approach to manage this or a large enough group of developers/users haven’t requested it. Which would also imply that no one is really that upset about the current standard.
I would argue that at least 50% of users (trained or otherwise) would prefer the current behavior. I would also argue, that even though it may be hard for less skilled users, does that mean we should make it harder or the less preferred method for skilled users.
I think my main point still stands, this should be an option on a per user basis, which can only be controlled by the browser, which means as developers we need to push for our users and our selves to have more choice by implementing a more consistent setting in the browser rather than having to make the choice on a per link / per user / per situation basis.
When talking about global behavior it should be the browser that implements the behavior not the developer. Should the developer have the choice to change that default behavior, sure. If the user has good choice control, however, the developer shouldn’t override very often.
In response to . Reply This is both wrong and a huge assumption. I am a web developer and WordPress the largest CMS (30+%) is on your side and has actively discouraged opening new tabs/windows and done everything to discourage this behavior except removing the option entirely. And yet it’s still the more common behavior.
I have built in WordPress and in platforms that pre-date WordPress, and have seen internal documentation and requests to enforce off-site links in new windows (driven almost exclusively by marketing departments) on nearly every project for over 20 years across thousands of sites.
These authors are not developers, which was my assertion. It may be anecdata, but I assure you I am not wrong.
I am skipping the speculative commentary since it is not grounded in data and does not further the discussion.
When talking about global behavior it should be the browser that implements the behavior not the developer. Should the developer have the choice to change that default behavior, sure. If the user has good choice control, however, the developer shouldn’t override very often.
I think you have made my case.
The global behavior is to open links in the same window/tab. The user has control to open them in a new window/tab if desired.
Developers override that global behavior by opening links in a new window/tab. The user has no control over that. So the developer shouldn’t override it.
It even adheres to the W3C Priority of Constituencies — users over authors over implementors over spec over theoretical purity.
In response to . Reply I have been doing this for 20 years too. In my experience users don’t like getting lost and when the navigation of a site changes, they often get lost and don’t easily know how to get back. Opening a new tab gives them the option to do that fairly easily.
I honestly think we are mostly agreeing, that this is both a problem, the current state of this issue, and that the user should get to make the choice. I think we are only going round about how the user should be able to make the choice or the action that should be taken to solve the problem.
You are stating that the developer should stick with the default behavior of the browser even if there’s a high possibility that the user may expect/want something different and thereby make the user figure out how to make happen what they want to happen.
I am stating that the solution isn’t to dictate to developers, but rather solve the underlying problem, which is users don’t have control over the default behavior without taking a special action (key press click, right click, or other). The browser should fix this issue and then once the user has choice the developer will respect that choice.
Should a user have to hit receive every time they want to get email? If that’s how they want it, sure. If they are concerned with bandwidth etc. sure. But by default most users expect email to come in automatically.
Should a user have to remember and know how to special click an external link they want to open in a new tab? Not by default. But they should have the ability to make that change. Since browsers don’t give users that option developers have attempted to implement the preferred behavior. Give the user the power and the developer doesn’t have to guess. Remembering to special click each time is too much cognitive load and is too easy for the user to forget.
Is there a better way? Yes a global browser option.
In response to . Reply Opening a new tab gives them the option to do that fairly easily.
Except, as I note in the post, it is not so easy for some users.
You are stating that the developer should stick with the default behavior of the browser even if there’s a high possibility that the user may expect/want something different and thereby make the user figure out how to make happen what they want to happen.
That is not what I am saying. My statement is not nearly that absolutist. In the TL;DR and in the Exceptions section I allow for exceptions. Even in the Wrap-up, the first sentence opens with
Barring some very specific reasons that clearly benefit users…I think our key difference is making assumptions about what the user finds easy. I have a bunch of prior art and experience telling me not to make that assumption so readily. I also know from running usability tests that assumptions are often off.
So by all means, test with your users (all your users) and see if your assumption is right or wrong, and then go from there.
Is there a better way? Yes a global browser option.
So until then? Another 20 years of business as usual with confused or trapped AT users? Users that we already know have a higher barrier to even understanding the mess that is many modern sites?
It seems the better way today is not wait, but to do something that has a demonstrated benefit — not arbitrarily open links in a new window.
Reply link since WP seems unwilling to provide one this deep.
In response to . Reply Thank you so much. This seems to be one of the few sane comments on this topic.
This article cites studies from up to 18 (!) years ago as if the way people use browsers hasn’t changed since then. Madness.
In every single user test I ever ran where external links were opening in the same tab the user ran into problems and couldn’t find their way back to what they were actually trying to do.
In response to . Reply This article cites studies from up to 18 (!) years ago as if the way people use browsers hasn’t changed since then. Madness.
I cite materials as far back as 18 years ago and as recent as, well, now. Mostly they demonstrate that we have known for a long time that users struggle and it has an outsized impact on users with disabilities.
In every single user test I ever ran where external links were opening in the same tab the user ran into problems and couldn’t find their way back to what they were actually trying to do.
This concerns me a bit, since generally you should see variance across tests. I do. I see variance across skill levels, audiences, sites, ages, etc. Be sure your methodology is sound and that you are not engaging in selection or confirmation bias.
Reply Well my article some time requires the link to the mdn docs, or sometimes I want to redirect to the particular section of the old article. But I want the user to come back to original article; is that the best use case for “_target”?
In response to . Reply No, that is very much a case where you do not need a
targetattribute. Linking to an anchor in another page is no different. A user who hits the back button will still generally return to where they were.
Reply This article is only crazy. If you open an external link from your website in the same tab, your visitors will leave your site. And after some more clicks they will not find the way back. Is this the behaviour you want?
I fully agree with Christian and Mario. Average users don’t want to become lost in the “World Wide Web”. If your studies are from 18 years ago, throw them away. The world has changed.
Keeping in mind the arguments of Christian ans Mario: open internal links in the same tab. Open external links in a new tab. The user does not need to choose.
In response to . Reply If you open an external link from your website in the same tab, your visitors will leave your site. And after some more clicks they will not find the way back. Is this the behaviour you want?
It does not really matter what I want (unless, as I note, my job depends on keeping bounce rates down or time-on-site up). The real question is, is this what the user wants? Do they want to come back? Or are you tricking them into staying?
If your studies are from 18 years ago, throw them away. The world has changed.
I cite materials as far back as 18 years ago and as recent as now. Since browsers have not created a method to let users override this behavior, the part of the world relevant to this case has not changed.
The user does not need to choose.
And this is the core of our disagreement. All of what I wrote is about user choice, about seeing users as people with agency. If you truly feel they do not need to choose, then there is little I can say to sway you.
Reply So is AirBnb wrong?
In response to . Reply I need a lot more context. You mean a specific page? Or some part of a design system? Or as a business model?
Reply I aggree with You but I use target_ blank because in one particular post of mine there are about 27 links to not much legal sports streaming sites. Nothing else.
Some of them are quite too often unavailable for
a short period .
And with opening in new windows , for example ,2 or 3 of the links, gives the users the ability to track when a better streaming source becomes available.
Indeed with noopener & noreferrer.
But that works only in that case of mine. Generally I don’t use target_blank.
Reply This is very interesting because for the past 20 years we have taught our users/content creators to open new tabs/windows for external links and for files. The thought process for external links is that external isn’t our content and we want that user experience of going to a different window/tab. For files, opening a new window allows the user to read that PDF, close the window/tab, (often accidentally) and still have their session in the other window/tab.
Reply Given that AA Success Criterion is connected with litigation i.e. someone could be sued for not following AA, AAA becomes a place for best practices that may be more subjective. In Google Trends, the search term “WCAG Level AA” seems to be searched at least 1000x more than “WCAG Level AAA”, which is a flatline at zero. Glad to see AAA get some more ink.
Reply I like being in control on whether a link opens a new tab or not. I typically don’t know if a link will do that unless it has a visual clue (box with an arrow in it or similar) so I always use ctrl+click to open a link in a new tab if I want to keep my place on the current tab. If I don’t care if the link opens in a new tab, I’ll just use a simple click and be surprised if it’s a new tab or not.
From an accessibility perspective, I think the browser should handle surfacing to the accessibility tree whether a link opens in a new tab or not. The developer shouldn’t have to do that. But then, there are lots of things I think the browser should do for accessibility, such as having built in support for navigating by landmarks. Screen reader users have that feature but non-screenreader keyboard users don’t.
Leave a Comment or Response