Review usage of target="_blank" in the admin

[theadityajain]

Some links in the Setting Pages (General, Discussion, Permalink) pages open in same window, which sometime can be awful.
While the users can press cmd/ctrl + click and click the link to open it in new tab but If the user does not open the link in new window, options (which are not saved) will be lost and one have to go through them again.
Also links in the Edit Profile page and all the links in the help tab open in new window except a few.(so it is possible that users may just click it thinking them to alike other links which open in new window)
So a consistency will be there and ux can be a little better.

[johnbillion]

Related: #14099

[SergeyBiryukov]

Related: #20839

[garthkoyle]

I reviewed all the links in the Settings, Writing, Reading, Discussion, Media and Permalinks pages in BOTH 3.5.1 and 3.7-alpha-24822. No links were found to open in another tab/window so the links are consistent.

[SergeyBiryukov]

Replying to garthkoyle:

I reviewed all the links in the Settings, Writing, Reading, Discussion, Media and Permalinks pages in BOTH 3.5.1 and 3.7-alpha-24822. No links were found to open in another tab/window so the links are consistent.

As mentioned in the ticket description, the link on Profile screen​ opens in a new window, as well as almost all the links in Help tab.

We should probably review all the Codex links. Whether they should open in a new window or not, I guess it would make sense to be consistent.

[SergeyBiryukov]

Related: #31363

[joedolson]

Mixed feelings on this question; in general, links should not open in new tabs/windows without informing the user, which would add a lot of noise to the screen. However, it is true that if a user opens the link in the same window without saving their settings, they can undo whatever work they were doing.

My vote would be in favor of using heartbeat to detect whether there are pending changes, or something to that effect, and throwing a warning if a user attempts to move to another page without saving changes, similar to what currently exists in post saving.

[SergeyBiryukov]

Related: #31386

[davidakennedy]

#31363 was marked as a duplicate.

[davidakennedy]

#31386 was marked as a duplicate.

[DrewAPicture]

#31386 was marked as a duplicate.

[Ankit K Gupta]

I think, Open the links in new tab is not good for point of user experience. If user want to open links in new tab then they have option to use Ctrl+click of keyboard.
If we give target="_blank" it means we are forcing user to open the link in new tab even if he doesn't want.
Also, it will increase the numbers of tabs in browser.

[juhise]

patch file for user-edit.php

[juhise]

Added patch for making all codex link consistent throughout the Admin.

[atomicjack]

#33303 was marked as a duplicate.

[netweb]

Here's another, if your permalinks are not pretty you'll see a button next to the post permalink "Change Permalinks"
https://core.trac.wordpress.org/browser/trunk/src/wp-admin/includes/post.php#L1292

1292:			$return .= '<span id="change-permalinks"><a href="options-permalink.php" class="button button-small" target="_blank">' . __('Change Permalinks') . "</a></span>\n";

[swissspidy]

#35244 was marked as a duplicate.

[rianrietveld]

This ticket needs to be broken down in into multiple tickets with this ticket as a tracker.
The a11y team has set this as a goal for 4.6 but me probably need more time then that.
We also have to look at the "saving settings” issue and make a uniform decision about that.

[afercia]

Discussed a bit during today's accessibility bug scrub, thinking this is something that should definitely be done but not sure well have time in this release cycle. Setting to future release for now.

[afercia]

#34727 was marked as a duplicate.

[rianrietveld]

Investigated the use of target="_blank" in the admin today.

Almost all target="_blank" links are in the help-wrap at the top of almost each admin-view.
And if no permalink structure is set, a button Change permalink is shown with a target=_blank link to the set permalink page.

I left out the media and press-this for this review.

Most links can be changed easily by just removing the target.
On other pages an alert needs to be set for possible unsaved data when a user leaves, as done in the edit.php, but that can be done later.

The (old) link functionality is still in core, you can activate it with the the plugin Link Manager, which has 100,000+ active installs. This also has "_blank in the help-wrap.

The plan is to open new tickets per functionality (like users/comments/network) and make patches for those. We can discuss per ticket what needs to go and what can stay. But for the links in help: I think all blank can go.

A few questions:

• Then there is the preview button. Should this open in a new window or in the same? I prefer stay with a visual warning.
• Some functionality, like the menus and the old link functionality, gives the user the option to add a link target="_blank". Maybe we should reconsider this? Related to this is #36809

[rianrietveld]

Patches done so far:

• #38145 Remove target="_blank" from help tab in serveral Admin screens
• #38143 Remove target="_blank" from help tab option files for settings in the Admin
• #38141 Remove target="_blank" from help tab custom-background/custom-header
• #38140 Remove target="_blank" from help tab comment/comment-edit
• #38159 Remove target="_blank" from help tab in Network screens in the Admin
• #38215 Remove target="_blank" from help tab in plugin, theme and update screens in the Admin
• #38217 Remove target="_blank" from help tab in user and widget Admin screens

