WordPress.org

Make WordPress Core

Opened 13 months ago

Closed 12 months ago

Last modified 8 months ago

#37527 closed defect (bug) (fixed)

Customizer: Links within text should be underlined

Reported by: afercia Owned by: afercia
Milestone: 4.7 Priority: normal
Severity: normal Version:
Component: Customize Keywords: has-screenshots has-patch
Focuses: ui, accessibility Cc:

Description

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:

https://cldup.com/8v9f_eqn7O.png

https://cldup.com/qivIcGfwZA.png

Attachments (4)

custom-themes.jpg (20.3 KB) - added by Presskopp 13 months ago.
button.jpg (26.8 KB) - added by Presskopp 13 months ago.
37527.diff (367 bytes) - added by Presskopp 13 months ago.
37527.2.diff (402 bytes) - added by afercia 12 months ago.

Download all attachments as: .zip

Change History (19)

#1 @karmatosed
13 months ago

  • Owner set to karmatosed
  • Status changed from new to reviewing

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

#2 @karmatosed
13 months ago

  • Owner karmatosed deleted

#3 @Presskopp
13 months ago

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

#4 @afercia
13 months ago

@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:

https://cldup.com/WWHWuKEC7f.png

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
13 months ago

#5 @Presskopp
13 months ago

About the screenshots:

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

Last edited 13 months ago by Presskopp (previous) (diff)

@Presskopp
13 months ago

#6 @Presskopp
13 months ago

Patch added, without touching the theme-css

If we want this also, we would delete this

.theme-overlay .theme-author a {
        text-decoration: none;
}

from \wp-admin\css\themes.css

Last edited 13 months ago by Presskopp (previous) (diff)

#7 follow-up: @celloexpressions
13 months ago

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.

#8 in reply to: ↑ 7 @afercia
13 months ago

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 :)

#9 @Presskopp
12 months ago

  • Keywords has-patch added; needs-patch removed

related #37529

Last edited 12 months ago by Presskopp (previous) (diff)

@afercia
12 months ago

#10 @afercia
12 months ago

  • Milestone changed from Future Release to 4.7

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:
https://cldup.com/kQ-evX_GDz.png

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?

#11 follow-up: @celloexpressions
12 months ago

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.

#12 @afercia
12 months ago

  • Owner set to afercia
  • Resolution set to fixed
  • Status changed from reviewing to closed

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.

#13 in reply to: ↑ 11 @afercia
12 months ago

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.

#14 @westonruter
8 months ago

In 39677:

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

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

#15 @dd32
8 months ago

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.

Note: See TracTickets for help on using tickets.