When users enter a shipping address and the keyboard pops up, the submit button can't be tapped: should you change the page structure or the input component first?

Conclusion first: keyboard occlusion is mostly the page not leaving visible space

Conclusion first: when a user fills out a form in an app and the keyboard covers an input field or submit button, it is usually not a keyboard, phone, or OS version failure; it is the page not leaving space for the visible area the keyboard takes up. Based on 2026 mobile delivery experience, there are three common patterns: the focused input field is covered by the keyboard, the fixed bottom button is covered, and the page is forcibly pushed up but does not return to its original position after the keyboard is dismissed.

These three patterns require very different fixes. The first usually only needs the input area to be scrollable; the second depends on whether the bottom button is sticky-positioned or an element in normal document flow; the third is often caused by hard-changing padding without restoring it. Mixing them together commonly means fixing one page and breaking several others, and two or three rounds of rework are not unusual.

• Covered: the focused input field falls outside the area above the keyboard, so users cannot see what they are typing.
• Pushed off: the entire page is forcibly pushed up, the top navigation or title runs off screen, and it does not restore after the keyboard is dismissed.
• Button not tappable: the sticky submit button is pressed down by the keyboard; it is still visible but cannot actually be tapped.

Here is a delivery-site experience. In a 2026 multi-page form project, the constraints were a three-week schedule, Android and iOS sharing one page structure, a sticky bottom submit button, and several existing pages built in different development phases. The approach was not to swap the input component first, but to go through pages one by one with a four-layer checklist: make the main body a scrollable container, move the sticky button up according to the actual keyboard height, and restore the scroll position after the keyboard is dismissed. As a result, most form pages were closed out in 1–2 working days; however, one after-sales notes page was nested inside a fixed-height outer layer, its scrolling was clipped, and rebuilding the container took nearly 1 extra working day. In this project, the experience range for similar investigation and changes commonly fell within 1–3 working days, and when there were many form pages, total schedule commonly increased by 3%–8%.

Android and iPhone behave differently: what order should you use to diagnose?

iOS and Android have different default keyboard strategies. iOS relies more on safe areas and the system's automatic avoidance for input focus; in many cases it can automatically scroll to the focused position inside a scrollable container. Android is more strongly related to the page keyboard mode configuration and whether the page is scrollable, so the same layout commonly behaves inconsistently on the two platforms. Therefore, “iPhone works, Android is covered” is usually not because Android is worse, but because the page was not designed with a scrollable structure.

For the diagnostic order, start from the container to the elements, and from the whole to the parts; avoid changing a single input field's style right away. Keyboard avoidance is fundamentally a page-level problem. Adjusting only the input component often looks fine only on the current device model and current keyboard height, then recurs on another device.

• First, check the container: whether the page body is scrollable and whether the visible area shrinks when the keyboard pops up.
• Second, check focus: whether the input field automatically scrolls into the visible area after receiving focus, or stays where it is.
• Third, check the sticky bottom element: whether the submit button is sticky-positioned or in normal document flow, which determines whether to move it up or temporarily hide it.
• Fourth, check the keyboard itself: system keyboards, third-party input methods, and emoji panels have different heights, and whether the layout follows those changes.

Checking across four layers is more stable than only changing the input field

Turning the four steps above into a reusable checklist has the advantage that when someone else takes over or the same approach is reused on another page, it still lines up. It is ordered from the largest impact scope to the smallest: solve structural problems first, then handle detail offsets, reducing the rework that comes from “fix one place, break two others.” For multi-platform projects, this order also lets Android and iOS share the same acceptance checklist.

1. Structure layer: confirm the page body is a scrollable area and the scroll range includes all input fields; note that the scroll container must not be nested inside a fixed-height outer layer, or scrolling will be clipped.
2. Focus layer: when an input field is focused, actively scroll it to the middle of the visible area rather than to the edge; note that multiline text box height changes, so the position needs to be recalculated.
3. Sticky bottom layer: when the keyboard pops up, the bottom button should either move up or be temporarily hidden; both are acceptable, but it must not do neither; note that the upward movement distance should follow the actual keyboard height.
4. Cleanup layer: after the keyboard is dismissed, restore the scroll position and padding; note that when switching input fields quickly in succession, do not stack multiple offsets.

