Fix five issues found testing with a real paper menu

[AnirudhG15]

Stacked on #44 (which is stacked on #42), so the diff shows only this round's changes. Retargets to main automatically as those merge.

All five come from one session with a printed menu. Two of them turned out to be the same root cause.

1. Read menu was buried, and the camera started too wide

Read menu is the step that actually starts the reading, and it sat at the bottom of a long control stack. A VoiceOver user had to swipe past the preview, both zoom buttons, the shutter, the retake button and the upload button to reach it. It now sits directly under the heading. Its label carries the photo count, so it doubles as the running progress report.

Confirmed in the browser — reading order is now:

H1: Capture menu
button: Read menu (1). Read the menu from the photos you have taken
button: Auto capture on
[CAMERA PREVIEW]
LIVE REGION
...

The camera also opened at 0.5x. That was chosen to fit more of a page in frame, but people hold the phone well above the menu and at 0.5x the text lands too small to read. Now 0.8x, as a named DEFAULT_ZOOM with the reasoning beside it.

2 + 3. Messages cut each other off — which is why "turn the page" was never heard

"It'll start reading it, and then a new message will pop up so quickly it just interrupts it."
"It doesn't tell the person to switch the page."

These are one bug. A screen reader restarts the moment a live region's text changes, and the capture screen had two live regions updating independently — coaching every ~170ms, plus photo confirmations on top. "Photo taken, turn to the next page" lands exactly when coaching resumes, so it was the message most reliably destroyed.

Now one region, fed by lib/announcer.ts — a paced queue that gives each message time to be heard (estimated from word count, 1.3s–4.5s) before it can be replaced:

• Coaching is superseded freely. Only the newest is worth hearing; advice for a position the phone has already left is worse than silence.
• A photo confirmation is urgent. It preempts coaching immediately — by the time the shutter has fired the framing advice is already history — but is never cut off by anything else.

The confirmation now says plainly: "Photo 2 taken. Turn to the next page, or tap Read menu."

4. "Retake the picture" never said how

Three separate messages suggested retaking without naming any control, which isn't an instruction if you can't see the button. All now name it: "Tap Retake last photo". The button already existed — nothing pointed at it.

Worth noting: my first test checked one phrase, and let the upload path's own "Consider retaking it" straight through — which was the exact message on screen when I inspected the running app. The test now checks every string in the file that mentions retaking, which immediately turned up a third one on the analysis-failure path.

5. Auto zoom, and a beat to flip the page

Auto zoom was in fact working — but its "Adjusting zoom in/out" announcements were being stomped like everything else, so it read as doing nothing. Fixed by the pacing. The chance to flip the page is the confirmation above, which now holds the region for its full reading time before coaching resumes.

Tests

15 new. The pacing is clock-injected, so timing is verified without a browser or a screen reader. The reported case is asserted directly: a confirmation must hold the region for its full reading time while coaching floods in at the real frame rate.

Mutation-checked — removing the pacing fails 4 of them.

The rest are source-level guards on the screen: one live region, the turn-the-page wording, every retake message naming its button, Read menu rendered above the preview, and a floor on the starting zoom.

Full suite 204/205, tsc -b clean, vite build clean. The one failure (auth.test.ts) fails identically on main — jose is declared but not installed.

⚠️ Verified in the browser by feeding synthetic photos through the upload path, since getUserMedia is blocked in the sandbox. The layout, the single live region, the new wording and the pacing are all confirmed on the running app — but the auto-capture path itself still needs a real phone, and so does whether 0.8x is the right starting zoom. That one is worth trying on the actual menu; it's a one-line change if it wants to be 0.7 or 0.9.

🤖 Generated with Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
meetmymenu-ai	Ready	Preview	Aug 16, 2026 4:45pm
meetmymenu-ai-site	Ready	Preview	Aug 16, 2026 4:45pm