Accessibility issue with the logo on the login page

[roytanck]

Currently, the login page (wp-login.php) contains a logo, that is created using the following HTML markup:

<h1><a href="https://wordpress.org/">Powered by WordPress</a></h1>

Both the href URL and the link text can be filtered. Through CSS, the link text is placed off-screen, and a logo is added to the link as a background.

The <h1> is required for proper a11y, but it should contain the title for the page below. Something like "Log in" would probably be ideal. Instead, it currently contains a link that takes the user off the page, with no description of the login page's content.

This is causing serious issues for client who are required to conform to WCAG standards, as required by European law.

I'd like to suggested removing the <h1> from around the logo link, and adding an actual <h1> title to the white box below, with relevant textual content.

[roytanck]

Quick mockup of a login page containing a proper title.

[roytanck]

To clarify, the issue can not be resolved using the relevant filter hooks, because the overall HTML structure is hardcoded.

<h1><a href="[filterable URL]">[filterable link text]</a></h1>

Whatever you put into the two filterable elements, it will always be an <h1> with (nothing but) a <a> in it. The two elements need to be separated to make the page properly accessible.

• For a11y, the <h1> should contain (just) the page's title
• The <a> can link to wp.org (or to any other place through filters), but must not be an <h1>

This will require a bit of tinkering with the page's markup and styling, and will introduce a new translation string. And perhaps a new filter for the title text.

[SergeyBiryukov]

Related: #34625, #42537.

[joedolson]

Hi, @roytanck! Can you provide a citation for why there's a problem with having a link be the content of the site's H1 heading?

In general, I'd be happy if the logo/link used the site's logo & linked to the site home page if the site's title and logo are set; but I'm not aware of any arguments that it isn't acceptable to have a link inside an H1 element. The H1 should illustrate the primary subject of the page; but having a link within that H1 is not an issue that I'm aware of.

As a note, the primary subject of this page is already fairly clear, particularly given that the entire content of the page consists of a couple of form fields and a couple of links. The topic is made clear in numerous ways, and the H1 is not particularly crucial to understand the purpose of the document.

That said, I think that the clarity could be improved if the primary branding of the screen was associated with the site, rather than with WordPress, and that WordPress was secondary branding.

[roytanck]

Hi @joedolson. Thank you for looking into this. The problem isn't with the HTML markup as such. It's perfectly fine to have an <a> inside an <h1>. The issue is with the purpose of the <h1>.

​https://fae.disability.illinois.edu/rulesets/HEADING_1/

The <h1> should contain an indication of the contents of the current page. A link to another location (whether it's wp.org or the site's home page) is not a description or title for what's found on the current page.

To people using assistive technologies, the purpose of the page is less immediately obvious. They often rely on headings to navigate the page, and don't immediately "see" the form below it.

It's great that WordPress offers filters for the link's href and text, but they can only be used to modify the link. The link text should always describe the link's target (a different page), so in no case will it describe the current page's contents.

This issue came up during an accessibility audit of a client's site (a large government organization in NL). The a11y expert and I concluded that there was no way to fix it using the hooks that WP currently offers. The <h1> and the <a> serve different purposes, and the best option is to split them into two entities. A credit link for WP, and a proper page title.

[ryokuhi]

The ticket was discussed today during the accessibility team's weekly bug-scrub.
The team agrees that there are some aspects of the login page to improve, so the ticket will be considered for one of the next releases.
The main topic argument against changing the h1 is that it might impact backward compatibility, so some more exploration should be done.

[sabernhardt]

Backward compatibility is not really an obstacle to this change, but it could present some challenges with multiple existing filters and custom CSS.
I've used a ​custom stylesheet and some of the filters.

Supporting custom CSS (that's already implemented) is not as difficult I had thought with the replaceable background image and text clipping. Anyone who has replaced the logo with a logo of different dimensions probably edited the .login h1 a image and/or size without modifying the h1. It would be good to add a class to the H1 tag to facilitate any overrides, though, for plugins that continue to support older WordPress versions.

Some other considerations:

1. The wp-login.php file is also used for registration and password-changing forms.
2. The Powered by WordPress message could be moved to the bottom, with site branding at the top.

[sabernhardt]

@roytanck Until there's a better option, I recommend using these two filters and replacing the logo image with CSS.

function sab_login_logo_url() {
        return home_url( '/' );
}
add_filter( 'login_headerurl', 'sab_login_logo_url' );

function sab_login_logo_text() {
        return get_bloginfo( 'name' );
}
add_filter( 'login_headertext', 'sab_login_logo_text' );

The Site Title would fit as link text for a link to the home page, and it would work well enough as a heading.

[roytanck]

Replying to sabernhardt:

Until there's a better option, I recommend using these two filters and replacing the logo image with CSS.
...
The Site Title would fit as link text for a link to the home page, and it would work well enough as a heading.

Thank you. This is almost exactly what we're currently using.

As for backwards compatibility, I'd assume that at least some plugins/tweaks that style the login screen will have the h1 as part of CSS selectors. So for some 3rd party code, styling could break. Adding more specific CSS classes seems like a good idea.