Opened 2 weeks ago
Last modified 2 weeks ago
#8418 new defect (bug)
Multiple buttons on Planet WordPress have incorrect text/background colors and poor contrast
| Reported by: | valani9099 | Owned by: | |
|---|---|---|---|
| Priority: | high | Milestone: | |
| Component: | Planet (planet.wordpress.org) | Keywords: | has-screenshots |
| Cc: |
Description
Multiple buttons across Planet WordPress have an incorrect color combination, resulting in poor text/background contrast and making the button labels difficult to read.
URL:
https://planet.wordpress.org/
Steps to reproduce:
- Visit https://planet.wordpress.org/
- Scroll through the page.
- Observe the buttons throughout the page.
- Notice that multiple buttons use a blue background with blue/dark-blue text, resulting in insufficient contrast.
Button Examples include:
- Read the Letter
- Check out what's new in 7.1
- Other buttons using the same styling
Expected result:
Buttons should have sufficient color contrast between the text and background so that their labels are clearly readable and accessible.
Actual result:
Multiple buttons across the page have insufficient color contrast between the button text and background, making the button labels difficult to read, as shown in the attached screenshots.
This appears to be a site-wide button styling/CSS issue rather than an issue affecting only one button.
Attachments (4)
Change History (7)
This ticket was mentioned in Slack in #meta by valani9099. View the logs.
2 weeks ago
@
2 weeks ago
Same viewport with the patched wp4.css, only the stylesheet changed: white on the button background, 5.61:1
@
2 weeks ago
New hover state after the fix: white on the darker hover background, 7.70:1, matching wordpress.org/download/
#2
@
2 weeks ago
Confirmed, and it is a specificity collision rather than a colour choice. PR: https://github.com/WordPress/wordpress.org/pull/849
Cause
The block theme emits its button colours through global styles:
:root :where( .wp-block-button .wp-block-button__link ) {
background-color: var( --wp--custom--button--color--background );
color: var( --wp--custom--button--color--text );
}
That selector is specificity (0,1,0). Only :root counts, :where() adds nothing.
The link rules in wp4.css are (0,1,1):
a:link,
a { color: #21759b; }
a:visited { color: #4ca6cf; }
a:hover { color: #d54e21; }
So the link colour wins on color while the button keeps its own background-color. The custom property is not broken: --wp--custom--button--color--text resolves to #ffffff. It is simply being overridden.
Measured on the front page:
| State | Text on background | Ratio |
|---|---|---|
| rest | #21759b on #3858e9 | 1.09:1 |
| hover | #d54e21 on #3858e9 | 1.32:1 |
| visited | #4ca6cf on #3858e9 | 2.05:1 |
The orange in the reporter's screenshot is a:hover, not a separate bug.
One detail worth recording. a:hover and a:visited have always been (0,1,1), so those two states have been wrong for a long time. The rest state broke when a:link was added next to a: a bare a is (0,0,1), which loses to the button rule. wp4-rtl.css has not been regenerated since that change, which is why it still has a bare a and why the rest state still looks correct in RTL.
Fix
Guard the three link rules with :where( :not( .wp-element-button ) ). Because :where() contributes zero specificity the selectors stay at exactly (0,1,1) and (0,0,1), so nothing else in the cascade moves and only the match set narrows. It is the same idiom core already uses on these pages, for example :root :where( a:where( :not( .wp-element-button ) ):hover ).
Excluding buttons from a:hover also removes the only hover feedback Planet had, because Planet loads wp4.css and not the parent theme's button stylesheet. So the PR also adds the hover, focus and active states from the button custom properties the wporg parent theme already defines. Pages that do load the parent theme's button stylesheet are unaffected: those rules are [class*="wp-block"] .wp-block-button__link:hover at (0,2,0) and load later.
Result
| State | Before | After |
|---|---|---|
| rest | #21759b on #3858e9, 1.09:1 | #ffffff on #3858e9, 5.61:1
|
| hover | #d54e21 on #3858e9, 1.32:1 | #ffffff on #213fd4, 7.70:1
|
| active | not styled | #ffffff on #1e1e1e, 16.67:1
|
The hover result matches https://wordpress.org/download/, which does not load wp4.css and gets these states from the parent theme.
No regressions found on the Planet front page. 1,335 non-button links keep #21759b and the full link colour census is identical before and after; the search icon button is unchanged at rgb(30, 30, 30); buttons no longer match the link rules and ordinary links still do.
Tested by swapping wp4.css for the patched file at the same position in the cascade, at 1440px and 375px. Screenshots attached: 8418-before.png and 8418-after.png are the same viewport with only the stylesheet changed, and 8418-after-hover.png is the new hover state.
![(please configure the [header_logo] section in trac.ini)](/chrome/site/your_project_logo.png)
Planet front page before the fix: button label is the body link colour on the button background, 1.09:1