44px Buttons, 16px Fonts: Standard Numbers in Mobile Chat

Late yesterday afternoon, I opened the AI chat panel I have been building on my phone while waiting for a coffee. The moment I tapped the text field, the screen zoomed itself into the textarea uninvited. My thumb missed the stop button twice because it was simply too small. A design I considered tidy on desktop fell apart the second it moved to a five-inch screen.

My first guess was trivial: shrink the padding, tidy the margins, done. The three complaints turned out to have three unrelated roots, and the answers were not about aesthetics at all. They were numbers somebody else standardized long before this pass.

The send button and the 44px threshold

The send and stop buttons started at 32 pixels. Fine to look at on desktop, hard to hit with an imprecise finger, worse one-handed. The WCAG 2.5.5 Target Size report settles the debate: targets for pointer input need at least 44×44 CSS pixels, because touch is a coarse input mechanism that hides the exact point being touched [1]. In this commit the buttons grow to 44px on small screens, then step back down to 36px from the tablet breakpoint up:

className="flex size-11 shrink-0 items-center justify-center
  rounded-full bg-[#25E2A8] text-black sm:size-9"

That 44 is not magic. In Tailwind, sizing utilities come from the spacing scale: h-<number> equals calc(var(--spacing) * n) [4], so 11 times 0.25rem is 2.75rem, exactly 44px. Platform guidelines converge on the same threshold; I anchored on WCAG so one number holds across devices.

16px fonts and the forced iOS zoom

The second complaint was sneakier: every time the textarea got focus on the iPhone, Safari blew up the viewport and never restored it. The cause is documented in a CSS-Tricks article: if an input's font-size is 16px or larger, Safari focuses normally; at 15px or below, the viewport zooms in [2]. Safari assumes your text is too small to read and "helps" by enlarging everything.

The fix in ChatInputBar: the textarea gets a 40px minimum height and a 16px font on mobile, stepping down to the small size from the tablet breakpoint up. Desktop stays compact, mobile stops zooming.

A 65vh transcript without scroll chaining

Third complaint: scrolling a long answer kept sliding into scrolling the whole page, and pull-to-refresh kept firing. The transcript is now wrapped in a 65vh cap below the xl breakpoint plus overscroll containment:

<div ref={scrollRef} className="max-h-[65vh] min-h-0 flex-1
  overflow-y-auto overscroll-contain px-4 py-4 xl:max-h-none"
  aria-live="polite">

The MDN documentation explains that overscroll-behavior: contain stops scroll chaining into neighboring scroll areas and disables the vertical pull-to-refresh gesture [3]. Scrolling now stops at the transcript boundary, and the input bar stays put. The rest of this pass: the history box collapses under the content below the lg breakpoint under a "Conversation history" label, and stays a left column from lg up.

Three small numbers, 44px, 16px, and 65vh, are now the contract of my chat panel. For another layout decision in the same shell, I wrote up keeping a full-height chat panel below a fixed navbar.

Sources

• [1] W3C WAI: Understanding SC 2.5.5 Target Size, accessed 2026-09-08
• [2] CSS-Tricks: 16px or Larger Text Prevents iOS Form Zoom, accessed 2026-09-08
• [3] MDN: overscroll-behavior, accessed 2026-09-08
• [4] Tailwind CSS Docs: height, accessed 2026-09-08