Remove `target="_blank"` from Browser Uploader Link

[dilipbheda]

While visiting the wp-admin/media-new.php page, I noticed that the Browser Uploader link included an unnecessary target="_blank" attribute.

Reason for Removal:

The Browser Uploader link does not navigate to a new page, it simply toggles the browser uploader section dynamically without reloading the page. Therefore, the target="_blank" attribute is redundant and should be removed.

[sabernhardt]

Yes, the browser uploader link apparently stays on the same page, behaving more like a button, unless you purposely open it in a new tab (with Ctrl+click or similar).

• The ​script uses .preventDefault() and hides the multi-file uploader by ​adding the `html-uploader` class.
• With Javascript disabled, the link is hidden (using the ​`hide-if-no-js` class).

For the patch, I would prefer to keep the translatable string as it is, replacing target="_blank" with an empty string. Then translators would not need to update anything, and the current string would still be available in case a future change requires additional attributes.

printf(
	/* translators: 1: URL to browser uploader, 2: Additional link attributes. */
	__( 'You are using the multi-file uploader. Problems? Try the <a href="%1$s" %2$s>browser uploader</a> instead.' ),
	$browser_uploader,
	''
);

However, if changing the string is important, it would only have one %s placeholder:

printf(
	/* translators: %s: URL to browser uploader. */
	__( 'You are using the multi-file uploader. Problems? Try the <a href="%s">browser uploader</a> instead.' ),
	$browser_uploader
);

[joedolson]

Good catch, @dilipbheda!

I'm thinking that we should also semantically change this to a button. To keep things simple, we might want to just add role="button" and add the extra key handler to the events to support spacebar triggering.

That would also continue to allow users to open in a new tab if they are accustomed to doing that, though I wonder how often that actually happens...

[rollybueno]

Honestly, I think adding role="button" still creates semantic mismatch and another accessibility issue. Since this is toggling the uploader in same page, why not just using real <button> instead?

[joedolson]

The reason for not using a real button is the possibility that users are accustomed to being able to open this in a new window.

The only question is whether anybody actually *does* that. There isn't really any sound reason for going to a new window to open the other uploader.

I'm somewhat inclined to simply change this to a button, and see whether anybody complains about the change. If so, it would be easy enough to switch to using role="button", instead.

[sabernhardt]

adds role="button" plus spacebar usability, while keeping the existing strings

[sabernhardt]

replaces links with buttons and updates elements in script

[sabernhardt]

If one switcher link has the button role or becomes a <button> element, the counterpart link with href="#" ought to have the same change.

I think I still prefer keeping the existing strings, but 63238.button-role.diff​ probably would need further editing.

[joedolson]

I think I'd rather change the translatable string that depend on manipulating the outcome of a translation. The role="button" patch would break with a simple error in the translated string that modified a href="#". While that's improbable, I think that the string change would be better.

[sabernhardt]

Well, changing the element with 63238.button-element.diff​ should be easier for us. I think the script in 63238.button-role.diff​ could need editing to work with the spacebar in all browsers, and it would require more testing.

However, the role option should be more backward-compatible.

• It would keep the well-established strings (see ​both strings, with their translations). Of course, untranslated admin strings are less of a problem than user-facing strings, and these might be labeled as 'fuzzy'.
• All of the href="#" string's translations include <a href="#"> today, but if that changes, it would fall back to link semantics and should continue to behave as it does now.
• If someone had a reason to create a custom replacement of 'plupload-handlers', then it should still function when people click the link or use the Enter key (without needing to update the element name in their script). Most plugins in the ​directory search results enqueue 'plupload-handlers' on its own or as a dependency. Gmedia Photo Gallery is the only plugin I found to dequeue it and enqueue another script, but that plugin apparently does not affect these switcher links within the core media library.
• If some people actually have a desire to open the one link in a new tab, the role would continue to allow that.

Removes some additional unused code from previous patch.

Trac ticket: https://core.trac.wordpress.org/ticket/63238

[joedolson]

Added a PR to update 63238.button-element.diff. The only change is that it also removes the now un-used variables from media_upload_flash_bypass().

[joedolson]

In testing, I observed that there was a focus loss when changing uploaders, so I also added focus assignment after switching.

@sabernhardt Can you give this a check? I've tested everything and it's working, but would appreciate a 2nd opinion.

[joedolson]

In 61099:

Media: A11y: Switch uploader toggle to button and set focus.

The control to switch between the browser uploader and the default uploader used a link with target="_blank", but was driven by scripts. In a no-js context, this meant that the link could be used to open the browser uploader in a new tab. This is unnecessary, however, because the default uploader is not rendered when JS is not available.

On switching uploaders, browser focus was lost.

For more predictable keyboard and screen reader behavior, switch the media uploader toggle to a button element and set focus to the upload button in the new context.

Props dilipbheda, sabernhardt, rollybueno, westonruter, joedolson.
Fixes #63238.