wp-login.php site title link points to wordpress.org

[ovann86]

In the WordPress administration login page, the site title at the top of the page is linked to wordpress.org

From an accessibility perspective, this is misleading. Specifically, WCAG 2.0 has a focus on making link text that describes the purpose of a link - which this does not.

The WC3 have several articles covering this topic, but this gives the general idea of what they're advising ​http://www.w3.org/TR/WCAG20-TECHS/H30.html

I am suggesting that we change this text to link to the home url, like happens for multi-sites.

The specific change would be

wp-login.php - line 101 and line 102

FROM

$login_header_url   = __( 'https://wordpress.org/' );
$login_header_title = __( 'Powered by WordPress' );

TO

$login_header_url   = home_url();
$login_header_title = wp_specialchars_decode(get_option('blogdescription'), ENT_QUOTES);

If this was done deliberately, such as to promote the wordpress.org website or to help users identify the CMS - you should consider adding a link to the bottom of the login form.

If you're wondering why the link title is not adequate, it's because by default screen readers do not read out the link title - they read the linked text.

Here's an article that touches on this and has a video showing how ineffective it is: ​https://silktide.com/i-thought-title-text-improved-accessibility-i-was-wrong/

[afercia]

Screenshot to illustrate the issue: the link text (hidden with CSS) is set to the site name while the link destination is wp.org

Worth noting this link is taken out from the tab order because it has a tabindex="-1" attribute but screen readers offer several ways to get to the link and activate it: arrows, shortcuts to jump through links, etc.

[ovann86]

Just to add to this ...

I was in my 'screen reader mode' (text only mode, using JAWS) when I noticed this issue.

I have just switched to standard visual mode and see that there is an image being applied to the link using CSS - which explains why someone at some point wanted the 'Powered by WordPress' title to appear when hovering over the element.

However I don't believe this changes the suggested change.

If the objective is to have the WordPress logo, linked to wordpress.org - I would consider including a link to the WordPress site in addition to the linked H1.

e.g.

<a tabindex="-1" title="Powered by WordPress" href="https://wordpress.org/">Powered by WordPress</a>

And applying the logo to this link instead.

This would however affect existing CSS customisations people have applied to their login pages by targeting

.login h1 a

As the new link wouldn't be contained by the H1 anymore.

[obrienlabs]

Added a patch with @ovann86's original suggested changes. I'm also adding the workflow keyword has-screenshots back as it looks like it was removed by mistake.

[afercia]

The version should be set to the latest major version :) Ideally, this would be the earliest affected or applicable version, i.e. the version where the issue was introduced. When retrieving the correct version is not possible (or actually not so useful), it's a common practice to set it to the latest major version, excluding the .1, .2, .3 ones. Please don't change it back.

@obrienlabs thanks for the patch :) to me it seems there's a clear intent to link to wordpress.org so maybe this should be discussed a bit before any change proposal. An alternate solution would be changing the link text, maybe adding a filter to allow developers to change it, as done for the link and title attribute which are already filterable.

[ovann86]

@afercia @obrienlabs - both changes were by mistake. Both updates were made as I was typing a response. When I posted my update the form reverted the settings (a trac bug perhaps - I saw your update via AJAX and assumed the metadata changes would have worked too).

@afercia - I'm unsure about the intent of this link.

I'm unsure why there is a different behaviour between multi-site and standard WordPress installs. The multi-site behaviour is all about the website (links to the multi-site home page) but standard WordPress is more about wordpress.org (links to wordpress.org).

I would expect it to have the same intent and functionality in both scenarios.

[ocean90]

The link was introduced in [1731]. In [12697] the Multisite behaviour was merged. See also ticket:18287:7.

[afercia]

Quickly discussed this ticket in today's accessibility chat on Slack and agreed it's a bug since users are basically "fooled" when the URL and title attribute are the defaults and the hidden link text is the "blog name". In fact, screen readers will read out the hidden link text e,g, "My beautiful website" but the link points to wordpress.org.

Things we discussed:

• maybe remove the title attribute
• set the default link text to 'Powered by WordPress'
• make the link text filterable
• all this without breaking existing sites :)

Any thoughts and patches more than welcome.

[afercia]

Trying to recap what's happening with the logo link and why it matters, here's the current setup:

1) multisite main site:
hidden link text: Network Name
title attribute:  Network Name
URL:              Network home URL

2) multisite site:
hidden link text: Site Name
title attribute:  Network Name
URL:              Network home URL

3) not multisite:
hidden link text: Blog Name
title attribute:  Powered by WordPress
URL:              https://wordpress.org/