The criteria for whether each layer is done are direct: for the structure layer, can any input field scroll to the middle of the screen; for the focus layer, is the content always visible when switching input fields; for the sticky bottom layer, can the button be tapped both when the keyboard is open and after it is dismissed; for the cleanup layer, does the layout have no residual offset after leaving and re-entering the page.

Comparing two implementation paths: where cost and maintenance differ

There are two common approaches in projects: one is to rely as much as possible on the system's default avoidance and adjust the page structure to be scrollable; the other is to listen to keyboard height yourself and dynamically adjust padding or button position. The former has smaller changes but depends on layout standards; the latter has stronger controllability but more maintenance points. Based on 2026 project delivery experience, the schedule difference between the two paths on typical form pages usually falls in the 1–3 working day range, depending on the number of form pages and shared components.

• Option A, structure first: make the page body a scrollable container, and let the sticky bottom button give way according to keyboard height. Suitable for apps with many form pages and a unified structure. Based on 2026 project delivery experience, focused adjustment of typical form pages commonly takes 1–3 working days; the more unified the upfront layout standards, the lower the reuse cost for newly added pages later.
• Option B, dynamic padding: listen to keyboard height and adjust bottom padding or button position in real time. Suitable for pages with frequent input, such as chat, comments, and customer service input. The common cost is an extra piece of state logic; when switching input fields quickly, you must prevent jitter, and test regression increases by about half a day to one day.
• Hybrid approach: use structure first for the main body, and dynamic handling separately for high-frequency input pages. Most multi-page apps end up here. Compared with using Option A alone, there are slightly more maintenance points, but chat-like pages are usually more stable.

The comparable points you can verify are not whether one device looks normal, but three things: whether adding a new form page requires another round of changes, whether the layout follows when keyboard height changes, and whether regression testing must go through each input method type one by one. Putting these three points into the acceptance checklist is more effective than arguing about which approach to use.

Applicable boundaries: which pages should be handled, and which can be left alone for now

Keyboard avoidance is suitable for almost all pages with text input, especially critical paths such as registration, ordering, address, after-sales notes, and search. Where it does not apply should also be clear: pure display pages, or cases with only a single search box and a page that is not long, are usually covered by default system behavior and do not need a dedicated keyboard-listening solution.

Another boundary: if a page heavily uses custom-drawn controls or a full-screen immersive layout, the system's default avoidance may no longer take effect. In that case, evaluate the investment based on the actual project situation, and do not add the same handling to every page just for consistency. A simple criterion for whether it is worth doing is: does the user need to see the input content and complete submission while the keyboard is open?

FAQ

Can swapping the input component solve keyboard occlusion?

Mostly no. Occlusion is usually a page structure and visible area problem. Swapping the component only works if the component itself handles scrolling or avoidance; otherwise the problem remains exactly where it was.

Android test devices work, but users' phones are covered—is it a phone brand problem?

Usually not. The differences mostly come from input method height, OS version, and page configuration; even different models from the same brand can differ. We recommend grouping regression by input method type.

For a fixed bottom submit button, should it hide or move up when the keyboard pops up?

Both are acceptable, depending on form length. For short forms, moving it up to keep it tappable is recommended; for long forms, temporarily hiding it is fine, but it needs to be restored after the keyboard is dismissed.

If keyboard avoidance is not done well, can it also affect page scroll position?

Yes. Forcibly pushing the page up without restoring it can leave the page stuck midway after the keyboard is dismissed, requiring the user to scroll back manually; this is a cleanup-layer omission.

Third-party input methods have different heights—do you need to adapt each one separately?

No need to adapt each one individually. Dynamically calculate based on the actual keyboard height; the key point is not to hard-code height values. A common practice is to take the actual height and leave a small margin.

Action recommendation: first go through existing form pages with the four layers—structure, focus, sticky bottom, and cleanup—and put focus visibility, button tappability, and cleanup restoration into the acceptance checklist. The applicable boundary is critical-path pages with text input; pure display pages and single-search-box pages can be left alone for now. If a delivery team takes it on, define the sticky bottom element and scroll structure during the prototype stage to avoid concentrated rework after launch.