[celloexpressions]

In response to the questions in 33:

• The preview button should open in a new tab by default since it's generally intended for back-and-forth (live preview is a better solution, which we'll have an option for eventually). Visual and/or screen-reader-text indicators of that would help. We have to remember that a very large number of users don't know how to open links in a new tab.
• I would be in favor of removing the link target option for nav menus. However, we should probably wait until custom nav menu item properties are possible, so that a plugin could bring that functionality back. See #18584.

[rianrietveld]

Replying to celloexpressions:

In response to the questions in 33:

• The preview button should open in a new tab by default since it's generally intended for back-and-forth (live preview is a better solution, which we'll have an option for eventually). Visual and/or screen-reader-text indicators of that would help. We have to remember that a very large number of users don't know how to open links in a new tab.
• I would be in favor of removing the link target option for nav menus. However, we should probably wait until custom nav menu item properties are possible, so that a plugin could bring that functionality back. See #18584.

Thanks @celloexpressions for looking into this. I agree with you.
The plan is to remove the targets first from the help tabs (and text links) and then find a good solution for the rest.

[afercia]

In 38718:

Accessibility: Remove target=_blank from the comment/edit-comments help tabs links.

Stop taking control of users' browsers.

Props rianrietveld.
Fixes #38140. See #23432.

[afercia]

In 38719:

Accessibility: Remove target=_blank from the old custom background/header help tabs links.

Stop taking control of users' browsers.

Props rianrietveld.
Fixes #38141. See #23432.

[afercia]

In 38720:

Accessibility: Remove target=_blank from the Settings screens help tabs links.

Stop taking control of users' browsers.

Props rianrietveld.
Fixes #38143. See #23432.

[afercia]

In 38721:

Accessibility: Remove target=_blank from the Network screens help tabs links.

Stop taking control of users' browsers.

Props rianrietveld.
Fixes #38159. See #23432.

[afercia]

In 38722:

Accessibility: Remove target=_blank from the Plugins, Themes, Media, Update, and Tools screens help tabs links.

Stop taking control of users' browsers.

Props rianrietveld.
Fixes #38215. See #23432.

[afercia]

In 38723:

Accessibility: Remove target=_blank from the Users and Widgets screens help tabs links.

Stop taking control of users' browsers.

Props rianrietveld.
Fixes #38217. See #23432.

[afercia]

In 38725:

Accessibility: Remove target=_blank from the help tab links on several admin screens.

Stop taking control of users' browsers.

Props rianrietveld.
Fixes #38145. See #23432.

[afercia]

Moving out from the release since this is now a task and used as tracking ticket. New, specific tickets for specific issues will have the target-blank keyword: https://core.trac.wordpress.org/query?keywords=~target-blank

[afercia]

In 39019:

Accessibility: Remove target=_blank from the help tab links in network.php.

Stop taking control of users' browsers.

Props wolly.
Fixes #38572. See #23432.

[afercia]

Just to highlight this new pattern landing in the Customizer in WP 4.7:

[afercia]

Worth noting the updated News dashboard widget merged in [40607] that is now able to display "Nearby Events", has just introduced a new icon to indicate external links.

Whether links open in a new window or not, I'd tend to think this icon should be used only to visually indicate the link points to an external resource.

Instead, target="_blank" should be communicated by other means, with a screen reader text as done for example in [40422] and [38829]. Any thoughts welcome!

As far as I know, this icon is used in only one other place: when reordering widgets in the customizer:

[joedolson]

In order to move forward on this, we need to come to agreement on how links that open in new windows are presented in the UI. There are two problems to solve: the first is not opening links in new windows unless necessary, second is to appropriately communicate that a link will open in a new window if it is necessary.

Links that open in new windows should include an indicator that shows they'll open in a new window that's available to both sighted and non-visual users.

[johnbillion]

#42529 was marked as a duplicate.

[garrett-eclipse]

#46323 was marked as a duplicate.

[audrasjb]

In 52646:

Media: Remove target blank attribute from media uploader edit links.

This change removes a dispensable target blank attribute from Edit links displayed in the asynchronous file uploader.

Follow-up to [22755].

Props kebbet, SergeyBiryukov.
Fixes #54945.
See #23432.

[generosus]

#56571 was marked as a duplicate.

[jwgoedert]

@sabernhardt Is this still being explored? I spent some time searching through core and found quite a few instances but many of them had disclaimers or seeming remedies. Interested in contributing to this or related tickets if that would be of value! (new to the accessibility WP world)

[generosus]

Hey Guys,

How do I get out from receiving notifications for this topic?

I have disabled everything but still keep getting them. There’s an open ticket requesting a fix. It’s been around for a while.

Details: ​https://wordpress.org/support/topic/bug-cannot-disable-email-notifications-from-wordpress-trac/

Above affects many. Help appreciated.

Thank you!