Opened 5 months ago
Closed 2 months ago
#65075 closed enhancement (fixed)
Links on wp-login.php are not identifiable
| Reported by: | dcavins | Owned by: | joedolson |
|---|---|---|---|
| Priority: | normal | Milestone: | 7.1 |
| Component: | Login and Registration | Version: | |
| Severity: | normal | Keywords: | has-screenshots has-patch commit |
| Cc: | Focuses: | accessibility |
Description
Accessibility scanning tools are pointing out that the links on a vanilla WordPress installation's wp-login screen are not identifiable. They are text-colored and the default text-underline has been nulled:
.login #nav a, .login #backtoblog a {
text-decoration: none;
color: #50575e;
}
On WP.org, specific login styles have been added to address this accessibility concern:
text-decoration: underline !important;
I propose that the property text-decoration: none; simply be removed from login.css for improved accessibility standards compliance.
Thanks!
Attachments (2)
Change History (17)
#2
@
5 months ago
Hi, I’d like to work on this ticket. Removing text-decoration: none; from login.css seems reasonable for accessibility. Happy to prepare a patch—any feedback before I proceed?
#3
@
5 months ago
- Keywords has-screenshots added
Thanks @audrasjb for sharing that perspective. I agree that it is not necessary to unthinkingly follow every suggestion a third-party accessibility tool (bot) comes up with. I can see it both ways in this case. Middle gray text does not look particularly interactive to me, but realize that I had familiarity with the internet before the Google Material interface deemphasized the cues of interactivity. So while I personally realize that those items are links, I can imagine that there is a body of users out there who don't immediately realize that they are.
Thanks @khushdoms for the offer, and feel free to submit the patch, but it's probably best to hold off until a decision has been made as to whether this is a worthwhile change to make.
I'll add an image showing the standard version and a customized version for easy comparison.
Thanks for your feedback!
@
5 months ago
A pair of screenshots showing a standard login screen with undecorated links and a customized login screen with underlined links.
#4
@
5 months ago
Hi, I’ve attached a patch for this ticket.
This patch updates the login.css file to improve link visibility and accessibility by adjusting the text-decoration property. Tested locally on wp-login.php and verified that links are more clearly identifiable.
Feedback welcome.
#5
@
5 months ago
Thanks for the feedback!
You make a good point about these links being identifiable through their context and placement. I agree that they behave more like navigation elements rather than inline text links.
My initial thought was based on accessibility scanning tools, which flagged the lack of underline as a potential issue. However, considering real user experience, the links may still be sufficiently distinguishable.
Perhaps a middle-ground approach could be to improve visibility on hover/focus states instead of enforcing underline by default.
Happy to explore this further or prepare a patch based on the preferred direction.
#6
@
5 months ago
I'm personally in favor of underlining the links. While I agree with the overall sense that it is not strictly necessary, as the links operate more as navigation than as body content, it is still a useful cue that can help with understanding.
This ticket was mentioned in Slack in #accessibility by joedolson. View the logs.
3 months ago
#9
@
3 months ago
- Keywords needs-patch added; 2nd-opinion removed
Following discussion in the accessibility team bug scrub, we're agreed that this will meaningfully improve the accessibility and usability of the login screen, though it is not strictly required by WCAG standards.
This ticket was mentioned in PR #12154 on WordPress/wordpress-develop by @khokansardar.
3 months ago
#10
- Keywords has-patch added; needs-patch removed
Restores the default underline on the navigation and "Back to" links on wp-login.php so they are clearly identifiable as links.
What the problem was:
- The
.login #nav a, .login #backtoblog arule in login.css settext-decoration: none, leaving the links with only a muted gray color. - Accessibility scanning tools flagged the links as not identifiable, and the accessibility team agreed this hurts usability.
What the fix does:
- Removes the single
text-decoration: none;declaration from that rule, letting the browser-default underline apply.
Approach and why:
- The generic
arules on the login screen set no text-decoration, so this one declaration was the only thing suppressing the underline. Removing it is the smallest change that achieves the agreed outcome. - No
!importantis needed — WordPress.org used it only to override core from a separate stylesheet; here the source ofnoneis removed directly. - The link color and hover/focus styles are intentionally left unchanged.
Trac ticket: https://core.trac.wordpress.org/ticket/65075
## Use of AI Tools
N/A
#11
@
3 months ago
I agree making these links underlined is an improvement.
As @dcavins pointed out, all these links are already underlined on .org. See this change that was made 10 years ago https://meta.trac.wordpress.org/changeset/2492
The linked PR looks good to me. Links should be tested on the various login / lostpassword/ register pages.
It is worth noting that once this is merged, the CSS for .org could be simplified.
#12
@
2 months ago
I posted screenshots on the PR, and I would like to consider positioning the underline beneath characters.
a { text-underline-position: under; }
![(please configure the [header_logo] section in trac.ini)](/chrome/site/your_project_logo.png)
Hello and thanks for opening this ticket.
I'm not opposed to underline these links. But in my opinion, these links are in fact quite identifiable as they are not part of a paragraph of text, they are just like navigation items, separated from the rest of the interface. The standard doesn't enforce underlined text for navigation links as the links located in a menu are identifiable by their context. I personally feel like it's pretty the same for these links.
Outside of the scanning tool result, what do you think?