@@ -739,6 +739,102 @@ describe("grid.css cascade contract", () => {
     ).toEqual([]);
   });
 
+  describe("filter funnel touch target (WCAG 2.5.8)", () => {
+    /**
+     * The funnel used to be an 18x18 button and nothing else, which is the tap
+     * target a phone got on every filterable column header. WCAG 2.5.8 (Target
+     * Size, Minimum) asks for 24x24 CSS px.
+     *
+     * These are source assertions, not measurements, because jsdom refuses to
+     * compute pseudo-element styles at all ("Not implemented: Window's
+     * getComputedStyle() method: with pseudo-elements") and lays nothing out
+     * regardless. The measurement that actually proved the fix was a hit-test
+     * sweep — `document.elementFromPoint` over every pixel around the funnel —
+     * run on an iPhone 13 profile in both Chromium and WebKit. What is pinned
+     * here is the geometry that measurement depends on, so a later edit that
+     * quietly breaks one of these invariants fails in CI rather than on a
+     * phone.
+     */
+    const funnelRule = (css: string) =>
+      css.match(
+        /:where\(\[data-pretable-filter-funnel\]\)\s*\{([\s\S]*?)\}/,
+      )?.[1];
+    const afterRule = (css: string) =>
+      css.match(
+        /:where\(\[data-pretable-filter-funnel\]\)::after\s*\{([\s\S]*?)\}/,
+      )?.[1];
+
+    test("the hit area is a 24x24 pseudo-element, and the glyph stays 18x18", () => {
+      const css = fs.readFileSync(GRID_CSS, "utf8");
+      const base = funnelRule(css);
+      expect(base, "no [data-pretable-filter-funnel] rule found").toBeDefined();
+      // The drawn control must NOT grow: the header is dense by design, and the
+      // hover chip and focus ring are painted on this box.
+      expect(base).toMatch(/width:\s*18px/);
+      expect(base).toMatch(/height:\s*18px/);
+
+      const after = afterRule(css);
+      expect(after, "no funnel ::after hit-area rule found").toBeDefined();
+      expect(after).toMatch(/content:\s*""/);
+      expect(after).toMatch(/width:\s*24px/);
+      expect(after).toMatch(/height:\s*24px/);
+    });
+
+    test("the hit area is out of flow, so it cannot resize the header box", () => {
+      // @pretable/ui's readDensity and @pretable/react's virtualisation both
+      // measure header and row height in JS. Anything that grows the header's
+      // painted box desynchronises painted layout from measured layout, so the
+      // extra 6px has to come from an absolutely positioned box — not from
+      // padding on the button, and not from a taller button.
+      const css = fs.readFileSync(GRID_CSS, "utf8");
+      expect(afterRule(css)).toMatch(/position:\s*absolute/);
+      // ...which needs the button as its containing block.
+      expect(funnelRule(css)).toMatch(/position:\s*relative/);
+      // No padding on the button itself — that WOULD grow its border box.
+      expect(funnelRule(css)).toMatch(/padding:\s*0/);
+    });
+
+    test("the hit area grows leftward only, clear of the 4px resize strip", () => {
+      // @pretable/react parks the funnel slot at `left: -22` and the resize
+      // strip at `left: -4` off the column's trailing edge, so the funnel's
+      // right edge is flush against the strip.
+      //
+      // The strip itself is never at risk: it declares `z-index: 2` inside the
+      // overlay anchor's stacking context, so it hit-tests above the funnel
+      // whatever the funnel does. Measured on an iPhone 13, a centred hit area
+      // takes exactly zero of the strip's pixels. What it takes is the
+      // FUNNEL's: 3 of its 24px land under the strip, unreachable, and the
+      // usable target comes back 21px wide — short of the 24 this rule exists
+      // to reach. `right: 0` spends all 6 extra px on the header cell instead,
+      // which is a sort target hundreds of px wide.
+      const after = afterRule(fs.readFileSync(GRID_CSS, "utf8"));
+      expect(after).toMatch(/right:\s*0/);
+      // A `left` here would either re-centre the box or stretch it back over
+      // the strip; `right: 0` plus a width has to be the whole horizontal
+      // constraint.
+      expect(after, "funnel hit area must not be left-anchored").not.toMatch(
+        /(^|[;{\s])left:/,
+      );
+    });
+
+    test("the hover-reveal rules still address the funnel, not the hit area", () => {
+      // The funnel is invisible until the header row is hovered, the button
+      // takes focus, or a filter is active. The hit area rides on the button's
+      // own opacity, so those three rules must keep targeting the button.
+      const css = fs.readFileSync(GRID_CSS, "utf8");
+      expect(css).toMatch(
+        /:where\(\[data-pretable-header-row\]:hover \[data-pretable-filter-funnel\]\)/,
+      );
+      expect(css).toMatch(
+        /:where\(\[data-pretable-filter-funnel\]:focus-visible\)/,
+      );
+      expect(css).toMatch(
+        /:where\(\[data-pretable-filter-funnel\]\[data-pretable-filter-active="true"\]\)/,
+      );
+      expect(funnelRule(css)).toMatch(/opacity:\s*0/);
+    });
+  });
+
   test("every grid.css rule selector is wrapped in :where()", () => {
     const css = fs.readFileSync(GRID_CSS, "utf8");
     const noComments = css.replace(/\/\*[\s\S]*?\*\//g, "");
 
@@ -760,6 +760,49 @@
     cursor: pointer;
     opacity: 0;
     transition: opacity 0.1s ease;
+    /* Containing block for the ::after hit area below. */
+    position: relative;
+  }
+  /* WCAG 2.5.8 (Target Size, Minimum) asks for 24x24 CSS px. The funnel drew
+     an 18x18 tap target on every filterable column, so a phone got an 18px
+     target on every header.
+     The GLYPH stays 18x18 — the header is dense by design and a bigger icon
+     would change the look of every grid — and the missing 6px is bought with a
+     transparent ::after. A pseudo-element rather than padding + negative
+     margin: padding would grow the button's own border box, and the button is
+     the thing the hover background and the focus ring are drawn on, so an
+     18px glyph would suddenly wear a 24px hover chip. Out-of-flow also means
+     the header box cannot change size — @pretable/ui's `readDensity` and the
+     surface's virtualisation geometry both measure header/row height in JS,
+     and a change there would desynchronise painted from measured layout.
+     `right: 0`, NOT centred: the funnel's right edge is flush against the 4px
+     resize strip (the slots are parked at left:-22 and left:-4 off the
+     column's trailing edge — see pretable-surface.tsx). The strip is not at
+     risk — it carries z-index: 2 inside the overlay anchor's stacking context,
+     so it hit-tests above the funnel either way, and a centred box measurably
+     steals none of it. What a centred box costs is the FUNNEL: 3 of its 24px
+     land under the strip where nothing can ever tap them, and the reachable
+     target measures 21px — still short of the 24 this rule exists to reach.
+     (iPhone 13, hit-test sweep: right:0 → 24 wide, left:-3px → 21 wide.)
+     Growing leftward spends all 6px on the header cell instead, which is a
+     sort target hundreds of px wide.
+     Height is a flat 24px, not 100%: the tightest shipped header is Excel's
+     compact tier at exactly 24px, so 24 fits every tier without spilling into
+     the first data row.
+     KNOWN GAP: with the drag-to-group panel on, @pretable/react also renders an
+     18px column-menu button immediately left of the funnel, and it paints above
+     the funnel's hit area (later in tree order, same stacking context). The
+     funnel then measures 24 tall but only ~17 wide. Three controls in the 40px
+     the overlay anchor allots cannot each have 24; closing that one needs the
+     slot offsets in pretable-surface.tsx to move, not another CSS rule. */
+  :where([data-pretable-filter-funnel])::after {
+    content: "";
+    position: absolute;
+    top: 50%;
+    right: 0;
+    width: 24px;
+    height: 24px;
+    transform: translateY(-50%);
   }
   /* Reveal funnels on header-row hover, on funnel keyboard focus, or when a
      filter is active. The header row is a flat list of sibling header cells,