origam 2.18.2 → 2.18.4

package/CHANGELOG.md

@@ -18,6 +18,71 @@ This project follows [Semantic Versioning](https://semver.org).
 
 ## [Unreleased]
 
+### Fixed — #818 baseline shrink : `aria-allowed-attr`/`aria-prohibited-attr`/`aria-valid-attr-value` (12 des 25 entrées)
+
+Recompté sur `a11y-violations.baseline.json` (pas repris d'un chiffre cité
+ailleurs) : la baseline #818 portait **25 clés / 33 violations** sur 24
+composants, dont **12 `aria-allowed-attr`** concentrées sur la famille
+`OrigamDataTable*`. Cause commune, pas 12 défauts distincts :
+`OrigamTextField` ne posait pas `inheritAttrs: false` alors qu'il
+redistribue déjà explicitement chaque attr de fall-through
+(`filterInputAttrs` → `rootAttrs` sur `<origam-input>`, `inputAttrs` sur le
+vrai `<input>`). Sans ce flag, Vue appliquait EN PLUS le `$attrs` brut sur
+la racine `<origam-input>`, qui ne s'y soustrayait pas non plus — doublant
+`aria-haspopup`/`aria-expanded`/`aria-controls`/`aria-valuenow`/… sur le
+`<div>` wrapper, qui ne porte aucun rôle les autorisant. `role` (prop
+déclarée sur `OrigamTextField`) n'atteignait par ailleurs que
+`<origam-field>`, jamais le vrai `<input>` — c'est ce défaut exact que le
+commentaire `KNOWN_FAILURES` documentait déjà pour `OrigamSelect` (test
+`fixme`).
+
+**Correctif à la source** (`packages/ds/src/components/TextField/OrigamTextField.vue`) :
+`defineOptions({ inheritAttrs: false })` + `role` désormais aussi lié sur le
+`<input>` réel. Élimine, mesuré axe-core en navigateur réel (Playwright +
+Histoire statique) :
+- `OrigamSelect` — sort de `KNOWN_FAILURES` (`components.spec.ts`), test
+  `fixme` → vert.
+- `OrigamDataTable`, `OrigamDataTableFooter`, `OrigamDataTableHeaderCell`,
+  `OrigamDataTableHeaders`, `OrigamDataTableHeadersCell`,
+  `OrigamDataTableRow` — `aria-allowed-attr` disparaît, entrée de baseline
+  retirée entièrement.
+- `OrigamDataTableGroupHeaderRow`, `OrigamDataTableRows`, `OrigamNumberField`
+  — `aria-allowed-attr` disparaît, l'entrée reste pour leur AUTRE violation
+  (`button-name` / `color-contrast`), non touchée par ce lot.
+- `OrigamDataTableHeadersCellMobile` — `aria-allowed-attr` ET
+  `aria-prohibited-attr` disparaissent (même fuite, deux règles axe
+  différentes), entrée retirée entièrement.
+
+**Deuxième cause, distincte, deux composants** —
+`packages/ds/src/components/ColorPickerField/OrigamColorPickerField.vue` et
+`.../DatePickerField/OrigamDatePickerField.vue` posaient un
+`aria-haspopup` avec une valeur inventée (`'colorpickerbox'` /
+`'datepickerbox'`, jamais un token ARIA valide) sur l'élément
+`.origam-field` (via `activator="parent"` d'`OrigamMenu`), sans `role` le
+justifiant. Remplacé par `aria-haspopup: 'dialog'` (motif WAI-ARIA « Date
+Picker Dialog ») + `role: 'combobox'` sur le même élément — même principe
+que `comboboxAriaAttrs` d'`OrigamSelect`. `aria-allowed-attr` ET
+`aria-valid-attr-value` disparaissent pour les deux ; `OrigamColorPickerField`
+est intégralement retiré de la baseline, `OrigamDatePickerField` y reste
+pour son `color-contrast` (non touché).
+
+**Bilan mesuré** : baseline #818 25 clés/33 violations → **17 clés/18
+violations**. Suite `pnpm -F @origam/tests test:a11y` complète (226 tests,
+catalogue 218/218) : **226 passed**, aucune régression sur les 36
+composants à baseline vide. Contrôle positif exécuté : réintroduire l'ancien
+comportement fait échouer `a11y — OrigamSelect Default Variant` avec
+`aria-allowed-attr`/`aria-prohibited-attr` NON baselinés — la porte capte
+la régression, pas seulement l'édition du JSON.
+
+**Laissé de côté, délibérément** (17 clés / 18 violations restent dans
+`a11y-violations.baseline.json`, cf. #818) : `color-contrast` (8 instances —
+plusieurs agents dédiés au contraste travaillent déjà sur ce périmètre),
+`button-name` (3, boutons icône sans libellé — famille distincte),
+`scrollable-region-focusable` (3), `aria-required-parent`/`aria-required-children`/
+`listitem`/`aria-prohibited-attr` (`OrigamChartMap`, sans lien avec ce
+correctif) — un défaut chacun, cause non partagée avec ce lot, non
+instruit ici.
+
 Récolte de deux dépréciations posées "pour la prochaine majeure" avant que le
 `CLAUDE.md` n'acte que `3.0.0` est réservé à la séparation en modules et que
 les ruptures, elles, ne le sont pas — voir "Work priorities and versioning"
@@ -156,6 +221,105 @@ conclure qu'elle ne l'est plus par défaut.
 
 ### Fixed
 
+- **#871 (clôture) — les 7 dernières violations AA étaient UN défaut de
+  palette répété, pas sept défauts de composant.** Mesuré avec
+  `packages/tests/audit/dark-contrast.audit.mjs` : **7 / 1 664 → 0 / 1 664**,
+  les 8 identités × 2 modes × 2 portées, quatre contrôles verts des deux
+  côtés. Exactement **7 lignes changent, aucune ne se dégrade**, et le ratio
+  minimum de toute la surface passe de 3.65 à **4.70**.
+
+  Les 7 se répartissaient en deux causes, toutes deux dans
+  `packages/marketing/src/themes` — **aucune dans le DS**, qui était déjà à
+  zéro :
+
+  | cause | marque · mode | couple | avant | après |
+  |---|---|---|---|---|
+  | encre héritée du mode clair | `apple` sombre | `#ffffff` → `#000000` sur `#0a84ff` | 3.65 | **5.76** |
+  | encre héritée du mode clair | `ecom` sombre | `#ffffff` → `#1a0f0a` sur `#f43f5e` | 3.67 | **5.12** |
+  | jeton de rôle inversé | `ecom` clair | `action.primary.bg` → `.fgSubtle` sur la crème | 4.43 | **5.93** |
+
+  **La cause commune.** Le mode sombre ÉCLAIRCIT l'accent de marque — c'est
+  la bonne pratique pour une grande surface (`#0071e3` → `#0a84ff` chez
+  `apple`, rose-600 → rose-500 chez `ecom`) — mais les deux palettes gardaient
+  l'encre `#ffffff` de leur jumeau clair. Or chacune applique **déjà** la règle
+  inverse à ses intentions `feedback` : les 4 d'`ecom` et 3 des 4 d'`apple`
+  encrent leur accent éclairci avec le `text.inverse` de la palette.
+  `action.primary` était la dernière exception. Le badge n'était pas en cause :
+  `--origam-badge__badge---{background-color,color}` lit exactement ce couple —
+  tout comme `--origam-btn--primary---*`, qui n'est pas dans la sonde et était
+  donc en défaut sans être mesuré.
+
+  ⚠️ **On n'a PAS foncé l'accent**, bien que ce soit l'autre levier : chez
+  `apple`, `action.primary.bg` sert aussi d'ENCRE (le bloc `components` passe
+  ce `var()` en `color` sur `origam-breadcrumb-item`). Le ramener à `#0071e3`
+  donnait 4.70 sous du blanc mais faisait tomber le fil d'Ariane à **4.47** sur
+  le fond noir — un défaut échangé contre un autre. Vérifié par calcul avant
+  d'écrire la moindre ligne.
+
+  La 3ᵉ cause est une erreur de RÔLE : `bg` est un jeton de surface, `fgSubtle`
+  la teinte prévue pour être LUE sur une surface neutre. `ecomDarkTheme` posait
+  déjà `fgSubtle` ; seul le bloc clair se trompait de jeton. Les deux modes sont
+  désormais symétriques.
+
+- **#871 — une 8ᵉ violation, que la sonde ne pouvait pas voir** :
+  `material` sombre, `feedback.success`, `#1b5e20` sur `#81c784` = **3.91**
+  → `#0d3b10` = **6.32**. La sonde de `dark-contrast.audit.mjs` ne rend qu'UNE
+  intention par famille de composant, donc elle ne peint jamais
+  `feedback.success`. Trouvée par la spec statique ajoutée ci-dessous. C'est
+  l'encre qui était l'intruse, pas le conteneur : les trois autres intentions
+  sombres de `material` tiennent 5.79 / 7.70 / 7.71 avec des encres bespoke
+  très profondes, `success` était la seule à se contenter du green-900 de la
+  rampe.
+
+- **#871 — l'audit lui-même ne démarrait plus.** Son `npx vite build` résolvait
+  vite par le PATH, via un lien `node_modules/.bin` qu'un peer auto-installé
+  ne garantit pas : sur un `pnpm install --frozen-lockfile` propre,
+  `packages/tests/node_modules/.bin/` ne contient que `playwright` et `vitest`,
+  et la commande mourait en `127 — sh: vite: command not found`. **L'audit ne
+  rendait plus aucun chiffre**, et rien ne le signalait puisque rien ne le
+  rejoue en CI. `resolveViteBin()` passe désormais par le realpath de
+  `@vitejs/plugin-vue`, ce qui ne dépend ni du PATH ni du hoisting et
+  sélectionne la copie de vite que le plugin utilise réellement (deux majeures
+  coexistent dans le magasin). Les commentaires qui affirmaient le contraire
+  dans les deux fichiers ont été corrigés.
+
+- **#871 — l'état SURVOL était en défaut plus grave encore, et le correctif
+  d'encre l'a réglé sans qu'on y touche.** Le survol n'a pas d'encre à lui :
+  `--origam-btn--primary---background-color-hover` bascule la surface, mais il
+  n'existe **aucun** `--origam-btn--primary---color-hover` (ni de
+  `--origam-badge__badge---color-hover`) — l'encre reste `action.primary.fg`
+  dans les deux états. Sous l'encre blanche, `apple` sombre y tombait à
+  **2.19:1** et `ecom` sombre à **2.69:1** : *pires que n'importe laquelle des
+  7 violations comptées*, et invisibles parce que la sonde de
+  `dark-contrast.audit.mjs` ne rend que l'état au repos.
+
+  **Aucun `bgHover` n'a été modifié.** La direction du survol n'était pas le
+  problème — l'encre l'était. Mesuré sur les deux marques :
+
+  | mode · encre | direction du survol | ratio repos → survol |
+  |---|---|---|
+  | clair · blanche | fonce | 4.70 → **6.95** / **6.29** ↑ |
+  | sombre · blanche *(avant)* | éclaircit | 3.65 → **2.19** / 3.67 → **2.69** ↓ |
+  | sombre · foncée *(après)* | éclaircit | 5.76 → **9.60** / 5.12 → **6.99** ↑ |
+
+  La règle n'est donc pas *« le survol doit foncer »* mais **« le survol doit
+  déplacer l'accent à l'opposé de la clarté de son encre »**. Les palettes la
+  respectaient déjà dans 3 quadrants sur 4 ; le seul cassé l'était par son
+  encre. L'idiome « le survol éclaircit », qui est le bon en mode sombre, est
+  conservé dans les deux marques.
+
+- **#871 — non-régression : `packages/tests/TU/marketing/brand-palette-contrast.spec.ts`.**
+  Les couples `{bg, fg}` littéraux des 7 palettes de marque (14 thèmes) doivent
+  tenir AA. L'audit de #871 est un script qu'on lance à la main : rien ne le
+  rejoue, donc rien n'empêchait une retouche de palette de ramener ces couples
+  en silence. La spec lit les hex **dans l'objet `IOrigamTheme`**, avant toute
+  indirection CSS — la règle jsdom/`var()` du `CLAUDE.md` ne s'y applique pas,
+  et le navigateur reste l'arbitre de ce qui est peint. Elle embarque ses
+  propres garde-fous : les 3 témoins de la formule, un contrôle négatif sur les
+  3 couples corrigés, et un plancher de couverture qui rend bruyante une dérive
+  du filtre. **Vérifiée ROUGE sur `origin/develop`** : 3 échecs / 14 succès.
+  C'est elle qui a trouvé la 8ᵉ violation ci-dessus.
+
 - **#871 — le mode sombre ne peignait qu'à moitié dans un sous-arbre thémé.**
   Les feuilles de tokens portent ~1 761 déclarations **dérivées**
   (`--origam-title---color: var(--origam-color__text---primary)`). Une custom
