origam 2.18.3 → 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

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/package.json

@@ -1,6 +1,6 @@
 {
   "name": "origam",
-  "version": "2.18.3",
+  "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": [