Does the iOS keyboard cover your Submit button? Check it with an AI agent
Disclosure: I make thumbs, one of the options below. I'll say where each option fits, including where mine doesn't.
The classic mobile-web bug: you tap the last field of a form, the keyboard slides up, and the Submit button is under it. On a desktop browser's device mode it never happens, because there's no on-screen keyboard. This guide is about that one check: how to get an AI agent to do it in Safari on iOS, and how to read the result.
If you want the wider picture of testing a web app with an agent, start with how to test your web app on an iPhone with an AI agent. This page goes deeper on the keyboard.
Why the keyboard covers the button
Mobile browsers have two viewports: the layout viewport, where the page is laid out, and the visual viewport, what is actually visible. MDN describes the on-screen keyboard as something that can shrink the visual viewport without affecting the layout viewport (VisualViewport on MDN). On iOS, the CSS Working Group's notes say the same: the visual viewport shrinks, the fixed-position viewport keeps its size, so elements fixed to the bottom can end up out of view (csswg-drafts #7475).
That means these are the usual suspects:
- A fixed bottom bar with the Submit button: it stays where the layout puts it, which is behind the keyboard.
- A full-height layout (
100vhor a similar unit) with the button at its bottom edge. - A form near the bottom of a short page, where Safari has to scroll the page to show the focused field and the button ends up below the fold.
Chrome on Android uses the same two-viewport model by default now, and offers an interactive-widget viewport option to change it. As of Bram van Damme's note of 11 September 2026, WebKit has it implemented but it hasn't shipped in Safari, so you can't rely on it for iOS (bram.us). Check current support before you build on it.
The second bug: zoom on focus
Safari on iOS zooms the page in when you focus a text field whose font size is under 16px. The layout jumps and the button can leave the screen even before the keyboard matters. The common fix is a field font size of at least 16px; blocking zoom with maximum-scale or user-scalable=no is not a good fix because it takes zoom away from people who need it (CSS-Tricks).
How to ask an agent to check it
With a phone behind your MCP client (thumbs early access is the iOS Simulator; see the limits below), a single prompt does most of it:
Open https://your-site.com/signup in Safari on the iPhone.
Take a screenshot before touching anything.
Then tap each form field in order, one at a time. After each tap,
take a screenshot and tell me:
1. Is the on-screen keyboard showing?
2. Did the page zoom in?
3. Is the Submit button fully visible above the keyboard?
4. If not, can you reach it by scrolling the page, or does it stay hidden?
Don't submit anything. Don't use real personal data.
A few details make the result trustworthy:
- Make sure the keyboard really appeared. If a screenshot after tapping a field shows no keyboard, the check proves nothing. Ask the agent to say so rather than report "button visible".
- Judge from the screenshot, not only the list of tappable elements. A button can be in the page's element list and still be hidden behind the keyboard. Ask the agent to describe what it sees in the picture.
- Check the last field, not only the first. The last field is the one closest to the button, and the one that gets the bug.
- Check scrolling with the keyboard open. "Hidden but reachable by scrolling" is a very different bug from "hidden and unreachable".
- Don't submit. You're checking layout, not the back end. Use a staging site or throwaway test data.
Reading the answer
| What the agent reports | What it usually means | Where to look |
|---|---|---|
| Submit hidden, can't scroll to it | Fixed bottom bar, or a full-height container with no scrolling | Move the button into the normal page flow, or position it using the visual viewport |
| Submit hidden until you scroll | The button is below the focused field | Add spacing under the form so the page can scroll far enough |
| Page zoomed in after the tap | Field text is under 16px | Set field font size to at least 16px |
| Everything visible | Fine on this phone, this keyboard and this iOS version | Re-run on another screen size if you can |
Fixes that tend to work
- Keep the Submit button inside the form, in normal flow, rather than fixed to the bottom edge.
- If a fixed bar is essential, compute the keyboard's height from
window.visualViewport(the difference betweenwindow.innerHeightand the visual viewport's height and offset) and lift the bar by that amount. Listen to both itsresizeandscrollevents. - Give the end of the page bottom padding so the last field can scroll above the keyboard.
- Set text inputs to 16px or larger.
After each fix, run the same prompt again. It's a quick regression check you can repeat.
Limits
- thumbs' early access is the iOS Simulator, not a real iPhone. It is a good guide to Safari's layout behaviour but not a guarantee of how a real device with its own keyboard settings, third-party keyboards or an iOS version you didn't test will behave. A real iPhone of your own is planned; it isn't available yet and has no date or price.
- Early access is shared between testers and has Safari and Apple's built-in apps. It can't install your own app.
- Don't sign in to personal accounts on a shared Simulator.
- An agent's judgement of a screenshot isn't a proof. For a release-critical form, look at the screenshots yourself.
FAQ
Why does the iOS keyboard cover my Submit button? On iOS the on-screen keyboard shrinks the visual viewport without resizing the layout viewport, so elements fixed to the bottom of the layout, or buttons near the bottom of a short page, can end up behind it.
Can an AI agent check this for me? Yes, if it can open your page in Safari on an iPhone or the iOS Simulator, tap fields and take screenshots. Ask it to screenshot after each tap, to confirm the keyboard is showing and to say whether Submit is visible.
Why does the page zoom when I tap a field? Safari on iOS zooms in when a text field's font size is below 16px. Setting fields to 16px or larger avoids it without disabling pinch zoom.
Does thumbs run this on a real iPhone? Not yet. Early access runs on the iOS Simulator, shared between testers. A real iPhone of your own is planned, with no date or price.
Keep reading
- How to test your web app on an iPhone with an AI agent: the wider walkthrough, options and prompts.
- A mobile-web QA checklist for an AI agent: the keyboard check plus nine more, in one list.
- iOS Simulator MCP: local or remote, and which to use: if you have a Mac and prefer a local setup.