@@ -301,6 +465,84 @@ conclure qu'elle ne l'est plus par défaut.
 
 ---
 
+#### `v-contrast` était silencieusement inerte sur fond opaque (#869)
+
+La directive `v-contrast`, câblée sur 30 composants, n'émettait **jamais**
+rien — ni classe, ni `color: !important`, ni `console.warn` — dès que fond
+**et** texte étaient tous deux OPAQUES, c'est-à-dire la configuration par
+défaut du DS. Deux ruptures indépendantes dans le code partagé, corrigeant
+l'une ne suffisait pas sans l'autre :
+
+1. **`toRgb()`** faisait **toujours** passer la couleur par un aller-retour
+   `canvas.fillStyle`, même quand `getComputedStyle` avait déjà rendu une
+   chaîne `rgb()/rgba()` exploitable. Le getter `fillStyle` de Chromium
+   sérialise toute couleur OPAQUE en hexadécimal `#rrggbb` (seul l'alpha < 1
+   ressort en `rgba(…)`), ce qui transformait une valeur déjà utilisable en
+   une valeur morte pour `rgbaParts`/`channelsOf`.
+2. **`channelsOf()`** extrayait les canaux via `match(/[\d.]+/g)`, taillé
+   pour `rgb(r, g, b)` — une suite de chiffres hexadécimaux SANS séparateur
+   (ex. `#777777`, six chiffres) s'agrège en UN seul grand nombre au lieu de
+   trois, donc `channelsOf` rend `null` sur exactement la forme hex que la
+   rupture 1 pouvait encore produire (couleur nommée, `hsl()`, …
+   nécessitant légitimement le détour par le canvas).
+
+**Correctif** : `toRgb()` court-circuite désormais le canvas quand l'entrée
+est déjà `rgb()/rgba()` (le cas de la quasi-totalité des appels, puisqu'ils
+lisent `getComputedStyle`), et le chemin canvas restant convertit son
+résultat hexadécimal en `rgb()/rgba()` via un nouveau `hexToRgb()` avant de
+le rendre — `toRgb()` ne rend plus jamais de hex. La mécanique de correction
+elle-même (forcer noir/blanc, poser `data-origam-contrast-fixed`, journaliser
+le ratio) n'est pas modifiée : elle fonctionnait déjà, elle n'était
+simplement jamais atteinte.
+
+**Preuve** — `packages/tests/e2e/contrast-directive.spec.ts` (Playwright,
+Chromium réel — jsdom n'a pas de `canvas.getContext('2d')` fonctionnel dans
+ce dépôt, donc ne peut ni reproduire ni vérifier ce bug) : contrôle positif
+(`#777777` sur blanc, 4.48:1, opaque des deux côtés) déclenche désormais la
+correction + le `console.warn` ; contrôle négatif (noir sur blanc, 21:1) ne
+déclenche rien ; non-régression du chemin translucide (fond composé via
+`resolvePaintedBackground`) inchangée. **A/B contre le commit parent** : 4
+des 5 tests rougissent sur le code d'avant (le contrôle négatif reste vert
+des deux côtés, comme attendu).
+
+⚠️ **Rayon mesuré séparément, pas hérité de #871 — et le chiffre publié par
+#871 contenait un artefact, corrigé depuis par #883.** Le chiffrage initial
+du ticket (346 violations en mode sombre) datait d'avant #876. #876 avait
+d'abord publié **189 → 11** ; en rejouant `audit/dark-contrast.audit.mjs`
+avec la VRAIE directive (redirect du stub désactivé) au lieu de sa
+reformulation mathématique, seuls **7 `console.warn` réels** se
+déclenchaient sur les 32 configurations (30 composants × 8 identités × 2
+modes, portées racine + sous-arbre) — écart signalé à l'auteur de #876, qui
+l'a reproduit, creusé et corrigé sous #883 : **les bornes AVANT et APRÈS
+étaient toutes les deux fausses (185 → 7, pas 189 → 11)**, la même erreur de
+mesure existant déjà dans le comptage "avant". Le delta réel (178) n'a
+jamais changé.
+
+L'écart venait d'`origam-tooltip__content` (identité `apple`, root + subtree,
+light + dark) et, découvert par #883, également d'`origam-bottom-nav` sur la
+même identité. Fond réel : `color(srgb 0.898039 0.898039 0.905882 / 0.94)`
+(translucide) ; `toRgb()` le résout correctement en `rgb(215, 215, 217)` une
+fois composé sur son ancêtre opaque, contre du texte noir : **ratio 14.61:1,
+conforme** — vérifié en appelant directement `toRgb()`/
+`resolvePaintedBackground()` de la vraie directive sur cette page. La
+fonction `parse()` de `dark-contrast.audit.mjs` (une réimplémentation
+distincte, pas la directive) ne reconnaissait que `rgba?\(…\)` — elle
+ignorait silencieusement cette couche `color(srgb …)`, sautait jusqu'à
+l'ancêtre opaque suivant et rapportait à tort un faux "noir sur noir"
+(ratio 1.00). **Ce n'était pas un défaut du DS ni de `v-contrast`** — la
+même classe de lacune que ce ticket corrige, mais dans un autre fichier. Les
+7 restantes (4 `origam-badge__badge`, 3 `origam-breadcrumb-item`) sont
+confirmées identiques entre les deux mesures, et `sous 2:1` passe à **0** une
+fois l'artefact retiré : plus rien de ce qui reste n'est proche d'invisible.
+
+Non corrigé ici : `dark-contrast.audit.mjs` appartenait à #871/#876, pas à ce
+ticket — signalé, reproduit et corrigé séparément sous #883 (ne pas citer
+189 → 11, c'était faux des deux côtés).
+
+**Rupture d'API** : aucune — `toRgb`/`channelsOf`/`hexToRgb` restent des
+fonctions privées du module, non exportées ; la surface publique
+(`setContrastConfig`, `v-contrast` par défaut) est inchangée.
+
 ## [2.18.0] - 2026-09-19
 
 80 commits depuis `v2.17.1`. L'essentiel est du **correctif** : des tokens qui

