4 Commits

Author	SHA1	Message	Date
Guillem Arias Fauste	77dda53ffb	feat(ds): one canonical focus ring across primitives (#2140) ... * feat(ds): one canonical focus ring across primitives (#2136) Replaces the grab-bag of per-primitive focus indicators (neutral ring-alpha-black/white, outline-gray-900/white, faint form-field ring-4) with a single recipe — the #1737 accessibility follow-up. - New --color-focus-ring token: blue-600 (light) / blue-500 (dark), >=4:1 against both surfaces. - Canonical .focus-ring / .focus-ring-within in components.css: a 2px outline + 2px offset on :focus-visible only. Outline (not a box-shadow ring) so the offset gap is transparent on any surface with no layout shift; :focus-visible so it never shows for mouse/touch. - Applied to every focusable DS primitive: Button (had none), Link, Disclosure summary, Tabs nav, MenuItem (replaces the browser-default box), SearchInput, Tooltip trigger, Popover trigger, Select panel (focus-within), Toggle (peer-driven outline-focus-ring). .form-field adopts it via :focus-within, replacing the ~1:1 ring-4. - Dialog close button is a DS::Button icon variant, so it inherits the focus-visible-only ring and keeps no resting border (fixes "stuck ring"). Verified in-browser, light+dark: focus-visible ring on button, input, and full-width menu row — consistent blue 2px+offset, legible on both surfaces. Remaining follow-up: >=44px touch targets (disclosure trigger, composer send); bespoke notification / account-new close buttons that still carry a permanent border. * fix(ds): #2136 interactive-state follow-ups — touch target + close-button chrome - Disclosure default trigger: add min-h-11 (44px) so the standalone disclosure summary clears the touch-target minimum (was px-3 py-2 ~36px). Composer send + the coming-soon icons are already DS::Button icon/md (w-11 h-11). - Notification close buttons (sync_toast, notice): drop the resting border-alpha-black-50 box ("frame shouts, glyph muted"); keep a bg-container + shadow-xs chip so the corner control stays visible over the page, and brighten the muted glyph on hover (text-subdued -> hover:text-primary). * refactor(ds): focus ring -> neutral hugging box-shadow (was blue outline) Per design feedback: the blue 2px outline + 2px offset read as a loud, detached frame on the otherwise-neutral UI. Switch the canonical .focus-ring to a soft box-shadow ring that hugs the control (follows border-radius, no gap), in the theme-aware neutral focus-ring token (alpha-black/white-400). Transparent outline kept as a forced-colors fallback; toggle peer-driver switched from outline-* to ring-* to match. Still one token, :focus-visible only. Strength is tunable (currently subtle ~1.5:1). * fix(ds): focus ring vanished on shadowed controls — outline, not box-shadow The neutral box-shadow ring lived in the components layer, so any utility-layer shadow-* (or .form-field's focus-within:shadow-none) on the same element overrode it and the ring silently disappeared on shadowed buttons/inputs. Draw the same subtle neutral ring with a hugging `outline` (outline-offset: 0) instead — a separate property with no box-shadow conflict, and it doubles as the forced-colors indicator. Toggle peer-driver switched ring-* -> outline-* to match. Look is unchanged (neutral, hugging, subtle); it just no longer vanishes. * fix(a11y): enlarge sync-toast close-button touch target (p-0.5 -> p-1.5) The hover-revealed close button had ~2px padding around a 20px icon (~24px total), at the WCAG 2.5.8 AAA boundary. p-1.5 brings the interactive area to ~32px. Addresses CodeRabbit review on #2140. * fix(ds): keep form-field's resting halo; stop the outline color flash Two testing findings: - .form-field reverts to its original always-on soft ring (focus-within ring-4 at low alpha, theme-aware) instead of adopting the keyboard-only outline. It's a resting decoration, not a focus indicator, and the lower-opacity halo was the better look. The canonical block's comment documents the deliberate opt-out. - .focus-ring/.focus-ring-within now carry a base transparent 2px outline so consumers with transition-all (form-field had it) animate transparent -> token on focus instead of passing through currentColor, which flashed as a black border appearing and then fading out. * feat(ds): focus-ring token clears WCAG 3:1 non-text contrast alpha-black-400 (20%) measured ~1.6:1 against white — visible but below the AA bar for focus indicators. Bump to the 700 stop (50%): ~3.95:1 on light containers, ~4.6:1 on dark. Recipe unchanged; one token edit via tokens:build. * fix(ds): ring the hand-rolled privacy toggle too The header pair showed two different focus treatments: panel-right (a DS::Button) got the new token ring while the hand-rolled privacy toggle next to it fell back to the browser-default ring — the sweep covered DS primitives but not bespoke buttons. Both privacy toggles (mobile + desktop) now carry .focus-ring. Also documents the transition interplay on the focused-state rule: consumers with transition-colors fade the ring in over 150ms because Tailwind v4's color transition list includes outline-color. Verified settled value at the intended 50% alpha via Playwright. * fix(ds): ring the sidebar and settings nav links The reshoot caught both nav species falling back to the browser's blue default ring — main sidebar items and settings nav items are bespoke link_to markup the primitive sweep missed, and they're the primary keyboard path in the app. Both adopt .focus-ring (main nav adds rounded-lg so the outline follows a shape). * fix(ds): retire the legacy base-layer button ring for the canonical outline The @layer base button rule still painted a ring-2 ring-offset-2 box-shadow on :focus-visible. Box-shadow and outline are independent properties, so .focus-ring (an outline) could never clear it and every button-tag primitive double-painted both indicators on keyboard focus. Apply the canonical recipe to the base button rule itself: every <button> now gets the transparent resting outline + focus-ring token on :focus-visible by default. Two bespoke buttons suppressed the outline with focus:outline-none and relied on the base ring for their keyboard indicator (category dropdown rows, the sign-up password toggle). Drop the suppression so they pick up the canonical outline — :focus-visible keeps it keyboard-only, which is what the suppression was protecting against anyway. * fix(ds): segmented control adopts the canonical focus recipe The segment rule inlined its own focus-visible outline (offset 2, alpha-400 colors) with a comment noting it was temporary until the canonical token landed — this branch is that token. Drop the inlined utilities: button segments get the outline from the base button rule, and link segments now carry .focus-ring.	2026-06-11 16:05:13 +02:00
Guillem Arias Fauste	e30ccd94af	fix(design-system): DS::Tooltip a11y — focusable trigger, keyboard parity, Esc dismiss (#1845) ... * fix(design-system): DS::Tooltip a11y — focusable trigger, keyboard parity, Esc dismiss Closes #1747. Five fixes on the tooltip primitive. 1. **Tooltip anchor not in a11y tree.** The trigger was a bare Lucide icon, which Lucide renders with `aria-hidden="true"`. The tooltip target had `role="tooltip"` but nothing referenced it, so AT users had no way to discover the description. Wrap the icon in a focusable `<button type="button">` with `aria-describedby="<tooltip-id>"` so the underlying icon stays `aria-hidden` and the button picks up the description binding. 2. **Stable per-instance id.** Each DS::Tooltip now mints a `tooltip-<8-char hex>` id wired between the trigger's `aria-describedby` and the tooltip's `id`. 3. **Keyboard parity.** Hover-only triggers locked keyboard-only users out. Add `focusin` / `focusout` listeners on the controller element so Tab onto the trigger reveals the tooltip, Tab away dismisses it. 4. **Esc-to-dismiss.** Matches the WAI-ARIA tooltip pattern. `Escape` while the tooltip is open closes it without removing focus from the trigger. 5. **Resize-safe width cap.** Replace the hard-coded `max-w-[200px]` with `max-w-[20rem]` so the tooltip scales with the user's root font-size setting (large-text accessibility pref). Slightly wider visual cap (320px @ default) but no longer clips on text-zoom. Plus: docstring note that tooltip content must be non-interactive (no buttons / links / form controls inside) — `aria-describedby` exposes content as a description, not as an interactive subtree. Callers needing actions should reach for a popover/menu primitive. API unchanged. Existing 30+ DS::Tooltip callsites work without modification — they all pass `text:`-only payloads, which still render correctly under the new markup. * fix(review): as: option + alpha focus-ring on DS::Tooltip Addresses two AI review findings on #1845: 1. **Button-inside-summary spec violation.** Wrapping the icon in `<button>` regressed keyboard/AT behavior at 13 callsites where DS::Tooltip lives inside a `<summary>` (8 provider items, lunchflow disclosure, activity_date, 4 simplefin badges). HTML's content model forbids interactive content inside `<summary>`; browsers and AT can drop focus or conflate activation with the disclosure toggle. Add `as:` parameter — default `:button` preserves the standalone a11y wrap; `:span` renders a non-focusable wrapper for summary-nested usage. `focusin` bubbles up to the controller from the ancestor `<summary>`, so keyboard tooltips still appear on tab. Migrate the 13 in-summary callsites to `as: :span`. 2. **Raw palette focus ring → alpha tokens.** Swap `outline-gray-900 theme-dark:focus-visible:outline-white` to the established focus-ring pattern `focus-visible:ring-2 focus-visible:ring-alpha-black-300 theme-dark:focus-visible:ring-alpha-white-300` — matches the DS::Toggle fix landed in #1843 review and provider_card / form-field tokens. * fix(review): bind tooltip focus on ancestor <summary> Codex P2 follow-up on #1845: \`as: :span\` renders a non-focusable trigger inside the disclosure \`<summary>\`. Keyboard users hit Tab and focus lands on the summary itself; \`focusin\` fires on the summary and bubbles UP — never down to a descendant span — so the existing listener on \`this.element\` never fires and the tooltip stays hidden for keyboard-only users on every in-summary row (provider _item partials, lunchflow disclosure, activity_date, simplefin badges). My earlier reply that the focusin "bubbles up to the Stimulus controller on the outer span" was wrong about the direction; \`focusin\` only bubbles upward. In \`addEventListeners\`, resolve \`this.element.closest("summary")\` and bind \`focusin\` / \`focusout\` / \`keydown\` on it too. Track the ancestor on the controller and undo the bindings in \`removeEventListeners\` so reconnect-on-Turbo cycles don't leak. Update the template comment to reflect the actual mechanism. * docs(ds-tooltip): correct as=:span comment to match controller mechanism --------- Signed-off-by: Juan José Mata <juanjo.mata@gmail.com> Co-authored-by: Juan José Mata <juanjo.mata@gmail.com>	2026-05-20 18:17:51 +02:00
Guillem Arias Fauste	0fe1e06645	refactor(design-system): migrate fg-* utilities to text-* and remove namespace (#1626) ... * refactor(design-system): migrate fg-* utilities to text-* and remove namespace The design system carried two parallel namespaces for foreground colors: text-* (canonical, ~2,000 uses) and fg-* (32 uses). Most fg-* tokens were 1:1 duplicates of a text-* counterpart. fg-gray was nearly identical to text-secondary, with a one-step shade difference in dark mode. This PR migrates all 32 usages to their text-* equivalents and removes the fg-* block from the design tokens. Closes #1606. Mapping: - fg-inverse -> text-inverse (20 usages, identical light/dark values) - fg-gray -> text-secondary (7 usages; light values match, dark is one step lighter: gray-300 vs gray-400) - fg-primary -> text-primary (3 usages, identical values) - fg-subdued -> text-subdued (2 usages, identical values) The four other fg-* tokens (fg-contrast, fg-primary-variant, fg-secondary, fg-secondary-variant) had zero usages despite being defined; they are removed without replacement. JSON / build: - design/tokens/sure.tokens.json: $version 1.0.0 -> 2.0.0 (breaking schema change per the policy added in #1620). 8 fg-* token definitions removed. - button-bg-ghost-hover's dark value still references "fg-inverse" internally; rewritten to "bg-gray-800 text-inverse" so the cleanup doesn't break that utility. - _generated.css regenerated. 42 utility blocks now (was 50). Lookbook tokens preview: - The Text & foregrounds section dropped its split between text-* (canonical) and fg-* (legacy). Now a single section listing the five text-* utilities. The "(legacy)" framing is gone since there's no legacy left. README: - design/tokens/README.md's button-bg-ghost-hover edge-case example updated to reflect the new "bg-gray-800 text-inverse" dark value. Visual review needed in dark mode: - Anywhere icons use the application_helper#icon helper with color: "default" (most icons in the app). The default class moved from fg-gray (gray-400 dark) to text-secondary (gray-300 dark), so default-color icons render slightly lighter in dark mode. - DS::Buttonish icons in secondary buttons (same shade shift). - DS::Link icons (same). - Time series chart axes (same). - All tooltips, account add flow, settings hostings buttons, invitations, AI consent, family export, danger-zone buttons -- these used fg-inverse, which is identical to text-inverse, so no visual change expected. * fix(design-system): use inverse pair on tooltips for readable dark mode * fix(lookbook): use semantic tokens in menu preview header text * fix(lookbook): set text-primary on layout body so previews inherit theme * fix(design-system): keep shadows dark-toned in dark mode Inverting shadows to white|8% on dark surfaces produces a halo effect rather than an elevation cue, and stacks redundantly with the alpha-white 1px ring already in shadow-border-*. Switch dark-mode shadows to black at progressively higher alpha (25%/30%/35%/40%/50% for xs..xl) so they read as actual cast shadows on near-black surfaces. Surface-tint differences and the existing alpha-white border ring continue to handle elevation hierarchy and edge definition. Approach matches Material 3, Apple HIG, IBM Carbon, Refactoring UI, and the dark-mode shadows used in Linear/Vercel/Stripe. * fix(design-system): set text-primary on DS::Dialog element Browser UA stylesheets apply color: black directly to <dialog>, which overrides ancestor inheritance even when a body or html ancestor sets a theme-aware color. Unstyled child content then renders black regardless of theme. Setting text-primary on the dialog element itself defeats the UA override and lets descendants inherit the semantic token. * fix(lookbook): use shadow css vars in effects preview so dark theme renders * Revert "fix(design-system): keep shadows dark-toned in dark mode" This reverts commit 3e9d76ed0beb5ac5f2acbad61e4d1c39eadc9ac2. * fix(design-system): use opacity-70 instead of text-inverse/70 in value tooltip The custom @utility text-inverse expands to @apply text-white and isn't modifier-aware, so text-inverse/70 produced no CSS at all and the muted labels fell through to inherited color (invisible on the white pill in dark mode). Replace with text-inverse + opacity-70. Same visual effect, works with the existing utility definition.	2026-05-04 00:50:52 +02:00
Zach Gollwitzer	e8eb32d2ae	Start and end balance breakdown in activity view (#2466) ... * Initial data objects * Remove trend calculator * Fill in balance reconciliation for entry group * Initial tooltip component * Balance trends in activity view * Lint fixes * trade partial alignment fix * Tweaks to balance calculation to acknowledge holdings value better * More lint fixes * Bump brakeman dep * Test fixes * Remove unused class	2025-07-18 17:56:25 -04:00