Screen readers will always read out the hidden link text (and by default they don't announce the title attribute) so 2) and 3) would be misleading. The link text is set to the "single" site name but the link points respectively to the Network home and to wordpress.org

The link and the title attribute are filterable. The link text is given by bloginfo() which is filterable too. By the way the default values should be probably improved.

Tried to find the best way to handle this in the last accessibility team chat on Slack, the proposal was to remove the title attribute and use the current filter login_headertitle on the link text instead.

By the way, since plugins and themes are using this filter in ways we can't predict, I'd propose something slightly different and a bit more gradual approach. Any thoughts and feedback more than welcome. Maybe something along these lines could work:

• deprecate the login_headertitle filter
• make the default link text the same as the default title attribute
• introduce a new filter for the link text

[afercia]

A very first pass, to illustrate the idea. Uses _deprecated_function() to deprecate the filter as seen in class-wp-editor.php, not ideal I know but this is what's available for now.

[benoitchantre]

If the link is replaced by the home url as suggested, I think it would be also logical provide an easy way for the user to use a custom logo instead of the Wordpress logo.

[SergeyBiryukov]

Related: #18287, #33597, #33755.

[afercia]

Moving to future release, still needs to have a defined approach but it is something that should definitely be solved.

[lukecavanagh]

What if the WordPress logo, is replaced with the site icon if one is present and set in the customizer?

[lukecavanagh]

The WP Logo is being pulled from

/wp-admin/images/wordpress-logo.svg

So should be able to use

get_site_icon_url()

​https://developer.wordpress.org/reference/functions/get_site_icon_url/

[DrewAPicture]

Replying to lukecavanagh:

The WP Logo is being pulled from

/wp-admin/images/wordpress-logo.svg

So should be able to use

get_site_icon_url()

​https://developer.wordpress.org/reference/functions/get_site_icon_url/

• See comment:6:ticket:33597 for why the site icon was not implemented on wp-login
• See comment:8:ticket:35807 for why the site logo was not implemented on wp-login

[lukecavanagh]

@DrewAPicture

Okay fair point, what about using get_the_site_logo() instead then?

[afercia]

Moving to 4.8 for discussion and, hopefully, a fix. Probably needs a refresh.

[flixos90]

Replying to afercia:

Tried to find the best way to handle this in the last accessibility team chat on Slack, the proposal was to remove the title attribute and use the current filter login_headertitle on the link text instead.

34625.2.diff​ makes that adjustment. As discussed on Slack, let's choose that solution.

[jjcomack]

Just tested @flixos90's patch.
In regards to the title no longer there, all seems well. However, I noticed that there's no change regarding the actual URL or the logo on the login page.

Perhaps I missed something in the discussion, but shouldn't this also have been changed?

[lukecavanagh]

@jjcomack

So looks like the logo being linked to WordPress.org URL is defined here.

https://core.trac.wordpress.org/browser/tags/4.7/src/wp-login.php#L103-L104

Using this hook.
​https://developer.wordpress.org/reference/hooks/login_headerurl/

Non network sites could just use
​https://codex.wordpress.org/Function_Reference/home_url
​https://developer.wordpress.org/reference/functions/get_bloginfo/

if ( is_multisite() ) {
		$login_header_url   = network_home_url();
		$login_header_title = get_network()->site_name;
	} else {
		$login_header_url   = home_url();
		$login_header_title = get_bloginfo( 'name' );
	}

[lukecavanagh]

Basic patch

[lukecavanagh]

Updated Basic Patch

[lukecavanagh]

Also if a end-user does have a site icon uploaded, is it worth not pulling in wp_site_icon instead of loading in /wp-admin/images/wordpress-logo.svg?

​https://developer.wordpress.org/reference/functions/wp_site_icon/
​https://make.wordpress.org/core/2015/07/27/site-icon/

[afercia]

Needs a decision and some consensus. We're running out of time for the 4.8 release, so: punting.

[afercia]

Punting as per today's bug scrub.

[danieltj]

Is this something I could have a go at as a 'good first bug'? What's been decided in terms of an official course to solve this? Personally I like the idea of have the site icon, link to the blog homepage and title text being the site name.

That seems like the most sensible course of action.

[rianrietveld]

Replying to danieltj:

Is this something I could have a go at as a 'good first bug'?

Go for it!

[melchoyce]

@danieltj Still interested in working on this? Needs a patch ideally in the next week or two.

[danieltj]

Replying to melchoyce:

@danieltj Still interested in working on this? Needs a patch ideally in the next week or two.

Sorry, been busy and sidetracked.

I'll try to look into this by the end of this week if I can and get a patch before Sunday (fingers crossed).

[obrienlabs]

I know we're trying to wrap this one up and I see a few patches and questions but none accepted - so just checking in to see what is the right way to close this one?

[afercia]

I'd recommend to stick to the original scope of the ticket and don't touch the logo. Just fix the inconsistency between the link URL and the link text/title (deprecating the filter etc. as described above)

Specifically, this scenario:

3) not multisite:
hidden link text: Blog Name
title attribute:  Powered by WordPress
URL:              https://wordpress.org/

is just wrong: screen reader users will hear the blog name as link text, but the link actually points to .org... If the text was visible, it would be clear to everyone this is just a bad link.

[pento]

In 41843:

Login: On the single site login screen, match the logo link text with the title.

Previously, the (W) logo on the single site login screen linked to wordpress.org, with an appropriate title attribute, but the link text was the blog name.

To fix this discrepency, the link text is now the same as the title attribute.

Props pento, obrienlabs, afercia, flixos90, lukecavanagh, and the infinite stack of bikesheds that WordPress is balanced upon.
Fixes #34625.

[pento]

Post commit note: Deprecating filters, changing behaviour, etc should go in a new ticket.

[dlh]

[41843] uses bloginfo() on multisite, which echoes the blog name instead of returning it to $login_header_text. Should it be get_bloginfo()?

[pento]

In 41850:

Login: Swap bloginfo() usage for get_bloginfo().

[41843] introduced a use of bloginfo(), where it should be using get_bloginfo().

Props dlh.
Fixes #34625.

[SergeyBiryukov]

Replying to pento:

Post commit note: Deprecating filters, changing behaviour, etc should go in a new ticket.

Follow-up: #42537