package/dist/src/components/ColorPickerField/OrigamColorPickerField.vue

@@ -331,9 +331,31 @@ const menuProps = computed(() => {
   return {
     ...props.menuProps,
     activatorProps: {
+      /*********************************************************
+       * role + aria-haspopup — #818
+       *
+       * @description
+       * `'colorpickerbox'` was never a valid `aria-haspopup` token
+       * (spec allows `false|true|menu|listbox|tree|grid|dialog`) —
+       * axe-core's `aria-valid-attr-value` flagged it, measured
+       * against a real browser. The popup is a free-form panel
+       * (a color canvas + swatches), not a list of options, so
+       * `'dialog'` is the correct token — same family as the
+       * WAI-ARIA "Date Picker Dialog" pattern `OrigamDatePickerField`
+       * uses right below.
+       *
+       * @description
+       * `role: 'combobox'` is ALSO required here: `activator="parent"`
+       * (below) lands these ARIA attrs on the `.origam-field` wrapper
+       * `<div>`, which carries no role by default — `aria-allowed-attr`
+       * rejects `aria-expanded` on an element whose role doesn't
+       * support it. Same fix, same rationale as
+       * `OrigamSelect.comboboxAriaAttrs` (`role` MUST sit on the same
+       * element as `aria-haspopup`/`aria-expanded`).
+       ********************************************************/
+      role: "combobox",
       ...props.menuProps?.activatorProps || {},
-      "aria-haspopup": "colorpickerbox"
-      // Set aria-haspopup to 'listbox'
+      "aria-haspopup": "dialog"
     },
     contentProps: {
       ...consumerContentProps,

package/dist/src/components/DatePickerField/OrigamDatePickerField.vue

@@ -405,9 +405,29 @@ const menuProps = computed(() => {
   return {
     ...props.menuProps,
     activatorProps: {
+      /*********************************************************
+       * role + aria-haspopup — #818
+       *
+       * @description
+       * `'datepickerbox'` was never a valid `aria-haspopup` token
+       * (spec allows `false|true|menu|listbox|tree|grid|dialog`) —
+       * axe-core's `aria-valid-attr-value` flagged it, measured
+       * against a real browser. `'dialog'` matches the WAI-ARIA
+       * "Date Picker Dialog" pattern: a button/combobox opening a
+       * calendar dialog.
+       *
+       * @description
+       * `role: 'combobox'` is ALSO required here: `activator="parent"`
+       * (below) lands these ARIA attrs on the `.origam-field` wrapper
+       * `<div>`, which carries no role by default — `aria-allowed-attr`
+       * rejects `aria-expanded` on an element whose role doesn't
+       * support it. Same fix, same rationale as
+       * `OrigamSelect.comboboxAriaAttrs` (`role` MUST sit on the same
+       * element as `aria-haspopup`/`aria-expanded`).
+       ********************************************************/
+      role: "combobox",
       ...props.menuProps?.activatorProps || {},
-      "aria-haspopup": "datepickerbox"
-      // Set aria-haspopup to 'listbox'
+      "aria-haspopup": "dialog"
     },
     contentProps: {
       ...consumerContentProps,

package/dist/src/components/TextField/OrigamTextField.vue

@@ -91,6 +91,7 @@
 									:readonly="isReadonly"
 									:required="required || undefined"
 									:aria-required="required ? 'true' : undefined"
+									:role="role"
 									:size="1"
 									:type="resolvedInputType"
 									:value="displayValue"
@@ -208,6 +209,7 @@ import { applyMask } from "../../utils/Commons/apply-mask.util";
 import { filterInputAttrs } from "../../utils/Input/input.util";
 import { forwardRefs } from "../../utils/Commons/forwardRefs.util";
 import { resolveMaskConfig } from "../../utils/Commons/resolve-mask-config.util";
+defineOptions({ inheritAttrs: false });
 const props = defineProps({
   autofocus: { type: Boolean, required: false },
   counter: { type: [Boolean, Number, String], required: false },

package/dist/src/directives/Contrast/contrast.directive.cjs

@@ -34,10 +34,24 @@ function srgbToRgb(color) {
   const a = m[4] !== void 0 ? parseFloat(m[4]) : 1;
   return a < 1 ? `rgba(${r}, ${g}, ${b}, ${a})` : `rgb(${r}, ${g}, ${b})`;
 }
+function hexToRgb(hex) {
+  const m = hex.match(/^#([0-9a-f]{3}|[0-9a-f]{4}|[0-9a-f]{6}|[0-9a-f]{8})$/i);
+  if (!m) return null;
+  const h = m[1].length <= 4 ? [...m[1]].map(c => c + c).join("") : m[1];
+  const r = parseInt(h.slice(0, 2), 16);
+  const g = parseInt(h.slice(2, 4), 16);
+  const b = parseInt(h.slice(4, 6), 16);
+  if (h.length === 8) {
+    const a = parseInt(h.slice(6, 8), 16) / 255;
+    return a < 1 ? `rgba(${r}, ${g}, ${b}, ${a})` : `rgb(${r}, ${g}, ${b})`;
+  }
+  return `rgb(${r}, ${g}, ${b})`;
+}
 function toRgb(color) {
   if (!color) return null;
   const direct = srgbToRgb(color);
   if (direct) return direct;
+  if (/^rgba?\(/i.test(color)) return color;
   if (typeof document === "undefined") return color;
   if (normCtx === void 0) normCtx = document.createElement("canvas").getContext("2d");
   if (!normCtx) return color;
@@ -48,7 +62,7 @@ function toRgb(color) {
   normCtx.fillStyle = color;
   const onWhite = normCtx.fillStyle;
   if (onBlack !== onWhite) return null;
-  return srgbToRgb(onBlack) ?? onBlack;
+  return srgbToRgb(onBlack) ?? hexToRgb(onBlack) ?? onBlack;
 }
 function rgbaParts(rgb) {
   if (!rgb) return null;

package/dist/src/directives/Contrast/contrast.directive.js

@@ -22,10 +22,24 @@ function srgbToRgb(color) {
   const a = m[4] !== void 0 ? parseFloat(m[4]) : 1;
   return a < 1 ? `rgba(${r}, ${g}, ${b}, ${a})` : `rgb(${r}, ${g}, ${b})`;
 }
+function hexToRgb(hex) {
+  const m = hex.match(/^#([0-9a-f]{3}|[0-9a-f]{4}|[0-9a-f]{6}|[0-9a-f]{8})$/i);
+  if (!m) return null;
+  const h = m[1].length <= 4 ? [...m[1]].map((c) => c + c).join("") : m[1];
+  const r = parseInt(h.slice(0, 2), 16);
+  const g = parseInt(h.slice(2, 4), 16);
+  const b = parseInt(h.slice(4, 6), 16);
+  if (h.length === 8) {
+    const a = parseInt(h.slice(6, 8), 16) / 255;
+    return a < 1 ? `rgba(${r}, ${g}, ${b}, ${a})` : `rgb(${r}, ${g}, ${b})`;
+  }
+  return `rgb(${r}, ${g}, ${b})`;
+}
 function toRgb(color) {
   if (!color) return null;
   const direct = srgbToRgb(color);
   if (direct) return direct;
+  if (/^rgba?\(/i.test(color)) return color;
   if (typeof document === "undefined") return color;
   if (normCtx === void 0) normCtx = document.createElement("canvas").getContext("2d");
   if (!normCtx) return color;
@@ -36,7 +50,7 @@ function toRgb(color) {
   normCtx.fillStyle = color;
   const onWhite = normCtx.fillStyle;
   if (onBlack !== onWhite) return null;
-  return srgbToRgb(onBlack) ?? onBlack;
+  return srgbToRgb(onBlack) ?? hexToRgb(onBlack) ?? onBlack;
 }
 function rgbaParts(rgb) {
   if (!rgb) return null;

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "origam",
-  "version": "2.18.2",
+  "version": "2.18.4",
   "type": "module",
   "description": "origam — a Vue 3 design system with multi-theme design tokens, CSS-first components and TypeScript types.",
   "keywords": [