[a11y][mobile] 40 interactive elements per screen are under 40px — 12px checkboxes on Behaviour, 16px Remove on Repo, 24px message actions

[serge-ivo]

Measured, on the live console, in WebKit at phone widths

A sweep of 21 routes at 320px and 390px counted every interactive element inside <main> whose
rendered box is under 40px in either axis. Apple HIG says 44×44pt; Material says 48×48dp. 40 is
the lenient floor, and these are the counts against it:

route	targets < 40px	smallest examples
Assistant / Board	40	24×24 Copy message · 24×24 Delete this turn · 30px Load earlier
Terminals	39	26px agent links
Settings (instance)	30	28px Save · 26px Refresh
Preferences	30	30px Reconnect / Disconnect
Browse	28	32px Subscribe · 34px Open →
Behaviour	27	12×12 checkboxes
Knowledge	10	38px sub-tabs
Data	9	24px Records / Runs
Repo	5	16px Re-index · 16px Remove
tmux / Terminal	7	32×22 view switch

Identical at both widths — this is not a narrow-viewport artefact, it is the sizing everywhere.

The three that are not borderline

1. 12×12px checkboxes on the Behaviour tab (BehaviourTab.tsx:379 — a bare
   <input type="checkbox" className="mt-1">, so it renders at the UA default). That is a quarter
   of the recommended area, on the tab whose entire job is toggling how an agent talks. Everything
   else on that tab is a slider or a select; these are the only controls, and they are the smallest
   thing on the page.
2. 16px-tall buttons on the Repo tab — Re-index and Remove. Remove deletes an indexed
   repository. A destructive action at 16px, next to a 16px non-destructive one, on a touch
   surface, is a mis-tap waiting to happen.
3. 24×24px message actions (Copy / Delete this turn / speaker) on every chat bubble. These are
   also the controls a hands-free user reaches for when voice has gone wrong — the moment when
   precision is lowest.

Why this is not simply "make the buttons bigger"

The controls are hand-authored, one at a time — #366 measured 291 distinct control class strings in
14 shapes, with no Button primitive anywhere. So "40px minimum" cannot be applied as one decision;
today it is 291 edits, and the next control added starts the count again.

That makes this a strong argument for #366's component layer landing first: a Button with
sm/md sizes whose smallest variant still clears 40px of hit area (padding, not necessarily
visual size — an icon button can look 24px and be tappable at 44 via padding or a ::before
expansion) fixes the whole class in one place, and the next 291 sites inherit it.

Suggested order: #367 (the system, shipped) → #366 (the primitives, with the tap-target floor
baked into them) → this ticket becomes "adopt the primitive", not "resize 291 things".

What to decide

• The floor. 44×44 (Apple) is the safer number; 40 is what this audit measured against. Pick one
  and put it in DESIGN-SYSTEM.md so it is checkable — that document is descriptive today and this
  would be its first prescriptive rule, which is worth doing deliberately.
• Hit area vs visual size. An icon button does not have to look 44px. Deciding this once is
  what stops the fix from making the console look like a tablet app.
• Whether to guard it. The e2e mobile sweep already visits every route; a "no interactive element
  under Npx" assertion is the same shape as the overflow guard and would hold the line.

