Admin color schemes: improve contrast to make sidebar compatible with Gutenberg editor chrome

[fushar]

We want the block editor and Site Editor to follow the user's admin color scheme (see ​https://github.com/WordPress/gutenberg/pull/78397). With that, the editor chrome will use the color scheme, instead of being always black. However, as also discussed in the linked PR, this has a few problems with the current color schemes:

1. The editor chrome's background color is generated from a seed, through the WPDS ramp algorithm buildBgRamp()(​https://github.com/WordPress/gutenberg/blob/35487a041c6569399988a96d5956b92cd3da0a71/packages/theme/src/color-ramps/index.ts#L18). This function emits surface colors within a specific luminance bands, and cannot reproduce arbitrary colors. Most of the current scheme sidebars are outside the bands, so the editor chrome will NEVER match them regardless of the seed.
2. The primary button may appear in the editor chrome, e.g. as Review X changes... button. So, the background color should be distinct enough from the sidebar. Currently several schemes have similar colors (e.g. the purple Ectoplasm).

Proposed change

Update the admin color schemes so that they:

• Use sidebar colors that the editor's ramp can reproduce, so the editor chrome can match the wp-admin sidebar
• Use primary button colors that are distinct from the sidebar colors.
• While doing that, improve the contrast for better legibility.

Trac ticket: https://core.trac.wordpress.org/ticket/65382

## Summary

The block editor and Site Editor are moving toward applying the user's admin color scheme (see ​https://github.com/WordPress/gutenberg/pull/78397). With that, the editor chrome will use the color scheme, instead of being always black. However, as also discussed in the linked PR, this has a few problems with the current color schemes:

1. The editor chrome's background color is generated from a seed, through the WPDS ramp algorithm (​buildBgRamp()). This function emits surface colors within a specific luminance bands, and cannot reproduce arbitrary colors. Most of the current scheme sidebars are outside the bands, so the editor chrome will NEVER match them regardless of the seed.
2. The primary button may appear in the editor chrome, e.g. as Review X changes... button. So, the background color should be distinct enough from the sidebar. Currently several schemes have similar colors (e.g. the purple Ectoplasm).

This PR updates the core admin color schemes to satisfy both, while maintaining each scheme's characteristics.

Several notes:

• With this PR I also try to reduce the number of distinct colors in each scheme. Except for the Light scheme, the primary button's background color is made equal to the currently selected sidebar menu's background color. This simplifies the color schemes.
• I believe some color schemes currently being low-contrast is expected. However, the buildBgRamp() function CANNOT produce low-contrast colors. So, for each such schemes (like Coffee, Ocean) I tried to produce the color with the lowest contrast possible while still being similar to the original color.
• This PR: ​https://github.com/WordPress/gutenberg/pull/23048 changed the primary button color to be the sidebar color, for several schemes (such as Ectoplasm). This PR reverts that behavior due to the reason mentioned before.

[!WARNING]
The ​linked Gutenberg PR must also be backported, because the primary colors are also being updated in base-styles.

### Sidebar contrast (white/black text vs sidebar background)

And whether they pass WCAG 2.x AA (it requires > 4.5:1 for normal text)

Scheme	Before	After
Modern	16.67 ✅	*unchanged*
Fresh	15.89 ✅	*unchanged*
Light	10.03 ✅	10.03 ✅
Blue	2.58 ❌	8.23 ✅
Coffee	7.68 ✅	8.19 ✅
Ectoplasm	9.17 ✅	10.67 ✅
Midnight	11.33 ✅	11.26 ✅
Ocean	3.48 ❌	8.21 ✅
Sunrise	4.48 ❌	8.21 ✅

### Primary button contrast (white text vs button background)

Note that except for Light scheme, this primary button background color is now equal to that of the currently selected menu item.

Scheme	Before	After
Modern	5.61 ✅	*unchanged*
Fresh	5.17 ✅	*unchanged*
Light	4.15 ❌	4.57 ✅
Blue	6.63 ✅	4.58 ✅
Coffee	10.2 ✅	4.96 ✅
Ectoplasm	9.17 ✅	5.59 ✅
Midnight	3.93 ❌	4.65 ✅
Ocean	4.44 ❌	4.92 ✅
Sunrise	2.86 ❌	4.58 ✅

### Screenshots

Before	After
Blue<br>	Blue<br>
Coffee<br>	Coffee<br>
Ectoplasm<br>	Ectoplasm<br>
Light<br>	Light<br>
Midnight<br>	Midnight<br>
Ocean<br>	Ocean<br>
Sunrise<br>	Sunrise<br>

## Use of AI Tools

AI assistance: Yes
Tool(s): Claude Code
Model(s): Opus 4.7-4.8
Used for: iterating the color gradients

I didn't test yet but adding a note to test non-site-editor pages built with WP Build; Fonts, Connectors, etc.
Similarly also plugins building pages with WP Build; a good check would be core AI plugin's settings page.

I didn't test yet but adding a note to test non-site-editor pages built with WP Build

Yep, this is addressed in the Gutenberg PR ​https://github.com/WordPress/gutenberg/pull/78397. Together with that PR, this PR even fixes an existing bug with "disconnected" black chrome surrounding such pages. Copying here for easy reference:

Appearance -> Fonts

(see the gutter/border at bottom-left)

Before	After

Checking with .org designers about whether this match the desired direction cc @jameskoster @jasmussen

Thanks for the pings, appreciate it. My feedback from the reviews I gave in ​https://github.com/WordPress/gutenberg/pull/78397 stands: ALL core color schemes deserve near total re-invention, but that is not a near-term goal, and this is a solid step in the right direction.

