Preventing keyboards from hiding important checkout fields

An on-screen keyboard can cover a focused checkout field, its error message or the payment action. Start with the browser’s normal viewport and scrolling behaviour; for more complex layouts, use keyboard-aware viewport information to keep the active control visible.

Walk through focus changes

Start at the first field and move through checkout using the keyboard’s Next action. Check that the focused field, its label and value remain visible, and scroll the page enough to show any error message.

Repeat with a long validation message, enlarged text and a small screen. Sticky headers, chat buttons and coupon banners can use space the form needs; check that none covers the focused control or payment action.

Browser behaviour differs. Many mobile browsers adjust the viewport and scroll to focused inputs; iOS Safari can behave differently, with the visual viewport changing while the layout viewport does not resize. Safari on iOS 13 added support for the Visual Viewport API, while Android browsers may move fixed elements above the keyboard.

W3C WCAG 2.2 Success Criterion 2.4.11, Focus Not Obscured (Minimum), Level AA, requires a focused component not to be entirely hidden by author-created content; partial obscuring is permitted. For best visibility, keep the whole focused control clear. This criterion alone does not establish whether checkout remains workable with the on-screen keyboard open.

Browser Behaviour Differences: iOS Safari vs Android Chrome

WCAG 2.2 Success Criterion: Focus Not Obscured (Minimum)

Fix the cause

First, let the browser handle the keyboard and focused-field scrolling where possible. Reduce unnecessary fixed elements during checkout, allow the page to scroll around the focused field, and use scroll padding to keep sticky headers, footers and notices from overlapping focused controls.

For layouts that need to react to viewport changes, the Visual Viewport API exposes resize and scroll events on window.visualViewport. Respond to those changes by checking the focused field against the visible viewport and adjusting the page so the field and any error remain visible.

The VirtualKeyboard API gives more control, but it has limited availability and requires a secure context (HTTPS). Setting navigator.virtualKeyboard.overlaysContent = true opts out of the browser’s automatic viewport adjustment, so use it only when the layout adapts to the keyboard using its boundingRect or the keyboard-inset-* CSS environment variables.

Keep the payment action in the scrollable page rather than a fixed footer that sits over fields. Check that buyers can bring it into view with the keyboard open, including after a validation message appears.

When an address suggestion opens, check that it does not cover the selection or next control. Avoid forcing the buyer to close the keyboard just to read every instruction.

Retest the full input-to-payment sequence with the keyboard open in iOS Safari and Android Chrome after layout changes. A field can be visible in isolation but disappear when a validation banner appears.

Best Practice Workflow to Prevent Keyboard Obscuration