Measured 2026-08-08 against production (post-#384), WebKit, 320px and 390px, signed in.
Files: store/console/src/tabs/BehaviourTab.tsx:379, store/console/src/tabs/RepoTab.tsx,
store/console/src/pages/InstanceDetail.tsx:54, and ~291 other control sites (#366).

[serge-ivo]

Delivered in 2f5ec29 (refactor(console,admin): a floor under the type scale and a floor under the touch targets (#390, #389)) earlier today, and live in production. Re-verified independently before closing.

The floor was decided, and it is 24, not 44. DESIGN-SYSTEM.md §3 now carries it as the second of exactly two prescriptive rules in that document: every control clears 24×24 CSS px in both axes — WCAG 2.5.8 Target Size (Minimum), Level AA. A published number rather than a house preference, which is what makes it assertable. This ticket offered 40 or 44; both were rejected with the reason stated rather than quietly, because asserting 44 as a box would fail roughly forty controls per screen and the only route to green would be re-laying-out every dense row in the app under cover of an accessibility fix. 44 is met where it matters as reach, not as box size, and the commit says so wherever it used reach instead of size.

All three "not borderline" cases in the report are fixed, and the worst one was structural.

1. The 12×12 checkboxes on Behaviour — fixed in the base layer, not at the call site: input[type=checkbox|radio] are sized to 20px, and 24px below 640px, in both index.css files. They were the one control nothing sized because they are excluded from the form-control block (a width: 100% checkbox is a full-row box that pushes its label off-screen), and that exclusion is exactly why they slipped. One rule reaches all 22 checkbox/radio sites across the console and the operator portal, and the call-site w-3 h-3 / w-3.5 / w-4 h-4 overrides were deleted in the same pass — a utility beats @layer base, so leaving them would have pinned the old boxes while the rule read as if it applied. store/admin had a second bug underneath: its block did not exclude them at all, so a checkbox rendered at width: 100% with a !w-auto at one call site to undo it. That hack is gone.
2. The 16px Re-index / Remove on Repo — fixed by hand, because no table owns them. They were bare text with no padding, with the destructive one beside the two that are not. They are <Button size="sm"> now and Remove is variant="danger".
3. The 24×24 message actions — this is the honest one. Padding them to 44 would cover the message text or make every bubble taller, so @utility tap-target grows the pointer region to 44px vertically only. That restriction is the design, not a shortcut: a ::after overlay paints with its own element and siblings paint in DOM order, so expanding both to 44 wide would put Delete — the destructive one — over a third of Copy. That is a worse mis-tap than the one being fixed. The message-header replay button, which held an 11px icon and nothing else and was therefore 11×11, the smallest control in the app, got min-w-6 plus tap-target. No row is taller as a result.

BUTTON_SIZE also gained min-h-6 min-w-6 on all four steps, so the floor is a property of the table rather than of each call site.

Two guards, both confirmed red rather than assumed. I re-ran the red-checks myself:

• Unit — store/console/src/lib/control-classes.test.ts. Removing min-w-6 from BUTTON_SIZE.sm: × the button size ramp > sm clears WCAG 2.5.8's 24px minimum in both axes, and only that entry.
• E2E — mobile — every control clears the 24px minimum target (#389), 11 routes at 390px, in both engines (it carries the mobile — prefix playwright.config.ts makes load-bearing). Injecting a real 16px-high button into /console/notifications fails it by name: targets under 24px on /console/notifications: 110×16 <button> "Mark all read". "Effective target" is the union of the element's own box, its ::after overlay (which is how it sees tap-target) and, for an input, the enclosing <label> — because clicking that label is clicking the control, and an sr-only radio inside a segmented arm is 1×1 by design.

Live in production, checked just now against https://proagentstore.online/console/: input[type=checkbox],input[type=radio]{width:1.25rem;height:1.25rem;…} plus the 1.5rem mobile rule, .tap-target:after{…min-height:44px…}, and .min-h-6 / .min-w-6 are all in the shipped stylesheet.

This ticket proposed #367 → #366 → "adopt the primitive". That order was not needed for the three named defects — two were structural CSS and one is per-layout arithmetic no primitive can own — and #366's own report is that the count it moved was small. What is still outstanding is genuinely #366's.

Left open, tracked in DESIGN-SYSTEM.md §6:

• The button migration is 61 of 182 sites. AgentDetail, RunDetail, InstanceDetail, Profile, BoardTab, SettingsTab, StatsTab, TmuxTab, DataTab, TriggersSection, LoopPresetsSection, plus all of store/admin and agents/coder/web, do not get BUTTON_SIZE's floor until they migrate. The e2e guard holds them meanwhile, and only on the 11 routes it visits.
• The e2e guard's known hole, stated because it is real: it skips a <button> with no background, no border and no padding — a link wearing a button tag. RepoTab's destructive 16px Remove was exactly that shape, so this guard could not have caught the defect that motivated it.
• tap-target is on three controls, not a class of them. The Coder UI's icon controls, the Board's and the coding session's do not have it; widening it means measuring each dense row, because the overlap arithmetic is per-layout.
• Terminals and the Behaviour tab — two of the routes this audit found worst — are the two the guard sees least. Neither has a fixture rich enough to render its controls, so both were fixed by rule and neither is held by a test. A fixture for them is the cheapest next increment.

Closing: the floor is decided, documented, enforced in two places and live. The items above are follow-on work with somewhere to live.