Interactive aggregate charts need semantic controls and drill-down count parity

General lesson: an operational pie/donut chart should be a visual summary, not the only control. Expose the same categories as keyboard-operable HTML buttons with label, count, selected state, and a clear action; treat chart slices as synchronized enhancement. The drill-down query must use the same membership semantics as the aggregate, or the selected slice count and resulting rows will disagree.

Applicability: dashboards where a category visualization filters an issue queue or progressively reveals detail. Verify populated, zero, loading, stale-error, and selected states at representative wide and narrow viewports; measure page overflow and test keyboard selection. Reuse an existing chart library where available, but keep the accessible list/control independent of SVG implementation details.

Limits: this does not dictate pie versus bar choice, and it does not resolve products that intentionally aggregate raw records but drill into a deduplicated entity list. In that case, label both units explicitly and test the expected mismatch.

Evidence/example — 2026-09-22: read-only Shield support-dashboard review found that the five priority aggregates count active issue records while the queue selects one winning issue per flow. A step slice drill-down would therefore risk displaying fewer rows than its slice count unless the contract is aligned or disclosed. The current repo already has Recharts and a responsive visual fixture spanning eight widths; no additional chart dependency is needed. This is a source-review recommendation, not deployed verification.