ngwr 11.2.0 → 12.1.0

package/types/ngwr-color-picker.d.ts

@@ -232,8 +232,15 @@ declare class WrColorPicker implements FormValueControl<string> {
     protected readonly activeTab: _angular_core.WritableSignal<Tab>;
     /** HSL view of the current colour, computed lazily. */
     protected readonly hslView: _angular_core.Signal<WrHsl>;
-    /** Alpha as integer percent for display in numeric tabs. */
+    /** Alpha as integer percent — the numeric tabs and the alpha slider's `aria-valuenow`. */
     protected readonly alphaPercent: _angular_core.Signal<number>;
+    /** Hue in whole degrees, for the hue slider's `aria-valuenow`. */
+    protected readonly hueValue: _angular_core.Signal<number>;
+    private readonly areaLabel;
+    /** Name of the SV surface, carrying the two values a `role="group"` cannot. */
+    protected readonly resolvedAreaLabel: _angular_core.Signal<string>;
+    protected readonly resolvedHueLabel: _angular_core.Signal<string>;
+    protected readonly resolvedAlphaLabel: _angular_core.Signal<string>;
     protected readonly tabOptions: readonly WrSegmentedOption<Tab>[];
     protected readonly classes: _angular_core.Signal<string>;
     /**
@@ -250,6 +257,19 @@ declare class WrColorPicker implements FormValueControl<string> {
     private lastEmitted;
     constructor();
     protected onPointerDown(event: PointerEvent, surface: Edges): void;
+    /**
+     * Hue and alpha are real one-value sliders, so they take the APG slider keys —
+     * the same set `wr-knob` and `wr-slider` implement, including Home / End.
+     */
+    protected onSliderKeydown(event: KeyboardEvent, surface: 'hue' | 'alpha'): void;
+    /**
+     * The SV canvas is two axes at once, so the keys follow the picture: left and
+     * right run along saturation, up and down along brightness — the directions
+     * the thumb visibly moves. Shift takes ten percent at a time.
+     */
+    protected onAreaKeydown(event: KeyboardEvent): void;
+    /** Leaving a surface is what "touched" means, the same as leaving the hex field. */
+    protected onSurfaceBlur(): void;
     private updateFromEvent;
     protected onHexInput(event: Event): void;
     protected onHexBlur(): void;

package/types/ngwr-confetti.d.ts

@@ -56,9 +56,17 @@ declare class WrConfetti {
     private ctx;
     private particles;
     private rafId;
+    private readonly onResize;
+    constructor();
     /** Spawn a confetti burst with the given (or default) options. */
     fire(options?: WrConfettiOptions): void;
     private ensureCanvas;
+    /**
+     * Give back the canvas and the listener `ensureCanvas()` took from the page,
+     * stop the frame loop, and reset the state both of them guard on so a `fire()`
+     * from a fresh injector rebuilds cleanly.
+     */
+    private teardown;
     private resize;
     private spawn;
     private tick;

package/types/ngwr-config.d.ts

@@ -151,8 +151,17 @@ declare function provideWrConfig(config: WrConfig): EnvironmentProviders;
  * size scale is narrower than {@link WrControlSize} stops compiling here rather
  * than accepting a value it cannot render — the type checker doing the work a
  * parity script would otherwise have to.
+ *
+ * `NoInfer` is what makes that true. Drop it and the guard is a comment again on
+ * every call site that does not pin the generic by hand, which was all but two —
+ * `wr-btn` the only size one among them. Without it `T` has three inference sites;
+ * TypeScript collects all three candidates and keeps the SUPERTYPE, so `pick`'s
+ * `WrControlSize` won and `T` widened to the config's type. `Signal<T>` is
+ * covariant, so the narrower binding stayed assignable and the call compiled clean.
+ * Widening `WrControlSize` by one member used to raise exactly one error, in
+ * `wr-btn`; it now raises nine.
  */
-declare function useConfigValue<T>(binding: Signal<T | null | undefined>, pick: (config: WrConfig) => T | undefined, fallback: T): Signal<T>;
+declare function useConfigValue<T>(binding: Signal<T | null | undefined>, pick: (config: WrConfig) => NoInfer<T> | undefined, fallback: NoInfer<T>): Signal<T>;
 
 /**
  * @license

package/types/ngwr-context-menu-testing.d.ts

@@ -101,13 +101,12 @@ declare class WrContextMenuItemHarness extends ComponentHarness {
     /** The leading icon's registered name, or `null` when the item has no icon. */
     getIconName(): Promise<string | null>;
     /**
-     * Whether the item holds focus.
+     * Whether the item holds the menu's roving focus.
      *
-     * Worth asking, because nothing in this component ever puts it there: unlike
-     * `<wr-dropdown-menu>`, a context menu does not focus its first item on open
-     * and has no arrow-key cursor between items. Focus lands on an item when
-     * something sends it a key — which every keyboard method here does, since the
-     * CDK focuses an element before typing into it.
+     * The menu moves focus onto its first enabled row as the pane renders and the
+     * arrows walk it from there, so this is where the keyboard is. Opening a
+     * submenu hands the cursor to the submenu's own first row, which leaves the
+     * item that owns it unfocused while its pane is up.
      */
     isFocused(): Promise<boolean>;
     /**
@@ -143,8 +142,10 @@ declare class WrContextMenuItemHarness extends ComponentHarness {
      *
      * The keyboard, not the pointer: it opens with no delay (hover waits out
      * 120ms — `openSubmenuByHover()` covers that path) and needs no coordinates,
-     * which jsdom could not supply anyway. Sending the key focuses the item first,
-     * exactly as a roving cursor would have.
+     * which jsdom could not supply anyway. A keyboard open walks INTO the submenu,
+     * so afterwards the cursor is on the submenu's first row and `isFocused()` on
+     * this item is `false` — `openSubmenuByHover()` only shows the pane and leaves
+     * the cursor where it was.
      */
     openSubmenu(timeout?: number): Promise<void>;
     /**
@@ -223,9 +224,10 @@ declare class WrContextMenuItemHarness extends ComponentHarness {
  *   `clickItem()` leaves it closed.
  * - Submenus are a first-class input here rather than a nested trigger, so they
  *   are driven from {@link WrContextMenuItemHarness}.
- * - The menu never takes focus: nothing focuses the first item and there is no
- *   arrow-key cursor between items, so there is no `getFocusedItemText()` to ask
- *   — see `WrContextMenuItemHarness.isFocused()`.
+ * - Focus moves in on EVERY open, where a dropdown's does so only when a
+ *   keyboard opened it. There is no hover trigger here — a right-click, Shift+F10
+ *   or a long-press is always a deliberate request for the menu — so
+ *   `getFocusedItemText()` answers straight after `open()`.
  *
  * **Timing.** The waits are real: a 500ms `setTimeout` for the long-press hold and
  * another 220ms one for the exit animation the pane is held alive through, plus the
@@ -359,6 +361,17 @@ declare class WrContextMenuHarness extends ContentContainerComponentHarness {
     getItems(filters?: WrContextMenuItemHarnessFilters): Promise<WrContextMenuItemHarness[]>;
     /** The labels of this menu's items, in DOM order. */
     getItemTexts(): Promise<string[]>;
+    /**
+     * The label of the item that currently holds focus, or `null` when the
+     * keyboard is elsewhere.
+     *
+     * The menu roves focus rather than drawing a cursor — it lands on the first
+     * ENABLED item as the pane renders, and the arrows walk it over the enabled
+     * items only — so this is the only way to ask where the keyboard is. It answers
+     * `null` once a submenu has taken the cursor: that pane is a separate overlay,
+     * and its own rows are reached through `WrContextMenuItemHarness`.
+     */
+    getFocusedItemText(): Promise<string | null>;
     /**
      * How many separators this menu shows.
      *

package/types/ngwr-context-menu.d.ts

@@ -66,6 +66,18 @@ declare class WrContextMenu {
      */
     protected readonly openMenuId: _angular_core.WritableSignal<string | null>;
     private overlayRef;
+    /**
+     * The open menu's subscription to CDK's keyboard dispatcher, held so that
+     * `closeOverlay()` can drop it — see the unsubscribe there for why the pane's
+     * own disposal is 220 ms too late.
+     */
+    private rootKeys;
+    /**
+     * Where the keyboard was at the moment this menu took it, so a close can put
+     * it back there. Null when it was nowhere in particular (`<body>`) or already
+     * inside a menu pane, neither of which is a place to return to.
+     */
+    private restoreFocusTo;
     /**
      * Panes waiting out their exit animation, keyed by the timer that disposes
      * them.
@@ -149,6 +161,24 @@ declare class WrContextMenu {
     close(): void;
     private openOverlay;
     private closeOverlay;
+    /**
+     * Put the keyboard back where it came from.
+     *
+     * The element that had it when the menu opened comes first: a context menu
+     * hangs on a REGION — a card, a table row — and Shift+F10 / the Menu key fires
+     * `contextmenu` at whatever control inside it the user was actually on, which
+     * is their place in the page.
+     *
+     * The trigger is the fallback, and it needs help to be one. `[wrContextMenu]`
+     * adds no `tabindex` and every shape the docs ship is a plain `<div>`, so
+     * `focus()` on it does nothing at all — the handback silently missed, leaving
+     * the caret in the disposing pane and then on `<body>`, which is the outcome
+     * the call is there to prevent. Lending it `tabindex="-1"` for the call and
+     * taking that back on blur keeps the consumer's DOM as they wrote it; a
+     * permanent `tabindex="0"` would make every right-clickable region a tab stop,
+     * which is their decision and not the library's.
+     */
+    private handBackFocus;
     private cancelLeaveTimer;
     private scheduleLeave;
     static ɵfac: _angular_core.ɵɵFactoryDeclaration<WrContextMenu, never>;
@@ -191,9 +221,17 @@ declare class WrContextMenuItem {
     private readonly scrollStrategies;
     private readonly destroyRef;
     private submenuRef;
+    private submenuKeys;
     private openTimer;
     private closeTimer;
     protected submenuOpen: boolean;
+    /**
+     * Whether the pending open was asked for by the keyboard (→ / Enter / Space)
+     * rather than by hover — only then does the submenu take focus, the same rule
+     * `wr-dropdown` applies to its own open. Sweeping the cursor across a row must
+     * show its submenu without yanking the caret out of it.
+     */
+    private openedByKeyboard;
     /**
      * Id of the submenu's menu element while it is open, published on the item as
      * `aria-controls` — the same contract the root trigger keeps (see
@@ -257,6 +295,24 @@ declare class WrContextMenuItem {
     private cancelOpen;
     private cancelClose;
     private openSubmenu;
+    /**
+     * @internal Keys routed here while this submenu is the topmost overlay: the
+     * arrows walk the rows of the pane the caret is in, and Escape or the arrow
+     * pointing BACK the way the menu cascades steps out one level, returning the
+     * cursor to the row that owns the pane when the cursor was inside it.
+     *
+     * Escape closes this level only, not the whole chain — the APG's rule for a
+     * submenu. It reaches this handler rather than the root's because the
+     * dispatcher stops at the topmost overlay that listens, which is now this one.
+     *
+     * Which is also why the arrows are aimed at the pane holding the caret rather
+     * than at this one. The dispatcher routes by stacking order, not by focus, and
+     * a HOVER-opened submenu is topmost while focus is deliberately still on the
+     * root row the pointer swept off (see `openedByKeyboard`) — so ArrowDown used
+     * to jump into this pane's first row instead of moving down the menu the user
+     * is in. Same reason `wr-dropdown`'s menu handler checks ownership.
+     */
+    private onSubmenuKeydown;
     /** Bound handlers (= preserves identity for removeEventListener). */
     private readonly onSubmenuEnter;
     private readonly onSubmenuLeave;

package/types/ngwr-counter.d.ts

@@ -163,6 +163,7 @@ declare class WrCountUp {
     private readonly host;
     private readonly locale;
     private readonly isBrowser;
+    private readonly platform;
     private readonly destroyRef;
     private rafId;
     private delayTimer;

package/types/{ngwr-date-adapter-fns.d.ts → ngwr-date-adapters-fns.d.ts}

@@ -1,12 +1,34 @@
-import { WrDateAdapter, WrDateFormat } from 'ngwr/date-adapter';
+import { WrDateAdapter, WrDateFormat } from 'ngwr/date';
 import * as i0 from '@angular/core';
 import { EnvironmentProviders } from '@angular/core';
 
 /**
  * {@link WrDateAdapter} backed by `date-fns`. Same `Date` value type as the
- * native adapter, but defers all math, formatting, and parsing to date-fns
- * — pick this when you want more robust locale-aware patterns (`P`, `PP`,
- * `PPP`, `p`) without writing them by hand.
+ * native adapter, but defers all math, formatting, and parsing to date-fns —
+ * pick this when you want its long patterns (`P`, `PP`, `PPP`, `p`) without
+ * writing them by hand.
+ *
+ * **{@link WR_DATE_LOCALE} does not reach `format` or `parse`, and that is not
+ * an oversight.** date-fns resolves those patterns against a date-fns `Locale`
+ * OBJECT rather than a BCP 47 tag, and the objects are separate modules —
+ * mapping a tag onto one would mean importing all of them, which defeats the
+ * tree-shaking that is the reason this is an opt-in entry point. So the named
+ * formats render AND read in en-US whatever the tag says, while
+ * `getFirstDayOfWeek`, `getDayOfWeekNames` and `getMonthNames` go through `Intl`
+ * and do honour it: a calendar heads its columns `пн вт ср` beside a trigger
+ * reading `08/11/2025`. Reading is the sharper edge — `11/08/2025` typed by a
+ * user in a dd/MM locale parses as 8 November, valid and wrong.
+ *
+ * The lever is date-fns's own module default, and the adapter passing no locale
+ * is precisely what keeps it working. Set it once at bootstrap, or take
+ * `provideWrLuxonAdapter()`, which forwards the tag itself:
+ *
+ * ```ts
+ * import { setDefaultOptions } from 'date-fns';
+ * import { ru } from 'date-fns/locale';
+ *
+ * setDefaultOptions({ locale: ru });
+ * ```
  *
  * @example
  * ```ts
@@ -56,8 +78,13 @@ declare class WrDateFnsAdapter extends WrDateAdapter<Date> {
 
 /**
  * Register the {@link WrDateFnsAdapter} so date-pickers / calendars in this
- * app use `date-fns` for all math and formatting. Pass `locale` to override
- * the BCP 47 tag.
+ * app use `date-fns` for all math and formatting.
+ *
+ * `locale` sets {@link WR_DATE_LOCALE}, which this adapter reads for the first
+ * day of the week and nothing else — its `format` and `parse` do not pass a
+ * locale to date-fns. For localized month names and patterns, set date-fns's own
+ * module default with `setDefaultOptions`, or use the luxon adapter, which does
+ * thread the tag through everything.
  *
  * @example
  * ```ts

package/types/{ngwr-date-adapter-luxon.d.ts → ngwr-date-adapters-luxon.d.ts}

@@ -1,5 +1,5 @@
 import { DateTime } from 'luxon';
-import { WrDateAdapter, WrDateFormat } from 'ngwr/date-adapter';
+import { WrDateAdapter, WrDateFormat } from 'ngwr/date';
 import * as i0 from '@angular/core';
 import { EnvironmentProviders } from '@angular/core';
 

package/types/ngwr-date-picker-testing.d.ts

@@ -101,18 +101,23 @@ type Unit = (typeof UNITS)[number];
  * independently instead of by CSS nth-of-type gymnastics.
  *
  * Units are addressed by position, not by the boxes' `aria-label`: every string
- * in this panel is still hard-coded English (the box labels, the steppers'
- * "Increment hours", the AM/PM text), so keying on them would make this harness
- * the thing that breaks when they are moved into the i18n catalog. Column order
- * is the layout contract.
+ * in this panel now resolves through the i18n catalog (`datePicker.hours`,
+ * `datePicker.incrementHours`, `datePicker.am` …), so keying on them would make
+ * this harness answer in whatever locale the app under test is configured for.
+ * Column order is the layout contract.
  *
  * @internal
  */
 declare class WrTimePanelHarness extends ComponentHarness {
     static hostSelector: string;
-    /** The stepper's value as `HH:MM`, plus `:SS` and ` AM`/` PM` when those columns exist. */
+    /** The stepper's value as `HH:MM`, plus `:SS` and a space-joined {@link getMeridiem} when those columns exist. */
     getTimeText(): Promise<string>;
-    /** `'AM'` / `'PM'`, or `null` when the stepper is in 24-hour mode. */
+    /**
+     * The meridiem column's rendered text, or `null` when the stepper is in
+     * 24-hour mode. `'AM'` / `'PM'` on the built-in fallbacks — it reads whatever
+     * `datePicker.am` / `datePicker.pm` resolve to, so a configured catalog
+     * changes the answer.
+     */
     getMeridiem(): Promise<string | null>;
     /**
      * Type into the boxes named by `fields`, leaving the rest alone.

package/types/ngwr-date-picker.d.ts

@@ -1,7 +1,7 @@
 import * as _angular_core from '@angular/core';
 import { ElementRef } from '@angular/core';
 import { FormValueControl } from '@angular/forms/signals';
-import { WrDateFormat } from 'ngwr/date-adapter';
+import { WrDateFormat } from 'ngwr/date';
 
 /**
  * Unified date / time / date-time picker. Same `<input>` + popover skeleton
@@ -143,6 +143,10 @@ declare class WrDatePicker implements FormValueControl<Date | null> {
      * skip the echo of our own edits (so a live keystroke's raw text is never
      * reformatted mid-type). */
     private lastValue;
+    /** The format the sync effect last rendered with. Paired with `lastValue`
+     * because the echo guard has to answer "is the display still current", and a
+     * `[format]` / `[mode]` change makes it stale with the value untouched. */
+    private lastFormat;
     constructor();
     protected onInput(event: Event): void;
     protected onBlur(): void;
@@ -320,9 +324,9 @@ declare class WrDateRangePicker implements FormValueControl<WrDateRange | null>
     /** Resolved format — falls back to a mode-appropriate default. */
     protected readonly resolvedFormat: _angular_core.Signal<string>;
     protected readonly isDateTime: _angular_core.Signal<boolean>;
-    protected readonly triggerLabel: string;
-    protected readonly startLabel: string;
-    protected readonly endLabel: string;
+    protected readonly triggerLabel: _angular_core.Signal<string>;
+    protected readonly startLabel: _angular_core.Signal<string>;
+    protected readonly endLabel: _angular_core.Signal<string>;
     private readonly panelLabelRange;
     private readonly panelLabelRangeDateTime;
     /**

package/types/{ngwr-date-adapter.d.ts → ngwr-date.d.ts}

@@ -145,6 +145,18 @@ declare class WrNativeDateAdapter extends WrDateAdapter<Date> {
     format(date: Date, formatKeyOrString: WrDateFormat | (string & {})): string;
     parse(value: string, formatKeyOrString: WrDateFormat | (string & {})): Date | null;
     getFirstDayOfWeek(): number;
+    /**
+     * One `Intl.DateTimeFormat` per named format, built once.
+     *
+     * Constructing one is the expensive part of `format()`, and this adapter is
+     * called per CELL: `wr-event-calendar` builds an `aria-label` for every time
+     * slot on every day, so a week view asked for hundreds of identical
+     * formatters. `locale` is injected once and never changes for the life of the
+     * adapter, so the cache needs no invalidation — that is the whole reason it
+     * can be this simple.
+     */
+    private readonly formatters;
+    private intl;
     getDayOfWeekNames(style: 'narrow' | 'short' | 'long'): readonly string[];
     getMonthNames(style: 'narrow' | 'short' | 'long'): readonly string[];
     private formatWithTokens;
@@ -185,12 +197,19 @@ declare function provideWrDateAdapter(options?: WrDateAdapterOptions): Environme
  */
 
 /**
- * BCP 47 locale tag used by {@link WrDateAdapter} implementations for
- * formatting, parsing, and locale-derived defaults (first day of week,
- * month / day names). Defaults to `navigator.language` in the browser and
- * `'en-US'` on the server.
+ * BCP 47 locale tag the {@link WrDateAdapter} implementations read. Defaults to
+ * `navigator.language` in the browser and `'en-US'` on the server; override via
+ * {@link provideWrDateAdapter}'s `locale` option.
  *
- * Override via {@link provideWrDateAdapter}'s `locale` option.
+ * **How far it reaches depends on the adapter, and the difference matters.**
+ * The luxon adapter threads it through everything — every `DateTime` is
+ * constructed with it, and `format` / `parse` call `setLocale`. The date-fns
+ * adapter reads it only for locale-DERIVED defaults (first day of week); its
+ * `format` and `parse` pass no locale to date-fns, so they stay on that
+ * library's module default. Setting this token and expecting French month names
+ * out of `WrDateFnsAdapter` gets English ones, and the parse side of that
+ * mismatch is silent rather than loud — see the adapter's own class docs for the
+ * lever (`setDefaultOptions`).
  */
 declare const WR_DATE_LOCALE: InjectionToken<string>;
 

package/types/ngwr-dialog.d.ts

@@ -4,6 +4,7 @@ import { OverlayRef } from '@angular/cdk/overlay';
 import * as i0 from '@angular/core';
 import { ComponentRef, InjectionToken, ElementRef } from '@angular/core';
 import { ReplaySubject } from 'rxjs';
+import * as i1 from '@angular/cdk/scrolling';
 
 /**
  * @license
@@ -87,6 +88,15 @@ interface WrDialogOptions<D = unknown> {
     readonly closeOnBackdropClick?: boolean;
     /** When `true`, the Escape key closes the dialog. @default true */
     readonly closeOnEscape?: boolean;
+    /**
+     * When `true`, the dialog closes as soon as the URL changes — the Back button
+     * and any `router.navigate()` alike. Nothing else ties a dialog to the route
+     * it was opened on, so turning this off leaves the pane, its backdrop and its
+     * focus trap over whatever page the app navigates to. Turn it off only for a
+     * dialog that OWNS the navigation (a wizard that keeps its step in the URL).
+     * @default true
+     */
+    readonly closeOnNavigation?: boolean;
     /**
      * Render a dismiss (×) button in the panel's top-right corner. Set `false`
      * when the content supplies its own close affordance, or when the dialog must
@@ -139,7 +149,24 @@ declare class WrDialog {
     private readonly isBrowser;
     private readonly responsiveConfig;
     private readonly i18n;
+    private readonly location;
     open<C, R = unknown, D = unknown>(component: ComponentType<C>, options?: WrDialogOptions<D>): WrDialogRef<C, R>;
+    /**
+     * Tie the dialog's lifetime to the URL it was opened on.
+     *
+     * Nothing else does. The overlay belongs to a root service and is dismissed
+     * only by the backdrop, Escape or an explicit `close()`, so pressing Back
+     * swapped the routed view underneath and left the modal pane, its backdrop and
+     * its focus trap sitting over a page the user never opened them on.
+     *
+     * `onUrlChange`, not `Location.subscribe()` — which is what CDK's own
+     * `disposeOnNavigation` uses: `subscribe` fires on popstate alone, so an
+     * in-app `router.navigate()` left the dialog standing. And `dialogRef.close()`
+     * rather than disposing the overlay behind the ref's back, which would never
+     * emit `closed`, never destroy the focus trap, and leave `awaitClose()`
+     * pending forever.
+     */
+    private watchNavigation;
     /**
      * The dismiss button's accessible name.
      *
@@ -242,6 +269,16 @@ declare class WrDialogTitle {
 /**
  * Styles the scrollable body section of a dialog.
  *
+ * `CdkScrollable` is a host directive because this element is a real scroll
+ * container (`overflow: auto`) and an anchored overlay opened from inside it has
+ * to follow its trigger. CDK's `reposition()` strategy listens to
+ * `ScrollDispatcher`, which is fed by registered scrollables plus ONE
+ * non-capturing `document` listener — and element `scroll` does not bubble, so
+ * without the registration a `<wr-select>` halfway down a long dialog form kept
+ * its panel pinned to the viewport while the trigger scrolled away. Angular
+ * Material carries the same host directive on `MatDialogContent` for the same
+ * reason.
+ *
  * @example
  * ```html
  * <div wrDialogContent>…body…</div>
@@ -249,7 +286,7 @@ declare class WrDialogTitle {
  */
 declare class WrDialogContent {
     static ɵfac: i0.ɵɵFactoryDeclaration<WrDialogContent, never>;
-    static ɵdir: i0.ɵɵDirectiveDeclaration<WrDialogContent, "[wrDialogContent]", never, {}, {}, never, never, true, never>;
+    static ɵdir: i0.ɵɵDirectiveDeclaration<WrDialogContent, "[wrDialogContent]", never, {}, {}, never, never, true, [{ directive: typeof i1.CdkScrollable; inputs: {}; outputs: {}; }]>;
 }
 
 /**

package/types/ngwr-divider.d.ts

@@ -65,6 +65,31 @@ declare class WrDivider {
      */
     readonly align: _angular_core.InputSignal<WrDividerAlign>;
     protected readonly classes: _angular_core.Signal<string>;
+    private readonly host;
+    /**
+     * The consumer's own `aria-label`, resolved on the first sync — `undefined`
+     * until then, which is how "not looked at yet" stays distinct from "they wrote
+     * none".
+     */
+    private authored;
+    constructor();
+    /**
+     * Name the separator with the label it projects.
+     *
+     * `role="separator"` makes the host's children presentational and a separator
+     * takes its accessible name from the author alone — so `<wr-divider>OR</wr-divider>`
+     * reaches assistive tech as an unnamed rule while everyone else reads "OR".
+     * Copying the label into `aria-label` is the only way to expose it without giving
+     * up the role, and the two can never disagree because one is the source of the
+     * other.
+     *
+     * Written straight to the DOM rather than through a host binding, for two
+     * reasons a binding cannot cover: the label is projected content, so an
+     * interpolation or an `@if` can change it while the divider stays put; and a
+     * binding resolving to `null` would strip an `aria-label` the consumer wrote
+     * themselves — theirs is the author name already and is never touched.
+     */
+    private syncLabel;
     static ɵfac: _angular_core.ɵɵFactoryDeclaration<WrDivider, never>;
     static ɵcmp: _angular_core.ɵɵComponentDeclaration<WrDivider, "wr-divider", never, { "color": { "alias": "color"; "required": false; "isSignal": true; }; "type": { "alias": "type"; "required": false; "isSignal": true; }; "width": { "alias": "width"; "required": false; "isSignal": true; }; "align": { "alias": "align"; "required": false; "isSignal": true; }; }, {}, never, ["*"], true, never>;
 }

package/types/ngwr-donut-chart-testing.d.ts

@@ -31,11 +31,15 @@ interface WrDonutChartLegendEntry {
  * Test harness for `<wr-donut-chart>`.
  *
  * **The ring itself is unreadable, and that is by design.** The slices are SVG
- * paths inside an `aria-hidden` drawing: a screen reader is given the chart's
+ * paths inside a `role="img"` drawing: a screen reader is given that drawing's
  * `aria-label` and nothing else, and a spec cannot get a label or a value off a
  * path's `d`. {@link getLegend} is where the numbers are — which is also the
- * argument for keeping `showLegend` on, since with it off the chart's data has no
- * textual form at all.
+ * argument for keeping `showLegend` on, since with it off the only other text is
+ * whatever {@link getCenterValue} and {@link getCenterLabel} were given.
+ *
+ * The name is read off the `<svg>` rather than off the surface that wraps it, and
+ * the two are not interchangeable: `img` makes its whole subtree presentational, so
+ * a name on the wrapper would take the centre text down with it.
  *
  * {@link getSliceCount} is therefore the one thing the ring answers: how many
  * wedges were drawn. Compare it with the legend's length to catch a slice that was

package/types/ngwr-donut-chart.d.ts

@@ -23,9 +23,9 @@ interface WrDonutSegment {
 declare class WrDonutChart {
     readonly segments: _angular_core.InputSignal<readonly WrDonutSegment[]>;
     /**
-     * Accessible name of the chart. The ring is `aria-hidden` and the legend is optional,
-     * so with `showLegend: false` this is the only thing a screen reader gets. Falls back
-     * to `donutChart.label`.
+     * Accessible name of the drawing. The arcs carry no text and the legend is optional, so
+     * with `showLegend: false` this and the centre text are the whole of what a screen reader
+     * gets. Falls back to `donutChart.label`.
      */
     readonly ariaLabel: _angular_core.InputSignal<string | null>;
     protected readonly resolvedAriaLabel: _angular_core.Signal<string>;

package/types/ngwr-drag-drop.d.ts

@@ -21,8 +21,21 @@ interface WrSortableReorderEvent<T> {
  * emitted via 2-way `[(items)]`.
  *
  * Drop a single template — it's rendered per item with `let-item
- * let-index="index"`. Add `[handle]="true"` (or `[wrDragHandle]` inside
- * your template) to restrict drag start to a handle element.
+ * let-index="index"`. Put `wrDragHandle` on an element inside that
+ * template to restrict drag start to a handle; there is no input for
+ * it, the directive's presence is the switch.
+ *
+ * Every row is a tab stop: Space or Enter picks it up, the arrow keys move it,
+ * Space or Enter drops it and Escape puts it back. CDK's `cdkDrag` ships no key
+ * handling of its own, so without this the component's only function was
+ * unreachable from a keyboard.
+ *
+ * What that does NOT answer is WCAG 2.5.7, which asks for a POINTER alternative
+ * to the drag. Click-to-pick-up is the obvious candidate and is not safe here:
+ * the CDK's drag-drop bundle installs no click suppressor of any kind, so the
+ * mouseup ending a drag still produces a click, and a row that grabbed itself on
+ * click would be picking itself straight back up. A visible move-up /
+ * move-down affordance is the remaining answer, and that is a design change.
  *
  * @example
  * ```html
@@ -64,7 +77,48 @@ declare class WrSortableList<T = unknown> {
     /** Fired after a successful reorder with the new array + indices. */
     readonly reorder: _angular_core.OutputEmitterRef<WrSortableReorderEvent<T>>;
     protected readonly rowTemplate: _angular_core.Signal<TemplateRef<any>>;
+    private readonly injector;
+    private readonly rowEls;
+    /** Index of the row the keyboard is holding, or `null` when nothing is held. */
+    protected readonly grabbedIndex: _angular_core.WritableSignal<number | null>;
+    /** Live-region text. Written by the keyboard path only. */
+    protected readonly announcement: _angular_core.WritableSignal<string>;
+    /** Links every row to the key model via `aria-describedby`. */
+    protected readonly keyHelpId: string;
+    protected readonly resolvedKeyHelp: _angular_core.Signal<string>;
+    private readonly grabbedText;
+    private readonly movedText;
+    private readonly droppedText;
+    private readonly cancelledText;
+    /** Where the held row started. Escape puts it back there. */
+    private grabOrigin;
+    /** True while a keyboard move is handing focus back — see `onRowFocusout`. */
+    private restoringFocus;
     protected onDrop(event: CdkDragDrop<T[]>): void;
+    /**
+     * The keyboard reorder path: pick up, move, drop — deliberately a two-step
+     * grab rather than "an arrow moves the focused row", so that arrowing through
+     * a list a user is only reading can never rearrange it.
+     *
+     * Keys are handled only when the ROW itself is the event target; a button or
+     * an input projected into the row template keeps every key it would normally
+     * get.
+     */
+    protected onRowKeydown(event: KeyboardEvent, index: number): void;
+    /**
+     * Focus leaving a held row ends the gesture as a drop rather than dropping the
+     * change on the floor — `[(items)]` has already been written by then, so a
+     * silent release would leave `reorder` never reporting a move that happened.
+     * The guard is what makes it safe: moving a focused node in the DOM blurs it,
+     * so every keyboard move fires this too.
+     */
+    protected onRowFocusout(): void;
+    private grab;
+    private moveGrabbed;
+    private drop;
+    private cancelGrab;
+    private relocate;
+    private position;
     static ɵfac: _angular_core.ɵɵFactoryDeclaration<WrSortableList<any>, never>;
     static ɵcmp: _angular_core.ɵɵComponentDeclaration<WrSortableList<any>, "wr-sortable-list", never, { "items": { "alias": "items"; "required": true; "isSignal": true; }; "orientation": { "alias": "orientation"; "required": false; "isSignal": true; }; "disabled": { "alias": "disabled"; "required": false; "isSignal": true; }; "lockAxis": { "alias": "lockAxis"; "required": false; "isSignal": true; }; "dragStartDelay": { "alias": "dragStartDelay"; "required": false; "isSignal": true; }; "trackBy": { "alias": "trackBy"; "required": false; "isSignal": true; }; }, { "items": "itemsChange"; "reorder": "reorder"; }, ["rowTemplate"], never, true, never>;
 }