Looking at the screenshots, personally the new adapted colors look easier on my eye, so probably slightly better in terms of a11y but would love other opinions here.

[youknowriad]

In 62454:

Administration: Improve admin color scheme contrast for the editor chrome.

Update the core admin color schemes so their sidebar and primary button colors
work well when the block editor and Site Editor apply the user's admin color
scheme to the editor chrome. The chrome background is generated from a seed
through the WPDS ramp algorithm, which only emits surface colors within
specific luminance bands and cannot reproduce arbitrary colors, so several
schemes could never match.

Adjust the Blue, Coffee, Ectoplasm, Light, Midnight, Ocean, and Sunrise schemes
to bring sidebar and primary button text contrast to WCAG 2.x AA (4.5:1), keep
each scheme's character, and reduce the number of distinct colors per scheme by
reusing the selected menu item's background for the primary button (except for
Light).

Props fushar, simison, youknowriad, joen.
Fixes #65382.

[joedolson]

I'd definitely agree that this is generally an accessibility improvement; it may not bring all the themes fully up to WCAG expectations, but that's not necessary in order for them to be an improvement!

[needle]

I really like the new admin colour schemes, but please can the colours be defined as CSS variables for those of us who develop UIs in WordPress admin?

The introduction of e.g. --wp-admin-theme-color has been a fantastic time-saver but keeping track of new hard-coded colour schemes on a per-WordPress-version basis is time-consuming and avoidable.

[youknowriad]

The CSS variables update is going to happen on the next Gutenberg update on Core after the related Gutenberg PR lands (See ​https://github.com/WordPress/gutenberg/pull/78397). So there's a small period in trunk where the CSS variable is indeed not in sync but it should be solved soon.

[needle]

@youknowriad Ah that's good to know, thank you.

Trac ticket: https://core.trac.wordpress.org/ticket/65382

This PR bumps the bundled Gutenberg to commit d18be22, which contains ​https://github.com/WordPress/gutenberg/pull/78397.

This is necessary to backport the ​updated --wp-admin-theme-color colors, so that the admin bar, sidebar, and primary button background all have the same color. See the linked Trac issue for more details.

The rest of the changes are generated, via npm run gutenberg:download.

## Screenshot

(See the bottom-right button and the bottom-right gutter/chrome color)

Before	After

## Use of AI Tools

AI assistance: Yes
Tool(s): Claude Code
Model(s): Fable
Used for: Updating the SHA and running the download script .

[fushar]

^{That should bring the color tokens (like --wp-admin-theme-color) back in sync. @youknowriad / other core committers, please check :)}

Hi @adamsilverstein , I noticed that you have a similarly open PR here: ​https://github.com/WordPress/wordpress-develop/pull/12009.

My PR here is pinning to a hash that's seemingly newer to yours. I believe my hash already contains React 19 revert (​https://github.com/WordPress/gutenberg/pull/78940), so I believe it's safe.

Can you help confirm? Should we just use this new PR instead of yours? Thanks!

@fushar fine to use yours instead of mine. I'll close my PR. We weren't able to merge due to the modified files that weren't meant for trunk.

@adamsilverstein Thanks for the reply. But I can't seem to find the linked PR that you mentioned :)

Also could you confirm that I did the right thing here? I.e. update the hash and run npm run gutenberg:download?

Apologies for the cryptic reply, I'm replying from my phone. The pr I was talking about is ​https://github.com/WordPress/gutenberg/pull/76715 and it looks like it was merged.

[needle]

Replying to youknowriad:

The CSS variables update is going to happen on the next Gutenberg update on Core after the related Gutenberg PR lands (See ​https://github.com/WordPress/gutenberg/pull/78397). So there's a small period in trunk where the CSS variable is indeed not in sync but it should be solved soon.

So maybe I'm not understanding something here.

Given the comprehensive screenshots of the new colours being applied to the WordPress admin menu and left-hand menu, I thought that these PRs would introduce CSS variables for those colours - but they still ​seem to be hardcoded in the respective colors.css files.

So given that I can style buttons etc in my backend forms using --wp-admin-theme-color, it is not possible for there to be equivalents for menus, e.g. --wp-admin-menu-bg-color and so on?

Hi @adamsilverstein, since you already have context, could you help land this PR? I am not a Core committer myself. Also looks like there's failing checks, but I'm not sure if those are real errors or flay ones. I can't restart the jobs myself 😄

Sure, let me double check to make sure the build process is in a good place for this update and bring the SHA closer to gb trunk.

👋 Just wanted to jump in and note that after r62525 the build script is in a better place and all files should be updated as expected (especially deleted ones).

I noticed that chosen commit corresponds to the most recent Gutenberg release (23.4.0) which was 2-3 days ago. Now that the bugs related to deleting files has been addressed, I plan on posting on Make Core to bump the Gutenberg hash every other week opposite the Gutenberg plugin releases. That way changes are being synced regularly but allowing a bit of time for any X.Y.Z+1 releases that may be necessary.

This PR bumps the bundled Gutenberg to commit d18be22, which contains ​https://github.com/WordPress/gutenberg/pull/78397.

Since the first plugin release including this fix was 23.4.0, we can update to the latest this time and then move to the every other week cadence.

It seems Core is already on latest Gutenberg. Closing this issue. Thanks for taking core of bringing the latest Gutenberg to Core.

[joedolson]

Re-closing this issue; as far as I can tell, this is fully resolved.