@wildmason/aegis 1.14.1 → 1.16.0

package/CHANGELOG.md

@@ -0,0 +1,309 @@
+# Changelog
+
+All notable changes to `@wildmason/aegis` are recorded here, following
+[Keep a Changelog](https://keepachangelog.com/en/1.1.0/) and
+[Semantic Versioning](https://semver.org/spec/v2.0.0.html).
+
+This file was started on 2026-09-01, later than it should have been. Entries
+from 1.8.0 onward are backfilled from the release commits and the project health
+page; both were written at the time, so the entries are sourced rather than
+reconstructed from memory. Anything before 1.8.0 lives in `git log` only, and is
+deliberately not summarised here rather than guessed at.
+
+**Releases 1.12.0 through 1.14.1 carry no git tag.** They were published through
+the GitHub OIDC workflow, which does not tag, so `git tag` skips from `v1.11.0` to
+`v1.15.0`, and the tag names before that are inconsistent (`1.4.4`, `v1.5.1`).
+Version links below are omitted where no tag exists rather than pointed at a URL
+that 404s.
+
+## [Unreleased]
+
+_No unreleased changes._
+
+## [1.16.0] - 2026-09-01
+
+### Added
+
+- `.wm-kbd--on-accent` — the key cap for an accent fill. The base `.wm-kbd` is
+  `--wm-bg-sunken` inside `--wm-border-input`: a recess in a *surface*, and both
+  tokens are wrong the moment the cap sits on `.wm-btn--primary`. The modifier
+  carries no fill of its own, so the cap's label **is** the button's label and
+  inherits the contrast that pair already guarantees; only its edge is new, drawn
+  as `--wm-color-accent-text` at 75% over whatever is behind. Mixing toward
+  `transparent` rather than toward `--wm-color-accent` is what lets one
+  declaration serve the rest fill and the hover fill both.
+- `check:accent-contrast` — measures `.wm-btn--primary`'s label on both of its
+  fills, the new cap's edge on both, and how far the hover fill sits from the rest
+  fill, across every theme. Its destructive twin has had a guard since
+  white-on-danger was caught failing 8 of 12 themes; the accent button is the same
+  shape and had none.
+
+  The separation bar is there because the first pass shipped without one and eight
+  hovers came out invisible: the derivation took the smallest lightness step that
+  cleared contrast, which is a hover nobody can see. It is expressed as a Weber
+  fraction, `|L_hover - L_rest| / L_rest >= 0.14`, because an ABSOLUTE distance
+  cannot separate the accepted values from the rejected ones at any threshold —
+  sorted by OKLab distance an accepted theme sits below a rejected one. Normalised
+  by the rest fill's own lightness they separate cleanly, and 0.14 is the low end
+  of the band occupied by the three hovers this repo already shipped and nobody
+  ever complained about.
+
+### Fixed
+
+- **`.wm-btn--primary:hover` failed WCAG AA on warm-light: white on
+  `--wm-color-accent-hover` `#2aa198` measured 3.16:1.** The cause was
+  structural rather than one bad value. On five themes the hover was the
+  palette's *second accent* rather than a lighter or darker step of the first
+  — Solarized cyan behind Solarized blue, Dracula pink behind Dracula purple,
+  Monokai orange behind Monokai magenta. A hue jump promises nothing about the
+  label riding on it, so the label's contrast was whatever the two palette
+  entries happened to be, and on hover it also missed APCA Lc 60 on nine themes,
+  as low as Lc 28.7. Nine hover values are now the accent's own hue and chroma at
+  a different OKLCh lightness, moved *away* from the label, far enough to clear the
+  separation bar as well as the contrast bars. Where sRGB cannot hold the accent's
+  chroma at the higher lightness — vampires-kiss and twilight-peach — the colour
+  is gamut mapped with hue and lightness held and chroma reduced, rather than
+  clamped per channel, which shifts hue.
+- `--wm-color-accent-text` on arctic-night, vampires-kiss and twilight-peach was
+  short of APCA Lc 60 on the rest fill by 0.1, 0.3 and 1.4. Each moved a little
+  further from its fill in OKLCh lightness — hue and chroma held, two of the
+  three by under five values out of 255.
+- `DESIGN_LANGUAGE.md` §13 claimed `.wm-kbd` was "used identically in Helm
+  (command palette) and Slate (sidebar search button)". Neither consumer used it
+  at all. Helm draws seven key badges from five component-local rules; Slate draws
+  none. `check:docs` gates class *existence* in both directions and cannot see a
+  false claim about who uses one, so this was found by looking.
+
+### Known limitation
+
+- **Four accents cannot reach APCA Lc 60 with any label, and are pinned rather
+  than repaired. All four clear WCAG on both fills** — WCAG is the bar this
+  package ships to and no theme is exempt from it; APCA Lc 60 is the bar it
+  reaches for, enforced the same way because a bar nothing enforces decays. A
+  pinned theme is behind an aspiration, not broken. Pure white and pure black bracket every achievable Lc, and on
+  posh-sandalwood (`#f92672`, best 40.7 dark / 68.8 white — but white measures
+  3.79:1 and fails WCAG outright), source-control-dark (`#3fb950`, 54.6),
+  crepuscular-sky (`#c09d06`, 55.7) and wildmason (`#82a682`, 57.8), neither end
+  reaches it. Clearing the bar means changing the accent itself, which is each
+  theme's brand colour. The shortfalls are recorded to one decimal in
+  `check-accent-contrast.mjs`, which fails if one drifts in either direction.
+
+## [1.15.0] - 2026-09-01
+
+### Added
+
+- `.wm-input--error` — the invalid state for `.wm-input` and `.wm-input-group`.
+  It was documented in prose and in a live demo on the inputs guide page and had
+  never existed, so the demo captioned "error state" rendered a field identical
+  to a valid one. It fills with `--wm-color-danger-bg` and rims with
+  `--wm-color-danger-border`, the same tokens as the `.wm-error-msg` block below
+  the field, and yields to `:focus` so an accent border is never fighting a red
+  one while the user is fixing the field. Pair it with `.wm-error-msg` and
+  `aria-invalid="true"`: colour must not be the only signal.
+- `scripts/check-design-language.mjs`, wired into `npm run build` as
+  `check:docs`. It holds all 32 agent-visible documents — `DESIGN_LANGUAGE.md`
+  plus the guide pages in `mcp/guide-index.json` — to the CSS this package
+  actually ships, in both directions: a name no CSS defines, and a shipped
+  `.wm-*` class no document mentions.
+
+### Changed
+
+- `check:semantic-contrast` measures a fourth recipe and a fourth surface. The
+  new pair is `--wm-text-primary` on the danger tint, which is what
+  `.wm-input--error` paints and which no bar covered, because every other status
+  recipe reads `--wm-color-<tone>-readable` on the tint. `bg-sunken` joins the
+  surface sweep, since both `.wm-input:hover` and `.wm-input-group:hover` fill
+  with it. 144 combinations became 192; all pass.
+
+### Fixed
+
+- `DESIGN_LANGUAGE.md` had never been migrated through the background-token
+  rename. It prescribed `--wm-bg-inset`, `--wm-bg-canvas` and `--wm-bg-surface`,
+  which became `sunken` / `base` / `raised`+`float` — so a consumer following the
+  spec wrote a `var()` naming an undefined property, which makes the whole
+  declaration invalid and apply to nothing, silently. Corrected against the
+  shipped CSS rather than by find-and-replace, since `surface` split in two.
+- §13 taught eight lines of inline style for a keyboard badge. `.wm-kbd` and
+  `.wm-kbd-combo` had shipped all along; the spec now names them.
+- §6 documented `.btn-primary`, `.btn-secondary`, `.btn-ghost` and `.btn-danger`
+  — classes this package has never shipped. It now documents `.wm-btn` with its
+  real variants, including `--flat` and `--xs`, which were undocumented.
+- §15.1 listed `.wm-focus` and `.wm-focus-inset` utility classes that do not
+  exist. Every shipped control already carries its own `:focus-visible` rule; the
+  section now says which treatment goes with which fill.
+- §17 presented twelve syntax, diff and code tokens as part of the token set.
+  Nine syntax tokens ship; the other twelve are app-local and were never
+  promoted. They are now listed as names to avoid, with the promotion path.
+- §20 was still a roadmap for a package that had shipped, and was the source of
+  several of the names above.
+- `docs/token-migration.md` stated that `--wm-bg-sunken` is the darkest colour in
+  every theme. Measured across all twelve theme blocks, it is the **lightest** in
+  `warm-light`, `neutral-light` and `solarized-precision`, and `sage-linen`
+  follows neither convention on purpose.
+- The inputs guide's `.wm-class` placeholder and encapsulation example named
+  classes that do not exist.
+
+### Known limitation
+
+- `.wm-input--error` measures APCA **Lc 60.3** on `solarized-precision` over
+  `--wm-bg-float`, against a bar of 60. It passes both bars on all twelve themes
+  (worst WCAG 6.20:1), but the margin is thin, and 1.13.0 set a precedent of
+  tuning to Lc 61 because Lc 60.0 can be flipped by a single hex rounding. The
+  tint reduces contrast on every one of the 192 combinations by construction, so
+  closing the margin would mean retuning a shipped token. Accepted deliberately
+  rather than overlooked; `check:semantic-contrast` will fail if it slips.
+
+## [1.14.1] - 2026-08-27
+
+### Fixed
+
+- Five theme/tone pairs shipped at 1.08:1 to 1.38:1 because a guard asserted the
+  fallback it was checking. `themes.css` selects its default as
+  `:root, [data-theme='warm-light']`, so that block is both the warm-light theme
+  and a later bare-`:root` declaration — a theme silent on a token receives
+  warm-light's value, not its own tone. Every theme must now declare all four
+  `-readable` tokens; `var(--wm-color-<tone>)` is the supported way to say "my
+  tone already reads", and the guard resolves and measures it.
+
+## [1.14.0] - 2026-08-27
+
+### Added
+
+- `WmTooltip` — an accessible tooltip directive on a CDK overlay, beside the
+  CSS-only `data-tooltip` chip. It shares `aria-describedby` rather than owning
+  it, satisfies WCAG 1.4.13 (Escape dismisses without moving focus and without
+  stopping the event; the pointer can enter the panel), and has no border by
+  measurement — at least 6.67:1 from every surface Aegis can put behind it.
+  `wmTooltipFocusable` is opt-in on purpose: never set it inside a
+  roving-tabindex container.
+- `check:tooltip-contrast`, a third build gate.
+
+### Fixed
+
+- Every anchored overlay now stays with its trigger when anything scrolls.
+  `createRepositionScrollStrategy` had never fired once: CDK's `ScrollDispatcher`
+  listens on the document in the **bubbling** phase and `scroll` does not bubble,
+  so in a fixed-height shell with an inner `overflow-y: auto` element both of its
+  sources are empty and the strategy is a silent no-op. `wm-popover`,
+  `wm-select` and `wm-combobox` had never set a strategy at all. Upgrading is the
+  whole fix.
+
+## [1.13.0] - 2026-08-27
+
+### Changed
+
+- `--wm-color-accent-readable` is now declared by all twelve themes and held to
+  APCA. On WCAG the accent family looked healthy at 4.5:1 to 6.3:1; on APCA
+  eleven of twelve missed Lc 60 on a bare surface and all twelve missed it on the
+  accent's own 10% tint. Both pre-existing overrides failed, because both were
+  tuned to WCAG alone. Tuned to Lc 61 rather than 60, because tuning to the bar
+  exactly put one theme on Lc 60.0.
+
+## [1.12.0] - 2026-08-27
+
+### Added
+
+- `--wm-color-<tone>-readable` for danger, warning and success — 31 overrides
+  across 12 themes. The tone is the saturated colour that *names* a status; it
+  was never a colour that could be *read*, failing on 31 of 36 theme/tone
+  combinations.
+- `--wm-color-accent-border`, used by `.wm-info-msg`.
+- `check:semantic-contrast`, a build gate over every theme/tone/surface
+  combination on both contrast models.
+
+### Fixed
+
+- No status rim had ever met WCAG 1.4.11. `-border` was a 25% mix toward
+  `transparent`, measuring 1.18:1 to 1.88:1 on every theme and tone. Rims now use
+  the button-edge rule at 65/35 — 70/30 fails at 2.93:1, because a rim has a
+  neighbour the edge never had: the tint the block is filled with.
+- Toasts stopped mixing their own 20% tint and took the shared tokens.
+
+## [1.11.0] - 2026-08-22
+
+### Added
+
+- `--wm-color-danger-solid` and `--wm-color-danger-edge`.
+- `check:destructive-contrast`, the first build gate to measure a token *pair*.
+
+### Fixed
+
+- `.wm-btn--destructive` painted `#ffffff` on `--wm-color-danger`, a token tuned
+  for danger as *text*, so the label failed WCAG AA on 8 of 12 themes — worst
+  2.74:1. The fill and the 3:1 component boundary now come from separate tokens,
+  because on `arctic-night` no single red satisfies both. Only the fill darkens
+  on hover; darkening the edge would eat the contrast it exists to guarantee.
+
+## [1.10.2] - 2026-08-18
+
+### Fixed
+
+- The UI token now selects bundled Inter, and the mono token Cascadia Code,
+  before OS fallbacks. 1.10.1 packaged every face but still selected Segoe first,
+  so asset-presence proof did not prove runtime selection. The build guard now
+  checks both.
+
+## [1.10.1] - 2026-08-18
+
+### Added
+
+- The complete typography stack is vendored: Inter and Cascadia Code variable
+  WOFF2 faces, normal and italic, with both SIL OFL 1.1 licenses and pinned
+  upstream checksums. The docs app no longer downloads a font.
+
+## [1.10.0] - 2026-08-09
+
+### Added
+
+- `WmPopover` accepts a nullable `ariaLabel`, applied to the overlay shell that
+  already owns the role and the generated id the trigger's `aria-controls`
+  points at. Existing consumers emit no new attribute.
+
+## [1.9.2] - 2026-08-09
+
+### Fixed
+
+- Inactive and unavailable tabs both resolved to `--wm-text-muted`, so
+  desaturating neutral text did nothing. Unavailable labels and icons now mix
+  muted text to 52% transparency, while focus outlines stay fully opaque.
+
+## [1.9.1] - 2026-08-09
+
+### Changed
+
+- `wm-tab-separator` uses `--wm-border-subtle` and renders as an unfocusable
+  `role="separator"` with `aria-orientation="vertical"`, so grouping reaches
+  assistive technology without adding a keyboard stop.
+
+## [1.9.0] - 2026-08-09
+
+### Changed
+
+- **BREAKING:** `wm-modal` traps focus itself. Consumers that applied their own
+  `cdkTrapFocus` must remove it or they nest a second trap. The removed traps
+  were inert, so nobody loses working behaviour: `CdkTrapFocus.ngAfterContentInit`
+  calls `attachAnchors()`, which requires a `parentNode`, and projected content
+  has none at that moment — measured at 0 anchors before, 2 after.
+- Published through GitHub OIDC Trusted Publishing. No long-lived npm token and
+  no 2FA bypass.
+
+## [1.8.0] - 2026-08-04
+
+### Added
+
+- `wm-combobox` gains `ariaLabel` and `ariaLabelledby`. The host is not a
+  labelable element and the input had no aria binding, so in multi-select — where
+  the placeholder is blanked once a chip renders — it could have no accessible
+  name at all. `ariaLabelledby` wins and suppresses `aria-label`, which makes
+  WCAG 2.5.3 structurally impossible to violate.
+
+---
+
+Releases before 1.8.0 are in `git log`. See also `wiki/products/Aegis - Health.md`
+for the decisions behind these changes, including the ones decided against.
+
+[Unreleased]: https://github.com/wildmason/aegis/compare/v1.16.0...HEAD
+[1.16.0]: https://github.com/wildmason/aegis/releases/tag/v1.16.0
+[1.15.0]: https://github.com/wildmason/aegis/releases/tag/v1.15.0
+[1.11.0]: https://github.com/wildmason/aegis/releases/tag/v1.11.0
+[1.9.0]: https://github.com/wildmason/aegis/releases/tag/v1.9.0

package/inputs.css

@@ -38,6 +38,7 @@
    .wm-input-group      Composite row: icon + .wm-input-bare (e.g. search)
    .wm-input-bare       Borderless inner input used inside .wm-input-group
    .wm-input-icon       Leading/trailing icon slot inside .wm-input-group
+   .wm-input--error     Invalid state for .wm-input / .wm-input-group
    .wm-select-trigger   Button-based custom select trigger (for app-select etc.)
    .wm-number-input     Number input variant (spinner chrome removed)
    .wm-number-controls  ± button strip appended to .wm-input-group
@@ -436,6 +437,38 @@
   cursor: not-allowed;
 }
 
+/* Invalid: --wm-color-danger-border, the same edge the .wm-error-msg block
+   below the field draws, so the field and its message read as one thing.
+   The fill is --wm-color-danger-bg rather than a flat tint, because it is
+   the only danger background tuned per theme to stay behind text.
+
+   Kept above :focus in the cascade order deliberately: focus wins while the
+   user is fixing the field, so the accent border and its pulse are not
+   fighting a red one. The error border comes back the moment focus leaves,
+   and the message block never went anywhere.
+
+   Colour is never the only signal — pair this with .wm-error-msg and
+   aria-invalid="true", or a red border is the whole message to a user who
+   cannot see red.
+
+   Each selector is anchored to the element it is for. `.wm-input--error` alone
+   would match BOTH a control and a group, and a group is never `:focus` — the
+   input inside it is — so the control rule's `:not(:focus)` is vacuously true
+   on a group and paints the tint straight through the group rule's
+   `:not(:focus-within)`. Measured, not reasoned about: a focused group showed
+   the accent border with the error fill still behind it. */
+.wm-input.wm-input--error:not(:focus),
+.wm-input-group.wm-input--error:not(:focus-within) {
+  border-color: var(--wm-color-danger-border);
+  background-color: var(--wm-color-danger-bg);
+}
+
+.wm-input.wm-input--error:hover:not(:focus):not(:disabled),
+.wm-input-group.wm-input--error:hover:not(:focus-within) {
+  border-color: var(--wm-color-danger);
+  background-color: var(--wm-color-danger-bg);
+}
+
 /* Inherit color-scheme so date/time picker chrome (calendar icon, spinners)
    matches the active theme's light/dark declaration. */
 .wm-input[type='date'],
@@ -1553,3 +1586,48 @@ select.wm-input {
   color: var(--wm-text-muted);
   pointer-events: none;
 }
+
+/* ----------------------------------------------------------------
+   On an accent fill — .wm-kbd--on-accent
+   ----------------------------------------------------------------
+   A plain .wm-kbd is --wm-bg-sunken inside --wm-border-input: a
+   recess in a surface. Put one on .wm-btn--primary and both tokens
+   are answering the wrong question — the fill is a surface colour
+   stranded on the accent, and the border is tuned to separate from
+   surfaces rather than from a saturated fill.
+
+   This modifier carries no fill of its own. It borrows the button's,
+   which means the cap's label IS the button's label and inherits the
+   contrast that pair already guarantees; nothing about the text needs
+   measuring twice. The edge is the label colour at 75% over whatever
+   sits behind it, and mixing toward `transparent` rather than toward
+   a named fill is what lets ONE declaration serve both the rest fill
+   and the hover fill — a mix toward --wm-color-accent could only
+   ever be correct for one of the two.
+
+   75% is held by check-accent-contrast.mjs against both fills on
+   every theme. The binding case is posh-sandalwood, where the edge
+   measures 3.47:1 against WCAG 1.4.11's 3:1.
+
+   Usage — inside an accent button:
+     <button class="wm-btn wm-btn--primary">
+       Accept
+       <span class="wm-kbd-combo">
+         <kbd class="wm-kbd wm-kbd--on-accent">Ctrl</kbd>
+         <kbd class="wm-kbd wm-kbd--on-accent">Enter</kbd>
+       </span>
+     </button>
+   ---------------------------------------------------------------- */
+
+.wm-kbd--on-accent {
+  color: var(--wm-color-accent-text);
+  background: transparent;
+  border-color: color-mix(in srgb, var(--wm-color-accent-text) 75%, transparent);
+}
+
+/* The combo's `+` is --wm-text-muted, a surface colour, so it is as wrong on
+   an accent fill as the cap's own tokens were. Same share as the edge, so
+   there is one number to keep in step rather than two. */
+.wm-kbd-combo > .wm-kbd--on-accent + .wm-kbd--on-accent::before {
+  color: color-mix(in srgb, currentColor 75%, transparent);
+}

package/package.json

@@ -1,16 +1,19 @@
 {
   "name": "@wildmason/aegis",
-  "version": "1.14.1",
+  "version": "1.16.0",
   "description": "Aegis design system \u00e2\u20ac\u201d CSS tokens and Angular component library",
   "scripts": {
     "check:offline-fonts": "node scripts/check-offline-fonts.mjs",
-    "build": "npm run check:offline-fonts && npm run check:destructive-contrast && npm run check:semantic-contrast && npm run check:tooltip-contrast && ng-packagr -p ng-package.json",
+    "build": "npm run check:offline-fonts && npm run check:destructive-contrast && npm run check:semantic-contrast && npm run check:accent-contrast && npm run check:tooltip-contrast && npm run check:docs && ng-packagr -p ng-package.json",
     "prepublishOnly": "npm run build",
     "check:destructive-contrast": "node scripts/check-destructive-contrast.mjs",
     "check:semantic-contrast": "node scripts/check-semantic-contrast.mjs",
-    "check:tooltip-contrast": "node scripts/check-tooltip-contrast.mjs"
+    "check:tooltip-contrast": "node scripts/check-tooltip-contrast.mjs",
+    "check:accent-contrast": "node scripts/check-accent-contrast.mjs",
+    "check:docs": "node scripts/check-design-language.mjs"
   },
   "files": [
+    "CHANGELOG.md",
     "dist",
     "fonts",
     "themes.css",

package/themes.css

@@ -354,7 +354,7 @@
 
   /* Accent */
   --wm-color-accent: #105987;
-  --wm-color-accent-hover: #2aa198;
+  --wm-color-accent-hover: #004771;
   --wm-color-accent-text: #ffffff;
   --wm-color-accent-readable: #004066;
 
@@ -500,8 +500,8 @@
 
   /* Accent — light teal requires dark text */
   --wm-color-accent: #8fc4d3;
-  --wm-color-accent-hover: #81a1c1;
-  --wm-color-accent-text: #2e3440;
+  --wm-color-accent-hover: #b2e8f7;
+  --wm-color-accent-text: #2c323e;
   --wm-color-accent-readable: #a5dbea;
 
   /* Semantic */
@@ -577,8 +577,8 @@
 
   /* Accent — slightly lighter than canonical purple for card contrast */
   --wm-color-accent: #c9a7fa;
-  --wm-color-accent-hover: #ff79c6;
-  --wm-color-accent-text: #282a36;
+  --wm-color-accent-hover: #e5d5ff;
+  --wm-color-accent-text: #242632;
   --wm-color-accent-readable: #dcc6fe;
 
   /* Semantic */
@@ -657,8 +657,8 @@
 
   /* Accent — warm peach */
   --wm-color-accent: #f5986a;
-  --wm-color-accent-hover: #f08458;
-  --wm-color-accent-text: #1c1d2e;
+  --wm-color-accent-hover: #ffc7ac;
+  --wm-color-accent-text: #0e0e1e;
   --wm-color-accent-readable: #fead85;
 
   /* Semantic */
@@ -737,7 +737,7 @@
 
   /* Accent — thistle (muted lavender) */
   --wm-color-accent: #c4a8d8;
-  --wm-color-accent-hover: #9e7abf;
+  --wm-color-accent-hover: #e7cafc;
   --wm-color-accent-text: #1a1715;
   --wm-color-accent-readable: #d8bced;
 
@@ -884,7 +884,7 @@
 
   /* Accent — Monokai hot pink */
   --wm-color-accent: #f92672;
-  --wm-color-accent-hover: #fd971f;
+  --wm-color-accent-hover: #ff8dc2;
   --wm-color-accent-text: #1c1c15;
   /* #ff8ac4 was chosen for the WCAG failure (#f92672 is 2.9:1 on bg-float) and
      cleared 5.03:1, but measures APCA Lc 51.4 there. See the note in :root. */
@@ -964,7 +964,7 @@
 
   /* Accent — golden orange, the crepuscular ray color */
   --wm-color-accent: #c09d06;
-  --wm-color-accent-hover: #b15000;
+  --wm-color-accent-hover: #e0bd3f;
   --wm-color-accent-text: #060810;
   --wm-color-accent-readable: #dcb83a;
 
@@ -1041,7 +1041,7 @@
 
   /* Accent — medium green, needs dark text for contrast */
   --wm-color-accent: #3fb950;
-  --wm-color-accent-hover: #58a6ff;
+  --wm-color-accent-hover: #62d96f;
   --wm-color-accent-text: #0d1117;
   --wm-color-accent-readable: #5dd46a;
 
@@ -1118,7 +1118,7 @@
 
   /* Accent — Forest Moss Green */
   --wm-color-accent: #82a682;
-  --wm-color-accent-hover: #94b894;
+  --wm-color-accent-hover: #9fc59f;
   --wm-color-accent-text: #161817;
   /* #9bc99b was chosen for the WCAG failure (#82a682 is 3.30:1 on bg-float) and
      cleared 4.74:1, but measures APCA Lc 54.3 there. See the note in :root. */