Keyboard Covers Submit Button on Small Screens? Test This Way in 2026

The Quick Fix: Scroll Into View Before You Tap Submit

When a mobile keyboard slides up and hides the submit button, the fastest solution is to ensure the button scrolls into view automatically. This is not just a visual tweak; it directly impacts conversion rates because users cannot complete forms if they cannot tap the final action. The most reliable method involves adding scroll-margin-bottom or padding-bottom to the form container so the button sits above the keyboard fold. At NetSixtySix Mobile QA, we run automated Playwright scripts that simulate keyboard input on iOS and Android emulators, then assert whether the submit button remains tappable throughout the interaction.

Start by identifying your form’s critical elements: the last input field, the submit button, and any sticky footer or fixed element. Next, trigger the keyboard event programmatically or manually on a real device. Finally, verify that the button is visible and clickable without requiring the user to manually scroll. This three-step process catches the majority of keyboard-related blockers before they reach production.

To put this into practice, open your form on a smartphone browser and navigate to the final input field. On iOS Safari, tap the email or password field and observe how the keyboard animates upward. On Android Chrome, tap the same field and watch whether the viewport resizes or remains static. If the submit button disappears beneath the keyboard, you have confirmed the issue. The fix begins with a simple CSS rule applied to the submit button itself:

This ensures that when the button is scrolled into view—whether by JavaScript or by the browser’s native auto-scroll behavior—it stops at least 120 pixels above the bottom of the viewport, safely above most keyboard heights. You can also add a small amount of padding-bottom to the form wrapper to create additional breathing room.

Why the Keyboard Overlap Problem Persists in 2026

Despite improvements in mobile browser handling, virtual keyboards still vary widely in height and behavior across devices. A 2024 Samsung Galaxy keyboard might cover 30% of the viewport, while a 2026 Pixel Fold keyboard shifts differently due to split-layout designs. Additionally, Progressive Web Apps (PWAs) and hybrid mobile applications often render forms inside webviews that do not automatically resize the viewport when the keyboard appears. This creates a silent conversion killer: the form looks fine during desktop testing but fails on real devices.

The root cause lies in how different platforms handle the visual viewport. On iOS, the keyboard does not always trigger a resize event on the visual viewport, meaning JavaScript listeners that rely on window.innerHeight may return incorrect values. On Android, the behavior depends on the browser version and whether the app is running in standalone mode (as is common with PWAs). Even within the same operating system, keyboard height can change based on user preferences such as emoji panels, voice input buttons, or one-handed mode.

This inconsistency makes manual testing essential. Automated tools can simulate keyboard appearance, but they cannot fully replicate the nuances of every device and OS combination. For example, a user on a Samsung Galaxy S24 Ultra may have a keyboard that includes a built-in GIF search bar, which increases the keyboard height by an additional 60 pixels compared to the default layout. Testing on real devices—or using device farms that offer real hardware—ensures these edge cases are caught before they impact users.

Common Scenarios That Trigger the Issue

• Forms placed inside modals or bottom sheets that do not adjust their position when the keyboard opens.
• Fixed or absolute-positioned submit buttons that remain locked to the bottom of the viewport.
• Long forms with multiple steps where the final button is buried below the keyboard fold.
• Autocomplete dropdowns or suggestion bars that expand upward and push content out of view.
• Single-page applications (SPAs) that dynamically load form fields without recalculating scroll positions.
• Forms embedded in iframes or shadow DOMs where viewport resize events do not propagate correctly.

Step-by-Step Testing Process for Keyboard Coverage

Follow this practical checklist to validate form accessibility when the keyboard is active:

1. Set up device emulation: Use Chrome DevTools, Safari Responsive Design Mode, or a real device cloud to simulate popular small-screen devices at 375px or 390px width.
2. Focus the last input field: Click or tap into the final text, email, or password field to trigger the virtual keyboard.
3. Inspect button visibility: Check whether the submit button is fully visible and not obscured by the keyboard or any fixed elements.
4. Attempt interaction: Try to tap the submit button without scrolling. If it requires manual scrolling, the layout needs adjustment.
5. Test across keyboards: Switch between default, compact, and split keyboard layouts if available, especially on foldable devices.
6. Validate with automation: Write a Playwright test that focuses the input, waits for the keyboard, and asserts the button’s bounding box is within the viewport.

Let’s walk through this process using a real-world example. Imagine you are testing a checkout form on an e-commerce site. The form includes fields for name, address, phone number, and payment details, followed by a “Place Order” button at the bottom. Here’s how to test it:

1. Open the site on a mobile browser (e.g., Safari on iPhone or Chrome on Android).
2. Navigate to the checkout page and scroll down to the form.
3. Tap on the last input field (e.g., the CVV field for credit card entry).
4. Observe whether the keyboard covers the “Place Order” button.
5. If the button is hidden, try to tap it. If you cannot, the layout fails the test.
6. Repeat the process using different keyboard types (e.g., numeric keypad for phone fields).

For teams using device clouds like BrowserStack or Sauce Labs, you can automate this process across multiple devices simultaneously. This allows you to catch issues on devices you may not have physical access to, such as older iPhone models or specific Android variants.

Automation Example Using Playwright

Here is a simplified Playwright snippet to detect keyboard-induced button occlusion:

This script focuses the last input, waits briefly for the keyboard to render, then checks that the submit button’s bottom edge is above the viewport boundary. Extend this with device-specific configurations for iOS and Android emulators.

To make this test more robust, consider adding the following enhancements:

• Use page.waitForFunction() instead of a fixed timeout to wait until the keyboard is fully visible.
• Check for the presence of a keyboard element in the DOM (if available in the emulator).
• Run the test on multiple viewport sizes to ensure consistency across devices.
• Add screenshots on failure to help developers debug the issue visually.

Layout Techniques to Prevent Button Obscuration

Apply these proven CSS strategies to keep your submit button accessible:

• Scroll-margin-bottom: Add a scroll-margin-bottom of at least 100px to the submit button so it stops above the keyboard when scrolled into view.
• Dynamic padding: Use JavaScript to detect the visual viewport height and apply matching bottom padding to the form container.
• Sticky button placement: Position the submit button as sticky within the form flow rather than fixed to the viewport bottom.
• Viewport units caution: Avoid using vh units for full-height layouts on mobile, as they do not account for the keyboard or URL bar.

Let’s explore each technique in more detail:

Scroll-margin-bottom

This is the simplest and most widely supported solution. By adding scroll-margin-bottom to your submit button, you ensure that when the browser scrolls the button into view (either automatically or via JavaScript), it stops a set distance above the bottom of the viewport. For example:

This works well for most cases, but you should test it across different devices to ensure the margin is sufficient.

Dynamic Padding with JavaScript

For more control, you can use JavaScript to detect the current viewport height and adjust the form’s padding accordingly. Here’s a basic example:

This approach dynamically calculates the difference between the layout viewport and the visual viewport, then applies padding to compensate. It’s particularly useful for PWAs and hybrid apps.

Sticky Button Placement

Instead of fixing the button to the bottom of the screen, make it sticky within the form flow. This allows the button to scroll naturally with the content while remaining visible at the bottom of the form when needed:

This method avoids conflicts with the keyboard and ensures the button is always accessible.

Validation and Retesting After Fixes

Once you implement a solution, retest using the same scenarios. Confirm that the button remains tappable on both light and dark mode, with and without browser zoom, and across different operating system versions. Document the fix in your QA regression suite so future form updates do not reintroduce the issue. Regular audits using tools like Lighthouse or custom Playwright suites will flag regressions early in the development cycle.

When retesting, consider the following additional scenarios:

• Test with browser zoom enabled (users often zoom in to read small text).
• Test in both portrait and landscape orientations.
• Test with accessibility features enabled, such as larger text or high contrast mode.
• Test with third-party keyboards installed (e.g., Gboard, SwiftKey).
• Test with split-screen or multi-window modes on Android.

Document each test case in your QA tracking system, including the device, OS version, browser, and expected outcome. This creates a reusable test plan that can be applied to future forms and updates.

Conclusion: Make Every Tap Count

Mobile form completion is a series of micro-interactions, and the submit button is the final gatekeeper. By proactively testing for keyboard coverage and implementing responsive scroll behavior, you eliminate one of the most frustrating abandonment points in the mobile journey. Whether you are a founder validating checkout flows or a marketer auditing lead generation forms, this simple check can recover significant conversion value.

Remember, the goal is not just to make the button visible, but to make it easily tappable without requiring extra effort from the user. Every additional scroll or tap increases friction, and friction leads to abandonment. By investing time in thorough mobile QA—both manual and automated—you ensure that your forms are not just functional, but frictionless. At NetSixtySix Mobile QA, we believe that attention to these small details is what separates good mobile experiences from great ones.

Related resources

Keep testing your pages with these NetSixtySix resources:

• Why Your Fixed Footer Can Hide the Consent Banner on Small Screens (And How to Fix It in 2026)
• Run a free mobile layout QA audit
• More mobile QA and layout testing guides