Customizer: Links within text should be underlined

[afercia]

In the Customizer, there are a few places (probably very few) where links within lines/block of text are not underlined. For accessibility, they can't rely on color alone since in absence of color they can't be distinguished from the surrounding text. Couple examples:

[karmatosed]

+1 to adding an underline in these cases. It's always better to be clear what is a link or not.

[Presskopp]

I'd say this could be archived by

.wp-full-overlay-sidebar-content a {
    text-decoration: underline !important;
}

but I don't like the !important

[afercia]

@Presskopp yep you're right !important should be avoided at all costs :) Wondering what happens when entirely removing this rule:

#customize-controls a {
	text-decoration: none;
}

how many other links are used in the Customizer that could be affected by this? The "X" close button on the top left would be easy to fix. Also, this would fix the missing underline in other places too for example the Remove/Close widget links:

It would probably need a bit of testing but I think this could be the best option: just invert the approach and always keep links underlined and reset the underline in the few cases where it's needed? /cc @celloexpressions

[Presskopp]

About the screenshots:

1) Should the theme-author be underlined, too?
2) This is a button, no ordinary link (for information)

[Presskopp]

Patch added, without touching the theme-css

[celloexpressions]

We should avoid making any <button>s that look like links look more like links. Instead, I think we need to come up with a standardized ternary button style to be used for thinks like the widget close and remove links. These are lower in hierarchy than the secondary buttons near them because the only primary button in the customizer is save & publish. This style may look similar to a link, but I'd like to avoid underlines if possible so that they aren't confused with actual links. Note that there is a link within the menu item control that should be styled like a link (this navigates the preview to the linked URL).

External links (which absolutely must open in a new tab in the customizer, and can have visual and screen reader indications of that behavior) should look like links, with underlines (including the author links). Internal links that link to another section (such as widget area) should probably also look like link, with underlines, especially in the context of a larger piece of text such as a description. However, I'm not convinced that navigating to other parts of the customizer is a "linking" action, and buttons are probably a more semantic option here where appropriate. We should get some UX feedback on whether in-customizer navigation is better described by buttons or links before making a final decision.

[afercia]

Replying to celloexpressions:

We should avoid making any <button>s that look like links look more like links

I agree, and I'm not entirely convinced they should look like links at all.

Instead, I think we need to come up with a standardized ternary button style to be used for thinks like the widget close and remove links.

I kindly disagree. Until they're <a> elements, they should look like links. If agreed they behave more like buttons then it would be more appropriate to mark them up as <button> elements, this also applies to other places in the Customizer where UI controls still use a not ideal markup and in some cases still use things like <span> elements.

However, this ticket is mainly about links within lines or block of text, no one wants to change the "Reorder" button :) Let's stick to the original scope of the ticket :)

[Presskopp]

related #37529

[afercia]

Refreshed patch with a minimal, and reversed approach. Still thinking the best option would be keeping the <a> elements underlined by default, and then override the style case by case. That's because many of these links that are not real links should be changed in buttons sooner or later. Haven't touched the widget action links.

Note that there is a link within the menu item control that should be styled like a link

Should be OK now, see the "original" link below:

Worth noting there are still some small inconsistencies here and there. For example, the "Delete Menu" button-link is underlined while the "Remove" menu item button-link is not underlined. Not sure why, would be nice to review them.
@celloexpressions do you feel this is a viable approach?

[celloexpressions]

I think this makes sense, and since the patch is simple, I'm fine with 37527.2.diff​ being committed and then leaving the ticket open for a few weeks to track any issues that come up.

The remove/delete buttons should not be underlined since they aren't links; however, the decision was made to explicitly underline the delete menu button at one point. We can continue working toward consistency here as we notice issues.

[afercia]

In 38503:

Accessibility: Make links in the Customizer underlined by default.

Links within lines or blocks of text should always be underlined since they can't
rely on color alone to be distinguished from the surrounding text. Exceptions
can be handled on a case-by-case basis.

Props Presskopp for the initial patch.
Fixes #37527.

[afercia]

Replying to celloexpressions:

and then leaving the ticket open for a few weeks to track any issues that come up.

Conversation can continue on closed tickets :) feel free to reopen at any time if you notice issues to address.

[westonruter]

In 39677:

Customize: Prevent removal of underline upon hover/focus for nav menu deletion links.

Props monikarao.
Amends [38503].
See #37527.
Fixes #39444.

[dd32]

In 39696:

Customize: Prevent removal of underline upon hover/focus for nav menu deletion links.

Props monikarao.
Amends [38503].
See #37527.
Merges [39677] to the 4.7 branch.
Fixes #39444.