Make WordPress Core

Opened 7 months ago

Last modified 2 months ago

#47682 new defect (bug)

The links "hover" color has insufficient color contrast

Reported by: afercia Owned by:
Milestone: 5.4 Priority: normal
Severity: normal Version:
Component: Administration Keywords: wpcampus-report color-contrast has-screenshots needs-design
Focuses: ui, accessibility Cc:
PR Number:


Supersedes #35622 and #47157.

During the contributor day at WCEU 2019, it was proposed to merge #35622 and #47157. They're strictly related and the root issue needs to be tackled holistically across the whole WordPress admin.


Default links (and "button-links") in WordPress are blue. The ones for destructive actions are red.

Generally, the default colors for their normal state do have a sufficient color contrast ratio of 4.5:1 with the background. However, the colors used for the "hover" (and "active") state don't.

Relevant standard

W3C Web Content Accessibility Guidelines (WCAG) 1.4.3 Contrast (Minimum) (Level AA)


#35622 dived into the red links issue and after some exploration it became clear that finding a color pair (one color for the normal state and one for the hover/active state) that always works across the admin, is nearly impossible given the several, different, background colors used in the admin pages.

Part of the problem is that the hover color is "lighter" than the default one. Worth noting the color used for the "focus" state is darker instead.

More importantly, there are several different background colors, including an arguable amount of grey shades.

Trying to summarise the reason why #35622 didn't progress:

  • darkening the "hover" red forced to darken also the default red
  • once a new color pair was identified, it worked well on some backgrounds
  • however, it didn't work on other darker backgrounds
  • started from scratch and further darkened the color pair
  • it worked on more backgrounds
  • found edge cases
  • darkened the color pair again
  • at some point the normal red was so dark to look almost "brownish"
  • failure

The same problem applies to the blue links, as reported in the WPCampus accessibility report. See #47157.

Some examples

The "hover" blue #00a0d2:
3.02 contrast ratio on white background
2.67 contrast ratio on the admin default grey background #f1f1f1
2.87 contrast ratio on the tables zebra-stripe grey #f9f9f9

The "hover" red #dc3232:
4.62 contrast ratio on white background (which is OK)
4:39 contrast ratio on the tables zebra-stripe grey #f9f9f9
4.09 contrast ratio on the default grey #f1f1f1
4.16 contrast ratio on media views grey #f3f3f3
3.98 contrast ratio on customizer grey #eee

Note: these are just a few examples. There are more background colors to take into consideration and also edge cases, e.g. the yellow background for unapproved comments.

Some screenshots








Questions and possible options

  • Does the hover state needs to be communicated with a color change in the first place?
  • If so, does the hover color needs to be "lighter"? Using the darker color already used for the "focus" state may help. Generally, the color used for the hover state shouldn't be "lighter", as that reduces contrast right in the moment when users need it the most.
  • Are there better ways other than a color change? For example: toggling the link underline, or using a border, or an additional shape, would allow to use just one color and greatly simplify things.

Background colors

Background colors are an important part of this problem. I do realise design considerations led to use different background colors in different parts of the WordPress admin. For example, the media views and the customizer made some autonomous design choices for their background colors. There are historical reasons for that. However, this led over time to a great inconsistency across the admin.

For the greater good of maintenance, consistency, and simplification, I'd strongly suggest to start by exploring a way to drastically standardise the shades of grey used as background in WordPress. Ideally, there shouldn't be more than 3-4 shades of "light" grey used for the background. Some work in this regard was done in #35783 but there's still a lot of work to be done.

According to the WordPress accessibility coding standards:

When links can be identified as such by the context, for example because they're part of a menu, or a set of links clearly identified as user interface controls, they don't necessarily need to be underlined. In all the other cases, especially for links surrounded by other text (in a line or block of text), links need to be always underlined.

Change History (12)

#1 @afercia
7 months ago

Note: Props inherited from the superseded tickets: nrqsnchz, ronakganatra

Last edited 7 months ago by afercia (previous) (diff)

#2 @afercia
7 months ago

#47157 was marked as a duplicate.

This ticket was mentioned in Slack in #design by afercia. View the logs.

7 months ago

#4 @afercia
7 months ago

Related: #40633.

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.

6 months ago

This ticket was mentioned in Slack in #accessibility by audrasjb. View the logs.

6 months ago

#7 @audrasjb
6 months ago

  • Milestone changed from Awaiting Review to Future Release

As per today's accessibility team bug scrub, let's move this one to Future release.
Would be a good candidate for 5.4. That would be nice to handle it early, since it will need design, accessibility and css code :)

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.

4 months ago

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.

3 months ago

#10 @afercia
3 months ago

  • Milestone changed from Future Release to 5.3.1

Discussed during today's accessibility bug-scrub: agreed that fixing only the hover color could be a quick improvement for 5.3.1. It's just a color change, for example the hover color could use the same color used for focus. Further improvements to the links default styling should be explored in a separate ticket.

This ticket was mentioned in Slack in #core by audrasjb. View the logs.

2 months ago

#12 @audrasjb
2 months ago

  • Milestone changed from 5.3.1 to 5.4

As per today's bug scrub, we found this ticket doesn't fit very well to a rapid release cycle like 5.3.1 as it's not a regression from 5.3. Moving it to next major.

Note: See TracTickets for help on using tickets.