Configure Nav links to be opened in a new tab

[amywtlin]

What

Currently, all navigation links open in the current tab where the user is, which sometimes isn't an ideal behavior. We are adding this flexibility, enabling admins to configure the where a navigation link will be opened in.

Options

• To be opened in the current tab
• To be opened in a new tab

Design

Please feel free to reach out to @anujbhavsar96 for support

See more here: https://docs.google.com/document/d/1tidFU5mR6vdTV1PMdAEUvLFKZHHqftwKTxo6YrVJHpc/edit#heading=h.lf99x9d1a3j5

[github-actions]

Thanks for the issue, we will take it into consideration! Our team of engineers is busy working on many types of features, please give us time to get back to you.

Feature requests that require more discussion may be closed. Read more about our feature request process on forem.dev.

To our amazing contributors: issues labeled type: bug are always up for grabs, but for feature requests, please wait until we add a ready for dev before starting to work on it.

To claim an issue to work on, please leave a comment. If you've claimed the issue and need help, please ping @forem/oss. The OSS Community Manager or the engineers on OSS rotation will follow up.

For full info on how to contribute, please check out our contributors guide.

[citizen428]

Currently, all navigation links open in the current tab where the user is, which sometimes isn't an ideal behavior.

FWIW, as a user, I really dislike this. Replacing the current URL is the expected behavior of a hyperlink and all browsers have a shortcut for opening links in a new tab if the user so wishes. Managing tabs on my machine should be up to me, not the site admin, in 90% of cases target="_blank" is as annoying as an unasked for pop-up. There are way more bad reasons to open a link in a new tab than there are valid ones, see e.g. https://css-tricks.com/use-target_blank/.

[amywtlin]

@citizen428 That's a great post!

I think we want this for multiple reasons:

• Our users read articles and sometimes they get distracted by links. This is a good reason to enable this flexibility so they can come back to where they left off. Similar to the "there's media playing" mentioned in the post, ours is "there's article being read." I didn't specify this behavior to only be applied when it's on post view in order to simplify this issue.
• Not going to lie, Forem admins have also requested this feature multiple times.

There isn't going to be an answer that pleases all. I would also point out, as a user, my preference is the opposite of yours - I detest when links are open in my current tab, especially when cmd+click doesn't open up a new tab either (I think it has to do with some of the SPA implementation with frontend JS, if I am not mistaken). Just saying that preferences are highly subjective.

[citizen428]

Fair enough, I'm probably in the minority here. The only argument I have left are potential accessibility issues:

https://codersblock.com/blog/external-links-new-tabs-and-accessibility/#accessibility-implications

But I'm sure @aitchiss knows way more about this topic than I do.

[amywtlin]

I agree we need to resolve accessibility issues this might cause here. I would love to hear what @aitchiss would suggest. As we manage general users' expectations with an icon attaching to the link, I wonder if there's something similar we can do to inform screen readers so that users won't feel disoriented.

[aitchiss]

Hey all! Yes there are some accessibility implications to opening links in new tabs, and the most important thing is that we communicate to users that this is going to happen. "Best practice" tends to look like:

• An icon indicating to sighted users the link will open in a new tab
• 'Screen reader only' text that conveys the same - this can be achieved in a few ways, but if we use an SVG for the icon, then I'd suggest an aria-describedby on such links (I actually have a wee codepen with an example of one way to achieve this)

On a more general note, I think there are likely other places in the app currently where we're not doing these things for links that open in a new tab - something we could think about for the new Link component too @ludwiczakpawel?

[aitchiss]

We could also consider adding some guidance in the admin portal about using the 'open in a new tab' option sparingly, e.g. noting that it's best used for e.g. links to contextual help guides where a user might want both windows still open.

For me personally, I tend to agree with @citizen428 - I know as a user how to open links in a new tab, so I'd rather the app didn't do it for me unless I'm on a page where I could accidentally lose form information. It makes sense to give admins the choice though, and we can just make sure we support making this as accessible as possible.

[ludwiczakpawel]

An icon indicating to sighted users the link will open in a new tab

This was actually a plan - we wanted to add an icon to indicate it's going to be open in new tab:

On a more general note, I think there are likely other places in the app currently where we're not doing these things for links that open in a new tab - something we could think about for the new Link component too @ludwiczakpawel?

Good point!

---

FWIW I don't have strong feelings about forcing new tab. I personally don't like it but I think it's slightly less bitter when it's communicated properly (with an icon, as @aitchiss suggested). And what @amywtlin mentioned: this has been requested by admins several times soooo 🤷‍♂️ . But I do like an idea of somehow educating admins to be conscious and careful when using this setting.

[Ridhwana]

@amywtlin we're tackling some low hanging fruit on the admin this week, hence I wanted to clarify what the way forward for this discussion is?

Also seems to be a duplicate of https://github.com/forem/rfcs/issues/320, so I'm closing that RFC since there's been more discussion on this one.

[amywtlin]

@Ridhwana Here's the conclusion:

We'll allow admins to decide if they want their links to be opened in the current tab or in a new tab, with the visual indicators as shown in Pawel's comment (sorry I should have attached that image in the body to avoid confusion; it's in the Google doc) and the accessible guidance for screen readers as Suzanne suggested.

[amywtlin]

Also, thanks for closing the duplicate issue!