Drupal Admin Theme Colors

@KentR I don't think that from an accessibility point of view, an "Increase contrast" button should be needed. Everything should default to WCAG 2.2 AA. So we could (and still may) remove:

Increase contrast Experimental
Increases text and interface contrast while preserving visual hierarchy.

Not that any of this is an overlay, but with CSS an a site-wide setting like this, there is more that could be done to highlight regions, make the content bolder and make the site easier to read.

I think it was initially added there to "meet WCAG" but it didn't work as advertised (at least as I understood it).

I changed the colors in this patch:

Accent color

• Cobalt (Default)
• Cerulean
• Teal
• Emerald
• Olive
• Amber
• Orange
• Vermilion
• Magenta
• Violet
• Neutral
• Custom

Focus color

• Blue (Default)
• Green
• Amber
• Neutral
• Custom

Changes (from AI review of AI code):

Default Admin now resolves more of its color system through semantic tokens that understand Light and Dark mode, instead of placing Light/Dark decisions directly inside individual components.

--admin-color-summary-text
--admin-color-summary-hover-bg
--admin-color-radio-hover
--admin-color-radio-hover-bg

The dark theme also retains several distinct surfaces rather than flattening everything into one background:

main      #1b1b1d
surface   #2a2a2d
nested    #3b3b3f
raised    #47474c
toolbar   #2d3755

The CSS now separates at least three distinct roles:

--admin-color-accent-base
--admin-color-accent-fg
--admin-color-accent-preview

--admin-color-accent-base is intended for fills and primary surfaces.

--admin-color-accent-fg is a foreground-safe version for links and other interactive foreground uses.

The tests explicitly guard that the fill and foreground tokens remain separate and use the same OKLCH color model.

The accent palette has also been redesigned as 10 chromatic choices plus Neutral rather than several closely related shades of the same hue.

The Dark-mode foreground is derived from the selected source accent rather than substituting an unrelated fixed color.

The selected accent remains recognizably the same color family throughout the interface, but it is much less likely to become unreadable.

selected Blue
   ↓
Blue button
Blue link
Blue hover state
Blue active state
Blue picker preview

but each of those is allowed to use the version of Blue appropriate for that role.

In Dark mode, the preview uses the foreground-safe accent instead of displaying the very dark accent fill. The test documentation explicitly describes this distinction and verifies the rendered swatches against their actual settings-page surface. The dark accent fill is intentionally dark because it needs to work behind light text. That made it a poor choice for showing the color in the settings picker: several swatches became difficult to distinguish from the surrounding dark UI.

The fixed focus choices are now independent color families:

The test suite describes this explicitly: focus presets are optimized for visibility rather than brand/accent identity.

Accent-filled controls such as primary buttons and checked controls use a two-part focus treatment. The CSS introduces a separate gap between the component and the outer focus ring:

accent-filled control
        ↓
surface-colored gap
        ↓
focus ring

Meaningful icons are being treated as their own contrast relationship rather than assuming that a text color automatically works for the icon.

Increased contrast

crease contrast no longer means flattening the interface into pure black and white.

The tests explicitly guard against replacing the normal surfaces with #fff or #000, and they preserve distinct text and border levels.

Accent foregrounds remain hue-preserving even when contrast is increased.

The author-controlled Increase contrast mode is also kept separate from forced-colors.

strengthen the contrast relationships while preserving semantic distinctions.

Previously, Dark mode behavior could be scattered across component styles, but now:

source color
    ↓
primitive color system
    ↓
semantic role
    ↓
light-dark()
    ↓
component

For accents:

selected accent
    ↓
--accent-base
    ├── --admin-color-accent-base
    ├── --admin-color-accent-fg
    └── --admin-color-accent-preview

For components:

semantic token
    ↓
Light / Dark resolution
    ↓
component consumes token

Modern CSS features such as light-dark(), relative oklch() colors, and color-mix() allow the theme to express those relationships directly in CSS rather than maintaining independent hard-coded palettes for every mode.

That improves maintainability because a component generally no longer needs to know:

“Am I in Dark mode, and which special color should I use?”

It instead asks:

“What is the semantic color for this role?”

The color system answers the Light/Dark question.

Overall effect

The larger change is therefore not simply “better contrast.”

It is moving Default Admin toward a semantic, mode-aware color system where:

Light, Dark, and Auto use the same underlying design language;
accents retain their identity without being forced to serve incompatible roles;
Dark mode preserves surface hierarchy;
focus is independent from branding/accent choice;
meaningful icons remain visible as controls change state;
increased contrast strengthens relationships without flattening the UI;
components consume semantic tokens instead of accumulating Dark-mode exceptions;
browser-based tests verify the colors users actually see.

That should make Default Admin both more accessible now and substantially easier to maintain as Drupal adds or changes administrative components.