I should have been more specific. It should have been “body text”. We’re talking about paragraphs of text, like a blog post. That’s where underlining or any non-color designator is required by WCAG.
Navigational links, or stand alone links, they need to stand out but they don’t have to be underlined. As WebAIM points out, many people are accustomed to these links not being underlined.
Well, for a login page, this is the main content, body text. You can’t pick apart the WCAG differently for each page.
HTML structure has no relevance on the text/content. For WCAG, structural header, main content, footer has no relevance when it comes to links. Body text refers to the literal body of text, sentences and paragraphs. This is an important distinction to understand success/failure criterion for links.
Those 2 links, forgot password and go back to site, are navigational links. They are not within any text. So they do not require non-color indicator to help color blind users. If they were part of a paragraph, then yes they would need underline to help users identify them as links and not just regular text.
Here’s the failure test for links:
https://www.w3.org/TR/WCAG20-TECHS/F73.html
Note this part, bolding is mine:
While some links may be visually evident from page design and context, such as navigational links, links within text are often visually understood only from their own display attributes. Removing the underline and leaving only the color difference for such links would be a failure because there would be no other visual indication (besides color) that it is a link.
I’m not picking WCAG apart for each page 
I’m applying WCAG guidelines to a T. Location of links matters, within text or stand-alone such as navigation.
I would go as far as saying I don’t think I have ever seen an example of an underlined lost password link.
Indeed it does. So moving links around without looking seriously at the implications for those with diminished sight is clearly a no-no.
I’ve been looking around at some of the login forms that I use. One that stands out and actually has to be fully accessible and even ADA compliant is from the US government. The login.gov SSO service. Screenshot below.
Interestingly, they do have underlined links @ozfiddler
This design actually works well. Even though they left-aligned links, it doesn’t look like it’s about to fall over on one side because the elements and design work well together to create a balanced look.
The large Sign In button (which seems to be popular across many websites) and links being part of the white box make the design balanced. Links in the footer are irrelevant for our discussion.
So, here’s a mock-up of what this might look like in CP inspired by login.gov. 3 different variations, with some minor adjustments. I think this looks clean, well-balanced, and accessible for everyone. I can help implement this. Thoughts?
Edit: Added option 4.
Ah, that’s interesting. Putting the links inside the white box suddenly makes the left-aligned much more sensible.
Any reason you didn’t put all 4 links inside? I’m not sure I see the point of one being left out.
(Oh, and I feel duty bound to point out that it fails the “instantly familiar” test 
)
Agreed. No. 1 (and therefore 2) is great, but let’s have all 4 links in the box.
@ozfiddler @anon95694377 I’ve added option 4 with all links in the white box in my original post. I thought leaving one at the bottom might serve as a footer that ideally the privact policy link would occupy.
I like 4. If you wanted to subtly differentiate the privacy link from the others, you could use a grey horizontal line, same as they have done in the login.gov example (but I don’t think it is necessary).
I think all of these would be fine. Thank you, @viktor and @ozfiddler, for persevering here! Like you both, my preference is for #4: once all the links are underlined and left-justified, they are clearly a list of links.
Not sure why it never occurred to me but I realized just now CP/WP form pages are missing page titles while using H1 for the logo. For accessibility, I’ve created a petition to add page titles to these forms. I included a mock-up under that petition.
This is looking much better to me also.
I am not one to blindly trust the US gov with everything, but in the case of web accessibility they certainly do their homework. I think basing our design on theirs is an acceptable alternative to what I had previously asked for in terms of investigating the history of this screen before making changes.
Let’s make sure that existing hooks to customize the login page keep working reasonably well (it seems like they probably would, since this isn’t a major change).
I had some time, so I’ve done some work on my local fork:
It’s a lot more complex than I thought, but everything seems to be working and nothing is broken. This includes a custom login logo feature. I’ve also included H1 page title from this thread for accessibility. Although it can be removed. Will be doing more testing, especially with translations.
What do you think about blue messages visible in the lost password and registration forms?
For example, many forms include a brief description below the page/form title. Here’s a Google and Amazon examples, and a mockup of what that might look like in CP:
Thoughts? I’m happy to leave it as is but thought I’ll ask.
This is already available in ClassicPress, as far I know.
What do you mean by it? That you added a new feature?
The blue messages are OK IMO, but they need to be filterable (do change them as the developer may like).
Also note that the footer text (go back to X and privacy policy) are part of an action and there might be plugins expecting that to be outside the box. But with the changes I see here, everything is going to be inside the box.
Not sure that is backwards compatible.
All filters and actions are still there. The only unnecessary filter/function I would like to deprecate is login_link_separator, checking about it on GitHub.
I don’t mean it’s gone.
I mean it changed location 
It all looks good to me. I don’t think changing the location is going to break anything because the text is all left-justified.
